[Solved] Game engine design basics

Topics: User Forum
Aug 11, 2012 at 5:06 PM
Edited Aug 11, 2012 at 5:07 PM

I've managed to set up a good proof-of-concept that shows my game idea is plausible and might even be fun. I'm a bit bothered by how I "had" to pass some arguments around in what felt like an unnatural way, and I could really use some help with how to design this kind of thing for scalability.

My Entity constructor (I currently consider an Entity to be any physical object) looks like this:

public Entity(World world, ContentManager content, Vector2 position, string textureName, bool isStatic)

Where the Entity is given a rectangular body and a texture. How can I get rid of the first two arguments? It doesn't seem natural to me that entities need to know about the world they're created in, or about managing files with the ContentManager (would prefer changing string textureName to Texture2D texture for example). Entities are created when the Map is loaded, and I'd prefer if the Map could somehow manage the World on Entity creation. What's a good solution to this?

Thanks to anyone patient enough to help out.

Aug 11, 2012 at 9:12 PM
Edited Aug 11, 2012 at 9:20 PM

What you are describing is a pretty common problem in modern systems. It's due to the fact that a game entity is no longer just and abstraction of a mostly graphical thing but it's actually an aggregation of assets and behaviors that are provided by a wide variety of subsystems (graphics, audio, physics, ai etc.). Thus a classical object hierarchy starts feeling quite unnatural as you noticed. Furthermore it becomes quite hard to implement modern practices like dependency injection, mocking and unit testing.

Perhaps a better approach is a component-based approach. It quite widely used in .NET programming everywhere so you're definitely familiar with it. Also XNA has it built-in (GameComponent). Some links:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://stackoverflow.com/questions/1901251/component-based-game-engine-design

Aug 14, 2012 at 3:50 PM

What I normally do (which hasn't given me any problems so far) is place the world in a static class or a singleton class then call it when needed throughout my game. You could also make the other parameters properties in your entities class that are set upon instantiation (they could have default values that are set in the constructor in case you forget).

Aug 18, 2012 at 10:04 AM

After doing a lot of reading starting from jerrysb's links I refactored my way towards using XNA's component based hierarchy and it's working marvelously so far.
And I also used a static class for my world. Problem solved and knowledge gained!

Thanks very much for your help!