[A js13k Game] Pariah

The day after js13k 2014

Quote

This was originally posted in our Tumblr, and was written by our coder. Reblogs, comments, questions or critics are more than welcome!

The js13k compo is over and we enjoyed it a lot. We have experienced lot of feelings and we have a bunch of things in our heads. It has been a really fun month in one of the most awesome compos we have done so far. The main reason? The size constraint. Here is our post mortem.
If you haven’t heard about this compo before let me give you a brief summary: you have to develop a web game where the file size can not be bigger than 13kb (13213 bytes to be exact).
There is no space for frameworks, helpers or for that library that you love so much and make your life easier. Even the assets could be a luxury. We tested a lot of frameworks and even the simplest was around 21kb so our approach was to go with pure javascript and create everything from scratch.
Our entry is a retro rogue-like game called Pariah. It is a mix of HTML canvas, CSS and DOM handling.

What went right

Concept and art: We were able to come with this nice idea within the first days of the compo and Alex worked with the tileset really quick. This was a total win because we could focus on the idea real fast without rethinking or redesigning the whole thing over and over.
Collisions: For this top-down game (with no physics) the least penetration algorithm was more than enough to handle collisions. A clean, simple and painless solution to our problem.
Camera: For the camera and the scrolling I used an old idea that I implemented in a game engine I developed years ago in Python called Ngine. No problem with this either. Simple, small and effective.
Input: As in the camera, for this system I used the same implementation of my old game engine in Python. I just had to do a couple of adjustments to make it compatible with this DOM/Canvas hybrid and we were done.
Fog system: For the fog system I used an algorithm known as Field of View using recursive shadowcasting. It’s not so complex and the result is beautiful. It took me 2 days since I started to read until I got the final version of the system.
File size: For me, the file size was the achievement. We could pack the full game with the assets and all the boilerplate code in 12793 bytes. Here are some dirty tricks I used to reduce the file size as much as posible:
- Short names for variables and methods: As @ooflorent said in his post mortem from 2013, this is the ugliest part. I had to cut down attribute and method names to one or two characters. It really hurts the readability but let you reduce a lot of space.
- Replace “this" keyword: I was using and Object-Oriented approach and I realized that "this" was present everywhere. What I did was to create a local variable called "_" and used it instead "this", that way I could cut down 3 chars per word. A nice improvement.
- Check words density: Putting the code in tools like http://wordcounter.net let me check which words repeated the most and optimize them.
- Use 1 and 0 instead of true and false: I achieved the same result comparing against 1 or 0 than comparing against true or false, so I used numbers and I saved 3 chars per comparison. Believe or not, it matters.
- Optimize colors: Canvas and CSS use RGB and HSL colors represented as strings, so uglifiers and minifiers won’t cut them down. A good practice is only use alpha when you really need it, remove all the spaces between commas and try to define global variables to store the colors, that way you won’t repeat them all along the code.
- Nested declarations: When possible, I used one “var" keyword to declare several variables. This let me save 3 more characters per declaration.
- Be careful with the boilerplate code: Even when the HTML and CSS can be minified they can’t be compressed or uglified, so they increment the package size real quick. To improve the size here I cutted down the credits scene (HTML) and some styles that weren’t too necessary.
- DO NOT do the optimization at the end: or YOU.WILL.SUFFER. DO NOT do it at the beginning either or YOU.WILL.SUFFER.MORE. I optimized one week before the deadline and I consider that it was a great moment because the code structure was ready and I just needed to add more classes or fix issues. If you start to optimize the code too early you will probably have hard times adding new features and if you optimize at the end you could run out of time or get a mess just hours before the submission time.
- Automate your minification and zipping process: One thing I really liked was to automate my building process a week before the end, mainly because on the latest hour my mind was focused on fixing issues and checking that everything worked properly. Having one less concern and building the whole package with a single command was simple beautiful. For the automation I used gulp, gulp-uglify to uglify and minify the code and gulp-zip to generate the final package. You can check the sources on github if you are curious.

What went not so well

AI: Our friend Fernando Larrañana helped us this time with the AI and the result was great, however we had to fight a lot the last 3 hours with a couple of bugs that were making our lives miserable.
Procedural level generation: For the level generation I used an algorithm based on BSP (Binary Space Partitioning). It took me like 1 day and a half to make it work and even when the final product was fine I had to apply a dirty hack to avoid unconnected rooms. I wish I would had more time to understand better the algorithm and make a better solution

What we missed

The most painful part was to renounce to the idea of adding sounds. I did everything I could but I wasn’t able to find more ways to reduce the code in order to include the sounds library (around 2.5kb). So we had to drop it.
We missed the particles system, two more levels, a nice fonts like the ones @jackrugile used in Radius Raid, a fancy battle system with power combinations, vulnerabilities and a couple of enemies that were in the initial design.

Conclusions and recommendations

The compo is an awesome experience and if you consider yourself a game developer you should participate. It’s fun and you will learn A LOT.
Keep in mind that you probably won’t be able to put all the fancy things that you imagined for your game at the beginning, so try to prioritize things. We had to sacrifice sounds in favor of AI and procedural level generation. If sound is vital for your game, reserve the space it needs at the very beginning.
Don’t try to develop the next Battlefield or the next Call of Duty, focus your effort on simple but fun ideas. The basic stuff sometimes require more time of what you think.

For me it was incredible useful to create a ToDo list with daily goals. That way I was able to plan what things were more important, when should they be ready and how much time I will invest in each one.

Be ready to chop things down. Rethink, redesign or rewrite. Sometimes is the only way.
Optimization is a delicated part here, give it the time it needs.

That’s pretty much everything so far.

Now go and check out our game, share with your friends and let us know what do you think:
http://js13kgames.com/entries/pariah

Feedback is more than welcome! The source code is available on Github:
https://github.com/satanas/pariah
By: Wil

[/list]