11 replies to this topic

[makuto]

Hi! I've been working on a game engine for a big learning experience and possible future use, and it's going along quite nicely. This is the code on SourceForge: http://sourceforge.net/p/woodenfoot/code/ci/26f967bdaa7291265910bf93273384fa41b73335/tree/trunk/Source/

Would anyone care to go through the little that I have done and give me some tips on the structure of the engine and my coding style? I've based the structure on what's discussed in Game Coding Complete, 4th ed (strongly recommended). It's in C++ primarily targeted for Linux (I'm on Ubuntu right now), but should still be platform independent as most of the code I've completed is basic C++ constructs.

The main portions that are far are the process manager:
http://sourceforge.net/p/woodenfoot/code/ci/26f967bdaa7291265910bf93273384fa41b73335/tree/trunk/Source/ProcessMan/
And the event manager:
http://sourceforge.net/p/woodenfoot/code/ci/26f967bdaa7291265910bf93273384fa41b73335/tree/trunk/Source/EventMan/

The demo.cpp files demonstrate the use of that specific component.

The main thing I'd like to get reviewed on is my overall coding style. What do you think of it?

[Goran Milovanovic]

Many of the files are empty ...

The ones with actual code seem convoluted: Whenever you have so many "managers", you should take a deep hard look at actual game requirements, because it's very likely that the game in question doesn't actually require a grand process/event handling architecture.

Build games, not engines.

[Hodgman]

One quick point: you've committed the generated files (e.g. .o) into version control - don't do that

[makuto]

Many of the files are empty ...

The ones with actual code seem convoluted: Whenever you have so many "managers", you should take a deep hard look at actual game requirements, because it's very likely that the game in question doesn't actually require a grand process/event handling architecture.

Build games, not engines.

That's true. The reason why I've started with the engine is that I got the book Game Coding Complete and am trying to follow along a little bit. Would you recommend I stop making the engine for a time and make a few games? The way I see it there are only 4 parts of a game that are really needed:

• Input via keyboard, mouse etc.
• Output via sound, graphics, haptic feedback etc.
• Objects (holds world, actors, interface, etc.)
• Processing/execution

If I made a few games from those components and saved the parts that would be very good to reuse, then added them to this engine, would that be a good idea?

One quick point: you've committed the generated files (e.g. .o) into version control - don't do that

I can't figure out how to delete any files or folders from SourceForge/Git. Do you know how? That's why there's a lot of .o's, old files, etc.

[thedevsykes]

Most development studios i've come into contact with in my local area don't build engines. In fact i'm with that regime, dont build an engine, build the game! The issue is, games are so diverse and your engine won't fit all problems. A better idea, as you've clearly pointed at is to take the reusable components of your game, and reuse them in other projects, eventually, you'll have compiled a lib of all your reusable systems. Personally I try to keep reusable components as independent as possible, but sometimes you just have to link them, but do that while building the game.

For example, any scene nodes may need to know about the rendering system, etc etc.

If you try to build an engine, (not saying you can't, but its a hell of a job) and you haven't built a whole lot of games, then how do you know for sure what you need ? Sure the book will take you along the path, but its generalised concept, you'll find that sometimes an engine is too much work for little gain.There fancy and nice, but in my personal opinion not very productive for a wide range of concepts.

So take what you can reuse, and pick and mix your components for any future games you may make, it creates a more flexible way of development in my opinion.

[makuto]

Thanks for the tips! I guess I will pause this engine for a bit.

[Goran Milovanovic]

Would you recommend I stop making the engine for a time and make a few games?

Yes.

For example, any scene nodes may need to know about the rendering system, etc etc.

I would also recommend holding to the KISS principle: Don't make some convoluted tree structure (scene graph) for a situation where a simple array would work just fine. There are various benefits to that: Operating on contiguous chunks of memory is far more optimal for cache, which can result in higher performance (significantly higher, in some cases). Also, arrays, being relatively simple structures, are easier to reason about, for nearly everyone.

[makuto]

Would you recommend I stop making the engine for a time and make a few games?

Yes.

For example, any scene nodes may need to know about the rendering system, etc etc.

I would also recommend holding to the KISS principle: Don't make some convoluted tree structure (scene graph) for a situation where a simple array would work just fine. There are various benefits to that: Operating on contiguous chunks of memory is far more optimal for cache, which can result in higher performance (significantly higher, in some cases). Also, arrays, being relatively simple structures, are easier to reason about, for nearly everyone.

Thanks! Would it be a safe decision to use Python for a game I'm entering into a competition and slowy migrate highly processed Python into C++? Most of my fellow peers working on the project aren't very seasoned C++ coders and I like programming in higher-level languages, but I still want to be able to do heavy processing (for more complex game mechanics) with the industry's C++ (which I have been learning & using for ~3 years).

Also, I was thinking of making one of those projects where I add a few things every week and the game slowly grows from it. It would be extremely nice if I could implement a simple Input Output Object system in C++ and code all the object-to-object interaction with Python. Basically, some C++ would loop through the object array and call each object's update function, which is where the control is passed to the Python script. Is this possible with Python?

[Goran Milovanovic]

It's relatively easy to interface with C/C++ code from Python. A google search for "python c modules", "python ctypes" or "python SWIG" should provide you with all the relevant information.

However, before you commit to anything, I would recommend writing the whole project in Python first, and then running a few tests; It's very likely that Python is more than fast enough for what you want to do.

If it's not fast enough, you should profile to find the "hot spots", and then try your best to think of a better algorithm to get around them.

If you can't find a better algorithm, then you should write C/C++ code to handle the bottleneck.

[makuto]

Ok. Thanks for the tips

[thok]

I can't figure out how to delete any files or folders from SourceForge/Git. Do you know how? That's why there's a lot of .o's, old files, etc.

To remove files from git, do `git rm <filename>`, then commit.

[makuto]

Thanks Thok!