Hi, I'm new here after searching the web for a little help on game development. Let me start by saying I do know a good deal of both C++ and Java experience(Junior Computer Science Major) and plan on writing my game in C++ with the allegro library. I'm not completly new to graphics programming, I've made some basic games such as Breakout and Tetris while doing studies at my university.

Now I plan on doing an independent project, which is more of a complex game. To be more specific a side scroller, almost metroid like game and i am aware of the massive scale of the project and plan to do small iterations and add on. It's mostly just a personal project that I want to do for myself and to build up something for when I'm applying to internships to show my workmanship.

Now for my main concern is not exactly how to program anything (as of yet), but rather when do I stop writing down ideas, concepts and documentations of what I will be programming and when do I actually start programming. I, at times, feel like I'm trying to be far too specific in some of my documentations and writing down every little thing I can imagine. While I know it is important to have a solid and sound idea to work off of, I just feel like I'll trap myself in the design stage and never actually get to the meat and potatos of the project.

Thanks!

My advice is that as long as you're thinking about the high-level stuff... engine architecture, etc... then you should keep thinking about it and planning until you have a complete, clear idea in your head of what you want to do, why, and how it all works together. Then, at that point, you should start writing code.

The high-level stuff is what will be hardest to change later, so it's worth thinking it through first. At that level, it's also worth asking questions or advice on forums like this, because you might get unexpected ideas that could make a big difference in how you approach the project. You might also want to post with what you're planning to implement, and then have people ask you questions. Once you can justify all your decisions and explain why each approach was chosen, then you're good to go. But if you cant, then it could mean that more thinking or rearchitecting might help.

Hope that helps.

Turn your ideas into some technical requirements for your project.
Then wear the developer hat and apply details to each entry, explaining how you will achieve that through programming. (Don't do them all at once)

By that time, you can start implementing bits. Like 0r0d says,

The high-level stuff is what will be hardest to change later, so it's worth thinking it through first.

With that in mind, think general game loop, UI, display modes and file I/O.
Then think about the concepts elevating the application into a game. (create a level format etc.)

It's nice to get back to that list. At first it might be a pencil thing, but this could eventually end up as your roadmap.
I love lists...

The time taken to think about something before doing it usually pays off.

With that in mind, think general game loop, UI, display modes and file I/O.

Yeah, stuff like this. Think about whether you want your code to be platform-independent, how the rendering engine will work (if 3D: low-level thin wrapper around DX/GL, or higher level?), how the object hierarchy works, how you will expose object attributes to editing (if at all), whether you're going to hard-code game logic or use scripting,...

Personally I would start with the definition of what a game object is, and what the hierarchy is. That's the heart of any game engine, and everything else radiates out from there. Once you get a good sense of what game objects are then you start to know how the rendering engine needs to work, how loading, exporting, editing, etc all need to work.

Thank you both for your replys, this helps me think a little clearer on the design stage. While I know I have much to go on this stage, it also helps to know what I should be thinking about in this process. It's good advice to have to be looking at the ideas I would want to implement and to completely justify implementing them. I will most certainly be back to these forums to discuss further on my game as I flesh it out to obtain opinions and possible ideas as I go.

Anytime!

Different people work differently, but my personal experience is that I benefit a lot from implementing parts of the project early on, even if in a simplified form. I find that, by writing a quick prototype of some key part of the project, I will often learn things that will inform the design. So I don't want to advance my design down to little details before I have gotten my feet wet.

Sometimes I end up throwing away most or all of the code I wrote for the prototype, but I have never considered it wasted time: If I have to throw it away it's because there was some flaw in my original plans and I just saved myself a lot of aggravation by changing my mind early in the process.

For a game, the level description (on disk) and the scene data structure (in memory) are probably the places I would start designing, and perhaps the interface with the AI (depending on the genre). I would probably try to prototype the gameplay early on, since that will define the essence of the game. If you are going to have a level editor, try to get the essentials of it working as soon as possible. Graphics can start as flat-shaded blocks or colored squares.



I saw a documentary on Pixar, where they described how they put together a crude version of the movie very early on. At the beginning the voices won't be professionally made (it's probably the screenwriter's voice or something), the missing animations might be replaced with a still image from the initial artistic concept... Eventually the movie is fleshed out into a finished product, but along the way people can get a good picture of what they are building and they can change things if they are not working. I feel the need to have something like this in my software projects, where all the basic structures are there and one can use the software, even if most of the functionality is missing or held together with duct tape.

Then again, some organizations would consider me an unruly hacker and not a serious software engineer.

This problem plagues me all the time, especially because I get anxious and jump the gun sometimes. I think what's most important, especially if you're building things from scratch, is to get the design for all of your classes and major functions done before you write any of them. Do not go coding those without having a specific, clear, implementable strategy first. If you do not heed this warning, you will be going back to change those functions again and again and again, and I mean before you even have a running prototype. It's just a lot easier to miss the forest for the trees in the design of your code when you run in head first.

As for features and all that, I would say as long as you design your base little "engine" code to be easy enough to modify, you should probably try to implement your original conception of the game in as simple a form first before you start making in-depth plans about it. You may play it and say "I don't think this will ever be fun, no matter what else I throw in." Then you can just change things, because you haven't gone through painstakingly building the whole thing up yet.

Most of all, aside from the pre-planning stuff, I'd like to add that you should keep a blog (either your own, or here on game dev) detailing your reflections on the process as you go through it. This will help you learn the most from it, as you'll have an in-depth view of your process later on (something that human memory just can't give you) for critiquing and study. But that's only if you're seriously into bettering yourself as a programmer and a person. Good luck.

Even more great advice! I actually like that idea of creating a prototype of the broad spectrum of some implementations, I didn't really think about that to be honest. So my question now is should I just start with some broad designs, prototype it, see what's working and what's not and design from there? I feel that would be the best way to go because I notice as I'm going through writing down designs I end up adding more and more to the game and may end up over complicating it. I'm sorry if I come off as a bit naieve on the whole process, I'm a bit new to doing larger self motivated projects.