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?
Here's a quick snapshot of some of the things I have been working on most recently: Making Ships
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.)
In ORG, tasks have a extraordinarily wide range of utility, some more story-oriented, some quite practical, even mechanical. As has been described in earlier dev diaries, building something like a dreadnought is, indeed, a single task, but the task to build a powerful warship also requires other things - engineer agents and shipyard facilities to slot, and component items as inputs that will be consumed.
For example, assembly of a medical ship might require varying numbers of components such as:
- Exothermic Chemical Engines
- Life Support Systems
- Cryosleep Tubes
So how do you get, say, a Life Support System? You could buy it from another player, or even claim it as bounty if you decided to engage in a little, ahem, commerce raiding ("piracy" has such a nasty ring to it...) But the most common way to get the life support system component is simply to make it. Whereas ships (and facilities) are made up primarily of components - things like the aforementioned hulls, engines, sensors, and lift support systems - components themselves are made primarily from refined raw materials like:
- Carbonates (water, carbon in various forms, etc.)
- Silicates (sand and non-ferrous minerals)
- Hydrocarbons (volatiles like oil and methane, as well as the products of such including fertilizers and plastics)
- Metals (iron, aluminum, titanium, etc.)
- Fissiles (radioactive materials, most often used as high-quality fuel)
- Helium-3 (fuel material for fusion generators, in addition to cryogenic freezing applications)
And how do you get the refined versions of these? Simple - you run tasks to refine the raw materials into refined materials. And, at the very beginning of the road, you get raw materials by running tasks to mine those raw materials out of moons, certain dense atmospheres such as Venus, Titan, and the various gas giants of the solar system.
To summarize then, you take raw materials, refine them into refined materials, then use those to in turn manufacture components, which are then finally used to assemble, among many other things, ships.
Here, of course, is where it gets really messy, because at each stage of this process, the inputs and outputs have to be defined for both varying levels of successful completion of the task (critical versus success versus failure versus disaster), for duration (some tasks take a couple of minutes to complete, some literally days), for real world availability considerations (Helium-3 isn't really much found on Earth, but it sure is on the Moon and Uranus), for game balance considerations (what happens if one resource, say Metals, are very rare in an orbit like the Kuiper Belt? What impact does that have on gameplay and player-to-player interactions?)
For this problem, I did what video game designers the world over will so often do - make a spreadsheet. Microsoft Excel is very commonly used for this, but these days I generally use Google Sheets.
It's not just about plugging in numbers in columns - most of the columns you can see in these snapshots are themselves the product of built-in equations. For example, the Total Unrefined Carbonates column for building, say, a Nuclear Reactor isn't something a designer plugs in directly, but is rather the derived spun-out aggregate of the number of, in this case unrefined carbonates, that were used to make all of the components necessary to make a nuclear reactor.
This has a number of uses, not the least of which it allows a quick way for a designer - in this case me - to make changes at one end of the process and immediately see the impact on other parts of the system. In this case, I used this method extensively to ascertain how many days of real world time it would take to mine, refine, manufacture, and assemble everything necessary to make each of the ships. My initial values for building a super-dreadnought, for example, wound up being 20 years of time. Amusing, certainly, but not a value that was at all practical. I was then able to adjust the inputs for various of the components, the time to refine varying batches of raw materials, and so on until I had a number that was more reasonable (about four months if one had only one mine of each kind operating - the reality would likely be quite a bit more), but at the same time gave appropriate values for building other, smaller types of ships, as well as making the process of mining and refining itself not feel too grindy to the player.
And all this just to get good values for a single column - inputs - for a task. Other columns address things that point to entirely separate sheets of their own covering rewards, randomized reward sets, traits, effects, regions, collections of regions, etc. ad nauseum.
Being a designer, as should be clear by now, is primarily about manipulating data. Lots of data.
Obviously, this is just a sliver of what goes into making it so a player can click a button to run a task to assemble that destroyer or medical ship or dreadnought they want, but hopefully it gives some view into the kinds of complexities that every game development project must ultimately find ways to solve.