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?

Improve this question
8
  • 2
    "Is there something obvious I've missed?" Yes, that json is better than xml. :)
    – candied_orange
    Jul 11, 2020 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.
    – CCD
    Jul 11, 2020 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, 2020 at 2:09
  • 1
    Sounds good. The less code that knows about the need to deep copy the better. : )
    – candied_orange
    Jul 11, 2020 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, 2020 at 13:07

1 Answer 1

Reset to default
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
1
  • 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!
    – CCD
    Jul 11, 2020 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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