Hi everyone,

This post is really like a message in a bottle, I not really looking for a unique absolute answer, more advises and game making wisdom !

For 4 months now I'm trying to develop an engine for a 2d action platformer with pygame library en pyopengl. I've got all the tools in terms of library but I'm really missing conception experience in object oriented programming. For now, I seem to go deeper every day, and the more I dig the more difficulties I encounter. I often restart for zero.

Thing is I don't really know how to describe my game actions in the first place so I run into programming just to realize that I forgot a huge thing. Now I'm stuck again (just forgot to implement an artificial intelligence decision system...)

The traditionnal object oriented methodology (user story, sequence diagram etc...) seems to not fit completly the conception needs for a game. So I ask you how you work !

When you start a new game engine totally from scratch (I mean no game maker or unity, not necessarily a very low level language), how do you plan your developpement ?

(For now it is just trial and error, but it's hard to ascertain wether or not I made a mistake sometime !)

Buy this book:

http://www.amazon.co.uk/Game-Engine-Architecture-Second-Edition/dp/1466560010

Wow... well... that was a thousand pages advice !

I would have preferred a methodology or as the topic's title says general advises... no offense intended.

But, indeed, after reading some pages on amazon, it seems simple enough to pick some topics. I'll give it a go maybe.

My question is maybe too generic...

My question is maybe too generic

Bingo. You're asking a very big question and really it's the topic of years of study and practice. People could offer relatively tiny snippets of advice that you could apply, but it wouldn't help you enough to satisfy your needs. A book like that is invaluable and you're going to get more use from it than anything you'll be able to get from people on these forums.

I've been developing proprietary engines for the better part of 4 years, and what I've learned is to start with the lowest level things and work up. I always work with a node system. Everything is based off of a node. A node can have a parent, a child, and 2 siblings. When the update function of one node is executed, it executes the update on the parent, child, and sibling nodes. Once a node system is in place, I create specific object types (entities, particle systems, players, etc.) that inherit the node type (I use c++, so class linking is rather simple.. I've never worked in python, so I can't say how any of that works). Once all of that is in place, I worry about the higher level stuff like rendering, sound, and input.

Software development is an iterative process. You need to constantly refactor and evovle. So don't be afraid to do that.

Personally, I spend a great deal of time writing down all that I wish to include in my engine. I then break them up into small modules. I always have a game in mind when I'm writing an engine. I run the game through (in my mind) the modules that I've written down and see if I've missed anything.

Have a clear picture of what kind of games you wish to develop with your engine. Think up a few full fledged demo that you would like to write once your engine is done. Once again, this is an iterative process. When you've run your simulations a few times, you will slowly see new relationships and modules emerge. Add them to your list and do the simulations again. When you reach a point where you're not adding anything new, stop, get out of the loop and start writing.

I would recommend this book: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Code examples are mostly in C++, but the general idea carries over to all OO languages.

It's okay to have forgotten or missed something. Write code to be reusable and as decoupled as possible. This will allow you to add new modules easily.

While difficult to learn, I would strongly recommend you look into TDD: http://en.wikipedia.org/wiki/Test-driven_development

This will help you catch bugs early on and TDD will force you to write decoupled code.

Edit: Forgot to add. I'm fairly new to game programming. But not new to software development in general.

Thank you for your answers.

It makes me feel I'm on the right path (which was in fact what was behind my question I think !)
The book suggested by axefrog is really great and I read things that also makes me feel I'm working the right direction.

I always have a game in mind when I'm writing an engine.

I've indeed a precise idea of the game I'm developing.

I spend much time writing down things on my white board !

Do you have experience making simpler games, or are you jumping straight into the 2nd platformer? I'm guessing the latter.

Writing simpler games and working up to what you want to do may seem like the long road, but typically it's the better way to go. Because trying to write a program that's significantly above one's skill level is intensely frustrating. It's just not worth it. Believe me--I was one of those guys.

The typical progression I'm seen is something like Pong, Tetris, Pacman, 2 platformer. Pong should be doable, or be an attainable goal if you don't currently have the skill for it. After that, follow the list in order. Each game builds on concepts learned from writing the previous one, and introduces new ones.

Don't worry about writing perfect code. Write working code, and if a section of code feels clunky or you just think that there must be a better way to do this, use big obvious remarks so you can find that bit easily later on.

After you've finished the game, go back and take a second look at the sections of code you flagged. Now is the time to research better approaches. After that, move on to the next game.

It's quite likely that you will discover that some of the code used on the previous game will be useful for the current one. Some more code could almost work but would need to be tweaked a bit, or reworked into a more general approach so that it can accommodate both games.

As you work your way from game to game, you'll gradually develop a code base of things every game needs and things frequently useful in many different games.

There's your engine.

Figuire out precisely what you need it to do and avoid "Creeping Featuritus" which can cause inclusion of elements you dont really need (and add unneeded constraints or work).

If you find yourself saying "it would be nice to have THAT" then you need to figure out early whether you need it or not.

Retroactively changing the engine to have features you 'now need' can be counter productive and quite wasteful of effort.

Do you have experience making simpler games

Yep (pong, arkanoid clone, simple platformer...), even it's almost 2 month I've not create something functionnal.

I'm ok on some topics like collision, sprites, state machines and event handling (not enough on this last one !)...

That's why I'm now stuck in conception problems. I know what to do, it's more a matter of where to do it and how to split repsonsabilities among my classes.

Figuire out precisely what you need it to do

I have a precise and documented idea on how the game works... so I thought.

For example, I worked hard on how the player behave, but not so much the ennemies, that's why they're now lacking a brain !

The next aim for me is to provide a functionnal level of my game. I think I'll need more specifications.

Though my previous so called games were clearly "Creeping Featuritus" , I'll try to avoid that now (but all short sometimes !)