Hello!

Sorry if I'm posting this in the wrong section, but I thought that it would fit the best to my question. I also want to say sorry for my bad english, but I hope that the following post will still be easy to understand.

So, first I want to describe my current situation a bit, maybe it could make answering a bit easier.

I'm a 15year old hobbyist programmer, and started learning how to code about 3-4years ago. About a year ago I wanted to start creating own games, not only little programs, tools, and such - And since then I learned quite a bit, but on every single project I started, I failed - And I believe that it's only because of one single reason: Organization, Concepts, and such. Everytime when I get an Idea, I just try to shape the "base-idea" in my head, and then directly start programming - As a result, I get to finish around half of the game, and then I give up - Either because I don't know which part of the game to implement next, or because I found a huge mistake, but I would have to change the whole code to fix it, or even oter things. Another problem is, that everytime I take a break of a few days, I have a hard time to understand my own code because it lacks documentation.

I've tried to think a bit about why all my bigger projects fail like this, and came to the conclusion that my "rushing" is the reason; I don't even have the whole Idea in my head, but I already start coding. Now I have a question: How do YOU design a game? And how should I do it? I never really designed the concept of a game, only the "base-idea", and I have no idea how to start... And once I have the concept on paper, what do I do? How do you guys make the step from designing to implementing?

I know, these questions are pretty big... But I really need help on these..

(The game idea I have right now is a platformer, TileMaps are used)

Greetings

First, some things simply come with age and there are some mistakes and failures one have to make himself :) So, I would not totally obssess over it.

Second, you need more experience with coding (it will be very useful later) so I would not prevent this "rushing" (it's far better to learn coding well now while not finishing anything than learn how to design things flawlessly without getting the experience), you need this "fruitless" coding you are doing right now.

And once I have the concept on paper, what do I do?

Do you have it on paper? :D You sound like you are worrying too much about future and try to skip phases. You said you don't have your whole idea in your head yet, so the next step would be to finish it in your head and put on paper and only then worry about implementation.

Learn how to code properly (so you understand your code the next day). Learn how to put your ideas on paper (I use various forums for this - as an added bonus I get (sometimes) a valuable feedback :)). Once you have these worry about implementation.

Another problem is, that everytime I take a break of a few days, I have a hard time to understand my own code because it lacks documentation.

I've gotten in the habit of writing (typing actually) my thoughts down in a seperate file before, while, and after I code. And when working on the actual code, I put a comment that is just today's date so I can refrence my notes later if I have to. Over all, this helps me remember what I was doing last time and also when I come to a piece of code where I go, "what the hell was I thinking when I wrote this crap?" I can refer to my notes and actually answer that question. I do this for both my hobby projects and professionally (I'm not a game dev though).

Aside from that, experience is probably going to be what helps you determine what you need when in the design phase. Think about what went wrong last time and try to plan ahead to avoid that situation again. Think about the features your going to develop and the risks are involved. And write all these things down.

That being said, for my current hobby project, I have no real design. I'm basically just developing various features and don't really have any sort of game. Ultimately, I expect the project to collapse under its own weight. It's kinda close to that actualy as I'm finding issues between SFML and my target machine's ancient graphics card. Also, I recently decided that the way I structured my objects was giving me no end of grief and I had to spend a week or two restructuring things and accounting for those changes as well (was really close to giving up there). Plus there's a couple other ideas for projects that I got in my head that I'm curious to try and the current project has been going on for about two years without a lot of progress towards an actual game. Of course, those ideas would be quite unable to make use of anything that I've developed in the past two years too. So um... yeah... plan ahead as best as you can or else you'll probably end up with a mess like I have on my hands at the moment.

How do YOU design a game? And how should I do it? I never really designed the concept of a game, only the "base-idea", and I have no idea how to start... And once I have the concept on paper, what do I do? How do you guys make the step from designing to implementing?

There's info in lots of places about how to write a GDD. You can start here:
http://www.sloperama.com/advice/specs.htm
http://www.sloperama.com/advice/lesson13.htm

And once I have the concept on paper, what do I do? How do you guys make the step from designing to implementing?

This conversation is taking place in the Game Design forum (I think someone moved it here from For Beginners). But implementing a game (after the GDD has been written) is not a proper subject for discussion in the Game Design forum. So you can post your programming questions in For Beginners.

Over-thinking things can lead to despair. (To much to think, you will never be able to plan all the details everything ahead, and at worst, you will never actually start coding)
Under-thinking things can lead to infinity. (you will have to redo everything because you didn't think of that one detail)

Try to be agile, try to think by module, cut your game into many little part, work by iteration, and move from finished game to finished game.

For exemple, in the case of a platformer. If the final game would be a platformer where you can throw at chicken.

First : Cut your project in multiple part or module which are as independant from the others as possible.

The character (he moves, he has health, is controlled by the player), The HUD (draw the value on the screen), the World (contain all the object), the Chicken (has physics, can kill zombies, is a chicken), the Zombie (move slowly toward the player, has health), etc...

Second : figure out how those modules will interact with each other, because this is the part where you will have problems. It is not really important to know that the picture for the health will be red or blue, but to know how the health on the HUD is linked on the health of the character.

Third : plan your iteration. At the end of each iteration you should be able to show a version of your game which is "finished".

Iteration 1 : You spawn a level following a txt file.
Iteration 2 : You have a character which can move. You spawn a level following a txt file.
Iteration 3 : You have an HUD and the game start and finish. You have a character which can move and jump. You spawn a level following a txt file.
Iteration 4 : You can throw chicken. You have an HUD and the game start and finish. You have a character which can move and jump. You spawn a level following a txt file.
Iteration 5 : etc...

Fourth : Now your plan is ready, the interaction between the module figured out, you can work on the content of the module. Now that your "scope" is reduced you should be able to plan everything or directly start coding.

Five : And if this is between your first and 10th game, you will fail. You won't finish it. But...who cares! You will fail, so fail fast and learn. And continue failing until the mighty eleventh attempt or you may not fail

Another problem is, that everytime I take a break of a few days, I have a hard time to understand my own code because it lacks documentation.

Try to adopt a norm and tak an habit of always commenting your code. At least at the top of each function, and maybe at the top of your class variable. Some will says that too much comments is not good, and you should use good names instead, and I also agree with that. But if you think that a part is tricky, try to rewrite it so it is not tricky anymore. And if you don't have a choice, then put a comment.


And this conclude my answers. It is not to be followed word by word, of course, but it may help you create your own developping method ^^'

As I think you know and others have suggested, good documentation goes a long way. Mine is always more for myself than others, but yeah, it's too easy to think that because you wrote it, you'll remember easily what it does down the line, which at least for me, is rarely the case:P

If it's entirely due to the complexity of your programs and how the parts fit together, I don't have much specific advice. Planning certainly helps there, but I think experience counts for most of that. I've gotten most of my knowledge of how to plan a project and piece game parts together entirely through trial and error (and my projects definitely could be improved, but I just take it all as a learning experience)

I find regardless of how much I plan beforehand, everything changes once I start implementing and coding things. Like yourself, I've lately taken a less planned approach and just taking the idea and starting coding. I work alone, so this is probably more feasible. It's also probably terrible advice But, it's probably very dependent on the scope and complexity of your project.

But, the basics for most games I have found lately are pretty much the same from game to game, and it's only the specifics that change. I recommend saving your failed games. Parts of them are likely good code and it's much easier to just reuse structures you've already created than building from scratch every time. I make a basic template for various styles. i.e. I have a template for a 2d platformer, a template for 2d rpg, a 3d opengl template, etc. Then, when I want to make something, I start with those and build upon them. Sometimes they change a lot, sometimes not much. But, I don't have to spend all my energy and attention on building up the basic structure again and then being burned out on it later.

But, it's possible you're being too ambitious for a lone programmer. I find personally, it's difficult to ever be "done" with my projects, as there are always ways to add more, make it bigger, better, more complex, etc. and once you start down those path you can sometimes bite off more than you can chew.

So, basically, I think just keeping a portfolio of even your failed games to use when starting something new is really helpful. Also, sometimes aim lower. Plan to make something you know you can finish. Once it's done you can always then begin to add complexity, more mechanics, better artwork, more levels, more worlds, etc. But, at any point, even if you quit, you have what is essentially a finished product.

And, lastly, save copies of your work in progress. I keep a daily build of everything I'm working on (not the assets, just a copy of the code). I try to only save versions that aren't mid-way through implementing something or have game-breaking bugs. But, if they do, note that (I just tag their folder names with "working" or "buggy"). If you find a bug that's you think is just too insurmountable to find and fix, go back a day or two to a good copy (i find that's also helpful to pinpoint the bug, you can see what you changed, when things worked, when they didn't). That way you're never stuck with a broken program that you don't have the patience or attention to fix or return to. I totally understand how going back to a program and having it not work can just kill motivation to start back on it, so again for myself, I just try to avoid that.

edit*

I also find, since I'm relatively new myself as well, that my code can always use cleaning up. If I'm working on a long project, at least once a week, I'll go through it and document things, see what I can parse down and make more efficient, rename things for clarity(I'm terrible with naming things the first time through), look for inefficiencies, etc. Usually when my code is looking too complicated and hard to understand, it's because I'm doing something wrong or lapsing into spaghetti coding. It's like editing a story you're writing, you don't keep the rough draft But, it took me a long time to realize that just because something in my program worked, didn't mean I was done with it. That's probably made the biggest improvement in my coding as anything else.

This is some good advice in general, not just for games :) As everyone else says, these things will come with experience. But you probably want to do something now, too, not just in a few years :) One thing is, it can be hard to learn two things at once (game design and game programming), because they're so intertwined. If you can separate the two it might help. (That's why reimplementing old games like Tetris is a classic beginner's exercise: the game design already exists so you only have to learn the implementation side of it.)

So, as possible project: design a physical game, out of cardboard, paper, marbles, whatever. Get it down to the details, to the point where a friend can play it when you're not around. Then once you're satisfied, implement that exact game in code. (Or a simpler version, as needs dictate. But not a more complicated version!)

Hi!

Thanks so much to everyone who answered.
(Sorry for my late answer, but I was busy wit shool)

First, some things simply come with age and there are some mistakes and failures one have to make himself So, I would not totally obssess over it.
Second, you need more experience with coding (it will be very useful later) so I would not prevent this "rushing" (it's far better to learn coding well now while not finishing anything than learn how to design things flawlessly without getting the experience), you need this "fruitless" coding you are doing right now.

I know that I learn many things through "this" - And I already learned many things since I started - But it's just so... demotivating, always creating new projects, but never actually finishing one. I mean, sure, programming is fun - But it would be even cooler to see results, not just abandoned projects everywhere.

Do you have it on paper? You sound like you are worrying too much about future and try to skip phases. You said you don't have your whole idea in your head yet, so the next step would be to finish it in your head and put on paper and only then worry about implementation.

Learn how to code properly (so you understand your code the next day). Learn how to put your ideas on paper (I use various forums for this - as an added bonus I get (sometimes) a valuable feedback ). Once you have these worry about implementation.

I'm gonna do that. It's just that I fear having problems if I don't have a "plan" for the implementation - It already happened quiet a few times that I was only stuck because I just had no idea what part of my project to implement next.

I've gotten in the habit of writing (typing actually) my thoughts down in a seperate file before, while, and after I code. And when working on the actual code, I put a comment that is just today's date so I can refrence my notes later if I have to. Over all, this helps me remember what I was doing last time and also when I come to a piece of code where I go, "what the hell was I thinking when I wrote this crap?" I can refer to my notes and actually answer that question. I do this for both my hobby projects and professionally (I'm not a game dev though).

I think I will do something like that, thanks for the reply!

Aside from that, experience is probably going to be what helps you determine what you need when in the design phase. Think about what went wrong last time and try to plan ahead to avoid that situation again. Think about the features your going to develop and the risks are involved. And write all these things down.

One of my problems is, is that I don't really know what went wrong. As I said in my first post, I think it's because I did not plan anything, and thats what I currently want to change

That being said, for my current hobby project, I have no real design. I'm basically just developing various features and don't really have any sort of game. Ultimately, I expect the project to collapse under its own weight. It's kinda close to that actualy as I'm finding issues between SFML and my target machine's ancient graphics card. Also, I recently decided that the way I structured my objects was giving me no end of grief and I had to spend a week or two restructuring things and accounting for those changes as well (was really close to giving up there). Plus there's a couple other ideas for projects that I got in my head that I'm curious to try and the current project has been going on for about two years without a lot of progress towards an actual game. Of course, those ideas would be quite unable to make use of anything that I've developed in the past two years too. So um... yeah... plan ahead as best as you can or else you'll probably end up with a mess like I have on my hands at the moment.

You probably have the same problem I have with your project (Only that mine isnt important). Well, good luck with it!

There's info in lots of places about how to write a GDD. You can start here:
http://www.sloperama.com/advice/specs.htm
http://www.sloperama.com/advice/lesson13.htm

Thank you for the links!

This conversation is taking place in the Game Design forum (I think someone moved it here from For Beginners). But implementing a game (after the GDD has been written) is not a proper subject for discussion in the Game Design forum. So you can post your programming questions in For Beginners.

I will do that, thanks!

@Navezof
Thanks for the reply!
About the modules: I'm already trying to do so as much as possible, and, uhm, wanted to say something here but I forgot...
About "Third": Wow, that's a really awesome idea! Never thought about that. I always just started to code the game and tried to take it as far as possible, thus most of the time I had not any "launchable" version... Gonna do that!
About "Fourth": By "you can work on the content of the module", do you mean the actual code? Or just details about this module?
About "Five": Let's hope it won't take that long
About "documenting": I will try to comment the code more. I just always forgot about comments while programing, and a few days later I understood nothing..
Thank you very much for the reply

@Misantes
Thanks for the reply!
The "template-system" seems pretty good - But how do you know how "far" to take it? Every style of game can have such unique games, isnt it a bit impossible to create a template fitting for many without having too many restrictions?

Also, sometimes aim lower. Plan to make something you know you can finish

Well, I've already finished plenty of little projects, but none of theres were games, they were just little tools for something. And I don't have so many ideas for games, so I actually want to get the joy to finish one of these ideas. I started with "game-developing" by just cloning existing games like Tetris, etc, but it became boring very soon.

@valrus
I can't really separate those two, since I'm "all alone" - I want to program a game, but I have to get the ideas by myself. As my first post may suggest, I'm... really new to game design, but I just can't avoid it, I think.
The idea with the physical design seems awesome, but I just can't think of a way to do something with my current ideas ^^

Again, thanks everyone for the replys !!

And sorry for my bad english.


Greetings,
-

@Misantes
Thanks for the reply!
The "template-system" seems pretty good - But how do you know how "far" to take it? Every style of game can have such unique games, isnt it a bit impossible to create a template fitting for many without having too many restrictions?

I personally keep mine really simple, just the basics. For my 2D template, I include all the boring code to open a window, load tile maps, implement a time step, maybe a character class and an NPC class with basic attributes like health and speed, some simple control scheme/physics/collision detection (nothing so complex that it would be difficult to change), ability to swap windows. I try not to include anything that will really restrict what I may want to do. Like, my 2D template just has a little guy who can run and jump, and collide with objects and load a new screen. That's about it. It's not a game really, but allows me to not retype all that stuff every time. And, I can just alter it any way I want and just focus on making the "game" at that point. It lets me experiment more with actual game mechanics and not waste a lot of time doing the same code over and over.

Most games have all these elements, regardless of the type. But, when it's all added together it's actually quite a bit of coding. None of it is really the "game" per se, but you'll still find yourself redoing all of it every time you want to make something if you start from scratch. Sure, some games won't fit neatly into that template, and in that case, I just edit as needed, maybe only keep the window creation/timestep and go from there and then save a new template type at some point as a new game-type. :)

You could even just save the elements individually and not even do a whole "template". Save a window creation function, a collision function, etc. but it amounts to the same thing. The point is to not have to redo the same code every time, especially if you're no longer learning anything at that point.

I think there's something to be said though for practice for practice's sake though. I wouldn't necessarily recommend reusing a template if you're still benefiting from the practice of doing things from scratch. But, at a certain point, you're no longer learning anything, and it's at that point that a template becomes really useful.

About "Fourth": By "you can work on the content of the module", do you mean the actual code? Or just details about this module?

It depends on the complexity/size of this module and your mood :D

You should be able to directly start coding simpler module, for exemple, in a case of an health system with only a variable for the health and a function takeDamage. But for something bigger, maybe a little more planning could be good.

It's only my opinion, but if you made good modules, the complexity of each module should be reduced enough to be clear even without planning first.