When to start actually programming

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.

Love the Pixar example. I think the rough outline is called the storyreel!?
Most professional artists work the same way. They don't render one part of a drawing after the other ... they go from rough rendering to the details for the whole piece of art.
So I would write the rough game design and the more technical documentation at the same time ... and add details as needed.

The problem is that even with that approach you might fall into the trap mentioned above (having to throw away all the code).

How well do you know the theory behind software architecture?
One approach that might help is developing low-level functionality as libraries that your game project uses.
That way you are less likely to be tempted to write god classes or go for quick/hackish solutions (write code where it doesn't belong).
Of course that complicates the build process.
But if you have to throw away the prototype code of your project ... maybe the functionality in the libraries can still be used.

I'm a fan of this article:
http://www.javacodegeeks.com/2011/10/if-i-had-more-time-i-would-have-written.html

It covers the jumping-the-gun-topic.

I personally would probably use a SCRUM based approach:

- Write the features of the game (product backlog).

- Turn the product backlog content into stories.

- Start working on stories in Sprints.

Your don't need to implement features right away. But you need to be aware of the features you might want to add in order to write a frame that offers a way to add those features.

If you don't know how to do that ... maybe just work on bringing the most simple versions ("Hello World!"-style) of those features together in a simple project.

The sooner you can get something working the better. Start with the simplest idea it's possible to implement and implement that. Pick something you have a chance of getting completely prototyped in 2 weeks. This will help you:

• figure out if what you want to do is technically feasible
• figure out if you actually like it

The next step is building enough so that you're comfortable showing it to someone else. Try to reach this step as soon as possible. After all, it's other people who are going to be playing your game the most. Ideally this will happen within a month. This will help you:

• figure out if other people actually like your game
• help prioritize which of the things you already know need to be done, should be done first

I recommend showing it to people who will be both honest and supportive. You need both. Show it to more than one person. This will be scary. Do it anyway.

Just because one person doesn't like it, doesn't mean it's not good. Try to listen to the people who don't like it, because you'll learn a lot, but take what they say with a grain of salt. If you think your idea is good, chances are there are at least 100 other people in the world who do, too. Your job is to find them.

Find at least one fan, someone who thinks what you're doing is awesome. Show it to them regularly and listen to their feedback. They will keep you motivated and on track. If you can't find anyone in your life like this, use the internet.

The process described above has most of the core features of Agile Development without all the extra crap designed for managers in a bogus corporate hierarchy.

Some notes about this process:

It is iterative. You will modify the structure of existing code over and over again, especially the new code, without much affecting it's functionality. This is not a bad thing. It's called Refactoring. Learning to embrace it will make you more productive and help you to discover new things about design, as you code. It is at the moments when you begin a refactor that you should consider the forest and the placement and shape of the tree you are about to plant.

When you show your game to people, their suggestions and criticisms will sometimes surprise you. This is good. Some of the surprises will be useful, some won't. Take care to decide which is which. A hint in this area: the useful surprises usually turn out to be very useful. The others usually don't make much difference either way, they're just a time sink distracting you from the useful stuff. Knowing who your audience is will also help with this.