Js13kGames entry finally submitted. Now I can think about something else, right? RIGHT?Posted on September 4, 2012 | 5 minute read
Well, it’s done. My final confirmation was positive feedback from /r/gamedev as they were the ones who criticised the heck out of the game before (nicely and constructively; thanks Reddit!) and this time everyone there said it was actually…you know…fun and stuff. I don’t expect to actually win anything because there are already great games submitted and I can already imagine (and have seen some screenshots of) the totally mind-blowing stuff that is being made by people who aren’t slapping code together like a pile of Lego blocks until something fits, but it feels awesome to finish something, and finish it within the set limitations, and be able to submit it and have it posted because it meets the requirements and, you know, runs. Mostly (see “Ubuntu” below).
The js13kGames framed game page kind of messes with some of the functionality and appearance. Eg the “Share on Twitter” link I have on my Game Over screen does not work in the frame and the bar at the top pushes the entire game screen down by that height. In some browsers this makes the bottom part of the screen unusable and in others it makes controls scroll, which is annoying. I’ve asked on Facebook if this can be fixed somehow (maybe even hide that bar by default?), but until that happens if it’s even possible if you want to play a properly sized non-scrolling version of the game with a functional Twitter link, please do it here.
Last minute changes
Last night was hectic. Someone on /r/gamedev suggested that I use
requestAnimationFrame instead of
setInterval for performance. Now, performance and browser compatibility have been my major points of
interest obsession. I had considered using requestAnimationFrame before, but for some reason never went through with it as it seemed like it would require recoding the way my entire main game loop worked. Now, for some reason, I decided that I needed to do this.
So I did. And it didn’t require that much recoding. I just hope that it was worth it - there wasn’t that much time left for testing and_ _I hope that it didn’t do more harm than good in terms of performance.
Last minute browser/OS compatibility problems
Safari - patched
During the above changeover I found out that due to the audio generation code I use in the game it totally locked up in Safari. I did not notice this before because I was not setting
sound.currentTime = 0, before attempting to play the sound effect before and that’s where it was getting hung up. I’m glad I stumbled into this. My “fix” for this was basically excluding any sort of sound activity for any browser except Chrome and Firefox. I really hate this. Really. I think it’s a stupid solution and the sounds are important even though they’re just sounds. I hate knowing that anyone playing my game in any browser other than Chrome or FF will not get to hear them and think this is possibly my biggest failure with this project.
Opera - fixed
Opera also had an issue with an alpha-dependent keybind (alpha incrementation in Opera was for some reason not going up to the defined 1 and stopping at something like 0.9222, and the SPACE key was only active if alpha was at 1 because I didn’t want people to accidentally double-tap between game states and skip straight past a menu too quickly). I just set the minimum alpha at which Space would be recognized to 0.9 and it was all good from there.
not fixed scratch that Someone just mentioned on Facebook that the game doesn’t run at all in Chrome Ubuntu. By the error looks like it’s an issue with jsfxr. Unfortunately I am unable to reliably test and patch this without installing…well…Ubuntu. This compatibility thing drives me up the wall. The patch is going to eventually come directly at http://liza.io/KROOG and it will be disabling sound in anything that doesn’t support whatever jsfxr feature that code is trying to trigger as opposed to disabling it for individual browsers and now trying to get into OS detection, which isn’t actually reliable anyway. For now, sorry Ubuntu people :(
Update: Turns out this was an issue with the version of Chrome the player was trying to use :) If you upgrade to the latest Chrome version on Ubuntu the game works as it should :)
The thing I hate about JS
This project made it obvious. I hate having to worry about how things would render/behave/perform in different browsers. Making a simple game becomes more about testing it in 10 different browser versions on at least two/three/whatever different operating systems and patching the hell out of it instead of actually making the simple game. This also makes me appreciate engines like ImpactJS even more. Though I’ve run into some browser compatibility and performance issues there as well, it wasn’t anywhere near what I’ve seen here so far.
Even though it’s submitted, I know that I’ll need to make this work better in different browsers (that is, with audio) as well as make it work in general in Ubuntu. Clay.io contacted me about uploading the game there and pushing it out to Chrome & Mozilla app stores/Facebook/whatever, which sounds like it would be a cool new thing to learn to do. Their API also allows me to add leaderboards and such, though that would come after. I’m considering porting this entire thing to ImpactJS after the challenge and using proper mp3 and Ogg vorbis sound effects instead of jsfxr as it’s been causing so much cross-browser trouble.
In short - it just never fricking ends. I just want to play some Guild Wars 2, darn it.
Categories:game dev dev games
comments powered by Disqus