School: Game Design 2

Game 1:

Theme 1: User Experience

Our first assignment was to create a game that would have a certain type of User Experience: Sensation, Fantasy, Narrative, Challenge, Fellowship, Discovery, Expression or Submission.
I chose Discovery. Mainly because I like to play MMO games where discovery is rewarded etc.

The game is being created in Unity. You can look around with the mouse, move with the WASD keys, and left click is summon a light…. 😛 The red light is the ‘finish’.

I tried to make a few things a real discovery (fun to discover it) but I’m not good with Unity, so it isn’t in the game (yet?) Right now its more of a discovery of the scenery.

The idea of this course is that every week we develop the game a bit further depending on a theme, this time it was User Experience, next time it is Mechanics.

Also we have to make a review on the game so far, explaining why it is a game of Discovery etc. The review will be below:

At first I thought  “what is Discovery, what have I gotten myself into!” Later I came up with the idea that there are 2 types: the first is Small Discovery, like finding ore in Minecraft, or a cave. The second type is Exploration Discovery, sightseeing for example, taking the world as a whole and explore it. So for me discovery either means finding or exploring.

Genre-wise  this game matches a bit with horror/puzzle.

The mechanic that’s currently in it is very discrete (state wise, summoning, floating, vanishing)  Without it you can’t see a damn thing, so it is a very important one. You might want to see it as part of the ‘Internal Economy’ of the game. Every five seconds you may summon one.

First I made a basic level, then the player, then I started adding detail to the level (trees, grass, water, wind and sky) then I added the main mechanic. This was plain stupid. I’m new with Unity and I did the most difficult thing in the end. I should have made a simple level and then the mechanic. That  way I wouldn’t have to worry about ‘oh god what if this doesn’t work’ and the chance of ending up with a non-functional game. After initial publishing on the website I changed the lightning settings multiple times, since the area you could see with a light was just too small, according to the playtesters. And I added the level end, mainly because I felt like the game needed something to end, rather than alt f4 the whole time.

I made a vertical prototype, meaning I did a little bit of everything, instead of horizontal, focusing on one thing (level, sound, mechanics etc.) This was mainly because, as a beginner, I wanted to learn a broad spectrum, rather than having trouble adding something later on.

This is the current heightmap of my level

The game has no prior art, it just popped into my mind when I read Discovery on the slides in class. Play-testers kept comparing my game to Amnesia, however I fail to see the link.

The player is, and will be, free to roam around, the level is small so you will reach the end eventually. And the mechanic(s) will keep it interesting along the way. The thing is if you give the player freedom, letting the game emerge from the player’s actions, you risk making him confused because the actions usually have a form of (forced) progression. For example finding a valve, that usually means that you will need it up ahead.

Theme 2: Mechanics

“For your game create an internal economy that has a variable, quantifiable outcome affected by the effort of the player and that is fun to interact with.”

An economy doesn’t always mean the production of an actual resource (wood, stones, iron etc.) but it can be: Tangible(physical entities) or Intangible (health, most inventory items etc.), Abstract (doesn’t exist yet its there, like item durability, strategic advantage) or Concrete. A combination of these two is possible (Intangible Concrete resource: XP, intangible because its not an game object, concrete because it can be spent) Depending on the game these combinations may change.

The review uses pictures made with the Machinations tool, created by Joris Dormans.


An economy for a horror/puzzle game, for quite some time I had no idea at all as to what put in there. The “economy’ that was in it was a simple mechanic:

Every 5 seconds you were able to spawn a light that removed itself after a random time (not in the diagram: a minimum lifetime of one second)

The idea was to make this more dynamic:

Part of the assignment was to create one or more feedback loops, but I had no idea how to implement these in the game, so at this point it became positive/negative reinforcement. As you can see in the diagram above I used a % but I am talking about time,  4 seconds charge time (which was 5 initially but playtesters said it was too long), negative event increases it, positive event decreases it.

After this Sanity was added in, it was supposed to be a layer to create feedback loops (game theory says that loops create more immersive gameplay) however this did not work out, I could not figure out how to add it to the mix.

(All values above are representations)

A day before the deadline I chose this Sanity to be the base for the score, which turned out to be: Score = Sanity.size.x – (Sanity.ammountGone*300);  A bit weird since I was calculating with pixels instead of points.

After the deadline I came up with the idea to put sanity in between the two upper rows, letting it function as a resource. A light stops the sanity from slowly draining, and events influence the resource. Because of the deadline this was partially implemented into the game, the drain and source kick in after a specific event:

An average of 400 seconds but of course this differs per player.

Theme 3: Level Design

“Structure your player’s progression through your game in such way that they experience progress. (With the help from lock and key mechanisms)”

This is the final build of the game:

Level design has been one of the reasons I chose this study so I tend to go over and over it again. Because  of the deadline I had to force myself to stop tinkering with it 😉

I read (and highly recommend) “Level Design: Concept, Theory, and Practice” by Rudolf Kremers.  Thanks to him I’ve learned quite a lot about the subject.


When looking over the current heightmap (see below, left picture) and seeing how playtesters went trough it I noticed something, they seemed to be stuck in the middle area, walking around in circles which annoyed them very quickly.

So I went over the map and made some changes to the level, resulting in the following heightmap (right picture):

The red X’es are events, the green things are part of the lock and key mechanism, and the yellow circle is the spawn.

As you can see in the picture the main pattern of the level hasn’t changed, only slight adjustments were made in order to ‘guide’ the player so the gameplay got a bit more structured. The upper right was made inaccessible since during playtesting (and my own walktroughs) nobody got there. The wall near the campfire in the upper right X was opened to show the player that there is something there, rather then seeing (or not, as I found out in the playtests) a faint light. When the player gets scared at the campfire a reaction could be to run away. I left a part of the middle mountain, so when the player looks left it gives the feeling that it is a dead end, to the right is big open space, the player tends to go that way. This mechanism makes sure that the player goes to the X near the lake. If the player has already been there it wont trigger the event again. The player moves further after a while and encounters the right bottom X. I increased the space around it so the player can choose to sneak around or go near it. If the player has managed to get past the campfire without triggering it  (it is possible) the same principle applies. If the player triggers the bottom X the player backs off and tends to run away, if he goes back he will trigger the campfire, if he ignores it there are no repercussions.

At the end of the long lane there is the double lock and key mechanism. The player approaches a console and triggers the second pool of the picture above (location based lock), this spawns the second key. This key was located in a small corner near the last event. When the player picked it up the sanity starts to drop slowly, so the player needs to go to the console ASAP. Then the score gets displayed and the game ends. With the first grading round at school I got the suggestion to place the console somewhere else, to prevent backtracking. Before the second grader got to me I had edited this suggestion in, resulting in the final heightmap:

Game 2:

Theme 1: Dynamics

This was a bit of an odd one for me, I just created some code for a school project, and wanted to do something else with it. Of course I have to learn something from it, so copy paste code isn’t going to work for me. So why not make a multiplayer game?

Dynamics, meaning not static, it can (or will) adapt based on certain inputs. An action, a resource, skill, randomness etc. All of these can change the gameplay phases and rules. Some of them are easy to understand, like with the Settlers 4 you build up the basic economy and start expanding. In the end with those games it tends to come together in a war phase where the player with the largest army and strongest economy will win.

We also learned about game design patterns, a design pattern is a generic solution to a common problem. A lot of patterns are available at I read trough a couple of them, and of course the Multiplayer Games pattern was quite helpful for me. It described various situations and elements that are common in an MP game.

Judging from the picture below, a game is a bit like a book, it has a beginning, middle and end.


Our assignment was to create a game with an economy that progresses through at least 2 distinct gameplay phases, not necessarily those in the picture.

WARNING: The game needs 2 players to function! I am not responsible for what happens to your cat/dog/goldfish by playing this game on your own!


You start with base building, then, based on the amount of Transport Robots, you load specific resources in your Mech (so the more TR the faster it will load), then in the final stage you fight against the opponents Mech. The phase change from 1 (building) to 2 (gathering) is made by a timer, the moment its 0.00 the game forces into the next phase. There the phase change (to battle) is made either by the player (clicking the launch button) or by a timer, to prevent endless waiting. The button was added to give the player a choice. Do I load more resources, or launch a preemptive strike? The camera angle will be turned down later so you only see your own base, it isn’t now because of debugging purposes. You can’t see your enemy’s base, and you can’t see what resources he has.


Above is a simplified version of the economy. The feedback this got, was that I built it like a pyramid, lots of base resources that converge to two points. StarCraft for example only has 2 base resources and is a lot more complex…. They suggested to build it more like a tree.

One of the things that I haven’t addressed in the game, but is described in the design pattern, is the fact that a beginning player will have a disadvantage over a more experienced player. One of the ideas the pattern site gave me was, that the buildings slow down production over time. An experienced player gets slightly dampened by this. However, the game is too short (3 to 4 mins, two minutes building time) that I decided not to put it in there.

Theme 2: Narrative

Narrative is more than the story itself, its also about the pacing. The assignment was to modify the game so there is a large contrast in pacing between at least two states, and those state changes occur in reaction to or together with story events.

yayFirst I worked on modifying the game with the feedback I got last time, the reworked economy (above) was one of the results. The other feedback was that it wasn’t clear what building did what. They are colored cubes, so I agreed with that. I made a particle system to show what produces what:

particleEvery time a building produces something an icon will pop out of it.

Then the actual narrative began, how to put a story in an 3-4 minute online game. The problem I had was that I made this game around some code, not around a story. I had to make up a story that fitted the game, without having to change a lot gameplay wise. I ended up modifying a piece of The Hitchhikers Guide to the Galaxy:

Two species, the G’Gugvuntts and the Vl’hurgs, existed in the distant past, a very great distance from earth. Actually they were of the same species, but after thousands of years of evolution God forgot to downsize their ego.
And things went on from there….
The G’Gugvuntts were enemies of the Vl’hurgs, and these strange and warlike beings were on the brink of a huge war, because of an insult uttered by the G’Gugvuntts leader to the mother of the Vl’hurg captain.

Resplendent in their black-jeweled battle shorts, they were meeting for the last time, and a dreadful silence filled the air as the Vl’hurg leader was challenging the G’Gugvuntts leader to retract the insult.
At the precise moment, the phrase “I seem to be having tremendous difficulty with my lifestyle” filled the air over the conference table, which in the Vl’hurg dialect was the most dreadful insult imaginable.
It left them no choice but to declare war on the G’Gugvuntts, which went on for a few thousand years and decimated the entire galaxy.
Good thing for us these two species were so narrow-minded that their galaxy only consisted of two towns, sitting on a remote planet, which was of no use to any space faring civilization.

These days, the war is almost over, no soldiers are left, and the remaining people are finally settling things once and for all.
Both towns decided to build up an economy from scratch, and load the final products of that economy, into their respective mecha, salvaged from the battlefield.
Then the supervisor will pilot the mecha, both supervisors will fight each other, the team that wins, wins the war.
That supervisor, is you…

Now that I had a story that encompassed the game, it now needed to be inside the game as well… This proved more difficult than I thought. I tried to give both species unique buildings, but this conflicted so heavily with the multiplayer code that I had to revert. In the end I made a announcer, that gave info on what to do (and how). Accompanied by an intro video, that explained the ‘why’. This caused the actual gameplay to have very little of the story. After the grading I came up with the idea that both teams could ‘communicate’ with scripted (spoken) texts. This way the story is drawn more into the game, even though it hardly effects the actual gameplay.

Theme 3: Polish

Polish involves making the game more juicy, attractive so to speak. For more info you can go to its a presentation by Martin Jonasson & Petri Purho about “Juice it or lose it”
The player wants to feel powerful, in control, have maximum (graphical) output with minimal input. Before the grading for narrative I made a small list of changes I wanted to make, to make it ”Juicy”:

Wait for other players to join before beginning….
Fix music for client and add more SFX in build mode.
Restart program button to prevent game bugging out.
SFX 3rd stage, effects, healthbar etc.
Prevent cheating… *sigh*
Fancy ground 😀

Waiting for the player is easy to understand, it prevents the host from gaining an edge while the other player is still connecting. This simple feature broke half the game. I spent a good amount of time fixing it, and it works, it just looks a bit dull (not juicy!). A waiting screen would have been juicier.

The music works fine for the host, but the client randomly gets stuck in an infinite main-menu-music loop. As they showed in the video, music is an important feature so I fixed that for the client.
In the beta version, the only SFX in the buildphase is when you spawn a building, and when a building can not be placed. I tried adding audio when a resource is made, but with a large screen full of blocks making things, it becomes very noisy, VERY fast…. So I decided to leave base building audio for what it was.

One of the bigger  bugs in the game is that when a game is finished and people want to play again, the game freaks out and suddenly your mech is flying across the screen. Though playtesters found it entertaining, but that was mainly because of me, getting confused…  So in the main menu I made a button that forced the game to go back to the intro video. I couldn’t reload the level, for some reason that kept everything on screen. This made the game less Juicy and more Annoying, good thing you can skip the intro. An automated reload would require less player interaction, and give the player a better ‘feel’.

“You can never have too much particles” The third stage was without any effects, so I added sound and a particle system. The grader of Narrative told me it would be nice if things felt big and massive. So I tried and indeed the last phase felt a lot nicer. 2 Sound effects, a particle hit effect and team coloring gave a very different feel to the last phase. I also added movement of the BattleCam, the main viewpoint of the third phase. Normally it would sit there and when the battle is in a corner of the screen, one of the players can’t see what’s happening. So now the camera is exactly in the middle of the two, making it more fair, and allowing more juiciness to be displayed.

During playtesting I noticed that people were cheating, not fair you say, but for the players it was entertaining! To remove, or not to remove entertainment, that was the question. In the end I did, the players knew each-other and they were sitting in the same room. Where as in a multiplayer game you play with random opponents, and then it is not entertaining at all.

Fancy ground, during the first polish class a play-tester told me he thought the ground was  a bit dull, so I made it more Juicy! I added some trees, grass, wind, dynamic shadows and I gave each mech a different color. This was the result:

KnipselOnly problem was that grass is only visible from a certain range, and even at max the camera couldn’t see it. Only in the battle phase you see grass. But, combined with all the other effects I certainly made it less dull!
One other change I wanted to make was a graphical representation of the resource tree, rather than having to hover over the buttons, less reading & more graphical output = more juiciness. This was the last feature I worked on, but it became so bugged that I had to scratch it, in order to have a working game.

After two games me and Kjeld from have decided to create a game together, combining knowledge and experiences. Updates on this game won’t be part of this page but will show up (eventually) on the main page. Funny to see what a school course can lead to 😀


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s