The Game Design Essay (2021)

Game Design Essay (2021)

Essay - based on your final design brief, introduces some of the game design elements, narrative, research commentary with literature, industry history, context, etc.

This year's game essay will be a practical document encompassing your game design project. The essay explains your game design's inspiration and present some of your design ideas. The essay will also relates or position your design concept within the current market. You will identify audience, value and market factors and consider a plan for further development.  

Suggested structure for the essay:

Introduction: An introduction to the game design project (inspiration). 

Literature/commentary: Write a short research commentary including a small number of relevant references from research literature, ludography, related games, history and context, etc.

Provide a text box with a written sample of the game narrative, its backstory or lore.

Provide a small number of illustrations, mood-board, drawings, figures, diagrams. Please use the appendix for providing more detailed design elements if desired.

Discussion: Write a short section as a business pitch and plan for Spiel/Kickstarter. 

Conclusion: Conclude 

References:

Appendix:

No set word-count. 8 pages max (including illustrations, tables, etc.)

Appendix is not included in the page-count.
Choose your own reference style.

You can think of the Game Design Essay as a description summarising the proposed game, including the artistic, project, technical, and commercial elements. The document is not the game itself, it is rather, all the related information about the game that another designer, an investor or publisher, would like to know about the game. The information in the essay would probably address most of the questions a reviewer would have about the game.

Pitch warm-up

---------

In a sentence “It’s like…”

Single player, multiplayer, puzzle, builder, collaborative, cooperative, competitive, open-world, sandbox etc?

Family/Adult, player age, number of players, time to play. Casual vs campaigning etc. 

Background research

----------

Inspiration? 

Genre?

Related titles in this genre? 

Published influences, related and similar titles (even, if you look for it, references in the game literature!!!!) 

Design structural elements

--------

Game design elements? Gamifications?

Outcomes? Win/lose? Display/sharing?

The application of emotion principles?

The application of the uncertainty principles?

Narrative backdrop constructed by the design

Narrative potential constructed by the players

Complexity, scope? Too much, too little?  

Developer perspective

------

Paper prototype or mockups?

Any playtest feedback?

Comment on ease to ‘onboard’ new players? Simple version, complex version. House rules.

Identified ideal player types, market segment? Appeals to who?

Market perspective

-------

Potential to adapt or expand, levels, extent, add-ons, expansions? Is it a platform.

Market size of equivalent or similar titles?

Route to market? (publisher, self-publish, kickstarter, crowdfund)

Packaging/presentation? (box, components, online, platforms) look and feel.

Countries/languages? Cultural fit. Suggest markets. 

Product Production: Value, costs, price, effort

--------

Price-point/Pricing? Cost to design/develop?

Cost to service/operate?

IP or licensing questions?

Potential to rebrand or repurpose the ‘engine’ to another genre?

Persona driven design process

Model users: 'personas'

In following up on the topic of Persona driven design processes, we wanted to highlight that the WCAG Guidelines actually provide example personas for designer. "Stories of Web Users" offer character centred scenarios. While not actual persons nor comprehensively addressing every kind of disability, the characters illustrate and challenge designers to consider users with a range of needs and goals. https://www.w3.org/WAI/people-use-web/user-stories/

Personas offer a cast of synthetic characters complete with values, personal histories, needs and goals. Personas are not average demographic 'types', they are individual characters whose biographical detail allows designers to 'imagine' the persona's individual aspirations, choices and behaviour as realistic, plausible, meaningful. It is simply another way for designers to generate empathy with their users. It enables them to build up a cast of characters, socialised and known among the design team, in order to focus the team's design attention, to enable and contain design ideation, development action, testing, user acceptance, etc.A persona is employed as a shared sense making device, a fictional 'identity' or a character who is imagined in putative roles wherein some future version of the product is employed. These design strategies occupy the conceptual boundary between the design-world and the use-world. Each persona can be used to...

“Develop a precise description of our user and what he wishes to accomplish.” (Cooper, 2004) “Personas are not real people, but they are based on the behaviours and motivations of real people we have observed and represent them throughout the design process. They are composite archetypes based on behavioural data gathered from the many actual users encountered in ethnographic interviews.” (Cooper et al., 2007)

We can use “personas” or special classes of users as representative clients/user/consumers in order to overcome the impossibility of maintaining dialog with each and every participant.

Further reading

For example: Lee, online shopper with color blindness (link)

[Cooper, 2004] Cooper, A. (2004). The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Sams, Indianapolis, Indiana, USA.

[Cooper et al., 2007] Cooper, A., Reimann, R., and Cronin, D. (2007). About Face 3: The Essentials of Interaction Design. John Wiley & Sons, Indianapolis, Indiana.

From great ideas to game features

Maciej Szczesnik at GDC 13 on how The Witcher devs turn ideas into features

Source: video still from GDC 13

https://youtu.be/moW8-MXjivs

• Ask questions about the feature (so you know what it could be)
• Research research research
• Talk with the team, brainstorm ideas, (the Crawford slip method - basically structured postit notes on a wall)
• Innovation by reversal, contrasts, strange combinations.
• Use measurable criteria and prioritisations
• Does the idea cohere with the rest of the game?
• Roadmap of ideas and stages so the plan can evolve
• Continuously simplify so you can do more

A good lifecycle for organising game development?

I'll prefix this post by drawing your attention, to notice, that the title of this post makes no claim to this as the best lifecycle, method, or best practice. Rather, I posit that it could be a good practice, a good or useful lifecycle. Why am I careful to couch the claim in such diffident terms? Well, the industry has, certainly in the past, often been in thrall of various experts, consultancies and others, falsely claiming that there are best practices, world leading, methods or methodologies promising certainty and control of software development.

Mark Cerny started talking about and presenting his ideas for the "METHOD" process in 2002, hoping to spark debate about process failures surrounding game development, to address in some way the human cost, the damage to people's health, of "crunch" mode management, of death march projects, of sweatshop conditions in the studio system. Interest in the Method echoed a parallel movement in software engineering that sought to shift from dominant project management paradigms (linear, stepwise and waterfall methods), that led to the Agile Manifesto and Agile Methods becoming mainstream in the software industry.

Cerny wanted those funding the game publishing industry to acknowledge that more fluid process structures and practices were needed for video games. They needed a method that supported game design's highly creative but uncertain development processes. It was a provocation to manufacturers and publishers. It was also a response to the possibilities presented by the inevitable transformation happening in the market for video games, the move from a physical product manufacturing paradigm, to a virtual digital good and distribution paradigm, the move away from copies of 'finished products' to versions and downloadable releases.

Management is the art of organisational control, of minimising risk while maximising benefit. Management methods are organisational approach for producing goods of one kind or another, they are systems of risk management. Processes, lifecycles and methodologies, are attempts to make product design and development repeatable, sustainable, to deliver value. Like many in the business, Cerny thought that games are different. A hybrid of software engineering, artistic expression, and all the creative drive to produce something that is fun, playable, enjoyable, valuable. 

The METHOD is like developing two projects, back-to-back. The first version partial, incomplete, promising. The second version an evolution (perhaps even a revolution) of the first, expansive, complete, a full realisation of the game's potential. And so we organise our goals, teams and activities differently for the different stages of a game's development lifecycle. Pre-product yields a first playable version. Production delivers on that foundation, by scaling and elaborating on the original ideas. The first version is the proof of game, the 30% prototype. At this point we can put the core idea to the test. If it remains exciting, demonstrates its value, convinces us that there is a game and and audience, then yes, we go into production, we invest the 70% to bring it to production. 

"Pre-production" is vastly different from "production". Likewise, the kind of feedback that is useful between the two is different. Think of a small focused audience for the pre-production effort. Think of wider more intensive play-testing (even further discovery) in the build-out and polish of the later design/development process in production. And accept that changes, even significant changes may be needed, even at, what might be thought of as, the end of the lifecycle.

Cerny's METHOD

https://www.slideshare.net/holtt/cerny-method

6 short stories on how to fund your indie game

This post on the Unreal Engine blog presents 6 short stories on how ot fund your indie game project. All of the hint at the value of a working prototype, of asking for and listening to feedback, of using that feedback in some way, either responding and expanding or for analytical introspection of your project. Look for attention, look for interest, listen to the responses, respond honestly while respecting your vision.

Keeping the team as small and costs low for as long as possible.

Reuse whatever you can rather than creating new technologies. That way you'll be investing in realising your vision, the things that are unique to your game, rather than reinventing the building blocks. Build on the shoulders of giants. Along the way, by serendipity or discovery you may invent new, useful, general purpose technologies that are valuable and sellable, (well done if you do).

Make sure you can answer the question; how is your game going to make money?

Building something, even something small but tangible builds confidence and offers immense learning opportunities, both for the team's capabilities and how others perceive the sample.

Look for multiple lines of investment at the appropriate moment. Self-funded, friends and family, public agencies, investors...

https://www.unrealengine.com/en-US/blog/how-to-fund-your-indie-game