One of the big advantages of JS13K game jam is there is plenty of time to finish the project, a month should be enough to elaborate an idea. If there is an idea. Surely I’m not alone in enjoying directionless coding, discovering tools meanwhile implementing random features. Turns out a competition might be not the right place to play like that to me. Let’s check out why.
Preconceived Idea
Way before the theme was published I was sure to do something with the Web Audio API, positioning sound sources in the 3D space promis great gameplay advantages. Recorded samples obviously out of the picture, a simple drum sample nearly ten times more than the compo size limit.
The plan is to create sounds using oscillators and filters. I started to make an audio graph editor and a simple sequencer to be able to save loops on a format I can play back. This could be an interesting project too, but when it started to do the job roughly I abandoned it, I want to make a game not a synthesizer. This is what I should realise earlier, I didn’t touch A-Frame or Three.js for two years and that time nearly scratched the surface. Knowing the tools properly instead of browsing manuals could save a lot of time.
Progress
For a quick start seemed a good idea to copycat some code. Even though I made a terrain generator with Unity3D before, I didn’t want to waste time with it, so I grabbed some snippets from a VR environment plugin. It was a very bad decision, didn’t look really good and its optimisation was ongoing during the whole project. Talking about optimisation I made another mistake, I was so afraid to run out of space that I started to hack core A-Frame components to personalise functionalities, for example a Sound accept audio buffer not binary files only. It was unnecessary since source code – especially zipped – cost no space. Thinking of it I shouldn’t reject the usage of shaders from the beginning. On the other hand it made me browse A-Frame source code – by the end I got pretty familiar with it – and led to check Three.js sources as well, and this is why it was worth the lame attitude, I can continue on from the next level.
With the Analyser audio node I could shoot sound waves with the controller. It doesn’t perform very well with plenty of sources, but creating my own with Audio Worklet would run on a separate thread and could be a solution. So do for my very basic bouncy physics by implementing purely Newton’s 2nd law. Have to say I pretty much enjoyed developing to VR, my Oculus Rift was always on my forehead to quickly test something new or interesting.
Created many components for A-Frame, including player control, position recognising object, obstacle hit detection during movement etcetera. Tried to figure out the optimal code structure, collected code snippets separately, renamed and moved features. This is what I also shouldn’t do, remove working features for a later good in this scale is pointless, just lost version history and functions.
Fallout
When I realised only hours left for the deadline, surely I wanted to make a controller tutorial instead of finding a nice version and tweak that. With a tiny modification of the character controller it could be possible to not only move the player but other entities too. Instead of leaving time to put all the things together. For the last moments it was clear that unlikely something great would happen from the mess I made, even the final build doesn’t really work. It’s not bothering me, I was enjoying all the moments of the process and also it was great to see how the community progressed. I think of it as a start. Migrated the codebase to a new repository already for continuing the flow without limits.
More Pictures on Twitter:
https://twitter.com/i/events/1306663802654674944
Js13k page:
https://js13kgames.com/entries/flow-of-four
Walkable build:
https://subztep.github.io/js13k-2020/old.html
Source – commits can be quite different:
https://github.com/SubZtep/js13k-2020