TIGSource Forums

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.
  (http://media.tumblr.com/8a83cd1fc9569cf517bc731640322580/tumblr_inline_nbyqptbqCn1qct0aw.png)
• 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 (http://js13kgames.com/entries/pariah)
 
Feedback is more than welcome! The source code is available on Github:
https://github.com/satanas/pariah (https://github.com/satanas/pariah)
By: Wil
(http://media.tumblr.com/1cf1865ddb8346190c8a8f039ce9e16f/tumblr_inline_nbyqv86V1b1qct0aw.gif)[/list]

Hi guys,

The result in the competition is out there, we didn't make it to the top, but, to be our 2nd game ever, it wasn't so bad either, I think (I think?)


I believe that being unable to include sounds, let alone a BGM really hurt us in the overall competition. And videogames being a 3 ways medium (mechanics, graphics and sounds) in the judges eyes we made an incomplete game. 13kb really put us under pressure to make the game we wanted to make, including the game jam topic and doing it without a sea of bugs.

Actually the host of the Jam tell us that he particularly liked the game, but not all of the judges did as well.


What I now would like to ask (and this being TIGSource I think is a rather good place to be asking this) is input in this game of ours. Feedback. What is fun, what is not. What are the mistakes. What is good.

Yes, a 13k game hardly show of what we can or want to to do, but it's a game never the less, a game that we did. And if we could have a feedback on it, we might learn sometime (more than we already did) from it.

Any, and all, comments will be highly appreciated.

Bests,
Alex.

I really like this concept.

Graphically I wish that the outer edges had a less that 100% alpha at the beginning even before you find another torch. Also I didn't understand at the beginning that I didn't have an attack and I had to avoid the bad guys until I found something else.

But I enjoyed it!
Congrats on the contest! Anything is awesome!!!

Super glad you enjoy it a little man :D

And thank you very much for playing it, and writing us about your experience. We are taking all the feedback we get from this game, to learn for our future ones. :)

Here is a gameplay video of your game.

https://youtu.be/KbwQvPpaC18

I really liked the game, if you are looking to further improve the game here are my suggestions:
1. Add music
2. Add sound effects
3. Add a small explosion effect when enemies die

What I liked:
1. The walls, doors and player graphics.
2. The 4 different abilites/elements
3. The gameplay: having to find the key to doors rather than simply just going through doors
4. How only a small area around you is visible as opposed to the whole room being visible