Welcome to the second entry in GLOWs Post-Mortem series. I've analysed my workflow and it boils down to two tips. People commented that the "immersion" of "the little world" I made was really great, and that they would love to come back. So this entry is about how I did quick design that has a certain degree of "very polished". While it is very simple on purpose (WASD only) has no text or explanation in the game itself, making level design the only way of communication to the user. I will first explain to you how I designed the world, then I will give you some examples of how it worked out: The good, the bad, and, sure why not, the ugly.
A relink on my article on Audio (from/for noobs) was summoned. So check it here.
The Good
Level design for Game Jams, especially during the ones that are over in the blink of an eye like LD, can be quite challenging if the approach is not very well prepared. However I learned that it is quite possible when you use the right approach, the hard way though. I think I did it with two main thinks I could describe as:
1. Teach as you go
2. Meaningfully Reuse
These two will dictate that you find a process that works great for you.
Finding a great workflow is key. It speeds everything up, and forces you to think your design through at every step, while KISSing (Keeping It Simple, Stupid). Even if, like me, you always try to go with completely different art styles, game genres and team compositions. Right between coming up with your idea and actually starting you should define which tools you are going to use, and design a workflow. Last week for me this was picking Illustrator, which I never used in game development before and getting it in Unity (Illustrator->Photoshop->Unity). Idem for GarageBand (GB4iPad->GB4macOS->Unity).
Teach as you go
You are getting a PhD in your own game, you discovered its laws and how they all work together, what's there to teach yourself? Well, getting a PhD is about learning, discovery, what elements will work together. Getting a PhD is also about explaining your findings to others. For each law, and interaction between them think of a way to explain it to someone who doesn't know anything about your world. While you might feel that that is the most important rule in game design, it is certainly something not getting enough care when you are in a rush. So, as you explore the possibilities of your discovered laws, think of ways to show others how they work, and make a level on how you would explain this. Make puzzles like you would make slides for a presentation, just keep in mind that there is no time for questions. If you do it this way, you automatically create some sort of workflow, one based on exploration that helps you generate levels.
Meaningfully Reuse
Only slightly modify the assets you have, don't make new ones. Rotate, scale, skew, warp your sprites, it will look differently. Making a grid based game? Add some detail sprites, which you randomly place of others, don't make ten by hand, just do some simple but clever programming and maybe get hundreds. This also goes for music, just do a quick reorder your notes to quickly make it more interesting, lower your a few octaves and poof a bass line. And even designed gameplay elements, e.g. simple mixing and change the distance between others.
Of course it should be meaningful. Does it make sense? Well, I think this can be answered with the previous tip: If you think you can teach it, it probably makes sense (or its just plain funny) and thus meaningful. Does it make sense to the player to find this plant in this area?
Some things are not obliviously things that can be meaningful. E.g. what colour schemes work, what kind of instruments sound well together. I think things like that boil down to spectra. Colours convey meaning, so thats definitely meaningful. Colour schemes should be well spread-out, but still have some connection to each other, e.g. different colour, same brightness or vice versa. There I think meaning comes from the relation between the colours. Similarly this works for audio. Does it make sense to make this sound when you hit something or pick up that orb. Does this bass line add meaning to the other instruments? I think those are questions that you can ask yourself to make even such abstract choices easier.
For programming this is a tad different: programming at its core, especially Object Oriented is reusing all the way. My tip here is, to embrace simple copy-pasting of code, its only 48 hours. Keep it simple by not over-engineering your game. And in this timeframe you should be able to memorize where you reused code when resolving bugs.
Don't feel like slightly modifying it? Just reuse it. Then mutate it a bit. (e.g. different distance between other elements, increased speed, different size) Especially if are you stuck with design, art, music, programming? The player will recognise it, and know what to do. This is actually a clever core mechanic that will test if the player learned what you want them to learn.
If you get stuck and depleted your resources, go to you stack of brilliant ideas and pick one. Then generate some new ideas and mix it with the others.
Again, tips for your workflow; don't overthink things, it will make you stuck. You don't have time for it and it is not required. Just make sure you teach each element and make sure it's meaningful. (I'm open for alternatives to the term 'meaningful', I'm not 100% happy with the word.)
Examples
Teach as you go
The Good
Coffee Beans (my preferred of many names, thanks @timbeaudet). Coffee Beans have the same color as the player's light. In addition they are spread around like breadcrumbs showing the path you can move. After picking them up the players light get's brigher. When picked up they emit a chime in the scale of the music. This is the core mechanic of the game, so I am really happy it worked out really well. They teach how light affects the player.
The Bad
Switches, Jellyfish and Evil Fish, all initially green are effected by the good color emitted by your bubbles. But it turned out it takes too many bubbles to show the effect of the bubbles. There is some ambiguity in the color green. Fish and Jellyfish deal damage when touched, while the Switches do not. Also green rocks cannot be affected by the bubbles but only deal damage, mixing in 2 different meanings to the color, that are mixed between the enemy type (In binary: Fish:11, Switches:10, Rocks:01). Amiguity is very bad! (Especially since I was aware of it but thought "Ah, who's gonna have problems with that". Rookie "PhD" mistake.).
The Ugly
I personally love the movement in my game, to me it really feels like you are swimming through the water; floaty with a very soft gravity. However the way I introduced it can cause many problems. Firstly there is a short animation at the beginning that is supposed to show the three icons that should be collected. However, during this time the player movment is disabled. Because of this being disabled players are focussing on trying to figure out how to move during this animation, often ignoreing the entire animation explaining the goal of the game. A second problem is that the fish rotates towards the direction you are steering in. However if you move to the opposite direction there is no single shortest rotation so the fish just flips, making it harder how the movement actually works. People will figure it out in the end, but it's a very ugly way of teaching.
Meaningfully Reuse
The Good (from Bad)
Initially I was trying to make my level from specially crafted blocks. Being afraid that people might notic too many repititions. Luckily I quickly changed my mind. (I still made about 20 different building blocks, but 50% of the entire game is made from one single rock). No one noticed and allowed me to make a full "immersive" world in only a couple of hours. Ofcourse I did make some simple changes to some of the same rocks, but that was just quick reshaping for the level design. The rocks that can easily be reused have more meaning (wall, rock,
The Ugly
The code for all bubble absorbers is practically the same. On touch: kill bubble, change color and a conditional reaction. Instead of nicely engineering this I just copy-pasted the code. This appreoach works fast and pretty good. Forces me to refactor (actually fully rewrite) most code if I continue. And since this game is so small, modifying all pieces of the code was easy with more quick copy-pastas. Ugly, but gets the job done quickly during a jam.
Final words
I hope you learned something from my approach and perhaps it can be benifcial for your workflow too. I will be doing a few more of these articles, and I will be highlighting some game clever Ludum Dare designs as GIFs on twitter. I only have small hand full of followers, so if you liked it (which is safe to assume; you are reading an obvious shameless plug), want more insights and want to make my day, follow me there:
https://twitter.com/abductypus