littleball.

Games, tools and other random bits and pieces.

Wisp - Js13kGames

13 Sep 2014 | games | js13kgames

Thirteen kilobytes is not a great amount. It's about the same size as the above the fold limit for css. JS13kGames' challenge was to build a whole game within this limit. Challenge accepted.

Play the game

Building the game

As the game would have to be put on Github anyway, I thought it would be a good exercise running the whole project from there. The first thing I did after some quick prototyping was to go to the issues page and set up some milestones. I then generated issues and used them as my to do list.

Now that my organising had been done, I needed a way of being aware of my size limit. So I set up a quick gulp file to handle that. I organised my html with jade and css with scss. It may have been overkill, but I like to future proof my games. It also resulted in having to a) write less, and b) have any errors highlighted in the build process.

The JavaScript was written in pure JavaScript. I normally use browserify, but I didn't want to bloat the code at all. Using vanilla JavaScript also reminded me of some old trick to make sure the code is working correctly. I was adding some additional documentation, and I noticed a few things I would like to change. Some of the issues would be solved with a better module structure. In future projects I may look into using TypeScript which would help with some of my class issues. I would also have a flatter structure, I ended up having functions relying on each other. I ended up passing in objects too often. Lesson learnt for next time.

Sound

One of my big issues was creating sounds. At 13kb adding even and image could take you over the limit, so a sound file would take up too much space. I read an article on generating sounds with jsfxr. This immediately struck a chord, as I've uses Bfxr many times for my Ludum Dare games.

It enabled me to bring the game to life with just a few extra bytes, so at first I was over the moon. It comes was a large drawback, and that is it takes time for the sound to be processed. On the desktop this didn't make much difference, but it caused me issues when it came to mobile devices.

Touch devices

There are three categories in the competition: desktop, mobile, and server. I wanted to enter into both the desktop and mobile categories. To do this I enabled touch input and tracked the first two fingers.

My trick was to take the start event and save the position. When the finger moved, the direction away from the start point became the direction for the input. This would then match the cursor keys for movement.

The second finger was used to control the element state. Again, each direction would match a state.

However, due partly to the sound processing, and partly due to the performance strains I added with particle emitters; mobile devices took an age to load. Time was running out and I didn't manage to solve these issues before the deadline, and so I just entered the game for the desktop category. If you want to try it on a touch device, go for it. I have warned you of the loading times.

Documentation

Previously I've used JSDuck to document my code. However I've the code does not seem to be being maintained much, and so I've given JSDoc a go. So far I'm impressed, although I've had to slightly re-think the way I added the code hints. I will leave that for a more in depth article once I'm happy I've mastered it.

Conclusion

To sum up, I had fun making the game. I'm reasonably happy with the game. The big win for me was writing the code. I always learn something new when entering competitions.

Play the game