Where does one begin when building an Engine/wrapper?

[Xecantur]

I've been trying to tie together a puny little engine however every time I get started I encounter a problem, I seem to lack the ability to design Modules/Nodes/Building Blocks whatever you want to call them. I'm very very very used to procedural programming I've not yet understood all the possibilities Object Oriented Programming brings to the table, Anyhow I suppose my Questions are:

1) How do you start out designing an engine? Is it on the spot(which in my experience is not working out) or do you sit down for a good long while and think about the types of methods and classes as well as what you need functionally from these objects as your going to build?

2) How do you keep track of the flow of execution in your OOP code? it seems the control of exectution can be very hard to keep track of in such large programs?

3) Do you document classes and methods(and or variables) as you code or do you just get something compilable then go back and write the documentation?

I'm sure these questions have common sense answers such as the 3rd one, but I'm wondering what experienced developers usually do when designing an engine.

[bstone]

If you're very very good with procedural programming then modules should be your best friend. Now in OOP the concept of modules is elevated a few orbits higher. Start with thinking about classes as your modules on steroids where modules can be arbitrarily small (as small as you need and still live in a single file as you don't have to rely on static scope of a C module so to speak), and you can have multiple instances of one module (objects), and you can have one module very similar to another without rewriting it completely but using inheritance and composition, then you start adding polymorphism into the mix and you're all set.

1) How do you start out designing an engine? Is it on the spot(which in my experience is not working out) or do you sit down for a good long while and think about the types of methods and classes as well as what you need functionally from these objects as your going to build?

If you're just starting out then both ways are doomed. You either end up with a mess or get the "paralysis from analysis" in most cases. Find a good balance. Later, when you breath with designs, you can get back to the on-the-spot approach and your experience will make it pretty smooth.

2) How do you keep track of the flow of execution in your OOP code? it seems the control of exectution can be very hard to keep track of in such large programs?

The flow of execution concept doesn't quite work for anything moderately complex. That's a correct observation. Google/wiki "design by contract" - that's one way to get a hand of it, on another level though. There are others as well but I recommend starting with good abstractions/interfaces anyway.

3) Do you document classes and methods(and or variables) as you code or do you just get something compilable then go back and write the documentation?

Documentation requires updating and quickly becomes stale and sometimes even misleading. Make your code be your documentation - always use readable and useful identifiers no matter how long they get (yes, you can use "i" for your loops but the 8 char identifier limits are long gone ). Have rules for distinguishing between action methods and predicates (e.g. use verbs and adjectives respectively). If you just coded a few lines that clearly need being documented or otherwise you'll forget why you added them - extract a local variable or a few from that code and name them in such a way that would reflect their purpose/specifics. If that can't be done using local variables then extract those lines into a new method or a few and name them properly. Keep your methods short, if one doesn't fit on a single page - split it and give good descriptive names to the new methods. It might sound simple but it works much better than any documentation. If you stick to something like that then reading your code will be like reading documentation that is always up to date. Don't avoid good old comments in places where you need to rant about some inevitable hacks but these will be rare and easily maintained.

[areay]

Why not grab the one of these frameworks and start from there?

http://www.ogre3d.org/tikiwiki/tiki-ind ... =Tutorials
http://www.ogre3d.org/tikiwiki/tiki-ind ... =Tutorials

After you've got your head around that and made some basic game with it you'll have answered most of your questions.

[Xecantur]

Thanks guys, areay I've already looked at the tutorial framework its kind of hard to distinguish what is a just an inherited pure virtual method, and what is just consolidation which I suppose it what I need to focus on more.

[Klaim]

1) How do you start out designing an engine? Is it on the spot(which in my experience is not working out) or do you sit down for a good long while and think about the types of methods and classes as well as what you need functionally from these objects as your going to build?

The current wisdom about this is to not make an engine first but a (game?) project first. See: http://scientificninja.com/blog/write-games-not-engines

If you have a project, you'll be able to have some used code. That used code then can be factorized in an engine. No engine has ever been successful without some concrete projects.

[areay]

...its kind of hard to distinguish what is a just an inherited pure virtual method, and what is just consolidation...

Does that really matter at the moment?

Sounds like you're already stuck in 'analysis paralysis' like bstone mentioned . You don't have to understand all the bits of those frameworks to start working on a game, which is what Klaim is (correctly IMHO) recommending you do. Just grab one of the frameworks and start on the tutorials, then when the Ogre stuff is all looking pretty easy, you can begin unravelling how the frameworks are pieced together.

[bstone]

Yeah, make games, not engines.

[Xecantur]

Heh I suppose that makes sense rather than piling on function after function and not knowing what functionality I'm looking for, I should just write what I want in a game rather than just what I maybe want or want to use later, thanks guys. klaim and bstone thanks for pointing me in the right direction

[Oogst]

As lead programmer at Ronimo, I wrote and designed most of the Ronitech (2D engine for Wii/PS3/Xbox360/PC/Mac/Linux/iOS, used for Swords & Soldiers and Awesomenauts), so I have a lot of experience in engine programming and design. I entirely agree with what was posted here that unless you have a lot of experience, you should make a game, not an engine. Otherwise you will constantly be making the wrong choices anyway, since you are not experienced enough to make the right choices without experiencing them in practical use.

I'm very very very used to procedural programming I've not yet understood all the possibilities Object Oriented Programming brings to the table, Anyhow I suppose my Questions are:

I really strongly advice against trying to make an 'engine' if you don't understand object oriented programming all that well yet. Or, well, you could start and learn on the way, but do realise that once you get a better understanding, you will want to throw everything away and start again anyway. So make whatever you feel like and learn as you go, and don't think whatever you make will be lasting for you once you know more. Do it for the fun and the learning!

1) How do you start out designing an engine? Is it on the spot(which in my experience is not working out) or do you sit down for a good long while and think about the types of methods and classes as well as what you need functionally from these objects as your going to build?

You first need to think about some of the core concepts, like how objects are created (new them yourself, or call the engine to create them, as Ogre does), and how platforms are handled (just one platform, or some flexible system for more platforms, and if so, what flexible system?). Once you decided on the core concepts, I advice starting somewhere (graphics makes most sense). Focus on that one part and don't get to something else until it is at least neatly done. It doesn't need to have a lot of features, but make sure you never go to the next step unless the previous step is good. Work iteratively.

2) How do you keep track of the flow of execution in your OOP code? it seems the control of exectution can be very hard to keep track of in such large programs?

This is indeed a really difficult thing to do. Awesomenauts+engine is now about 200,000 lines of code, maintained by up to 6 programmers, and it can get really confusing sometimes for the simple reason that it is so much.

There are many different ways of doing this. My prefered way is through managers. I have classes like SoundManager, InputManager, SceneManager and GameManager. My core frame loop just calls update() on each of these managers. Base managers have submanagers, so GameManager::update() goes on to call the update functions of CharacterManager, LevelManager and HUDManager. The benefit of this way is that it is very clear who is responsible for what, and in what order things are done.

I deliberately use very few Listeners, because they confuse what is done when. I don't want InputManager to call handleKeyPressed() in SoundManager, because then suddenly part of SoundManager is done during InputManager's update call. This is too confusing, in my opinion.

3) Do you document classes and methods(and or variables) as you code or do you just get something compilable then go back and write the documentation?

The core principe in my opinion should be Self Documenting Code. The names of functions, variables and classes should be clear. If I have a class SoundManager, then I don't need to add documentation that it manages sound.

Also, since you are not experienced enough yet to write an engine that others would want to use, you should not worry about writing the kind of documentation that Ogre has. Only add documentation where code is not clear without it, but do not add automated documentation generation like Ogre has. It costs a lot of time to do, is not fun to do (while learning, fun is key!), and whenever you change your code and forget to update the documentation (which will constantly happen), the documentation will be wrong anyway.

Finally, one last tip: REFACTOR! Refactor ALL THE TIME! Don't design your code too much before writing it. While writing it, constantly think about whether a different structure would be better. If it would, then refactor to that structure. Constantly strive for the clearest structure and constantly refactor to achieve that.

[phobossion]

This book is full of invaluable resources on the topic: http://www.amazon.com/Game-Engine-Desig ... 0122290631. However, it focuses on the low-level stuff more than necessary when working with a library such as Ogre. If you just want to make games, focus on designing a game and use a pre-made package by someone who focuses on engine development. Making a complete game engine with rendering, map editing, asset management, physics, scripting etc is a very daunting task and at the end you'll find out that you are getting nowhere with your game...