Unit types - inheritor classes or functions

Started by
4 comments, last by Ruszny 11 years, 1 month ago

Heyo guys, I have a question about the most optimal solution when it comes to developing games in an object oriented environment (C# atm - I'm trying to go with C++, but I still have a long way to go...)

So, I'm having a base Unit class. The question is wether I should add a string or enum marking the type of the unit -in this case I'd use functions to create the proper unit-, or create inheritors of the base class, then create instances. I'm the units will have different damage reduction functions, though I can solve that as well using delegates.

Also, I've heard that you should try to separate the graphics from the rest of the game, so it's easier to maintain and port. But in case of a 3D game (I'm not trying to do that anyway, just out of curiosity) how can you solve this, when you need the 3D engine to handle collisions?

Advertisement

So, I'm having a base Unit class. The question is wether I should add a string or enum marking the type of the unit -in this case I'd use functions to create the proper unit-, or create inheritors of the base class, then create instances. I'm the units will have different damage reduction functions, though I can solve that as well using delegates.

The former is definitely better than the latter. The former is a nice data driven approach which needs little or no inheritance, is easily extended with new units, and can be populated easily with data from a database or file. The latter hardcodes your unit types into an inheritance tree (which will likely grow complicated as you start trying to share behaviour between different unit types) and makes a data driven approach much harder, or forces you to recompile every time you want to tweak stats.

Also, I've heard that you should try to separate the graphics from the rest of the game, so it's easier to maintain and port. But in case of a 3D game (I'm not trying to do that anyway, just out of curiosity) how can you solve this, when you need the 3D engine to handle collisions?

A 3D engine will usually contain a rendering engine and a physics engine, which may be completely separate. The game logic code will deal with both of them, but they won't necessarily know about each other.

So a game object will have two representations, and while that may seem like a waste, there is little overlap between what the two systems need, and the data structures can look entirely different.

Mind that if you're going to use C++ and enum for Unit type, its compile-time only and you won't be able to extend your unit types in runtime. Worth mentioning if you're going for data-driven unit creation, from some config file for example - you won't be able to add new enum without recompiling your code, so if you need this capability, you may need to create your own Type class, or use strings or anything that can be created dynamically.


Where are we and when are we and who are we?
How many people in how many places at how many times?

In a normal data-driven design, what a Unit instance needs at runtime is not the name of its type, but a pointer or something equivalent to a UnitType instance, containing read-only data and function pointers. The use of string or numerical identifiers in the engine can stop at level loaders, script interpreters or the like.

Omae Wa Mou Shindeiru

Haha thanks, silly me forgot about extending the game after release - not that it would be such a big game, so I think recompiling is not that much of a problem, but wonders happen, and rewriting then would be painful -.-' Well, I'm still a beginner in these matters and I've never experienced a 10 minutes compilation time :3 I'm trying to aim low since if I finish this game, it'll be only my second game - the first one was a simple logical game, not much of a problem... I hope I can finish it, though I still don't know where and what kind of graphis I'll implement... But, you know, you have to start somewhere ^^

This topic is closed to new replies.

Advertisement