Question

I am developing a simple text-based game. In this game, the user is able to collect items and store them in an inventory.

My question is: how should I organize the internal structure of my game so that I can load these items in an efficient way?

I need to be able to create fresh instances of an item whenever the user acquires an item of that type, or when instantiating any feature in the game that contains items. In order to do so, I feel like I need some sort of "master list" of all items that I can just copy out of by indexing into the correct location in the list.

I've come up with two potential solutions:

  • Hard-code this entire giant list into a data structure within my game

  • Somehow load these items from an XML file at startup and then populate the "master list" of items on the fly

Pros of option 1:

  • Relatively easy
  • No IO time
  • Allows me maximum efficiency in designing the actual item objects

Cons of option 1:

  • Hard to maintain
  • Bloats source code
  • Very tedious to implement

Pros of option 2:

  • Easy to add/remove/modify items
  • Allows the user to customize the game if they want to

Cons of option 2:

  • Requires that I design my objects much more carefully so that they can be built on the fly and stored

  • Requires that I perform a deep copy from the master list each time I need a new copy of a specific item

  • I have to write an "item-builder" that is capable of translating the XML input into an actual item object in memory.

Neither of these ideas feels very good to me. Is there something obvious I've missed?

Was it helpful?

Solution

Go for option 2 and replace a deeply nested class hierarchy with a lean entity-component-system design.

If you want to know more about why this approach is widely used in the game industry and how to implement it in all details, you may be interested in Mike McShaffry’s excellent book “Game Coding Complete” (if there is still a recent edition).

Licensed under: CC-BY-SA with attribution
scroll top