Best practice for code organization

What’s generally considered the best practice for organizing the code?
There are a few different ways that could be used for text adventures, and probably other games as we go along, but there’s two main ways I can see.

1st is the way Ben showed us, where each state has its own function. This would result in many many functions, especially if any one ventured forth to produce a game on the scope of the old Infocom games.

Another would be to use a switch to read the state and execute instructions for each one. The main result of this one would be that there is one or two very large functions that set the text, etc. I can see advantages and disadvantages to each, but I’m wondering if any one, especially Ben, has a knowledge or opinion as to the best practice to use for this type of game design.

Ideally you would remove all repetition from the code. Scoping out the game and story initially would enable you to make some significant decisions early on.

One approach could be to put each story fragment and associated options into an XML document. You would then create a specific method(s) for reading in the data. Ideally in such a way that it could be replaced easily with an alternate data source in the future, for example a database.

You would need to make some decisions such as whether to read in the entire story with all the options, or, just the initial one and then load in others as required, or maybe a middle ground, such as reading in the initial 10 for example.

Moving to an object oriented design would enable the crearion and use of objects to hold data and perform specific tasks.

All the while the plan would be to make the code base as light weight as possible, separating the story from the code. A further separate should be considered with regards to the front end.

I hope this is of use.

Yes it does. For Text101, I decided to use one method to change the game states and update variables. Then, it calls another method that updates the text, dynamically choosing strings based on game state and variables. Now, that does serve to make two huge methods, but I’m using a switch to parse the game state, so I figured that would make it easier to follow, and the bulk of the text builder method is the text, itself. Otherwise, the operation of it is very simple.
So, for the purposes of this short game, maybe I should put the text itself in to a dictionary inside its own class, to follow that best practice.

Privacy & Terms