0% found this document useful (0 votes)
949 views33 pages

SagarShrestha DesignJournal

The document describes a game design journal for games created during a Game-A-Week course. It includes design documents, screenshots, and reflections for 10 games created over 10 weeks to assigned themes. The games covered different genres and mechanics, and the journal documents the design process and lessons learned.

Uploaded by

Sagar Shrestha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
949 views33 pages

SagarShrestha DesignJournal

The document describes a game design journal for games created during a Game-A-Week course. It includes design documents, screenshots, and reflections for 10 games created over 10 weeks to assigned themes. The games covered different genres and mechanics, and the journal documents the design process and lessons learned.

Uploaded by

Sagar Shrestha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

 

 
 
 
 
 
​ agar Shrestha 
S
 
 

Game Design Journal 

Game A Week (20/21) 


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


 

Contents: 
 
Game Design Journal 1 
Game A Week (20/21) 1 

Contents: 2 
Introduction: 4 

Week 1: Theme One Button (CrowdSurfer) 5 


CrowdSurfer design document 6 
Game Identity / Mantra: 6 
Design Pillars: 6 
Genre/Story/Mechanics Summary: 6 
Features: 6 
Interface: 6 
Art Style: 6 
Music/Sound: 7 
CrowdSurfer PostMortem (Prototype-State Not functioning) 7 

Week 2: Theme Berlin (Berlin Berlin) 8 


Berlin Berlin design document 10 
Game Identity / Mantra: 10 
Design Pillars: 10 
Genre/Story/Mechanics Summary: 10 
Features: 11 
Interface: 11 
Art Style: 11 
Music/Sound: 11 
Berlin Berlin Post Mortem: 12 

Week 3: Theme Destroy (Boom Miner) 13 


Boom Miner Design History 13 
Initial Concept: 13 
2nd Iteration (A good accident) 14 

Week 4: Theme Toy and Playfulness 16 


(Pocket Mansion) 16 

Week 5: Theme End of the World (Lost) 19 

Week 6: Jump (Hell Minion) 21 


Game Identity / Mantra: 22 
Design Pillars: 22 
Genre/Story/Mechanics Summary: 22 


 

Features: 22 
Interface: 22 
Art Style: 22 
Music/Sound: 22 

Week 8: Physics (Dwarven Defense) 24 


Game Identity / Mantra: 26 
Design Pillars: 26 
Genre/Story/Mechanics Summary: 26 
Features: 26 
Interface: 26 
Art Style: 26 
Music/Sound: 26 
Week 9: Gift (Guidance) 28 
Game can be researched furthermore: 29 
Week 10: Sequel (See You laser 2) 30 

Learning from the course 32 


[Link] design as a form of Problem solving: 32 
[Link] Scoping: 32 
[Link]: 32 
[Link]: 33 
5. Learned about myself: 33 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Introduction: 
This journal is the documentation for Design Process for the project’s in 
the Game-A-Week course. Held in University of Europe For Applied Science under 
the supervision of Prof. Csongor [Link] Journal Documents the various 
steps of Game Development and Design Documents for the Games created 
during the course. 
The course was Game Jam formulated into a course itself where we 
were to create Games in Week to the Theme [Link] documents included 
are the actual Game Design Documents in digital form, screenshot during 
development and conceptualising. And self reflection along with the learning 
from some of the games created. 
 
Sagar Shrestha 
 
 
 
 
 
 
 
 


 

 
 
 
 
 
 
 
 
 

Week 1: Theme One Button (CrowdSurfer) 


The theme for the first week was One Button. 
 
Conceptualisation: 
 
My thought process for this theme was how one button be used as the only 
input and completely cover the game mechanics with the single button. 
 
Theme--->Mechanics 
 
What Game works with 1 button mechanics? 
 
Flappy bird. 
 


 

A flappy bird always moves right and we only have to jump to evade from the 
pipes. 
 
Taking this idea. The second question in hand was 
 
When would this movement make sense? 
 
Then it clicked. A person in a concert crowd surfing has no control over his 
movement and (can jump?) 
 
That idea led to prototyping of ​CrowdSurfer. 

CrowdSurfer design document 

Game Identity / Mantra:  


An endless runner based on crowd surfing in a Metal concert. 

Design Pillars: 
Fast-Loud-Difficult 

Genre/Story/Mechanics Summary: 
This game uses the basic concept of crowd [Link] main mechanics in the 
game is diving (technically a jump).The platforms are crowds. 

Features:  
Pixel art/Ambient light representing lights/Alien Enemy(?) 

Interface:  
Input: Press Space to Dive. 
UI: Mouse Controlled. Instant restart with [Link] for the amount of time 
survived. 
 

Art Style:  
Modern Pixel art (64x64 asset) for the character and [Link] assets size 
(128x64) Heavy Metal themed 


 

Music/Sound:  
Include links to music and sound design similar to What you're trying to achieve. 
You can also list the emotional responses that the sound should invoke in the 
player. 
 
 
 
 
 
 
 
 
 

CrowdSurfer PostMortem (Prototype-State Not functioning) 


 
The game concept was quite unique and upon prototyping the jump mechanics 
worked very fine. But the introduction of enemy objects was definitely the worst 
decision made during the development. The enemies made broke the game as 
the enemy generation script wasn’t in sync with the level platform generation; it 
created a situation that a player was more likely to get enemies instead of safe 
platforms. 
 
During this project I developed the following skills: 
1. Create a game i.e. not just having the game as content but also menus and 
UI. 
2. Using Playerprefs. In unity for scores. Even though it isn’t the best way to 
create a high score it worked for this simple game. 
3. Taking a theme,concepting and then prototyping 
4. Even though the game wasn’t properly functional.I learned to accept 
failures as a part of any design process 
 
 


 

 
 
 
 
 
 

Week 2: Theme Berlin (Berlin Berlin) 

 
The second topic had a unique spin. After the mechanics heavy one button game 
this was a completely abstract theme. 
 
Conceptualisation: 
 
This theme had so much potential since the theme could be any game, any genre 
and any mechanics. 
I thought since this topic would be huge added self restriction to the project 
1. The game has to be in the classic Gameboy color palette. 
2. For some reason, I wanted to be somewhat of a small tribute to Ghost 
buster, the classic NES game from 1984. I had a fond memory of this 
horrible game from my childhood.  
 
Gameplay Concepts: 
The first idea was some sort of platformer that would bind Berlin as a part of it’s 
narrative. 
Once I had the narrative idea the gameplay started forming around it. 


 

 
Narrative: A game depicting a semi-reflection on somewhat my experience in 
Berlin with experiences like finding an apartment and small quirks that would 
very much define “Berlin” itself.  
 
 
 
Gameplay:  
A Gamified menu which came from restriction itself. The Ghostbuster-inspired 
cityscape layout would be the base for representing apartment buildings and 
monuments in [Link] the main game revolves around the interactable object 
within the apartment rooms. 
 
Game Loop: 


 

Berlin Berlin design document 


 

Game Identity / Mantra:  


Classic GB Palette mini games and interactive about a person landing in Berlin 
for the first time. 

Design Pillars: 
Semi-accurate depiction of Berlin.  
Slow paced game. 

Genre/Story/Mechanics Summary: 

Person landing in Berlin for the first time and having to go through finding an 
apartment,getting a job and earning more cash to get a better apartment and 
work enough to get a better job. This game loop continues until all the 
apartments have been rented once by the player.  
The main gameplay states must have 3 distinct state: 
[Link] Screen State (very reminiscence of early NES The GhostBuster game): This 
is where you find apartments. This will have all the major places in Berlin as a 
residential area. 

10 
 

 
 
 
[Link] Screen State 
Letter boxed screen showing just the apartment room .(Very focused) 

 
[Link] Screen State 
In the screen state there are many interactable objects that lead to a small mini 
game or interaction. Must have: 
[Link] 
b. Pc to find job and receive emails 
c. Door to go to the job 
[Link] to prepare meal 
e. fridge to go shopping 
 

Features:  
GhostBuster 1984 tribute.​Ghostbusters .​   

Interface:  
Input: ​WASD/ directional Key for movement 
Mouse for UI 
KeyDown F for interaction 

Art Style:  
Pixel Art. GB palette  
64x64 for all assets 
Assets: Character,Room and furniture, Tiles and buildings. Maybe a landmark (TV 
tower,World clock and Brandenburger Tor) 
 

Music/Sound:  
Very Berlin Club scene music (opensource) or traditional chiptune(16bit) 
 
 

11 
 

Berlin Berlin Post Mortem:  


 
 
What went right? 
● strong visual style 
● Game staying true to the core theme with game asset,narration and using 
music from berlin scene 
What went wrong? 
● Scope of the project was large. Hence couldn’t add all features 
● Couldn't find a clear identity to the game whether it would be narrative 
driven or just be a set of causal games  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

12 
 

Week 3: Theme Destroy (Boom Miner) 

Boom Miner Design History 

Initial Concept: 
For the third theme I decided to create a roguelite bomberman [Link] game 
would work as a traditional dungeon crawler but with bomberman mechanics as 
it’s backbone structure. 

 
But after creating the bomberman clone and applying some dungeon like room 
and enemy [Link] game felt fun for early room but felt slow and repetitive. The 
bombs felt very slow with a timer in an open dungeon environment. 

13 
 

2nd Iteration (A good accident) 


While protopying the game initially I had used the player controller script from 
the previous game jam (GameAweek: Berlin) The script had two movement 
methods. One was a top down version and the other one had a platformer style 
controller.I accidentally activated the platformer controller while i was testing the 
[Link] game felt completely different and had almost “Spelunkish” feel to it, 
which made me change my game into a fast paced platformer. 
 
There wasn’t a certain design to follow so the further iteration were based on 
tweaking the old concepts. The enemies ai was changed from top down to a 
platformer based ai. The dungeons were changed to larger top to down square 
platform [Link] the biggest change was all the enemies as well as platforms 
could be destroyed. 
 
Bomberman-->Boomminer 
 
Description of the game:  
 
Boom Miner is a speed platformer with relentlessly chasing magical 
[Link] play as Bopo, in a futuristic underground mine exploring the far 
[Link] can bomb each and every structure and environment that lay in the 
mine which can be often good or horridly [Link] the immersive futuristic 
mine and survive. 
 
Key Features: 
● Non Linear Exploration: 
There is no fixed path to [Link] your own path by destroying the 
mysterious 
environment as you go. 
● Relentless AI: 
Each and every enemy will chase till the end until dealt with. 
● Pixel art and VFX: 
Semi-modern pixel art style with intense vfx and a soundtrack that can kickstart a 
Rave in itself. 
 
 
Boom Miner Prototype Postmortem: 
What went right? 
● A working game with levels 
● Game Juice 
● Enemy design 
● Fresh design and color palette 
What went wrong? 
● Level design 
● Lack of boundary definition 

14 
 

● Introducing too many elements or mechanics too early 


 
Development after the Prototype: 
Boom Miner 0.5a 
Changelog: 
● 3 unique levels (The Fall, The Chase and The Fly) 
● Add Boundary tiles for the out of bounds area 
● Enemy balance in terms of speed and numbers 
● Removed plant enemy from the game 
● Minor fixes to controls 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

15 
 

Week 4: Theme Toy and Playfulness 

(Pocket Mansion) 
Group 
● Nina Hanau (Art/Concept) 
● Luisa Enciso (Art/Concept) 
● Sagar Shrestha (Coding) 
 
 
● Design Idea 
Nina/Luisa 
 
1. A digital polly pocket. Gameplay would replicate the joy of building up a 
polly pocket room 
2. Concept to Game Design 
 
A coin generates over time like in plants vs zombie ( PVZ the main inspiration 
behind the game play) 
 
Initial Prototype with placeholder art: 
[Link]
 
The game would be front facing and the furnitures could be dragged and drop 
into the scene 
 
My Code Requirement 
 
 
1. Coin Generator 
2. Drag and drop object Manager 
3. Furniture Manager (Scriptable objects) 
4. Level Manager 
5. Interaction Script(Onclick Audio,Drag Image) 
6. Furniture Placeholder script 
7. Timer 
 
 
 
 
 
 
 
 

16 
 

 
 
 
Self Evaluation 
 
Though the codes requirements were fulfilled the way I approached the 
task was too complex. From the very beginning I was convinced that UI based 
scripting would be best suited for the [Link] upon building on that concept 
the coding of UI script in Unity was more difficult than expected. The unity 
documentation had very little resources for UI based scripting. Hence a huge 
amount of time went on researching the topic.I should have realised it and 
should have changed my workflow to 2d GameObject based scripts but it was too 
late. 
Managed to get the game to work but was very buggy and irresponsive at times. 
 
Group Work 
This was my very first group project for the course. Nina and Luisa approached 
me with a few ideas they had for the project. One of them was a Dating simulator 
style game and the other was a game based on a polly pocket toy. 
 

 
We properly created a workflow where we had what is to be done and what is the 
highest [Link] had constant communication if anything was done or 
changed in the game in terms of art feature and codes. 
 
 
 

17 
 

 
Pocket Mansion PostMortem 
What went right? 
● Project Planning 
● Scoping 
● Work division 
● Communication 
What went wrong? 
● The linear game 
● Usage of coin mechanics for a playful game 
● The issue with UI’s 
● Coding using difficult approach 
 
 
 
Overall it was a great experience working with both of them.. It certainly 
helped much better to understand planning efficiently and understanding team 
dynamics while all of my early projects were [Link] even though the project 
was stressful at times in terms of workloads, the team had a positive attitude 
throughout the development phase. 
 

18 
 

Week 5: Theme End of the World (Lost)  


 
Lost 
 
─ 
Group 
Sagar Shrestha (Coding) 
Marie Wispler (Art) 
Jasmin Stahn (Art) 
 
Design Idea 
Point and click platforming adventure 
Game Staging: A room with a world in chaos 
Interactable object depicting the 2020  
 
Concept to Game Design 
SideScrolling platformer (Without Vertical movement or jump) 
Mouse click to interact with objects  
Game starts with animation  
In Gameplay state the play interacts with the objects. After interacting with all the 
interactables activates a final interactable leading to end animation 
My Code Requirement 
● Interaction Manager and main game logic 
● Platformer 
● UI Script 
 
Self Evaluation 
In terms of code requirement there was very little for me to input. The codes were 
done by the first two working days. And furthermore worked in fixing bugs and 
helping with other content as required. 
 
 

19 
 

Group Work: 
 

 
 
For this project, Marie, Jasmin and I had a very clear goal on what we 
wanted to achieve. The design goals were set on day 1 and we religiously followed 
it till the [Link] everyone had a clear understanding what we were supposed 
to do,the workload felt like a breeze. There was constant communication if we 
wanted to work on Unity and would always update each other if we changed 
something or something as done. We at the end managed to create a game that 
we visioned it would be. 
 
Lost Post Mortem: 
What went right? 
● The group coordination 
● Communication 
● Efficient work division 
● A finished game 
● Awesome art 
What went wrong? 
● Few UI bugs 
This was one of the most relaxed I had been from the beginning to 
the end in terms of the game development process. Both Marie and Jasmin 
pulled off the vision in terms of our artistic goals and we managed to 
deliver a staryrical narrative on current events. 

20 
 

Week 6: Jump (Hell Minion) 

The sixth theme was Jump. 


 
Concept: 
For concepting for the theme I initially decided on doing some sort of platformer 
but the theme it would be a very obvious choice. 
 
So, I decided on making the jump mechanics on a genre that would fit the jump 
mechanics.I planned on applying the mechanics on a top down [Link] was clear 
that it would difficult to implement the jump on top down style game. 
 
How did I approach the design challenge? 
There were few questions to design such a game. 
 
● Why would we require Jump in a top down? 
- A obstruction in the form of lava implemented 
● How could it be fun jumping from platform to platform? 
- Initially I thought of some sort of item collection game within a 
time period. But later I came up with a character design and 
formed a narrative around her. Then the ideas came pouring 
in. Instead of collection items the player had to survive from 
enemies' very bullet hell style. 
 
Core Loop was formed around these ideas. 

21 
 

Hell Minion Design Document 

Game Identity / Mantra:  


Top down Bullet Hell survival. The game revolves around surviving unique bosses 
over the given time duration. 
 

Design Pillars: 
Jump a core mechanic-No weapon No attack-Time based-Difficult 

Genre/Story/Mechanics Summary: 
Genre: Boss Survival 
This Game revolves around Layla the fierce Demonslayer, stuck in purgatory. She 
is given a chance to escape this Hell by The GateKeeper having her survive his 
minion without her trusty [Link] she fails she will forever be stuck in this loop. 
Mechanics: Just one -Jump. 

Features:  
Pixel Art-Music synced projectiles-One Button-One Mechanics 

Interface:  
Square Level Design 
Controls: Mouse Click for both UI and the main game mechanics 

Art Style:  
Pixel Art very much representing Hell like surface and unique minion with 
projectile that complement them 

Music/Sound:  
Open source music  

 
 
 
 
 
 
 
 
 

22 
 

Hell Minion Post Mortem 


 
What went right? 
● Polished Mechanics that was very responsive. 
● Level Design around mechanics 
● Sound effects for the character (random response sound effect) 
● Design pipeline that led to to usage of jump in a genre that would fit 
 
What went wrong? 
● Not updating to bitbucket regularly even if a small project.  
○ During the prototyping phase i accidentally formatted my hard drive 
while formatting a flash drive 
○ Had to redo the work form the start 
● Level Design 
The level had few flaws where it could be completed by jumping on two 
tiles. 
● Issues with the menus 
 
The game was presented in Playtest Evening. Had positive feedback 
but could see the level design issue where a boss could be completely 
ignored by jumping on two tiles.  
This game made me realise that projecting back is very important in this 
case updating regularly instead of the working game as a whole even if 
working alone. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

23 
 

Week 8: Physics (Dwarven Defense) 


For week 8 the theme was physics. 
 
Unlike other games I already had a clear idea what i wanted to work with 
this theme. I had been working with a fluid simulation based on a Unity package 
that would seem very fitting for the theme. 
 
Thought process for design: 
 
What I had? 
A fluid simulation  
 
How could it be gamified? 
My initial idea was to do a puzzle based game. But the more I started playing 
around with the simulation, the more I built up a story around it and more 
gameplay ideas were formed. 
 
Short Narrative: “A mere thousand army of us...Dwarves, Elves and Humans  
We are outnumbered against the Evils beneath. 
For now we shall borrow from the mountain again.. 
From it’s core..Deep from it’s fiery pits… 
They shall meet their demise in the burning inferno.. 
No soul is safe, not even the undeads.. 
Hail the burning pyre, Hail the Molten Core..” 

24 
 

So after thinking about the narrative and what could be done with the fluid 
simulation. I was fixed on the idea of top down invader like game going away from 
a puzzle based game i had planned upon. 
 

I created a small prototype playing around with the mechanics and 


created basic pixel art for the [Link] day Luisa asked if we could work 
together again on the week’s theme. So Luisa joined me for the game and I 
explained how I had a prototype already working and she agreed upon helping 
me with the art assets for the final version with the key art, animation and the UI’s. 
 
In the coming days I played around with more interactables adding side 
mountain slopes and more ledges.I completely focused on the level design and 
editing sounds for the game while Luisa took charge of the game arts. We also 
decided on the name “Dwarven Defense” for the game based on the short written 
narrative dialogue. 
 
 
 
 
 
 
 
 
 
 

25 
 

 
 
Dwarven Defense Game Design Document 

Game Identity / Mantra:  


The Dwarven Defense is a classic Invader like game with interactable lava. 
 

Design Pillars: 
Mass Enemy-Increasing pace-Short single level  

Genre/Story/Mechanics Summary: 
Hordes of Orcs are assembling beneath The Forge Mines of Dregor. Even though 
outnumbered. The sparks of hope arise from the depths of the mountain. 
 
Mechanics Summary: 
Fluid mechanics would be completely interacted with and each dispersion of fluid 
or lava would have hit colliders. 

Features:  
A game set in Lord of the rings fantasy realm 

Interface:  
Wide level design with environments and objects that interacted with the lava. 
Controls: Mouse Click for both UI and the main game mechanics as well as A/D or 
left/right for the movement 

Art Style:  
Pixel Art with Tolkien inspired characters. 

Music/Sound:  
Open source music: Catalyst by Alexander Nakarada @thenakarada 
 
 
 
 
 
 
 
 

26 
 

What went right? 


● Rapid prototyping 
● Game performance optimization with load heavy fluid mechanics 
● The Game Aesthetics 
 
What went wrong? 
● Linear gameplay 
● Lack of playtesting resulted in very imbalance game 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

27 
 

Week 9: Gift (Guidance) 


This was one of the unique themes for a project. 
So for this theme not only we were creating a game but also creating a game for 
someone special.I decided i would create a game for my grandmother. 
 
Game Design Conceptualization: 
 
What would be a game for my grandmother? 
It was a difficult answer for me to decide.  
As a background story she is slightly paralysed on her left arm due to a heart 
attack a year ago. And this was a very challenging issue not in terms of game 
design but what medium can she “Actually Play the Game”. 
 
I remembered I had recently seen a concept of speech control for Unity and if 
this would work, i could do something with that. I researched on this topic a lot 
for this project.I finally found the topic on Unity’s Scripting References on Audio 
and video based scripting. I finally had something that could be a medium that 
would allow my grandmother to play the game. 
 
I started working with a single sprite and had it working horizontally and 
vertically based on speech.  
For the first iteration: 
The sprite would move on dictation as left, right ,up and down. 
 

28 
 

And when i got it working I realised this could be perfect for a Maze like game. 
This would also be simple enough for her to understand. 
 
I generated a few maze levels from the maze generator( ​Maze Generator​) [Link] 
added a player sprite and end goal sprite. 
Then finally created controls dictation to english-nepali so that she can speak in 
the comfort of the native language. 
 
The controls Dictation: 
 
Right: Daaya 
Left: Baaya 
Up: Mathi 
Down:Taala 
 
The game was done and I sent it over back to my cousin to have then show 
it to [Link] had a hard time believing that the game was actually following her 
commands and was unsure whether to be scared or amused of [Link] overall she 
seemed happy for the gift I made. While my younger cousins seemed to very 
much enjoy the game. 
 
Reference to the concepts used for the game: 
 
Unity - Scripting API: KeywordRecognizer ([Link]) 
 
Since this was very experimental in terms of Design. This project led me to think 
more about the various possibilities and what else could be done. The game from 
other students, especially this theme showed very experimental games that had a 
huge influence on solving real world issues.  
From the huge resources of information and technology we have and we 
as game designers could have a bigger impact in society rather than creating 
games as a source of amusement. 

Game can be researched furthermore: 


● Games as therapeutic medium 
● Games as Learning medium 
● Games as Rehabilitation source 
● Games as Socio-historical representation 
● Games as Research tool (Simulation, Real World Data 
Experimentation) 
 
This course really helped me understand that games can be far much 
more than pixels on screen and they might be a tool, a self identity, a visual 
masterpiece, a voice.  

29 
 

Week 10: Sequel (See You laser 2) 


For the theme see you laser I worked with Ian who would be doing the art and 
reskin. 
 
Our Approach to the theme: 
For the sequel game. We discussed extensively on the game we liked from the 
course and strictly decided not to work on our own game. We both selected the 
game we liked and narrowed it down to the game we felt had a lot of potential to 
have a sequel. 
We finally narrowed down to two game 
1. Mole in a hole (Nina/Martin/Martim) 
2. See you laser (Marie/Gareon) 
We both had a look into the repository on how readable the game repository was 
and how difficult or easy it was to reverse engineer the [Link] so we both 
decided on working with See You Laser’s sequel.  
 
Our Idea for the game: 
● Have the main core mechanics as it is 
● Introduce two new mechanics 
○ A button 
○ A Prism 
 
 
I started working on the new mechanics while Ian worked on reskinning the assets 
of the game. 
 
 
 

30 
 

Coding Issue: 
This project seemed very much simple in terms of game codes and interaction. 
Later found out how difficult it would be to modify certain aspects of the game. 
Having done with the button part with the door. 
I started working on the prism that would take the main source of ray and 
diverge them into four [Link] it was achieved but the secondary ray 
would interact with the win goal sprites. I spent a huge portion of time 
researching how the line renderer worked in unity so as to properly be able to 
put our idea into a working mechanic. But even with so much time spent on the 
mechanics, I failed to achieve the goal. 
Then Ian i discussed and decided to leave away the mechanics for later and work 
on the advanced button mechanics that would allow the door to open once the 
button was hit and close if the laser moved away from the button. 
Then we ran into another problem: the line renderer would work for the opening 
of the door but wouldn’t close one if the laser was moved. This would also take a 
huge portion of the development phase. 
Finally we decided to make a simple puzzle based around the open door 
mechanics and let go of our other [Link] designed a couple of levels working 
around our limited mechanics and pushed our sequel of the game. 
 
See You Laser 2 PostMortem: 
 
What went right? 
● Communication with each other 
● Scoping the project 
● Simple Level Design 
What went wrong? 
● Not letting go of desired feature when they were not working 
● Time management 
 
What I learned from this project? 
● Dont keep on working on it if it keeps breaking 
● Manage time better 
● Failure is a part of problem solving 
 
 
 
 
 
 
 
 
 
 
 

31 
 

Learning from the course 


Within the span of the course I think my understanding of Games completely 
changed. Apart from that I figured out patterns in the games I created that 
reflected part of myself in some form or the [Link] main takings from the 
course for me are: 
 

[Link] design as a form of Problem solving: 


Within the course period, the way I approached game design completely 
changed. I think before the course my knowledge of game design was merely a 
piece of art with codes to form some sort of game play or [Link] within 
the course period I was constantly questioning myself the reasoning behind the 
design choices I was making.  
I started to view these designs as problem [Link] when the theme was 
introduced I would question myself either in Why/Where/Who sort of way. This led 
a large portion of the game I created seemed more in depth rather than for the 
sake of making it.I usually created a Design Document which would not be an 
actual goal but a guideline to follow so that not to go overboard with ideas and 
also keep in track with main visions. 
 

[Link] Scoping: 
I think project scoping was the most noticeable change I found in myself 
after the course. Creating small games in the given time frame allowed me to not 
only focus on a particular part of the game to perfection rather than have a 
prototype that would give a vertical slice of the entire [Link] was definitely a 
big issue for me going through the course. I would usually have big ideas with 
each and every aspect of the [Link] it took me a few theme’s prototyping for 
me to realise what I was possible to create and at what pace in a week. 
 

[Link]: 
Usually documentation for me was just to submit for an assignment. But 
for this course I religiously made documentation before,while and after creating 
a game. Documentation of things like the design documents helped me to stay on 
track and had a basic overview of the main goal.I was more focused and always 
felt good while all your to-do list or something got green ticked. 
 
 
 
 
 

32 
 

[Link]: 
Coming from a huge semester project from second semester narrative 
[Link] was far much different in terms of coming with a concept and having it 
complement the theme . During the course I watched enormous amounts of GDC 
talks or documentaries just to get [Link] really helped me to shape 
thinking and understand the mentality of successful sometimes unsuccessful 
game dev veterans on game [Link] with that I was also always 
researching over what tools and features we had on our disposal. I started 
following unity’s updates and features started going through their scripting 
documentations. 
 

5. Learned about myself: 


I think this was one of the things that I was most unaware of. That as an 
artist or a creator always has his or her self reflection on a piece they paint or 
mold. I thought the authorship idea was like one the important learning we got 
from the course and the way this idea was delivered after we already had few 
games made it clear we had games that were some way or the other a part of us. 
Like for my love of heavy metal music and love of movies were always influencing 
my design to a very Heavy, ambient and theatrical games. 
 
[Link] is a game?: 
 
From this course I realised games with guns and action were ot only the 
game. I had a chance to see amazing games from my fellow students that were 
more than just games. Sometimes voicing a cause, sometimes would be a visual 
porn, sometimes awaring us other times just an artist thought they were 
packaged in the form of an interactive. 
 
All in all this course was especially delivered for what I wanted to achieve 
while joining the University. This course not only helped with our skills but also 
helped us sharpen nour [Link] the end everyone had a bunch of 
games at their disposal to call them their “own”. 

33 

You might also like