Economy of scale<\/a> is an economic concept which, in brief, suggests that if you make more of something, each individual instance will cost less. \u00a0For 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; \u00a0one tenth the price. \u00a0There are a number of reasons that this might happen; \u00a0for one, there are often once-off costs to “set up” the creation of something. \u00a0Making an action figure, you must first make a mold for the figure, and that process is expensive. \u00a0Once the mold has been set up, each figure you cast is relatively inexpensive.<\/p>\nI’ve mentioned before that MMORPG Tycoon 2 is a massive, complicated game. \u00a0So 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; \u00a0by making different things similar, I get large benefits in terms of re-use of code. \u00a0For 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. \u00a0That 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. \u00a0By 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.<\/p>\n
Similarly, in MMORPG Tycoon 1, I had hundreds of different types of UI buttons; \u00a0they were implemented largely independently, and implementing and managing them was a huge task. \u00a0In version 2, all of the new buttons I’ve implemented thus far are exactly the same; \u00a0they simply send a text message to my new “ScriptEngine” when they’re clicked upon. \u00a0Doing this has made it much, much faster to implement new UI screens, and modify existing UI elements. \u00a0By making them all the same, it’s faster to implement them.<\/p>\n
I always have to remind myself that these benefits exist; \u00a0I keep thinking “oh, I’ll just go and implement this new thing by itself; \u00a0it 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.<\/p>\n
While I was implementing the “ScriptEngine” today, I found that I needed a string tokenizer. \u00a0A tokenizer basically breaks up a string into its core components; \u00a0words, numbers, etc. \u00a0Partway into the task, it occurred to me that I had already written a tokenizer inside my file reading\/writing code. \u00a0However, 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. \u00a0With 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.<\/p>\n
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; \u00a0as 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. \u00a0Which is lucky, because there’s an awful lot of it still to be created!<\/p>\n","protected":false},"excerpt":{"rendered":"
Economy of scale is an economic concept which, in brief, suggests that if you make more of something, each individual instance will cost less. \u00a0For 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; \u00a0one tenth the price. \u00a0There are…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[24,20,25],"tags":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-e3","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/871"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=871"}],"version-history":[{"count":0,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/871\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=871"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=871"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=871"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}