Àite Domhainn part 3: Game Design
23 Apr 2022Previous in the series
Planning: what a novel idea
It has been a long while - nearly two years - since I have looked at this project. My PhD thesis submission and correction got in the way a bit, but now I finally have some time to devote to this. Àite: strategy game for the patient, developed by the patient!
In the first months of development, I was mostly just flying by the seat of my pants. I had an idea of where I wanted the project to go, and I had written a few posts on the topic, but there’s not a lot of game or software design there.
The result was a project that was difficult (impossible) to continue - at no point was there a clear idea of what was needed or where to go next as there was no clear idea of how the problems encountered should be solved or even what those problems where!
So, two years later, here I am back on the project and I’m gonna try something a bit novel: planning.
So we can look at this in two ways: from a game design perspective, and from a software design perspective. The software is onlybeing built to support the game so it is fundamental. The limitations of what is possible in the software should, hopefully, not impact the game design. Perhaps that should be kept in mind.
What’s in a game?
A game exists to be played [citation neeeded]. The act of playing the game should provide entertainment value (through humour, story telling and characterisation, trial and triamph, intellectual engagement, and so on). The amount of time spent playing a game may not be large for the game to be considered “good”, but at the end of the day, using time is one of the goals of playing a game.
The Game Design Document
Normally, when planning out a game, a Game Design Document (or GDD) is used. This is a succinct text document describing the game in not too much detail. Too much detail leads to a verbose document that is cumbersome to maintain and get up to speed with.
Typically, a GDD contains several sections:
- Marketing
- High concept (elevator pitch or abstract)
- Gameplay
- Art (visuals)
- Technical aspects
There may be more, there may be fewer. I am not looking to make money nor am I courting investment, so the first section “Marketing” is not relevant to me and I’ll not discuss it. An elevator pitch is useful thing to have; a short paragraph giving the gist of the core aspects of the game. This is useful to keep in mind during development, as well as getting outside people interested (whether players or additional developers). Gameplay describes everything from how the player controls their character through level design to plot and story. Art and visuals describes, obviously, how the game looks. This includes setting and (in part) level design, as well as UI elements (HUD, menus, loading screens, text boxes, …). Finally, technical aspects. According to my research this typically looks at hardware requirements or constraints (is the game targeting a specific console? Phone? OS?).
Core gameplay loop
The satisfaction a player (or players) of a game get from the experience is decided by the gameplay loop - the core aspects of the game - and how they relate to the player. Deciding on this loop, then, is a good starting point for fleshing out the game. The gameplay loop are the key actions a player will take during play.
For a game like Call of Duty, for example, the gameplay loop is to take part in a multiplayer match, win or lose you earn XP and unlock new weapons or utilities, which you can then use in another multiplayer match. There are variations on this loop in terms of different rules for the matches (deathmatch, or teams etc), but the core loop stays the same. In Dark Souls, the infamous action RPG, the player will spend much of their time explorating, and engaging in combat, inbetween times planning character build (attributes, weapon choice and so on). In Civili(z/s)ation you plan cities, build units, strategise and so on.
I’ve given examples of video games, but this applies to all games; there are sets of rules and actions a player performs in order to progress (score points, move up the board, level up, etc).
Other gameplay
In addition to the core loop, there may be smaller ancillary loops (e.g. mini games like racing or fishing in RPGs, additional multiplayer content, collection). These side-loops are just as important as the core loop - providing an alternative for the player so they don’t get bored of doing the same tasks over and over.
I have touched on, implicity, some other key elements of a game: progress marker, player reward (whether in the form of a number incrementing or experientially in the form of overcoming a tough challenge)
Summary
So to summarise, a game should have:
- Challenge/risk
- Progress/reward
- (optional, but common) Story, engaging characterisation
- A core set of stuff to do
- (optional) A set of side tasks (variety of gameplay)
What’s in a piece of video game software?
I could get really patronising here, we all know what software is: a great multi-purpose tool for many problems. Software architecting is a whole complex area in itself and is definitely not something I can talk much about. What I can talk about are the elements of a simple video game software…
Simulation
Just like a physics simulation software package, a video game software seeks to simulate the video game world (which may or may not reflect our own world). This really boils down to a set of rules that govern what can be done and what cannot, as well as what it takes to win or progress.
Input
Video games also require some kind of human interaction making them distinct from a simulation package. A player needs a way of interacting with the game world. This could be controlling a character (e.g. Dark Souls) or characters (e.g. XCOM), making strategic decisions for an entire group of characters (e.g. Civ.).
Feedback
Finally, the simulated world needs to be presented in some way to the player. Often in action and platformer games this is a third person view of the game world: the player and their surroundings. In games requiring precision aiming a first person view is commin (e.g. first person shooters). In strategy games, a wider view is often required: a world map. Sometimes, it is not even necessary have a view more than a series of menus.
Summary
To summarise the core components of a video game:
- Simulated world (rules)
- Player input
- Player feedback (textual/visual, audio)
Capping it off
So I’ve enumerated a list of stuff that could be used to define a game… a basic structure for my eventual Game Design Document. I had set out to write this out more succinctly than I have ended up here. Since this is getting a bit long, I’ll leave the Àite white paper for another post.
Further reading
Questions? Comments? Get in touch on Twitter!