Keeping the "Spark" Alive
Ahh, remember when you came up with the idea for your game. A fresh, new game creator, eager to get your game underway. Maybe you know enough GML to code it right. You come up with a rough idea, sketch out a storyline, and begin to do heavy coding every day. Then some time into the game, you barely work on it at all. You play other games more often, and the 'spark' is lost. How do you keep the spark in your game designing techniques ?
Here are some tips other members have said(note, there are several contradictions in what our members feel is best):
1) Don't jump right into the easy coding. If you do, then when the hard stuff comes, it'll be impossible.
1.5) TURN OFF THE INTERNET occasionally. It's a giant distraction....
2) Try to pre-plan, but don't over plan! For example, in my Pokemon Game(how many of you honestly just rolled your eyes) I try something like this:
This is a nice graphic organizer:
WEEKLY PLAN:
Overall Goal~
Step 1~
-
-
-
-
Step 2
-
-
-
-
Step 3
-
-
-
-
**
I'll try it out for my game:
WEEKLY PLAN:
Overall Goal~Create Ectoskeleton of the Menu Engine w/ multiple pokemon
Step 1~Find a way to pause the game when the menu comes up
-Use keyboard_clear to prevent motion
-Set a 'menu_on' var that when turned to true pauses the object
-(~other ideas~)
-(~other ideas~)
*This may take several weeks*
Full Version: Do You Lose "the Spark" As You Make Your Game?
This happens to me alot... i have found that i loose the spark when i come across an error or i find that it seems more effort than its worth to get it done.
Answering your question, if your game is similar to a rival game, play the rival game and think what you like and don't like about it, then sometimes you get more ideas for your game of what would be cool. Thats usually how i tend to get ideas for games, just thinking of way sto improve another game. But it is hard to re-light a burnt out spark.
Answering your question, if your game is similar to a rival game, play the rival game and think what you like and don't like about it, then sometimes you get more ideas for your game of what would be cool. Thats usually how i tend to get ideas for games, just thinking of way sto improve another game. But it is hard to re-light a burnt out spark.
I tend to get the entire game idea in my head, so I know exactly where I'm going. Then I'll work on it, and when "the spark" is going, I work on a different aspect of the game, to keep it interesting. I can't just do all the coding, then all the level design, then all the menus etc etc. Even doing that I still sometimes lose motivation, but, to make sure it gets done, I simply don't allow myself to start a new game that I know I really wanna make til the other is done. So this has happened to me once, but now I'm at this very stage- the game is actually very close to being finished, just gotta put it together, so my last point has just got to hold to make sure it gets done!
Well I know a good way to keep the spark going, I just don't have the discipline to apply it. 
Limit yourself to an hour of programing or so a day. This way you won't over-work yourself so you will always be excited to get to work the next day. On top of this, you are usually more productive because you want to get as much done as you can in that hour. This usually works very well, but I have difficulty of getting off the computer and doing something else when I am "in the groove."
Limit yourself to an hour of programing or so a day. This way you won't over-work yourself so you will always be excited to get to work the next day. On top of this, you are usually more productive because you want to get as much done as you can in that hour. This usually works very well, but I have difficulty of getting off the computer and doing something else when I am "in the groove."
Ask yourself why you are making your game.
This article helped me out a lot. There's some good information there about how to avoid losing your so-called spark.
My God, this happens to me all the time. The article Aedious pointed out does have some good points. I'm always thinking that, what I've learned now, I can make a game. While not programming, I learn new stuff. Once I get back to my project, I could hardly care about it since the old style was so different. So I guess that as you learn new things, you can try to implement it into your current project (like it says in that article Aedious mentioned).
I keep it all written down on paper so that I don't forget my plans (I also draw the graphics of the game as a reference). Then I simply choose not to play any other games (well, at least not as often)
It happens to me when I end up creating a game that's a pain in the ass to maintain, modify or debug. To mitigate that, I began to invest a lot of time in creating functionality that saves much more time in the long run.
I could manually free each of the hundreds of structures and resources that the game uses. Or I could make a system that tracks everything for me automatically. No memory leaks. No need to remember every little thing. I can even free by tag or by type as well as ID.
I could manually type every configuration setting into a bunch of scripts. Or I could create a loader that parses a text file, automatically sets globalvars on startup and writes their current values on game end. Then I only have to type a single word in a text file.
Extended debug tools also help. Debugging collisions is much easier when you have a function that draws a rectangle and crosshairs over every bounding box and object.
There are hundreds of things like that. Long story short, creativity flows more easily unimpeded by technicalities.
I could manually free each of the hundreds of structures and resources that the game uses. Or I could make a system that tracks everything for me automatically. No memory leaks. No need to remember every little thing. I can even free by tag or by type as well as ID.
I could manually type every configuration setting into a bunch of scripts. Or I could create a loader that parses a text file, automatically sets globalvars on startup and writes their current values on game end. Then I only have to type a single word in a text file.
Extended debug tools also help. Debugging collisions is much easier when you have a function that draws a rectangle and crosshairs over every bounding box and object.
There are hundreds of things like that. Long story short, creativity flows more easily unimpeded by technicalities.
QUOTE (Desert Dog @ Oct 18 2009, 05:12 PM) 
Ask yourself why you are making your game.
I think he retired a few months ago...
I tend to lose the "Spark" when my game becomes too simple to program. Whenever I start to lose the spark, I incorperate something new into the engine, that way it stays interesting.
This problem is the bane of my existence! I have never fully completed a game (to my standards) because this happens to me. My problem usually isnt that I get bored, its just that I run into problems that I cant overcome. I try to force myself to continue, but I havent had much luck with it.
This happens to me a lot... I think of a great idea, but later on I feel like I have no idea what I would do next, and it gets boring. It also happens when the game is has an error, and it's blobbed up with lines of code, and I have trouble finding where the error is.
I'm sure pre-planning would help, but I'm not sure if that helps later on when work becomes stressful.
I'm sure pre-planning would help, but I'm not sure if that helps later on when work becomes stressful.
If you lose the spark, just take a break and don't worry about it. Come back to it when you feel comfortable and don't force anything. You will not maintain enthusiasm if you force yourself to work.
I learned from Game Fortress that working too heavily on your projects makes you burn out, and this can happen to anything, writing novels, drawing art, programming games, sculpting, etc. It's best to tackle a small bit at a time, not a lot at once... or the spark will fade but will eventually be reignited once again later down the track.
For instance, after seeing a few new movies I've turned back to my old fictions and began adding to them again @.@
For instance, after seeing a few new movies I've turned back to my old fictions and began adding to them again @.@
I know how it feels, you get an awsome idea, start on it, everythings working great, then suddenly you just don't feel like working on it anymore. This happens to me when I make complex games that take more time to make. Or worse, you've still got the spark, but you run into a big error that just pops out of nowhere and no matter how hard you look, it just doesn't make sense. It think soulsnatcher's idea of changing the aspect of the game that you are working on when you lose motivation is a good idea. Whenever I start to lose motivation, I visualise playing the game and how cool and original it will be. This usually works, although I don't think I have actually finished any games yet (I have a folder full of hundreds of half finished *.gm6 and *.gmk files). When you really think it is too hard to program, try working on an easier aspect (like the fancy health bar or main menu 
).
).
Problems that can`t be overcome can be a killer to stop progress dead in it`s tracks.
That would typically be what holds me back.
I think if it`s just a general losing of interest as you`re making the game, then the game isn`t interesting enough in the first place!
I think it`s important that the game itself is relaly playbale & something that you personally want to play - that way as you make a level you can get alot of satisfaction from trying it out & looking forward to more...
I think the projects that die off the very most on the GM community are the ones that are direct clones (ie: Zelda, Pokemon, Mario, Sonic etc) - the reason is that these games have already been done & finished to professional standard - it`s highly unlikley that your version of them will come close to what it already available to play - & that is very discouraging - also with these clones there is no way to eventually sell your games, so very little incentive to continue.
I think creating original games that you find fun to play & trying to keep the code simple as possible is important.
Also, I think limiting the size of the game is a good idea (a game that keeps growing & growing & getting more features added on will simply never get finished) - best to have a good idea of exactly how many levels, items or whatever there`s gonna be from the start & stick within that limit & focus on refining & perfecting the gameplay withing those few levels.
Also, sadly enough I think alot of people just have short attention spans, get bored easily or are just plain lazy... & will never get anything finished no matter what.
That would typically be what holds me back.
I think if it`s just a general losing of interest as you`re making the game, then the game isn`t interesting enough in the first place!
I think it`s important that the game itself is relaly playbale & something that you personally want to play - that way as you make a level you can get alot of satisfaction from trying it out & looking forward to more...
I think the projects that die off the very most on the GM community are the ones that are direct clones (ie: Zelda, Pokemon, Mario, Sonic etc) - the reason is that these games have already been done & finished to professional standard - it`s highly unlikley that your version of them will come close to what it already available to play - & that is very discouraging - also with these clones there is no way to eventually sell your games, so very little incentive to continue.
I think creating original games that you find fun to play & trying to keep the code simple as possible is important.
Also, I think limiting the size of the game is a good idea (a game that keeps growing & growing & getting more features added on will simply never get finished) - best to have a good idea of exactly how many levels, items or whatever there`s gonna be from the start & stick within that limit & focus on refining & perfecting the gameplay withing those few levels.
Also, sadly enough I think alot of people just have short attention spans, get bored easily or are just plain lazy... & will never get anything finished no matter what.
QUOTE (Polystyrene Man @ Oct 18 2009, 09:20 PM)
If you lose the spark, just take a break and don't worry about it. Come back to it when you feel comfortable and don't force anything. You will not maintain enthusiasm if you force yourself to work.
The problem with that solution is that it generally ends up making you abandon the game
.
Hey have 4 projects on the go xD.
I, also, tend to lose the spark when I come to an obstacle in the programming. Usually I can find the problem, but if it's something major, I procrastinate like I do in everyday life. 
But I'd like to raise a point. Why are this topic and post #8 reported?
But I'd like to raise a point. Why are this topic and post #8 reported?
i always lose the spark. iv'e only made 2 games
QUOTE (Phlum MKII @ Oct 19 2009, 12:19 PM)
But I'd like to raise a point. Why are this topic and post #8 reported?
Because some people just like to randomly push the report button everywhere to make more work for the moderators
.
QUOTE (superjoebob @ Oct 20 2009, 09:02 AM)
QUOTE (Phlum MKII @ Oct 19 2009, 12:19 PM)
But I'd like to raise a point. Why are this topic and post #8 reported?
Because some people just like to randomly push the report button everywhere to make more work for the moderators
.Because moderators love to moderate, they like to do things in moderation.
Cheers to all the posts above. You guys have some good stuff there. I especially like the tips on avoiding burn out and writing routines that make coding easier. That posted article was pretty sweet, too.
I have found three activities that help me stay inspired.
The first is other games. I make games because I love games. While the games that we're making at Toobix right now aren't clones, many of them are inspired by games from my past. When I'm feeling uninspired, I find that jumping on my PS3 for 30-60 minutes helps motivate me. Those games kindle my competitive spirit, and I always find myself wanting to make a game just as good. That's usually when I run to the studio and start working!
The second is varying activities. Since most of us are indie developers here, we're usually responsible for several (if not all) aspects of our game. While I do take part in nearly all aspects of game development outside of visuals, when I'm at the computer grinding away at an ongoing project I am usually either programming, writing music or designing sound effects. When I start feeling fatigued in one area, the next day I jump to another area. I stay on the same project, though, so there's always something getting done for that project.
My final advice is to find you a developer buddy. redbeard_prime and I meet several times a week over the phone to discuss what slice of the project we're going to be tackling next. We usually end up having a little review of what we've accomplished the week or so before, and that peps us both up for the weeks ahead.
I have found three activities that help me stay inspired.
The first is other games. I make games because I love games. While the games that we're making at Toobix right now aren't clones, many of them are inspired by games from my past. When I'm feeling uninspired, I find that jumping on my PS3 for 30-60 minutes helps motivate me. Those games kindle my competitive spirit, and I always find myself wanting to make a game just as good. That's usually when I run to the studio and start working!
The second is varying activities. Since most of us are indie developers here, we're usually responsible for several (if not all) aspects of our game. While I do take part in nearly all aspects of game development outside of visuals, when I'm at the computer grinding away at an ongoing project I am usually either programming, writing music or designing sound effects. When I start feeling fatigued in one area, the next day I jump to another area. I stay on the same project, though, so there's always something getting done for that project.
My final advice is to find you a developer buddy. redbeard_prime and I meet several times a week over the phone to discuss what slice of the project we're going to be tackling next. We usually end up having a little review of what we've accomplished the week or so before, and that peps us both up for the weeks ahead.
QUOTE (Desert Dog @ Oct 18 2009, 06:12 PM)
Ask yourself why you are making your game.
Well why do people make games? I make games for my entertainment and the hope that I entertain others.
Unfortunatly, I lose the "spark" quite a lot. I know GML well and all it's just that as things go on, I get bored and I gain new ideas and want to do something about my new ideas. I don't know, it just happens to me. I haven't finished a game at all. Maybe it's just me. I don't know. The longest I've help a game together is about a month...
QUOTE (daspirit @ Oct 20 2009, 09:47 AM)
QUOTE (Desert Dog @ Oct 18 2009, 06:12 PM)
Ask yourself why you are making your game.
Well why do people make games? I make games for my entertainment and the hope that I entertain others.
Unfortunatly, I lose the "spark" quite a lot. I know GML well and all it's just that as things go on, I get bored and I gain new ideas and want to do something about my new ideas. I don't know, it just happens to me. I haven't finished a game at all. Maybe it's just me. I don't know. The longest I've help a game together is about a month...
Hey i've been using GM since 03 and I have not completed a game either, xD largely due to corrupt games or hdd wiped *never boot from an XP disk if your using W7*.
But the good thing about looking a game is that you remake your game better then before with the new skills you've learnt.
C++ class has taught me very good ways to structure and format my code, by building well structured and thoroughly thought out code your less likely to come to a dead end or end up making the game extremely complex you just can't be bothered to code within it.
Just think of being able to say "I made this game". Maybe it's easier to make a game in a team because there are more people to share the work and to be creative with the project.
QUOTE (Rafferty97 @ Oct 20 2009, 05:22 AM)
Maybe it's easier to make a game in a team because there are more people to share the work and to be creative with the project.
I have found this to be absolutely true. Whenever you share the work load it makes things easier because you're twice as productive. Plus, while indie game developers generally have multiple talents, there may be things that we are better at than others. When you have that second person who is good at the things that you're not, well you can imagine how much easier that makes things. You get to be twice as productive at the things that you're good at and so does the other person.
That being said, I have found it helpful not to completely isolate yourself from one area of project development just because someone else is the lead in that area. For example, I'm the lead in music, but I always play my drafts for redbeard_prime. This is extremely helpful because it gets a fresh set of ears on the piece and a different perspective on it as well. Constructive criticism has always improved the end product in this way, and I think that improvement can help keep you inspired as well.
QUOTE (Krisando @ Oct 20 2009, 07:07 AM)
QUOTE (superjoebob @ Oct 20 2009, 09:02 AM)
QUOTE (Phlum MKII @ Oct 19 2009, 12:19 PM)
But I'd like to raise a point. Why are this topic and post #8 reported?
Because some people just like to randomly push the report button everywhere to make more work for the moderators
.Because moderators love to moderate, they like to do things in moderation.
Well They Dont Like Getting Their time wasted
QUOTE (Rafferty97 @ Oct 20 2009, 02:22 AM)
Just think of being able to say "I made this game".
Thats a big one for me, the more complicated a game gets the more it drives me to complete it for bragging rights
.
This happens to me a lot as well. The main problem is probably that I cannot code a decent game, and I must get someone else do do it with/for me, and so it depends really on the programmer. (A new problem about the spark) and obviously the spark dies down after you become restricted to the working limitations of your partner/team.
(for example, you have a awesome new idea for your game, which is 20% done, and then you lose contact with a team member for several days, your excitement about the new idea dies down, or you may even forget about it completely.)
(for example, you have a awesome new idea for your game, which is 20% done, and then you lose contact with a team member for several days, your excitement about the new idea dies down, or you may even forget about it completely.)
QUOTE (dadio @ Oct 19 2009, 07:20 PM)
(ie: Zelda, Pokemon, Mario, Sonic etc) - the reason is that these games have already been done & finished to professional standard - it`s highly unlikley that your version of them will come close to what it already available to play - & that is very discouraging - also with these clones there is no way to eventually sell your games, so very little incentive to continue.
Well thats not fair for atleast 3 or 4 people here, myself, Jext, Abecedariandude and I think Game Fortress are very close if not spot on to the real Pokemon games, for one, me and Jext prefer to add in features that are new and refreshing to boost desire to play the games, the problem is that it's HARD to completely mimick the game.
People who get this far can't stand the enormous amount of stress both attributed to the difficulty of replicating an engine in an inferior language and the fact that we have hundreds if not thousands of people to please with our work, that and we have to deal with more trolls than any normal game.
They come in and say Pokemon is gay, Pokemon should die, that we are gay for trying to make new Pokemon, etc etc, You can see now why we give up if we do, that and with Coding you always learn new tricks, and you eventually find your old code sucks, thus why I canceled 2 Pokemon games myself, the code was just horrendous.
QUOTE (michael pw @ Oct 18 2009, 04:31 PM)
Answering your question, if your game is similar to a rival game, play the rival game and think what you like and don't like about it, then sometimes you get more ideas for your game of what would be cool.
I find this is a great motivator for me also. Just yesterday I was searching through the gmc and found myself wanting to work on my old project again.
One problem I've had though, I take breaks quit often from my games. I go through a phase where I work non-stop on a game for about 3-4 weeks, then I find myself needing a break. I take a break for about 2-3 weeks, then when I try to come back to my game I find it is messy and almost unworkable.
I have constantly been learning better coding techniques as I grow as a programmer, and my old games become hard to understand after long breaks. Large chunks of code need to be rewritten, and it just becomes to time consuming. So I just wind up rewriting it or making a new game.
I am now learning C++, and one big thing that I can take and apply to Gamemaker is good structuring. I am taking a college level course on it which also helps too because they teach good coding practices. But C++ code has to be much more organized than Gamemaker for it to even run. Gamemaker allows for very messy and unorganized code and will still run without a problem, and this can lead to many problems down the road when you are making a game, especially when you take a break and come back. If your code is unorganized, and you chose bad variable names or other things, it can be a pain to keep working on it.
So basically, my advice towards keeping the "Spark", is to keep clean code. You will find it easier to keep going when you can easily understand everything, even after breaks. I guess that is another piece of advice, which kind of relies on my first advice, because it may not work if you dont do the first one. So take breaks, and keep clean code.
I plan on keeping a log and planning my code out before my next game. I'm going to write out my code structures and important variables to keep track of everything, to make sure I know where I'm going with the game. Planning everything out first is a good idea if you are making a larger scale game. I'm going to try anything I can so maybe I will actually be able to release a full game. I've been doing this for about 4 years so I think its about time I actually put out decent game...
QUOTE (soccer99 @ Oct 21 2009, 03:23 PM)
I plan on keeping a log and planning my code out before my next game. I'm going to write out my code structures and important variables to keep track of everything, to make sure I know where I'm going with the game. Planning everything out first is a good idea if you are making a larger scale game. I'm going to try anything I can so maybe I will actually be able to release a full game. I've been doing this for about 4 years so I think its about time I actually put out decent game...
Lol, me too... though my C++ project tends to get messy even with comments since I plug in a lot of error catches that many 'professionals' deem useless, right up until their games/applications throw off errors for a small group of users and then they get flooded with error reports and very little information in what happened.
Key tips:
- Don't slug away at the game or application for large periods of time, spread out some time allotments to it.
- Keep your code neat and clean, comment what complex things do so you know how to fix/improve them later.
- Make heavy use of a single method of syntax (being personal syntax) for instance:
CODE
if ( PlayerDead )
{
game_end();
}
//** Keyboard check events
if ( keyboard_check_pressed(vk_space) )
{
motion_set(2,direction);
}
{
game_end();
}
//** Keyboard check events
if ( keyboard_check_pressed(vk_space) )
{
motion_set(2,direction);
}
Not only is it neat and easy to understand, but it looks professional. If only I was legally allowed to share the source-code to a retailed game I have, the code is horrendous... there are entire 30 line chunks that literally look like a madman has hammered on the keyboard.
- Employ people in your team who are good at a key task and enjoy doing this task, try to apply this to yourself as well, work on what you enjoy.
- Team up with others only when it'll be more productive, if you do better solo, then do so, if teamwork is your thing then grab a bunch of dedicated buddies.
- Keep a single goal in mind and plan out the method of achieving this as best you can. Try not to stray too far or try to explore new things, this leads to losing interest in what you have to do.
- Learn the key methods involved in making the game before you start, this will help you later on down the track.
- Be prepared to do a lot of reading!
- Enjoy what you make, spend some time to admire it.
- Don't take a "troll's" opinion seriously, anyone who says they downright hate a game and give barely a reason, aren't really of much use as a reviewer.
- Only attempt something within your skill range, let's all admit it, we've all tried to make something we couldn't at some point.
There are a lot more but I'll stop with just those for now.
QUOTE
- Only attempt something within your skill range, let's all admit it, we've all tried to make something we couldn't at some point.
I agree, many people are trying to make really complex games beyond their ability. When they get stuck and can't continue because the game is way too complex, it can be very discouraging to try again at making other games.
Cleaning up my old external HDD I found this pretty relevant and true document.
So, I'm not gonna repeat it but rather post it instead. Might help)
So, I'm not gonna repeat it but rather post it instead. Might help)
QUOTE
Four important principles of a 'good' gamemaking
(by unknown Alex)
This is a very brief and easy-to-follow tutorial for novice and intermediate gamedevs.
Here we go:
#1 Try planning everything thoroughly in advance for all stages.
Diagnosis: you don’t have a clear and vivid visualization of your creation.
Remedy: make it more tangible and specific: use sketches, write down all your idea variations, and choose only one or two of them.
#2 A game should not be very difficult.
Although a deep game may become a hit, developing such a “colossus” will apparently take much time, besides you just won’t be able to finish these grandiose ideas. Of course, you can work in a team so you could use your energy sparingly, but the major part would still be yours – clearly explain your insights to the others.
Diagnosis: try seeing your creation at a different angle, compare it with other GM games, or just ask someone else to give it a fresh look. Also try considering your ideas objectively and realize how difficult they could be for implementation (theory, any GM examples, and so on).
Remedy: KISS. Keep it simple, stupid. Everybody wants to do everything even better, but very often one’s “better” becomes “more” - expressed only in quantity (more levels, more weapons, more sophisticated AI system etc), thus it is unlikely that the final work will be radiant with originality or even get some shape.
#3 As a “part-time” developer you should spend on your creation no longer than one (1) hour a day.
It often happens that at the very beginning one spends some 4+ hours every day and in a couple of days he either forgets about the project or there appear some more important and urgent things to do. This is a psychological aspect: at first, you're very excited and even can get something done easily, however while spending a lot of time and efforts makes the interest fade away and you are just sickened even looking at that infamous “thing”, not speaking about creating something.
Once again: the more is not always the better; the same with the time you spend on game developing – after a few hours of hardworking you will be so tired that your operating efficiency will be less than zero.
Diagnosis: check your clock; think a little so you can realize that your excessive concentration on the ideas can finally cow you...
Remedy: calm down and relax. As it’s written earlier: do not bother developing games longer than an hour a day. If you really like Game Developing then use your spare time wisely – surf the forums, try example codes, and study useful documentation or tutorials.
#4 Do not rely on others.
A teamwork may be very effective and efficient, but the project may still be unrealizable. Getting pieces of advice from others, you may assume that they have much better understanding/ skills than it really is. Or, for example, some novice coders and you want to create something really overwhelming, but when it comes to the push, it’s very-very seldom that your teammates could read your mind and do everything as you want and the way you like. It is very true when you are a project manager.
Diagnosis: You need to allocate your resources optimally. So, you are continuously waiting for others and it makes you all go not as planned, the teammates keep adding their ideas too (but not developing them!), and your project appears to be a container of plenty unshaped thoughts. It is really whammy.
Remedy: ...simple (see #1) - from the very beginning plan the entire process as if you were doing everything alone. It may slightly reduce its quantitative potential for the sake of quality. Believe me, if you get something worth then you will surely make a couple of extra levels easily.
P.S. don't forget you still need food and rest. The same goes regarding your teammates, so treat them properly (if any).
(by unknown Alex)
This is a very brief and easy-to-follow tutorial for novice and intermediate gamedevs.
Here we go:
#1 Try planning everything thoroughly in advance for all stages.
Diagnosis: you don’t have a clear and vivid visualization of your creation.
Remedy: make it more tangible and specific: use sketches, write down all your idea variations, and choose only one or two of them.
#2 A game should not be very difficult.
Although a deep game may become a hit, developing such a “colossus” will apparently take much time, besides you just won’t be able to finish these grandiose ideas. Of course, you can work in a team so you could use your energy sparingly, but the major part would still be yours – clearly explain your insights to the others.
Diagnosis: try seeing your creation at a different angle, compare it with other GM games, or just ask someone else to give it a fresh look. Also try considering your ideas objectively and realize how difficult they could be for implementation (theory, any GM examples, and so on).
Remedy: KISS. Keep it simple, stupid. Everybody wants to do everything even better, but very often one’s “better” becomes “more” - expressed only in quantity (more levels, more weapons, more sophisticated AI system etc), thus it is unlikely that the final work will be radiant with originality or even get some shape.
#3 As a “part-time” developer you should spend on your creation no longer than one (1) hour a day.
It often happens that at the very beginning one spends some 4+ hours every day and in a couple of days he either forgets about the project or there appear some more important and urgent things to do. This is a psychological aspect: at first, you're very excited and even can get something done easily, however while spending a lot of time and efforts makes the interest fade away and you are just sickened even looking at that infamous “thing”, not speaking about creating something.
Once again: the more is not always the better; the same with the time you spend on game developing – after a few hours of hardworking you will be so tired that your operating efficiency will be less than zero.
Diagnosis: check your clock; think a little so you can realize that your excessive concentration on the ideas can finally cow you...
Remedy: calm down and relax. As it’s written earlier: do not bother developing games longer than an hour a day. If you really like Game Developing then use your spare time wisely – surf the forums, try example codes, and study useful documentation or tutorials.
#4 Do not rely on others.
A teamwork may be very effective and efficient, but the project may still be unrealizable. Getting pieces of advice from others, you may assume that they have much better understanding/ skills than it really is. Or, for example, some novice coders and you want to create something really overwhelming, but when it comes to the push, it’s very-very seldom that your teammates could read your mind and do everything as you want and the way you like. It is very true when you are a project manager.
Diagnosis: You need to allocate your resources optimally. So, you are continuously waiting for others and it makes you all go not as planned, the teammates keep adding their ideas too (but not developing them!), and your project appears to be a container of plenty unshaped thoughts. It is really whammy.
Remedy: ...simple (see #1) - from the very beginning plan the entire process as if you were doing everything alone. It may slightly reduce its quantitative potential for the sake of quality. Believe me, if you get something worth then you will surely make a couple of extra levels easily.
P.S. don't forget you still need food and rest. The same goes regarding your teammates, so treat them properly (if any).
Soccer99, you had some great points there. Just a couple quick thoughts on them:
1. TAKING BREAKS. I agree, this is in general a good idea, but take a look at my post above for ways to take breaks but still be productive on a project. What do you think?
2. REDOING CODE. Don't do it! I know the temptation is great because every time we code we improve and make our old coding styles obsolete; however, usually the old code, while drab and not as sleek as the new code, works. Otherwise, you wouldn't have coded it in the first place. I try and remember that no code is and ever will be perfect. If it works just let it lie and move on. That way the project gets done.
3. KEEPING A LOG. A great idea, but may I suggest an alternative way? Instead of a separate log, I keep all my notes in comments within the code. That way as I read the code I can see how it connects to the other aspects of the game.
1. TAKING BREAKS. I agree, this is in general a good idea, but take a look at my post above for ways to take breaks but still be productive on a project. What do you think?
2. REDOING CODE. Don't do it! I know the temptation is great because every time we code we improve and make our old coding styles obsolete; however, usually the old code, while drab and not as sleek as the new code, works. Otherwise, you wouldn't have coded it in the first place. I try and remember that no code is and ever will be perfect. If it works just let it lie and move on. That way the project gets done.
3. KEEPING A LOG. A great idea, but may I suggest an alternative way? Instead of a separate log, I keep all my notes in comments within the code. That way as I read the code I can see how it connects to the other aspects of the game.
QUOTE (e-effect @ Oct 21 2009, 08:43 PM)
2. REDOING CODE. Don't do it! I know the temptation is great because every time we code we improve and make our old coding styles obsolete; however, usually the old code, while drab and not as sleek as the new code, works. Otherwise, you wouldn't have coded it in the first place. I try and remember that no code is and ever will be perfect. If it works just let it lie and move on. That way the project gets done.
I never rewrite code just to make it look nicer. Many times when I have messy code in a project, it holds me back from new features I wish to add. Or when I add newer features, the old ones become incompatible and it causes errors.
QUOTE (James_ogden @ Oct 20 2009, 10:26 PM)
- Only attempt something within your skill range, let's all admit it, we've all tried to make something we couldn't at some point.
I disagree with this statement, I find the main driving point for me is knowing that I'm still learning something from what I'm doing. If you never challenge your skill level your not going to get any better!
QUOTE (superjoebob @ Oct 22 2009, 01:43 AM)
I disagree with this statement, I find the main driving point for me is knowing that I'm still learning something from what I'm doing. If you never challenge your skill level your not going to get any better!
I agree with that. The challenge is usually what keeps me going.
I've had a few abandoned projects, and i lost motivation for most of them after the challenging part was done.
Don't plan too much from the beggining; the greatest videogames have started as a small experiment. After you complete a mini-version, you can further develop it. Thus the game grows more and more but you never have to think at the whole game from the beggining. Just the next step. Always just the next step.
QUOTE (andrew_berge @ Oct 22 2009, 09:49 AM)
QUOTE (superjoebob @ Oct 22 2009, 01:43 AM)
I disagree with this statement, I find the main driving point for me is knowing that I'm still learning something from what I'm doing. If you never challenge your skill level your not going to get any better!
I agree with that. The challenge is usually what keeps me going.
I've had a few abandoned projects, and i lost motivation for most of them after the challenging part was done.
Although I agree with both of you that if you want to learn new things you have to try new things, it is also sometimes true that if you are starting a project because you plan to finish and eventually release it, it is a good idea to shoot for something within your skill range. But trying new things just for a fun little game for practice is always a good idea.
oh yeah!
i just thought of something else, maybe getting the hard part done to start with then do level design after, that way you don't end up making half the levels then go: "this script is really hard, i cannot be bothered"
i just thought of something else, maybe getting the hard part done to start with then do level design after, that way you don't end up making half the levels then go: "this script is really hard, i cannot be bothered"
QUOTE (michael pw @ Oct 22 2009, 11:23 PM)
oh yeah!
i just thought of something else, maybe getting the hard part done to start with then do level design after, that way you don't end up making half the levels then go: "this script is really hard, i cannot be bothered"
i just thought of something else, maybe getting the hard part done to start with then do level design after, that way you don't end up making half the levels then go: "this script is really hard, i cannot be bothered"
Thats sort of what I've done with my most recent project, I did get the bulk of code done first, but was doing everything else at the same time. I have to say its gone better for me, as I'm actually going to finish it. My only contradiction would be that the off putting thing then becomes the tediousness of level after level tiling and planning. Thats why I work bits of everything at a time.
Wow, lots of replies! One of the things that I find troubling for my game is the fact that I am in a rut. I have all the little bugs fixed, so If I want to code more, I have to start something big! I've been glitch fixing for a while, but I find it kind of frightening to have to dive deeper into the realm of coding. Also, I have issues staying on topic. Like I always get sidetracked with something.
I like this topic because I know how some things to do whenever I lose the spark. This will help me alot. Thanks, all!
This will help me alot. Thanks, all!
Yes. But for me it's mainly not enough graphics.
I usually lose interest when I find that I've coded myself into a ditch and have no way of adding a feature without doing massive changes to the overall structure.
I also seem to lose the spark when the game is so unorganized and cluttered with junk (That's still important enough for me to not just delete it) and I carry on to just start a different game.
Every time this happens, I learn from my old mistakes, and do better the next time around.
I also seem to lose the spark when the game is so unorganized and cluttered with junk (That's still important enough for me to not just delete it) and I carry on to just start a different game.
Every time this happens, I learn from my old mistakes, and do better the next time around.
I've suffered from this a lot in the past, but find it less of an issue now. Here's a few things I've found that helped me a lot in my approach to development:
Don't aim too high - This one gets most first-timers, myself included. Sure, your favourite games might be RPGs or open-world action games, but if your new creation will be "like megagame X but with SHINY NEW FEATURE Y" you've already set yourself an uphill struggle. There's a lot of things Indie developers can do that the big studios can't, but beating them at their own game is not one of them. It's simply too much work to realistically achieve. If you must do one of these, strip your design down to its absolute core elements, and build those first. Which leads us to...
Build from the bottom up - Start off on your core engine, control system and gameplay elements. This is the absolute bedrock of your design, and if these aren't fun and engaging, no amount of fancy features are going to save you. Keep working at them until you get them locked down. It's a lot easier to expand from a solid foundation like this than to attack everything at once. If you start implementing more advanced, upper-level features first, you'll find maintaining your code to be more and more like balancing a tower of cards while swapping out the cards at the bottom. Also, working at such a basic level will give you a better understanding of how your core gameplay functions, and may lead you to new approaches at a fundamental level you hadn't thought of.
And even if you decide to can the game, you'll at least be left with a functioning engine you can revisit later and not a patchwork of half-implemented ideas to weed through.
Your code can (usually) be cleaner - Don't be afraid to revise old code, the sooner the better. This work's easier when you're all fired up on a project, and like many have said here, will save you endless headaches further down the line. Cleaner code makes for easier development, better understanding (and retention) of what your engine's actually doing, and will help massively when working with others on a team project. It's just good sense.
Window-Dressing can wait - Graphics and sonics are best left until later. Nothing slows you down quite like sidetracking into complicated character designs and animation when placeholders will do. It can also cause you to drift away from your coding until you've lost track of where you were. Yikes, I've taken this route a few times too many. Save the artwork for when your game's going to be seen outside of your own desktop.
Those have helped me a lot, anyway. And hopefully they'll have helped enough that you might be able to see a functional WIP game project pretty soon.
Don't aim too high - This one gets most first-timers, myself included. Sure, your favourite games might be RPGs or open-world action games, but if your new creation will be "like megagame X but with SHINY NEW FEATURE Y" you've already set yourself an uphill struggle. There's a lot of things Indie developers can do that the big studios can't, but beating them at their own game is not one of them. It's simply too much work to realistically achieve. If you must do one of these, strip your design down to its absolute core elements, and build those first. Which leads us to...
Build from the bottom up - Start off on your core engine, control system and gameplay elements. This is the absolute bedrock of your design, and if these aren't fun and engaging, no amount of fancy features are going to save you. Keep working at them until you get them locked down. It's a lot easier to expand from a solid foundation like this than to attack everything at once. If you start implementing more advanced, upper-level features first, you'll find maintaining your code to be more and more like balancing a tower of cards while swapping out the cards at the bottom. Also, working at such a basic level will give you a better understanding of how your core gameplay functions, and may lead you to new approaches at a fundamental level you hadn't thought of.
And even if you decide to can the game, you'll at least be left with a functioning engine you can revisit later and not a patchwork of half-implemented ideas to weed through.
Your code can (usually) be cleaner - Don't be afraid to revise old code, the sooner the better. This work's easier when you're all fired up on a project, and like many have said here, will save you endless headaches further down the line. Cleaner code makes for easier development, better understanding (and retention) of what your engine's actually doing, and will help massively when working with others on a team project. It's just good sense.
Window-Dressing can wait - Graphics and sonics are best left until later. Nothing slows you down quite like sidetracking into complicated character designs and animation when placeholders will do. It can also cause you to drift away from your coding until you've lost track of where you were. Yikes, I've taken this route a few times too many. Save the artwork for when your game's going to be seen outside of your own desktop.
Those have helped me a lot, anyway. And hopefully they'll have helped enough that you might be able to see a functional WIP game project pretty soon.
What hinders me is the fact that i just cant program at all. I can do the simple stuff (REALLY SIMPLE), but when it comes to for example making a working inventory, a saving/loading system or just a pausefunction... I cant do it. I start off with a some motivation, i say to myself "you can do it, if there's something you cant get around - dont" or i post a topic in the novice q&a forum. It all breaks down when i realize i can barely implement ANY of the ideas i had in mind.
I cant make a friggin tic tac toe game. My platformers are without slopes and the characters get stuck in the ground. My topdowners get stuck in the walls and the bullets go through the enemies.
I can probably make ok music, my graphics are good, my ideas excellent - but my programming skills lousy...
I cant make a friggin tic tac toe game. My platformers are without slopes and the characters get stuck in the ground. My topdowners get stuck in the walls and the bullets go through the enemies.
I can probably make ok music, my graphics are good, my ideas excellent - but my programming skills lousy...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.