But what does that mean? What does it mean to design something?
For my Ba. I went to a university where they taught us graphic design in a very broad sense. I have a “Ba in Design”. But I don’t feel like I have even scratched the surface of what design is.
I used Photoshop since middle school, I learned to hate InDesign early when composing the school newspaper, I took photography at uni, I drew abstract paintings and so many chairs that I want to break them. I created brand guidelines, websites, I’m working on a “user experience”, I make games.
But I do not know, what design is.
To me design is creating but it is also art. I’m willing to argue that all creation is art even if the creator did not intend it to be art. What is the difference between a painting and a well designed web page? Their function? Does this mean that mastery and expression are not part of either of the professions? Why do we separate them?
What about coding?
Or let’s be radical, cleaning.
Everything we do, everything we create, we design. Ergo, design is all and design is nothing.
Design does not just live beyond the pen tool, the pen tool is an artifact of design around it.
Even human behavior is designed. Ever since the first tool, we used design and design shaped how we act. Design is human.
I started studying game design 3 weeks ago at IT University of Copenhagen. During these two weeks we’ve had to work on multiple, smaller, team projects already, In those projects a question often came up. How many points should X give you? How long can you do Y?
I fundamentally detest these questions. This is not something a designer should care about, especially in low fidelity prototypes.
What we, designers, should care about is interaction. Not balance. Yes, balance can affect interaction, there would be a big difference in basketball if the 3 point field goal was suddenly a 10 point goal.
However, when we are making prototypes, I am of belief that this does not matter. The only thing that matters is that we distinguish between something being worth more or less. If shooting outside the normal range gives you 5 points in our basketball prototype, who cares? The important thing is that we distinguish it being worth more than the usual amount.
How much more? We will figure that out later. We don’t even know if having the separation between shots is fun.
So don’t care about the balance now, care about design. Test your design, see if it works, then worry about the fucking balance.
It’s a small game that I made for a 3 hour jam. I really liked the core concept and wanted to expand upon it. It was a platformer, but you are a magnet.
I decided to go with a minimalist approach to the gameplay. Essentially there we no other mechanics added to the game.
This meant that what I wanted to do during the next few wees of development was: – Make the game as juicy as possible – Create levels that use the core mechanic in a lot of unique ways – Create a good pacing for the game – Work on “supplemental” features (saving, high-scores, achievements…)
1) What went right
I really wanna pat myself on the back here, but I think visual juice* was something that I did a good job with. What was just a block spinning later becoming a loving rectangle that wiggeled and waggled based on the player’s input, squished when it hit a wall and splatted the floor with color when it hit an obstacle.
The only “feature” added to the game were optional pickups.
Towards the end of the development I really hit the home run. Thanks to a friends encouragement I added eyes and a mouth to the magnet. While this is recommended even in the classic “juice it or lose it” I didn’t want o do it at first. I didn’t want to “commercialize” the game. I felt like doing that would ruin the minimalist aesthetic of simple
Besides this being juicy visually, I think the core mechanic of the game was really strong and I am happy that I did not succumb to feature creep. Good job me, stay lazy on feature implementation 🙂
*I believe that I could have done a much better job at audio juice as well, however, for my next project I have an audio god on my side so that’s gonna be covered.
2) What went bad
Online stuff is hard.
When I uploaded the game to itch.io I had a high-score system that used google forms as a “back-end”. It would send data to a google form when a speedrun was completed that would submit it to a spreadsheet.
This spreadsheet was supposed to act as a sort of back-end system for the high-score that the game would pull data from.
This was a solid plan and maybe someone with more programming knowledge would be able to execute on it easily. However, I was f*ing lost. I lost about a week of development time trying to get this work, to no avail.
In the end the itch version linked to the spreadsheet instead of having an in-game high-score. This broke half way through and I don’t know how to fix it. The newgrounds version ended up using their built in highscore system, which worked quite well. Occasionally it reports an impossible time like 10 seconds, no clue how but hey I can manually remove those times so that’s nice.
Level design is also hard. I felt like one of the goals I was not able to achieve was teaching the player how to correctly play the game. From anecdotal evidence, players usually have the most trouble at level 4.
They are required to spin and then, spin again while still using the momentum from the first push, to travel further vertically. This is a core concept of the game that is used in other levels to allow the player to finish the level faster or to reach some of the hearts.
In my anecdotal user testing players completed this level without understanding what they did or they failed to complete the level.
I tried to amend this by introducing level tittles, this one being “Two spins = high jumps”. However, this was really dirty and the level itself didn’t really teach that to the player.
Reflectively, I should have put more of the obstacles that require the same trick to get the player to “get it”.
3) What I’ll do next time
A few bullet points for myself:
I will do even more playtesting
I will spend more time creating levels
I won’t waste time on high-score systems
Make sure that my code base won’t be super messy
Throw away the 3 hour prototype, build it from scratch next time!
During the last month I challenged myself to get better at prototyping games. To do this I decided to enter a gamejam every week – the jam I chose is Trijam, a 3 hour game jam. I’ve noticed that I developed some interesting patterns during these jams and I will discuss these here.
Sketching out ideas is the way I start my designs
Let me preface this that the structure of Trijam allows you to do “some” parts of the work outside of the allocated 3 hours. This primarily includes brainstorming ideas so usually I come into the 3 hours having a good idea knowing what I want to make. However, I do try to keep the brainstorming time limited to a span of 1 hour and I primarily try to look for inspiration outside of games. I do this as I try to avoid doing the “easy” 3 hour prototypes that don’t really differ from each other – endless runners, top down shooters these are the most common of Trijam entries.
Because of the 3 hour time limit I am forced to strip the game to it’s very core idea. This means that any sort of “extras” and “variety” is stripped away. Does your game include different “extrapolations of clicking”? That’s not going to be included in the prototype. Is there a randomly generated level in the game idea? That is not going to be in the prototype.
Variety makes games fun, without them they would be dull – I mean imagine if you could only pick between 5 champions in league of legends or play only with one gun in CS:GO. It would not be nearly as interesting as it is right now. However these are 3 hour games and the goal that I have here is to create a GAME and not a system! I understand that 3 hours might be enough to code 3 quick variations of an enemy or a system that generates a level – however it is not enough time (at least for me) to do that and make a GAME.
Core mechanics of my 3 hour games:
Heal the Peasants – Press the correct button to heal the peasant, pressing the incorrect button wounds him.
A cozy storm – Point and click on objects to get descriptions of them.
Bomb the gum – Turn based movement with bombs that destroy their surrounding.
The Night Shift Cycle: Reach the end of the map however you only see things when you move.
Six Waves: Tower defence where you need to defeat 6 waves of enemies.
Late Time: An evil twin mirrors your moves with a delay. Kill him without killing yourself.
The reason why I am capitalizing “GAME” in the previous paragraph is that I am trying to create a full game prototype. So something that you play and feel like it is actually a game, with some sounds, graphics with some juice. This is why usually I try to limit myself to 1-2 hours of programming and the remaining time being dedicated to polish. Fig. 1 has the exact same gameplay that Heal the Peasants had in the end, however it does not feel as much of a game as it did at the end of the jam.
The best part about this is that every weekend I end up with a working (for the most part) prototype for a game that tries to capture some form of vibe. It allows me to experiment with some mechanics and it is visibly making me better at quickly prototyping games. I (almost) always get something tangible at the end of the 3 hour cycle and I feel like I am always impressed by the amount of things one can do in 3 hours if you plan correctly.
When I really enjoy a game and feel like I have a good groundwork I usually spend 2-3 more hours the next day making the game feel better. Just small, juicy changes.
Adding a bit of particles and smoother UI transitions made Cosy Storm a bit more cosy.
Interestingly enough, I feel like I started valuing sound and music inside of games a lot more since starting to participate in Tri jam. Having a game with sound makes it feel a lot more like a game and music is key to creating a good atmosphere. I usually use SFXR to create quick sound effects and when I’m set on the theme I try to spend some time on the Newgrounds music portal to find a song that would help “sell” the game.
While this definitely made me push myself in prototyping speed one thing that I became a bit more afraid of is trying out completely new concepts. This is the most apparent when I try coding something completely new because OBVIOUSLY it is going to be way worse than something I already
No cycling was done that night
know. With The Night Cycle I ran (cycled?) in a bunch of bugs which caused me to not have a working game in the end.
While Late Time managed to be exported in the end I wouldn’t necessarily say it is a stellar game considering I spent 2+ hours working on a mirroring system that did not end up working.
After 6 weeks of active participation in Trijam I am more than happy with the results. I’ve became much more swift at transforming ideas into code and I’m more confident in my abilities to actually code a game into existence. I’m looking forward to attending more Trijams – they have become a good habit that I look forward to over the weekend. I would encourage you to do the same and if you wanna see some of my results go ahead.