Ludotronics

A Comprehensive Game Design Methodology
From First Ideas to Spectacular Pitches and Proposals

The content of this website is licensed under a Creative Commons CC BY-NC-SA 4.0 Attribution–NonCommercial– ShareAlike 4.0 International License. You can freely use and share everything non-commercially and under the same license as long as you attribute it to and link to:

J. Martin | betweendrafts.com | ludotronics.net

However, you can also buy the Ludotronics PDF edition
for an unreasonably moderate price at DriveThruRPG.
Learn here about the five excellent reasons to do so!

Why DriveThruRPG? It’s the largest download store for role-playing stuff in existence and you’ll probably end up buying much more than just your copy of Ludotronics. Which would benefit game designers everywhere!

Why not Amazon? For one, illustrated non-fiction isn’t well-suited for the Kindle format. Also, at a €14.99 price point, Amazon’s cut amounts to €9.75. Well, no.

Level Three: Plurimediality

Process Phase Level Three

Beat 1. Style

Squaring Efficacy with Enchantment

As established in the Opening, Plurimediality, the intersection of Ludology and Cinematology, integrates design thinking from two perspectives: functional aesthetics and aesthetic experience. The former demands efficacy, the latter enchantment. The question is how to have both without sacrificing too much on either side. That’s what this beat is essentially about.

You might or might not do actual design work at this point in time, in the same way that you might or might not write actual code for your rules and rule sets in Level Two: Interactivity or sketch your dramatic development arcs in Level Five: Architectonics. But you should have a good understanding of what your game will look like, possibly a vision, and you need to convey that understanding or vision in your pitch and your proposal document.

Let’s start with style. The question of style, from how to define it to how to find it, has a long and rich history. For our purposes, once again, we will rudely compactify this history into three manageable and practical categories that can be directly applied to game design. These three style categories are:

  • Genre Style. Literary and cinematic genres as entertainment categories like fantasy, science fiction, science fantasy, western, mystery, horror, survival, romance, hard-boiled/noir, contemporary, military, cyberpunk, post-apocalyptic, and so on.
  • Period Style. Art styles like Archaic, Classical, Byzantine, Tang, Muromachi, Kuba-Bushong, Realism, Expressionism, or Art Deco; architectural styles like Neolithic, Khmer, Romanesque, Aztec (Mēxihcah), Gothic, Victorian, or Bauhaus; and musical styles like Gregorian, Gagaku, Baroque, Romantic, Guoyue, or Postmodern. And don’t forget typographic styles for good measure, from cursive to movable type, from gothic to humanist, from Roman to Ming and beyond.
  • Presentation Style. Artistic renderings, often simulating other media forms and media types (through advances in digitization and media convergence) that stretch from life-like realism to comic/anime, from wood-block printing to papercutting to graffiti, from stop-motion to rotoscope, and many more.

The style elements that you pick from these categories constitute your style set. It will inform everything from game world to asset to character design. You can go and combine contemporary with life-like realism and “what you see right now outside your window” period style. Or you can go and combine post-apocalyptic anime with Western frontier towns and Gothic cathedrals, as in Vampire Hunter D: Bloodlust. Whatever you do, though, it must closely match your theme and set of motifs.

If you want to create an original, innovative style that the world hasn’t seen yet, you still need to build upon styles that already exist—in the same way that new ideas are built upon what already exists, discussed at length in the Preparation phase. You can pick a style and modify it, or you can fuse two or more styles from the same category into something new. There’s no better lesson to learn how to do this than the “Ask ‘What If?’” section of Feng Zhu’s GDC 2015 presentation “A Live Art Demonstration of Creating Worlds through Design Thinking.”

There’s one more ingredient, though, that will be added later: personal style. As soon as individual artists, possibly including yourself, set to work and create your game’s artwork, personal style will naturally join your style set.

Fig.4.28 Style Set
Fig.4.28 Style Set

Now, putting your style set to use for architectural, level, or character sketches, and so on, and create enchantment for the player, that’s challenging already. But the real battleground where enchantment and efficacy collide is your game’s interface. Is it possible to make your interface match your game’s style set in terms of genre, period, and presentation, and still comply with usability requirements?

What doesn’t work is designing your interface following genre, period, or presentation styles as a fantasy, sf, western, horror, Gothic, or graffiti interface, or anything like that. Because that is a recipe for unreadability, incomprehension, and general disaster. You have to work with what people readily and intuitively understand, and that can neither be historical interfaces (just think how hard it is today to read original Wanted! bills in wood type letters) nor interfaces of the future (because we can’t possibly foresee how these will look or work in their own usability contexts). Interfaces must be easily understood, and they can only be easily understood if people who exist right here, right now can easily understand them! People, that is, who live today, not in the past, not in the future, and not in a grim fantasy world with a lava-spewing volcano as their daily backdrop. So how can it be done?

The first step is to differentiate the interface into what we will call the preference interface, the gameplay interface, and the inventory interface. Together, they constitute your interface set. The preference interface is the place where the player determines how the game is played via option menus. The gameplay interface is the place through which the game is played via constant feedback data. The inventory interface is the place where the player manages and administrates gameplay-related data, covering everything from equipment to skill trees to log files to crafting. Obviously, different design parameters apply to each, and this differentiation alone goes a long way toward solving the problem of bridging usability and style, of joining efficacy with enchantment. Let’s go through each interface’s characteristics one by one.

The preference interface, without doubt, should be as user-friendly as possible. All the general rules for designing great user interfaces apply. There should be no pseudo runes, fake computer read-outs, garish backdrops, or blazing colors. Everything should be as easily locatable, recognizable, memorizable, and painstakingly obvious as possible.

The preference interface has only one job, and that job is to lead the player into the gameplay with the least amount of friction. Not before you get this right can you proceed and connect your preference interface with your style set. And the way to do this is through ornament and touch-up, highlighting and adornment, tone and color palette—but always subtle, muted, unobtrusive. Less is more, much less is much more. This also applies to sound effects and music because unambiguous auditory feedback should always have the right of way.

The gameplay interface is tasked with providing all the forms of feedback that your player needs in order to play the game, to get better at it, and to become part of the game world.

Thus, usability for the gameplay interface means different things for different games, for different types of games, and for different types of players. You can’t just apply a few hard and fast rules from usability design manuals. Instead, you have to approach your gameplay interface from the vantage point of specific functions, for which three basic classes are in use right now: the transparent, the overlay, and the skeuomorphic interface.

  • A transparent gameplay interface provides affective feedback data that is predominantly continuous.
  • A traditional overlay gameplay interface provides superimposed feedback data that is predominantly discrete.
  • A skeuomorphic gameplay interface provides feedback data from objects that are part of the gameplay environment that is predominantly discrete.

In software design, the term “skeuomorphic” has come to designate a certain type of design where objects from the physical world are emulated and imitated to make interfaces more intuitively accessible and usable, ranging from operating systems’ desktop metaphors to the knobs, dials, and sliders of music editing software to swiping and page-turn animations in e-book readers. Admittedly, skeuomorphic interface elements in games often “imitate” objects that only exist in the game world, not in the real world—in other words, the game itself creates the objects that are imitated by its interface. (Sometimes, such objects are “imitated” in overlay interfaces too, but these are purely visual, iconic imitations, not the functional imitations of skeuomorphic interface design.) Still, this can be tolerated, as the term “skeuomorphic” is inextricably linked with interface design, and not a term hijacked from a different field that comes with its own foreign problems. Which, alas, is the case with “diegetic,” a term that is sometimes used for this particular kind of video game interface design as well. It’s okay to use it, so go ahead if you want! But unlike the term skeuomorphic, which is indeed intimately linked to interface design, the term diegetic is intimately linked instead to the diegesis/mimesis dichotomy in drama theory on the one hand, and the diegetic/non-diegetic dichotomy for music and audio on the other. (We will discuss the latter in-depth in Beat 3. Sound.) Thus, a host of distinctions and disputes ride piggyback on the term diegetic that are not productive for the task of designing interfaces at all. Equally, in contrast to being skeuomorphic or not, being diegetic or not isn’t intimately connected to functionality, and functionality is what interface design is first and foremost about.

Clearly, every meaningful gameplay interface decision toward transparent, overlay, or skeuomorphic design must be based on your style set and your theme. Let’s go through a few examples.

  • Transparent Gameplay Interface. If your player character is a Pleistocene hunter dealing with woolly mammoths and the occasional cave lion, a transparent gameplay interface that gives the player “affective” feedback data by indicating the player character’s hunger, thirst, exhaustion, or injury through brief or persistent visual, auditory, or kinesthetic effects might be your best choice. Feedback on injury and shock, e.g., could be indicated by a partial loss of vision through a stronger or weaker blur effect across the visual field. Such techniques can also be extended to reveal states of mind by showing how they affect the player character’s perception, as exemplified brilliantly by Hellblade: Senua’s Sacrifice.
  • Overlay Gameplay Interface. If your player character is a Cold War operative in an espionage action-adventure, a traditional overlay gameplay interface might serve you best. It provides discrete, exact data, superimposed on the visual field, about everything from health and armor in percentage values to ammo count, from available weapons or attacks to a line-of-sight indicator, and maybe some non-discrete, continuous data like a stealth meter on the side.
  • Skeuomorphic Gameplay Interface. If your player character is a space soldier who’s always heading out for EVA or combat, you might want to go with a skeuomorphic gameplay interface with equipment-specific HUDs and items like watches, pressure gauges, health monitors, motion trackers, and other objects that are functional parts of the character’s environment. And for any kind of vehicle simulation, skeuomorphic cockpit-type interfaces are certainly the best choice.
  • Mixed Gameplay Interface. If your player character manages a roller coaster park or a sports team in a construction or management simulation or commands the Procyon Uprising or the allied forces of World War II in a strategy game, a traditional overlay gameplay interface with a dash of skeuomorphic office or command desk–type elements might be the best option.

You can mix and match, of course, with an overlay for action sequences augmented by both skeuomorphic and transparent elements—HUDs and guns with ammo count displays for the former and field-of-vision fade-out and slowed-down movement for the latter—and throw in skeuomorphic elements like command desks or cockpits for strategic missions or vehicles. But never forget that design is about decisions! Finally, always try to be creative, even innovative, with continuous information. Presenting discrete information is easy, but there’s a whole lot of human experiences that cannot be represented by quantifiable and numerical data.

The inventory interface, finally, will be the hardest part to sketch. It is both part of the gameplay and not part of the gameplay. It must be every bit as efficient as the preference interface and every bit as enchanting as the gameplay interface. It will consist, most likely, of many different parts with many different functions for many different purposes. Depending on your game type, players might need to switch often between the gameplay interface and the inventory interface, and then to navigate between different parts of the inventory interface quickly. The navigation part can be alleviated somewhat through shortcut keys, but shortcut keys need time to learn (and pose further usability challenges you will then have to solve, exacerbated in case of multiple platforms).

There is no recipe. But there are two principal approaches that can help you get started, and they can also complement each other: the combo approach and the constraints approach.

The combo approach’s two barrels are content and form. Form is used to communicate the choices offered to the player, and content is used to communicate the actual decisions users can make, related to these choices. You’re wrapping efficacy into enchantment, so to speak. Here’s how it works:

  • For the choices offered to the player, design elements are used that the player has learned to recognize from the gameplay interface (form/enchantment).
  • For the decisions players can make related to these choices, data design patterns are used that the player has learned to recognize from the preference interface (content/efficacy).

While the design itself is always hard, the design principle is simpler than it sounds. Here’s an example.

Let’s imagine a Lovecraftian horror game where the player collects ancient tomes full of magic formulae; tracks and interviews people; receives testimonies, notes, and letters from contacts and agencies; travels to and investigates places; acquires and upgrades skills; collects herbs, plants, and whatnot to concoct potions for various purposes; obtains weapons and ammunition; keeps a diary with texts and sketches; and gathers assorted items for bargaining and puzzle solving. While all this is certainly not too fancy, the inventory interface will nevertheless be tightly packed!

The first step, now, is to assign each principal choice a “form” that the player is familiar with from the gameplay interface. These could be iconographic elements that appear, for example, as a book with a pentagram on its cover, an address book, a file cabinet, a map with pins, a stylized player character portrait, a cauldron, a knife or a bullet clip or both, a paper notebook, and a pouch. Or these could be skeuomorphic elements that appear as a book case that can be opened, an address book that can be flipped through, a searchable file cabinet, maps that can be drawn out from a drawer, a training facility, an apothecary cabinet, a duty belt, a paper notebook with flippable pages, and a deep pouch the player can rummage through. Either way, that’s the enchantment part, and players can easily find the principal choices they’re looking for.

The second step is to make the data behind these iconographic or skeuomorphic elements easy to read, easy to digest, and easy to manipulate with names and descriptions in plain text, just like the data from the preference interface—so that it becomes a breeze for the player to find the right formula, the right person, the right place, the right weapon, and the right item; to skim evidence, notes, letters, and diary entries; to craft potions; and to upgrade skills, attributes, or sanity (if possible). That’s the efficacy part, and players can easily make the decisions they want to make.

With this combo approach, your inventory interface will satisfy all the conditions listed above for the preference interface, i.e., locatable, recognizable, memorizable, and as painstakingly obvious as possible, but also remain fluidly and intimately connected to the gameplay interface as an intrinsic part of the playing experience.

Curiously, major action-adventure franchises like Assassin’s Creed do the exact opposite: plain text for principal choices and iconographic elements for player decisions. The latter aren’t recognizable (you can’t design hundreds of recognizable icons), so they trigger scenic video illustrations and descriptions, either as overlay or in another part of the screen. But think about it! As there is no mnemonic link between these icons and their video illustrations, it’s impossible to keep dozens of these icon–illustration connections in memory. And that’s true even if players weren’t operating at full cognitive capacity already to maximize their upgrade paths! Thus, as observed, players trigger these video illustrations dozens of times, sometimes more than a hundred times, to refresh their memories and be able make consequential decisions. This wouldn’t be the case with names and descriptions in plain text instead of icons, and it wouldn’t even occupy more screen estate. Which, indeed, most of 2018 God of War’s excellent menus demonstrate (but some menus like “ranged combat” and “close combat” still have it upside down in that respect).

The second strategy, the constraints approach, is guided by the principle of constraints that we worked with in the Preparation phase’s Level One: Spawning Ideas and Level Six: Capture the USP. A very useful aspect of this principle with regard to user interfaces comes from the field of industrial design, developed and popularized especially by Don Norman. The idea is that in order to make something really easy to use, you have to constrain the possible choices—so that whatever a user wants to do, they will always do the right thing because it can’t be otherwise.

As a natural consequence, alas, this design principle will always constrain the number of features. Here’s a well-known example. From 2007 to 2009, until the release of iOS 3, the iPhone didn’t have a copy-and-paste function. Tech writers in particular were baffled as to why this didn’t stop people from buying iPhones. When iOS 3 finally came out with a copy-and-paste function, it was indeed “easy to use” because it was almost impossible for the user to get it wrong. Until Apple’s engineers got it right, they refused to implement anything at all. Google, in contrast, implemented a dirty workaround for copy-and-paste on Android early on. And boy, was it dirty! It allowed such a great number of wrong user decisions at the time that it was all but useless except for a handful of power users (and tech writers).

As such, the constraints approach isn’t the most rewarding road to take if you want to make feature-focused players or publishers happy. But sticking with constraints has another advantage. Clutter is always ugly, and the less stuff you need to cram into your preference, gameplay, and inventory interfaces, the easier it will be to make these interfaces look fantastic. And look great they should! For the gameplay interface in particular, Jordan Mechner—of Prince of Persia and The Last Express fame—relates his approach in an interview for Richard Rouse III’s Game Design: Theory & Practice. What Mechner did was working under the constraint that, at any given time, the interface must be a pleasing experience for someone who isn’t playing at all, but happens to walk by and starts watching what’s going on on the screen. This an excellent yardstick. It will generate buzz and get more people attracted to the game.

Fig.4.29 Interface Set
Fig.4.29 Interface Set

Now you can put this theoretical framework into practice. Choose your style set and sketch your ideas for your interface set. The actual design, of course, will take place in the development phase. But you need at least a principal idea, a general sketch, and maybe a vision. Everything should fit your theme, your primary target audience, your value set, and your USP, as discussed in the Preparation phase. For your interfaces, you should collect everything that these will probably need to convey, or could convey in principle. Put everything you come up with into one of three categories: the indispensable, the possible, and the unnecessary. (Don’t skip the latter. If you don’t document what you’ve already thought of, you’re doomed to think about it again and again.) Use the principle of constraints as your primary guide and try to err on the side of less. Also, for every gameplay interface item that is not on your indispensable list, try to think of a way to convey that information through action. This will make your game a tighter, more focused experience. Indeed, you should regard and assess gameplay interface elements as you would regard and assess cutscenes. What interface elements and cutscenes have in common is their seductive power to lure you into convenient cop-outs and dump information on the player that should really be dissolved into gameplay experiences and player action.

Finally, to communicate your ideas or your vision, you should use mood boards, sketches, and written briefs. These three elements constitute your communication set.

  • Mood Boards. For your mood boards, collect images that are similar to what you have in mind. To that effect, create a list of keywords based on your genre, period, and presentation styles and start grinding through image search engines on the web, photo communities, stock photo sites, artists’ and concept designers’ portfolios, and similar. But don’t stop there! Consult art books and classical paintings, graphic novels, cinematography examples, software and hardware interfaces for technical and military equipment, data visualization and infographics, dashboards of any kind, ideogram and pictogram sets, and display typography examples. And so on. Depending on the styles you have in mind, you might come up with even more corners around which to peek.
  • Sketches. For your sketches, rough drafts that convey the principle form and structure you have in mind for your style and interface sets should do. If you happen to be an artist, you can go beyond sketches and express your vision—there’s no need to hold back.
  • Written Briefs. Impressive mood boards and amazing sketches notwithstanding, written briefs are obligatory. Even if a picture happens to be worth more than a thousand words, these won’t be the exact thousand words you have in mind. Your written briefs should reveal your reasoning behind your style set decisions, from genre to period to presentation style, and meticulously explain what your interfaces will require and why.

That’s about as far as you need to go. Again, if you’re an artist, you may want to follow the call of your profession and cast your envisioned style—genre, period, presentation—into concrete color and shape and proceed to palette and shading and to proportion and form. The same applies to your interfaces—if your professional focus happens to lie on communication and user interface design, draft away! If any of that is not your forte, rough sketches will do at this point. Later, though, you will need artists and designers whose forte it is, to create actual design work for your pitch presentation and possibly your prototype. Hence, your communication set!

Fig.4.30 Communication Set
Fig.4.30 Communication Set

up