Unlike most software development, game development requires that the end product be that elusive thing called “fun”.
Because of this admittedly rather unusual requirement, it isn’t unusual for people from outside the industry to have the impression that game design is itself fundamentally a “fun” endeavor.
To be sure, the process of game design can be enjoyable, but generally in the same way that anyone who enjoys their job enjoys it.
So, what is actually involved in this kind of game design? (And, it should be noted, this is almost the exact same process I used on Star Trek Online‘s duty officer system or on many of the game modes over on Marvel Heroes.)
In ORG, ships are one of three types of a broader category called minions consisting of agents (people), facilities (things like shipyards, mines, refineries, military bases, and universities), and ships (freighters, medical ships, destroyers and other types of ship). The vast majority of tasks that a player will engage in require one or more minion to be temporarily slotted into the task, and thus unavailable for the duration of the task until it completes.
Players gain ships – and indeed, all minions – as rewards for tasks, or by purchasing them from other players, or by acquiring them from purchased packs. Behind the scenes, of course, the process is quite a but more complex:
Games like ORG can be seen as running on three basic layers – the engine, the game code, and the game data.
The engine represents the most fundamental code that handles things like drawing the user interface on the screen, interfacing the database with the rest of the code, coordinating the ability to purchase things in the game and have them show up properly in game. In terms of coding time, building the engine is almost always a far more expansive task than the game code.
The game code represents the game logic that makes a game like ORG, well ORG, and not Monopoly. The game code defines how tasks are processed, how durations are calculated, how rewards are processed, and a hundred other questions.
The game data represents the actual information for each individual task, each trait, each effect, each region, and so on. Whereas the tasks of building the engine and the game code are undergone by software engineers, the task of implementing the game data is undergone by designers. There is, even, an additional layer of distinction – design architecture (or sometimes just “design”) and design implementation. Whereas the game code is the actual programming code that tells the program how to process things, the task of design architecture is concerns itself with the basic gameplay decisions of how should the game process various actions by the player. Design implementation, on the other hand, is concerned with the replication, extension, and elaboration of the multitude of individual missions, tasks, player classes, items, and other elements that will vary depending on the type of game.
(Years ago, at the dawn of video game development, it was common for developers to wear multiple hats, and it was quite common to see software engineers, or artists, or producers also engaging in design; these days, especially on well-established and well-funded projects, these tasks are almost always fairly specialized.)