SagarShrestha DesignJournal
SagarShrestha DesignJournal
agar Shrestha
S
1
Contents:
Game Design Journal 1
Game A Week (20/21) 1
Contents: 2
Introduction: 4
2
Features: 22
Interface: 22
Art Style: 22
Music/Sound: 22
3
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
4
5
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.
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
6
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.
7
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.
8
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:
9
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
12
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
14
15
(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
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
21
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
23
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.
25
Dwarven Defense Game Design Document
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
27
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.
29
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
[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.
33