Play it! | View on GitHub
Now that I am slightly recovered after the Week of Awesome, I want to share my thoughts about what went well and what I have learned after this experience. A quite important part of my project was to experiment with functional reactive programming in games, and I promised to share some reflections about it afterwards. I'm going to talk about that in the second part of the post-mortem, which I expect to publish early next week.
What was great
Community support and feedback
The absolutely best thing about participating in this contest was all the encouragement and feedback I got from the community. Big thanks to everybody who took the time to play my game, read my blog entries, post feedback and encouraging comments, and even find and report bugs!
My game would have been a lot worse without that feedback. Many people suggested features I hadn't thought of or I had dismissed earlier because I didn't think they were that important. The ability to move to the left and better control of the landing position when jumping are clear examples of this. It was also really motivating to see every day people playing the game and posting new feedback.
Browser game
I think that going down the browser route was a good idea after all. The cool thing about the browser is that everybody has one. Distributing your game is so easy: no installation or configuration required, and everybody can play it regardless of operative system or installed runtimes. I could upload the game to my VPS since day one, update it often, and have people trying it out, which was great and I think that it made a difference in the amount of feedback I received.
What I would do differently
Have a level editor
The game I delivered is inexcusably short. Once I had the basic mechanics going, it would have been really easy to add more and longer levels. The only reason holding me back was that I didn't have any visual tool to create and edit them. I created the only level in the game by manually editing a JSON file. As you can imagine, that was a tedious job and I decided to invest the little time I had in solving other stuff. Not having a level editor also prevented me from iterating the level and making sure it was fun and challenging enough.
Next time, I will make sure to have a visual tool to create levels and maps at hand before the contest starts.
Test the delivery format early
When I set off to make a browser game, I set up a local development web server to serve the file and recompile and reload the changes quickly. I knew that I would end up delivering an index.html file with a .js bundle and that the judges would load that file from the file system instead of a web server. That should make no difference, right? Wrong! Turns out that Chrome, among other browsers, doesn't allow AJAX requests when loading a file directly from the file system. And guess how the rendering library I used loads spritesheets? Exactly: AJAX calls.
I should have tested running the game from the file system since day one. Instead, I only tried it when I was about to upload the final submission. If I had known about the AJAX issue earlier, I could have written my own resource loader, or bundled the game with electron. Instead, by the time I noticed the issue, I didn't have the time nor the energy to do something about it.
Even though the game can still be run locally with Firefox, I provided a python script to run it on a local web server, and some judges didn't mind playing it on my VPS, my developer soul still hurts because I wasn't able to deliver software that runs with a single click.
Conclusion
This community is awesome. I got far more interest and feedback than I expected. I liked the experience of making a browser game, even though at the end it wasn't as smooth as I thought, and I definitely need to get a level/map editor next time.
If you are interested in reading my musings about using functional reactive style in games, stay tuned for the second part of the post-mortem.
↧