Code & Engine Structure Review?

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.

One quick point: you've committed the generated files (e.g. [font=courier new,courier,monospace].o[/font]) into version control - don't do that

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. [font=courier new,courier,monospace].o[/font]) 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.

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.

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

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.

[quote name='makuto' timestamp='1347293538' post='4978613']
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.
[/quote]
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?

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.

Ok. Thanks for the tips

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 , then commit.

Thanks Thok!