Console Adventure Game Structure
I'm a beginner, but have a slight knowledge of concepts from college 20 years ago. I'm trying to recreate a text based adventure game (L.O.R.D., if you're familiar) to get my feet wet. I've been following a few different youtube tutorials. The first started out with each area being a new method. It's functional, and ready for me to flesh out more of the mechanics, but also messy. The second divided each area out into their own classes, and pointed out how messy methods can get - agreed! They also suggested "as you learn, you'll see other ways to organize a game like this", using patterns such as singletons, state, or locator.
My question is, which would be the most efficient? Or, preferred, maybe is a better description.
6 Replies
There's really no best way of doing this but since this is a C# community, object-oriented is what is the language is best at. You would want things be mostly data-driven, with classes defining base concepts, such as an Area class that is intantiated for each area.
For specific cases, you can always created derived types with custom logic or try to generalize it so you can apply it to various areas.
That's roughly what the second tutorial had. The benefit of that was that you could start in any area and test it out. I'd imagine other structures would probably allow that also, but the method structure certainly didn't.
That's one part of a greater benefit. By being data-driven, you can make changes in runtime without changin the code.
In a larger project, especially gamedev, you want to expose things for designers to mess with, ideally having to write zero code.
In practice, this also means exposing data externally, in an editor or by modifying files that are read at runtime.
At what point do you switch from separate classes to methods in the class? In the tutorial I watched, they explained that spaces that weren't related should be split into their own class, which is understandable. But, if you're talking to the bartender in the Inn, should the bartender logic be in its own class, or just a method of the Inn?
If you have proper dialogue, you would have a Character class that gets instantiated for areas with characters. The Character methods get called when interacting with them, with the instance defining things like dialogue trees.
That's for a very generalized and fully data driven approach however which may be too complex for your needs. For a more code-based yet still generalized approach, you would have a base Character class with virtual/abstract methods like OnTalk, OnGiveItem and you derive the class for each character
With that, general structures like the layout of dialogue options, entering and exiting out of conversations can still be generalized through the base class.
The areas can define Interactibles which can include items, observations and characters.
Interactives can have base class methods for each of the verbs the game supports, with the base implementations outputting the generic "I can't do that"
Thanks for your help.