Jump to content

  • Log In with Google      Sign In   
  • Create Account


Unit types - inheritor classes or functions


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Kanadaj   Members   -  Reputation: 124

Like
0Likes
Like

Posted 27 February 2013 - 05:32 AM

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?



Sponsor:

#2 Sandman   Moderators   -  Reputation: 2093

Like
1Likes
Like

Posted 27 February 2013 - 06:01 AM

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.



#3 EWClay   Members   -  Reputation: 659

Like
2Likes
Like

Posted 27 February 2013 - 06:58 AM

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.

#4 noizex   Members   -  Reputation: 856

Like
0Likes
Like

Posted 27 February 2013 - 07:24 AM

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.



#5 LorenzoGatti   Crossbones+   -  Reputation: 2670

Like
1Likes
Like

Posted 27 February 2013 - 09:44 AM

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.


Produci, consuma, crepa

#6 Kanadaj   Members   -  Reputation: 124

Like
0Likes
Like

Posted 28 February 2013 - 02:38 PM

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 ^^






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS