Economy of scale and the construction of games

Economy of scale is an economic concept which, in brief, suggests that if you make more of something, each individual instance will cost less.  For example, creating one t-shirt might cost you $20, but if you were to make 100 of them, they would only cost you $2 each;  one tenth the price.  There are a number of reasons that this might happen;  for one, there are often once-off costs to “set up” the creation of something.  Making an action figure, you must first make a mold for the figure, and that process is expensive.  Once the mold has been set up, each figure you cast is relatively inexpensive.

I’ve mentioned before that MMORPG Tycoon 2 is a massive, complicated game.  So it seems to me that the only way I’m ever going to finish it is by designing it in such a way that I can get maximum benefit from economies of scale;  by making different things similar, I get large benefits in terms of re-use of code.  For example, the areas occupied by “Regions” in the game map are now defined using the same data structure that is used to designate the areas where quests take place.  That same structure is also used to define the space where a building exists, and subdivides into more instances of itself to create the procedural geometry which is being used for all structures and most movable objects within the game.  By making all of these different things use the one structure, it becomes worthwhile to improve that one structure, to make it easier to work with everywhere where it’s being used.

Similarly, in MMORPG Tycoon 1, I had hundreds of different types of UI buttons;  they were implemented largely independently, and implementing and managing them was a huge task.  In version 2, all of the new buttons I’ve implemented thus far are exactly the same;  they simply send a text message to my new “ScriptEngine” when they’re clicked upon.  Doing this has made it much, much faster to implement new UI screens, and modify existing UI elements.  By making them all the same, it’s faster to implement them.

I always have to remind myself that these benefits exist;  I keep thinking “oh, I’ll just go and implement this new thing by itself;  it won’t take long at all”, when things are always much faster, in the long run, to try to re-use as much existing functionality as possible, or to refactor that existing functionality to allow you to use it in a new way.

While I was implementing the “ScriptEngine” today, I found that I needed a string tokenizer.  A tokenizer basically breaks up a string into its core components;  words, numbers, etc.  Partway into the task, it occurred to me that I had already written a tokenizer inside my file reading/writing code.  However, it was written in such a way that it could only tokenise strings which had been read from a file on disk, not ones which were generated by code.  With only minor adjustments to the fsRecord class, I was able to have my needed string tokenizer in place in just minutes, instead of taking an hour or two to implement a new one for use exclusively by the script engine.

So now with all of my UI screens being named instances of a single class (so they’re all the same), and buttons being able to show or hide UI screens simply by sending a text command when they’re clicked, suddenly it’s trivial to add new screens, add buttons that summon them, and so forth;  as a result, I can create new UI in a tiny fraction of the time and effort that it used to take me in MMORPG Tycoon 1.  Which is lucky, because there’s an awful lot of it still to be created!