Puzzle Design / Game Design

Description

I worked as a game/puzzle designer on We Were Here Together, the third entry in the co-op ‘escape room’ series.

We Were Here Together has 1500+ positive Steam ratings, (90% positivity) and had 42K concurrent viewers on Twitch when it came out.

Steam page: https://store.steampowered.com/app/865360/We_Were_Here_Together/

My contribution

• creating puzzles, from idea to releasable content
• collaborating with a multidisciplinary team
• setting up and running playtests, analyzing and summarizing results

More…

In this project, I was responsible for creating puzzles from scratch and bringing them from idea to releasable content (ie. concepting, (paper) prototyping, whiteboxing, testing, adjusting based on tests, QA). I worked together with two other game designers and a team of artists and developers as well as several other disciplines. My biggest contribution was in conducting regular tests which allowed us to direct the team’s (design) efforts to those areas that could use that attention the most.

Project

Approach

Use a MoSCoW-style planning to make sure the most important elements are present when the camp starts.

Decided on making it possible to manually fill in information before going to a public state that would be shown to the children. This way, it cost the camp organizers more time to set up the program, but it also gave them more flexibility in how to use it.

Result / Evaluation

Working application with the main elements functional: a character that walks towards a current level in a level-overview screen and certain skills that have an “increase” animation

Application became embedded in the camp’s culture. The children had built little rituals around the application, which was used to start and end their activities for the day

Description

Key design decision

Making the design choice to have users fill in all the required information before it the application could be shown to the children.

This saved development time, which was our scarcest resource. The flipside of this choice was that the camp organizers needed to do a bit more preparation work. However, this also gave them the flexibility to tweak scores when necessary.

Process

We started off by interviewing our contact person at the camp about what they wanted help with. Based on this, we formulated a Minimum Viable Product (MVP), as well as things that would be nice to have, but not absolutely essential.

This MVP proved to be instrumental, as we had very little time available to actually work on the project. (all three project members had other deadlines as well) Because we had prioritized different features upfront, we were able to finish something without having to update the design much.

We worked together with the camp organizers, one of whom voice-acted the transitions in the application.

We were invited to join the camp for half a day, so we could see the application while it was being used.

Project Role

Niels de Jong – design, programming

Melissa Tammens – 3d character modelling & animation

Esmeé van ‘t Hoff – 2d art, contact person

Project Duration

4 weeks (2 weeks actual project time)

26^th of June 2017 – 2^nd of July 2017

16^th of July 2017 – 21^st of July 2017

The camp took place from the 22^nd to the 29^th of July 2017

Play time

3~5 minutes

Praise & Press

Our school (of the arts) featured this project in an article:
https://exposure.hku.nl/verhaal/4271358/over-mutsen-mindsets-en-een-knuffel-met-een-verloren-been (Dutch)
The project has been nominated for the ‘Cinekid Golden Guppy Media Award’, an award for media products suitable for children, and has received an honourable mention for this award.

Player count

armor games: 17.222 views, 141 ratings, rating 81/100
itch.io: 6.550 views, 34 ratings, 436 downloads
gamejolt: 1.277 views, 32 ratings, 427 downloads
(note: this is a web-game)

Design

Key design decision

A third into the project, we had lots of bits and pieces of knowledge, all related to the general direction we wanted the game to go in. However, a specific, clear vision of what we were trying to achieve with the game was lacking.

I analysed the information we had and defined a single goal for the game, and went on to identify how every piece of information fit into this overarching goal. I visualized these relationships in a onepage (seen below), pointing out areas we needed to explore further.

Materials

analysis of the game as it is now, relationships between different elements and what elements still need to be improved

a paper prototype we created to test the relationship between setbacks and exploring an interesting environment

More design information, as well as the design process

Chalk Gardens Design Package (2057 downloads )

Project

Approach

try to translate the concept of ‘positive reframing’ to an entertainment game that conveys a deeper message through its mechanics.

put together a team to be able to make a full game

short research phase to be able to quickly get to prototyping and playtesting

Result / Evaluation

Complete, if unpolished, entertainment game that conveys its message through both mechanics and story.

Was nominated and received a special mention for the Cinekid Media ‘Golden Guppy’ Award. (press release)

Project was highlighted and used for promotion of all graduation projects

Great collaboration that allowed both of us to become a better professional

I should have managed the (design) goals of this project better, as it would have allowed us to create a more focused and thereby more powerful game.

Keep paper prototyping for longer when you’re both designing and programming, because digital prototypes eat up all the design time.

Description

Process

Our process was straightforward at a glance, but complex in the sense that we were trying out and improving on a lot of different ideas and elements.

By generating new ideas and prototyping those, we were able to slowly create a unique space the game could fill. This space was carved out first by trying to convey our message through the mechanics, and later by supporting the mechanics by creating a world and narrative in which you could use these mechanics meaningfully.

A lot of times the process felt like a balancing act between the two different goals of accurately modeling how it can feel to gradually break out of a certain mindset and making the experience of playing the game a fun, positive one. Though it wasn’t necessary to make the game fun or positive, it was a condition we had set for ourselves, to stay away from more horrorlike experiences.

We defined our design goals and how we wanted to run the project.

Then we started generating concepts that we thought would be able to fulfill our design goals. In this we took a mechanics-first approach, because one of the goals of the project was to try to convey a message through mechanics alone, so we wanted to have a strong core mechanic.

We selected a concept we thought would be able to fulfill our design goals. We prototyped it and felt the core mechanic was lacking. We switched concepts, we prototyped the new concepts, we made variations on the new concept, we prototyped that.

By then what we were working with had become very much like a puzzle. I had intended the game to be a more open-ended, sandbox-like experience, and we created a digital prototype to try and capture the sense of exploration.

This worked but the digital prototype had many flaws as well. To be able to quickly try out different ideas, we went back to paper prototyping, and performed the above-mentioned balancing act by trying to integrate exploration with the story the mechanics were telling. After lots of prototyping and by looking back at our research we were able to reach something that more or less worked.

We started building this digitally, because we knew a lot of the work and time was in translating our paper prototype to the digital medium, providing the feedback mechanisms necessary for understanding what the game was doing and to tell players how they were influencing it.

After numerous iterations we’ve reached the current state of the game: something that achieves a lot of things to some degree, but is maybe not the most focused it could have been.

Project Role

Niels de Jong – design, programming

Joanna Siccama – art

Project Duration

22 weeks

started the 6^th of february 2018

project showcase 29^th of june 2018

armor games version (containing small tweaks) 13th of june 2019

Play time

~20 minutes

Links

https://armorgames.com/play/18618/chalk-gardens

https://red-owl-games.itch.io/chalk-gardens

https://gamejolt.com/games/chalkgardens/332358

https://www.facebook.com/ChalkGardens

Chalk Gardens Design Package (2057 downloads )

https://www.cinekid.nl/en/news/94

Design

Key design decision

I’m going to talk about one of the three concepts we developed into a somewhat refined prototype.

We stumbled on an effective way of starting meaningful conversations by having players estimate the answers of their co-player.

My contribution, then, was in safeguarding this core effectiveness while simultaneously improving on it. I did this by coming up with alternative versions of several game elements, and testing these alternatives to see if the change was an improvement.

This can be seen in the designproces.

Levenseinde Design Process (Dutch) (1278 downloads )

Project

Approach

heavily invest in teambonding to create a safe environment in which it is okay to discuss feelings surrounding death

researching and familiarizing oneself with this serious subject matter, by interviewing several experts in this subject field (e.g. an end-of-life coach, a preacher)

quickly creating throwaway concepts to redefine project deliverables and problem definitions

creating persona’s as the embodiment of three different problem definitions

evaluating on 1/6th of the project duration (something I picked up working on a previous project)

prototyping and playtesting to improve on game mechanics and interface/feedback clarity

Result / Evaluation

3 prototypes that each take a different approach on tackling the main problem

complete research, project and design documentation

design advice for a possible follow-up team

presented results to a group of ~30 subject field experts

featured on regional television

It’s possible to deal and design with heavy subject matter by being respectful and curious and the same time

Subject experts are a great way to get (additional) information about a vulnerable target audience, even if it imposes a risk because they’re not the target audience themselves

‘Exploratory’ does not mean ‘define no clear goals or deliverables’: it’s important to distinguish between ambiguity in the design process (which can absolutely be a good thing) and ambiguity in the project boundaries (which, you guessed it, is not a good thing)

1/6th evaluation yielded less information than I hoped for, but it did confirm everyone was still on board and motivated

Process

We wanted to know for whom we were going to design our games/toys/things, and wanted to get familiar with how care for the terminally ill worked right now. Because we had explicitly been told to not engage with the (vulnerable) target audience, we sought out experts in the subject field, ie. people that have to deal with the terminally ill elderly on a daily basis. Also, we shared our own experiences regarding death and communication with (terminally) ill family members.

All in all, this process was a liberating experience because by talking about these things, we broke the taboos surrounding the subject. This open way of speaking about death gave us some special moments where a stranger would open up and share his or her own experiences. It was an enriching life experience in its own right.

Of course, the subject ‘terminally ill elderly and their communication with their loved ones’ is a very broad subject, and much of the work we did was in carving out specific problems and definitions to guide what we were going to make.

The research coalesced into three personas, each with their own problem. Because we had quite a large team and our client mainly wanted to see different possibilities we decided to come up with solutions to all three problems.

I personally worked on two of the three resulting problem definitions, and helped shape the prototypes we showcased at the end of the project. We got a feature on the regional television for that showcase.

Our client was quite happy with the results. We showed our prototypes and explained the underlying design to a group of about 30 experts. We were encouraged to further develop these prototypes, but chose to focus on other projects instead.

Project Role

Niels de Jong – designer (tegeltjeswijsheid + levensverhaal), programmer

Youri Stans – game artist, designer (tegeltjeswijsheid)

Kris van Geel – interaction designer (geroerd)

Floris Roding – game artist, designer (levensverhaal)

Loren de Bont – game artist

I personally worked on two of the three concepts, created paper and digital prototypes for these concepts and iterated on those.

I also wrote the general design process documentation and the specific design process documentation for the two concepts.

Project Duration

17 weeks

started the 18th of september 2017

stopped the 23rd of january 2018

Play Time

The download of one of the prototypes is below

play time is 10~30 minutes depending on how much you talk

Links

Levenseinde Design Process (Dutch) (1278 downloads )

feature regional television

Levenseinde RTV Utrecht uitzending (2237 downloads ) (starting from 10m55s)

playable .apk of one of the concepts

tegeltjeswijsheid android (Dutch) (1423 downloads )

(please note this is a development version so you’ll need to be in developer mode and allow unsafe apps)

(2 player couch/hotseat co-op, works best on tablet)

Around the Creek is a storydriven game in which you get to know and love weird characters while making difficult (moral) choices in order to solve an exciting mystery

Design

Key design decision

About halfway into the project, we had integrated so many design guidelines and gameplay mechanisms into the concept, that we lost sight of the core value of our game. I decided, in cooperation with my co-designer, to side-step our current goals and design goals and take time to find back the value of the game. We then strengthened this value (the uniqueness of the characters, in both art and dialogue) by building a “chunks” structure around it, based on interest curves. These “chunks” structured how we approached the latter half of the project.

Chunks structure

(for more explanation see download below)

Materials

Around the Creek Design choices (dutch) (1695 downloads )
Around the Creek Design document (Dutch) (1577 downloads )

persona created based on research using our game

early onepage

Project

Approach

create a game along with a viable plan for selling it to an audience

use SCRUM evaluation techniques in a non-SCRUM team process

create interesting characters in a living world

Result / Evaluation

a vertical slice of a complete game, with many points that need to be improved, plus an accurate view on our target audience

check everyone’s ideas about how to design a game, because not everyone designs with a target audience in mind / at all

only create prototypes to answer questions you have (also, if you don’t have questions to prototype, that’s a warning sign)

check how everyone is feeling about the project about 1/6th into the project

SCRUM evaluation techniques like daily standup and “retrospections” offer an indirect and because of that effective way of giving feedback to eachother

map out the skills and personalities of team members, and explicitly create responsibilities to fill gaps

game design documentation (eg. onepages) shows how the game has grown

prototype faster

Description

This project had to be pitched and approved first. We created an elaborate concept, and used the following weeks to start building parts of this concept and get some initial reactions. However, because we had created such an elaborate concept, we had a hard time finding the core of what we wanted to achieve. Moreover, the team was (subconsciously) divided about what direction to take the game in. This confusion came to a head about halfway into the project. At this point, we had a bloated concept and we had created several prototypes that we had not really tested, because we didn’t know how we could use the results. We spent a week finding back the core value of the game we wanted to create (the characters, both in art and dialogue), and built a “chunk” structure around this value to really put this unique value in a good light.

This “chunks” structure was modular and allowed us to fulfill our initial goal of creating a vertical slice of the complete game.

We used this vertical slice for getting an accurate view of our target audience as well as getting feedback we could use to improve the vertical slice.

We then jointly decided to stop this project, because our opinions on how to further develop the game differed on a too fundamental level.

Project Role

Niels de Jong – lead design, lead programming

Youri Stans – lead environment art, design

Esmeé van ‘t Hoff – lead writing, environment art

Loïs Vehof – lead character artist, writing

Runic Sounds (http://runicsounds.com/) – audio

Project Duration

16 weeks

started the 6^th of february 2017

stopped end of may

Play time

~20 minutes

Links

Around the Creek game page (gamejolt) (2118 downloads )

Around the Creek blog (tumblr.) (2178 downloads )

Around the Creek Design document (Dutch) (1577 downloads )

Around the Creek Design choices (dutch) (1695 downloads )

Play time

+- 4 minutes per try

Links

Play in-browser web version

Project Description

A small venture into the territory of the fantasy console PICO-8, Squashy is a game heavily based on a basic pong/breakout game.

However, the old gameplay pattern is twisted to push you towards prediction and risk-taking.

I focused on making the whole game juicier as well.

Project Role

I designed, programmed and created all art and sound assets.

The retro style is largely due to the fantasy console PICO-8

This game is an adaptation of the Squashy game found in the online magazine Picozine

Oh this is awesome!

Internet of Elephants just released two pages about game prototypes I worked on during my internship at Little Chicken. Go check it out!

Link to prototype 1

https://www.internetofelephants.com/safari-central/

Project Description

Internet of Elephants is trying to preserve wildlife by engaging an audience through games using real-world data. During my internship I worked on prototypes that explored some of the ways you can create games or playful apps using wildlife and wildlife data.

Project Role

Niels de Jong – Programmer (intern)

Ramses di Perna – Programmer (intern)

Daan Ruiter – Programmer (intern)

Linda Kentie – Artist

Lianne Alink – Product Owner

Joris van Leeuwen – SCRUM master

In Unity you’ll want to change the transforms of your objectinstances quite often. The transform of an object determines its position, rotation and scale (size) in the world. If you want to do anything beyond changing textures on a static scene, there is no way around manipulating the transform. Now, this is hardly a problem when translating (changing the position), or scaling (changing an object’s size).

When rotating however, this becomes a problem when you manipulate eulerangles, the easiest way to understand rotations. You’ll have to deal with Gimbal Lock. (a phenomenon that makes small, incremental changes to rotations makes them go haywire when over a certain point) To prevent this, Unity internally represents rotations as Quaternions. But what are Quaternions?

In this selftuition, I will try to clear both my own confusion about Rotations as well as any confusion readers might have. I will focus only on 3D.

Download

Please download the full tutorial including all sources:

Unity Rotations Tutorial (1571 downloads )

Body snippet

Gimbal lock

Gimbal lock is what happens when two of the axes align. (See the screenshot below)

Here, the Y-axis and the Z-axis are aligned. This happened by simply rotating the (red) X-axis 90 degrees. We now have a situation in which rotating around the Z-axis and rotating around the Y-axis have the exact same result. That means we’ve lost the possibility to rotate in three dimensions. When you are interpolating from one orientation to another, this property of using Eulerangles causes the object to rotate in an unpredictable way. Instead of interpolating smoothly between two orientations, it will follow a strange arc because at some point two of the axes align which influences the motion. A visual explanation of this phenomenon can be found under sources (source 3)

End

I hope I have supplied you with enough information to understand rotations, as well as some practical examples you can copy into your own projects. As mentioned in the Introduction, I was really struggling with rotations, not knowing how to properly use them. While writing this article I gained a lot of knowledge on how you use rotations and I hope I have succeeded in passing some of that knowledge on. If you feel like you need some more information or maybe hear it in a different way, please check out the sources linked below.

Good luck with your own Unity endeavors!

This is very much an overview of stencil testing. It does not discuss Read / Write masks or specific commands for frontfacing or backfacing geometry.

This article is focused on Unity developers, but it might be useful in a broader context.

Stencil buffer

The stencil buffer is a 2D grid of values. Every value corresponds to a pixel on the screen. Based on the values in the stencilbuffer, pixels can be discarded. (or values in the stencil buffer can be manipulated) This is called stencil testing. It works as portrayed in the picture below.

In this example, the stencil buffer is set with some 1’s, then, only the pixels for which the corresponding value is 1, are drawn.

The values range from 0 to 255. In Unity, this value starts as 0 for every pixel.

Position of stencil buffer in rendering pipeline

Important to note is that the stencil buffer is an extra layer on top of the depth buffer. That means that when a pixel is not drawn because it has been discarded by the depth buffer, the stencil test cannot make that pixel reappear again. It is possible to change the value in the stencil buffer that corresponds to that pixel, but that’s it. If you peek ahead to the pseudocode approximation of how stencil testing works, you will see that a pixel only gets rendered when the depth test passes.

Implementation in Unity

In Unity, you can manipulate the stencil buffer through a separate stencil section within a subshader or within a Pass. (similar to where you would place the Tags section)

Shader "shadername" {
 Properties {
  _PropertyAwesome ("Awesomeness", 2D) = "white" {}
 }
 Subshader {
  Stencil {
   //stencil section for entire subshader
  }
  Tags { "RenderType" = "Opaque" }
  Pass {
   Tags { "Queue" = "Geometry" }
   Stencil {
    //stencil section for this pass
   }
   CGPROGRAM
    //cgcode for actually drawing pixels, either through a vertex+fragment shader, or through a surface shader
   ENDCG
  }
  Pass {
   //regular pass with no stencil section
   CGPROGRAM
    //cgcode for actually drawing pixels, either through a vertex+fragment shader, or through a surface shader
   ENDCG
  }
 }
}

Stencil section

Inside the stencil section, you can issue several commands that determine how the stencil testing is done and what influence the results should have. These are all described in the unity documentation as well (http://docs.unity3d.com/Manual/SL-Stencil.html), but for some reason the explanations there didn’t really ‘click’ for me.

Ref = reference value. Like every value in the stencil buffer it ranges from 0 to 255. This is the constant value used when comparing.

Comp(arison) specifies which type of comparison to use. (I suppose this is similar to the types of comparison you can specify when depthtesting)

Pass, Fail and Zfail can be seen as events that get called by the stencil functionality.

Pass is called when both the depthtest and the stenciltest pass (note, this is the only case in which the pixel is actually drawn)

Fail is when the depth test passes, but the stencil test fails

Zfail is when the depth test fails, but the stencil test succeeds

When Pass, Fail or Zfail trigger, they can perform an operation on the value that is currently being tested in the stencil buffer. There are several of these StencilOperations. A special case is the ‘replace’ operation, which writes the reference value into the stencil buffer (ie. the value for the current pixel is being overwritten with the reference value)

Stencil testing in pseudocode

Below you can see a piece of pseudocode approximating how stencil testing works and how the different commands influence this process.

if (valueOfCurrentPixel <comparison> referenceValue) {
 if (depthTestPasses) {
  Pass(stencilOperation);
  Render(currentPixel);
 }else{
  Zfail(stencilOperation);
 }
}else{
 Fail(stencilOperation);
}

Pass/Zfail/Fail(stencilOperation) {
 if (stencilOperation == replace) {
  valueOfCurrentPixel = referenceValue;
 }
}

Practical Example

(Note: I know this effect can be achieved through different means than stencil testing, but yeah… then I can’t explain how stencil testing works ;p)

Okay. We are going to use stencil testing to draw objects that lie behind other objects. Say, for instance, an enemy is crouching behind a wall. We may want to see this enemy anyway, but maybe with an outline, or in a single color. A picture of the effect is shown below.

So how would we go about achieving this? We can simply draw the model twice: First, we render it like we normally would. However, for every pixel that fails its depth test (ie. every pixel of the model behind the wall), we’ll set the stencil buffer to a specific value. Then, when we draw the model for the second time, we will check whether the stencil buffer contains that specific value. If it does, that means the pixel we’re processing at that moment is behind the wall. We can then draw it anyway, but in a different style.

So what we want is:

First Pass {
 draw normally
 set stencil value to a specific value
}
Second Pass {
 compare value in stencil buffer to the specific value
 if they match
  draw special
}

or visually

(note, in the picture I used the value 1, but you could use any nonzero value)

Now, for the actual code.

Shader "Seethrough" {
 Properties {
  _MainTex("Texture",2D) = "white" {}
  _BackTex("Showthrough Texture",2D) = "black" {}
 }
 Subshader {
  Tags { "RenderType" = "Opaque" "Queue" = "Geometry" }
  /*First Pass, renders the normal texture, sets values in the stencil buffer for the pixels where the depth test fails (ie. behind objects)*/
  Pass {
   Stencil {
    Ref 1
    Comp always
    ZFail replace
   }
   CGPROGRAM
    //draw normally
   ENDCG
  }
  /*Second Pass, render only pixels that have value 1 in the stencil buffer, ie. the pixels that weren't drawn the previous pass) uses the second texture for this*/
  Pass {
   Ztest always
   Stencil {
    Ref 1
    Comp Equal
   }
   CGPROGRAM
    //draw special
   ENDCG
  }
 }
}

Posting the complete drawcode would blow up the size of this article. Please download the complete shader code including different examples here:

Seethrough Shader Pack (2088 downloads )

As you can see you can use the stencil block in a Pass in two different ways: to “mark” certain areas of the model for further passes, or to draw a model based off the marks that were placed by a previous pass.

A thing to note here is that in the second pass, you should set the depthtest (=Ztest) to always. This forces all faces to be drawn, which is what we want, because if we wouldn’t do this, only the faces not obscured by other objects would be drawn. But the face which are not obscured by other objects aren’t marked in the stencil buffer, which means nothing will be drawn in the second pass.

Control Pass execution order with the Queue tag

In the Tags section of a pass, you can specify a value used to determine which Pass to render first. Geometry (standard for regular solid objects) is equal to a value of 2000. Higher values mean the Passes will be drawn later (ie. on top) of lower value Passes. You can specify your own value by putting +1 / -1 after the Geometry/Transparent/Background specification.

Tags {"Queue"="Geometry-10"}
Tags {"Queue"="Background+1"}

See all values: (scroll down a bit, they’re in a really short paragraph)

http://docs.unity3d.com/462/Documentation/Manual/SL-SubshaderTags.html

End

Hopefully you now know what stencil testing is and how you can use it for your own special effects. Below are some ideas for which the stencil buffer may be used. (I haven’t tried them out yet) Good luck writing shaders and making games!

Ideas

Draw on objects using a stencil buffer. You could use a sphere you control through script to obscure parts of the model, then draw those with a certain color.

Debug stencil shader. Give a different value if there is a different value in the stencil buffer. Most likely possible, but if you’d do this for all 256 values, it would be a hell, so a different solution is required.

Sources

https://open.gl/depthstencils

https://en.wikipedia.org/wiki/Z-buffering

Unity documentation

http://docs.unity3d.com/Manual/SL-Stencil.html

http://docs.unity3d.com/462/Documentation/Manual/SL-SubshaderTags.html

seethrough effect

http://studenthome.hku.nl/~niels.dejong/oudesite/files/shader/JongNielsde_shader_eindopdracht_v1.pdf

When I’m saying to someone: I’m the game designer on the team, what is it that I do?

This might seem a strange question to ask. After all, it’s easy right? You design a game. That makes you a game designer. But then, what is designing a game?

Design process

Let’s start by defining designing or the design process. Designing for me is “making informed choices to create a specific ‘should-be’ form for your subject.”

This definition gives a lot of hooks that can be used in your day-to-day design practices.

Let’s go over it.

“making informed choices” Simply put, randomly doing things is not designing. Designing is deliberately choosing one option over another. The metaphorical monkey hitting random keys on a computer will eventually create a videogame. However, this has nothing to do with design, because the monkey is not making choices.

The informed aspect of these choices is actually redundant, because you cannot make a choice when you have no information, because then you wouldn’t be choosing but guessing.

However, the word informed serves as a reminder of exactly that: when you make a choice as part of the design process, you have to make sure you know why you are choosing one option over the other, so you don’t regress to guessing. Of course, this isn’t a binary relationship: there is a spectrum between a complete guess and a completely informed choice. It is impossible to know everything, so naturally any choice will be at least partially a guess. In general, the more you know, the better your choices will be.

Also, this implies that you have to have some knowledge on which you base your decisions. A big part of what you do as a designer is checking whether you have the required knowledge to make certain decisions, and gaining more knowledge if you don’t.

“to create a specific ‘should-be’ form” You have to know what you’re trying to create. A vision or a feeling or a story theme or an insight, or something else. It doesn’t matter, the important part is that you have a clear idea of what you want to reach. It is impossible to design when you have no idea what your endresult should be like. This is because a specific endresult gives your choices a direction, an ultimate criterium that can be used to valuate different options.

so uhhhh… should-be? These words accentuate that you do not actually have to make the thing you’re making to design it. So, in theory (it’s not practical) you can design an entire game without ever making the game itself. It’s not a good idea however, because you do not increase your knowledge of the game you’re making while working on it. (and thus miss out on the opportunity to make more informed choices)

Put differently, this splits the execution, the making of the thing you’re making, from the designing of the thing you’re making.

“for your subject.” Your subject is the thing you’re designing. Your game, your ash tray, your book cover, whatever you are working on. This part is here for completeness, to emphasize that you design something, in our case a game.

What is a game? (and does it matter)

Now that we’ve defined what designing is, let’s define what a game is. Or… not? Recently I read the book ‘Clockwork Game Design’ by Keith Burgun¹, in which he outlines four interactive forms², all of which we call games, but these forms are fundamentally different and have different underlying values.

This opened my eyes to the idea that is not all that useful to try and find an all-encompassing definition of a ‘game’. The thing that helps you most when actually designing a game, is to formulate a clear vision of the kind of game you’re trying to make. Of course, it’s wise to look at existing definitions to formulate this vision, but the practical value of a definition for games in general is small. After all, you’re not designing a game in general, you’re designing a very specific game. This very specific game has specific needs that most likely are not shared by the majority of other games.

By trying to group all different types of games together and finding guidelines to design these, you lose the possibility to find guidelines that work for your specific kind of game.

A different example of this is the book ‘Game Feel’ by Steve Swink³. This book is about a virtual sensation of control when playing games. But, not all games have this. Before going on to say things about this ‘game feel’, the book defines for what kind of games game feel is applicable, meaning in some games there isn’t any game feel whatsoever! By limiting the scope of game feel to a specific subset of games, the author is able to provide much more valuable guidelines for achieving a certain game feel.

So, when you want to improve your game’s design, defining what a game in general is, can be a good first step. However, I believe that in order to find information that is relevant to the games you’re designing, you need to find a more specific term for the kind of game you’re making, and start defining that. (and as more people do this, we’ll have more guidelines that do have value for specific types of games)

This is not to say that there are no valuable insights to be gained from looking at games in general. However, you need to know what to do in a specific situation and for a specific kind of game. For that, you need to have definitions and guidelines for those specific kinds of games.

Sources

Clockwork Game Design by Keith Burgun