I'm trying to write a generic turn-based strategy game, with a few unit types, building types, etc. Since this is something I've never done before, and its not a very easily searchable subject, I'm asking here.

[See title question] I thought of two ways to implement unit/building types.

The first is the most obvious, with each unit being a complete object in-and-of itself. This means that it would have all stats, abilities, etc. contained in the object. A factory method would create these objects when units are trained. The main drawback is that each unit of the same type would also have duplicate information, like movement points, that are constant among all units of that type. Of course, in the event of stat upgrades, these could be changed directly, so they would no longer be duplicate.

The second method of doing this, is storing basic unit info, such as base health, movement points, etc. in a Unit_Types class. The unit object could then be done away with completely in favor of a list of unit types (whose important stats are kept in Unit_Types). Alternatively, the unit object could hold unique info, such as stat upgrades. This seems better because its less data being used, as well as making unit type upgrades simpler. The unit would just change its type field to its previous type plus 1. But this might be much harder once I actually begin writing it and encountering issues I haven't thought of yet.

Is there a standard practice? It seems like one of those things where one approach is way better than the other in 90% of situations.

  • \$\begingroup\$ It sounds like you've described the type object pattern. Have you had a specific problem implementing either of these two strategies that you need help solving? If not, then this looks like a judgement call you'll need to make for yourself. \$\endgroup\$ – DMGregory Sep 16 '17 at 20:51
  • \$\begingroup\$ That's exactly it. Thanks for the link. In my hours of searching, I hadn't found anything like that (probably just wasn't using the correct terms). I've implemented the first structure I listed in the past, but the second I had just considered and it seemed difficult to structure. But that article clears it up. \$\endgroup\$ – Prime624 Sep 16 '17 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.