2

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?

  • 2
    "Is there something obvious I've missed?" Yes, that json is better than xml. :) – candied_orange Jul 11 at 1:58
  • Noted. But what about the general structure of my solution? The second one is pretty robust, but is also high intensity in terms of design. – Aaron Jul 11 at 2:08
  • My instinct would be to adopt a design that allows for both. The less code that knows which way you went the better. – candied_orange Jul 11 at 2:09
  • 1
    Sounds good. The less code that knows about the need to deep copy the better. : ) – candied_orange Jul 11 at 2:13
  • 1
    also if you arent wed to java there are languages with a lot baked in for text games e.g. inform 7 – jk. Jul 13 at 13:07
5

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).

| improve this answer | |
  • Thank you. I had already thought of a system close to this as a way to try and avoid creating a ton of dependencies. I'd break the items down into their lowest-level functionality (inert, consumable, wearable, etc) and just add "functional" objects to them on the fly to add functionality to each object. So this is very helpful as I can avoid re-inventing the wheel! – Aaron Jul 11 at 19:28

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.