And so concludes my third game jam of this year... Out of the three so far I think I'm most disappointed in this one. Mostly this is because the original scope was a little too large for the time frame of the jam, but also because I lost a lot of time due to unavoidable family commitments. What was supposed to be an extension away from an "endless runner" type of game ended up being cut back to a bare basics. It stings all the more because I was really interested in the theme for this game jam, much more so than the Candy and Flappy Jams before it.
That's not to say I'm disappointed in all elements of Apex Diver or the process of making it. If anything, this game's pushed me harder than any previous game I've worked on. I've learn't much more about using GameMaker, its strengths and limitations, and even where I can develop (in a car, in a bed, everywhere!). But now on to specifics:
The Good
Prior to starting this jam I wanted to make this game look much better than the previous two, which luckily is not too hard considering how Ascii Bird looked. I was aiming to make this look like a commercial mobile game as much as possible, and I think the animations and shader effects work pretty well in that regard. For the animations I was kind of flying blind a lot of the time, aiming for a bigger loop and more frames per second than any previous animation I'd done. Despite that, I'm pretty happy with the run loop, and considering the short amount of time I had to work with, the other animations weren't too bad either. There's quite a lot of movement going on between the player and the enemies, and everything has at least 8 frames to it.
Similarly, while I'd done some research into shaders before the jam, I still wasn't at the stage where I could actually get them working as intended for the finished product. In Apex Diver, I used two separate shaders (one for the lighting effects, and the other for the scanlines/postprocessing effects) and by the end not only could I get them to work, I could adjust them to do additional things as needed. I'm still probably not at the stage where I can code my own shaders, but it's still a pretty good start.
Apex Diver is also the first game I've made where I've had sound (despite how it turned out, but more on that later) so that's a good achievement. GameMaker's new sound system makes it super easy to do 3D/Stereo sound, which I added a lot, but annoyingly there are some limitations in HTML5 that ended up derailing the project for a little while.
Overall, I was pleased with the amount of polish (in most areas of the game at least) I managed to do in such a tight timeframe. Plus the game runs and there's not any major bugs (that I know of at least).
The Bad
The biggest issue with this jam was time management. Annoyingly, it's also the one thing I couldn't really do anything about. I think I ended up losing something like 2.5 - 3 days of time I thought I was going to have, out of the 8-9 allotted for the jam, due to some inescapable commitments. In terms of development time, that would've been another (planned) mechanic, or some additional/background art, or additional bells and whistles.
Obviously this biggest problem stems from the gameplay: I was making a runner but I wanted to throw in a new mechanic to make stand out and match the theme more. After all, jams are suppose to be more about trying new ideas rather than just playing it safe. At the same time though, One of the bigger lessons I learnt from the Candy Jam was that jam games need to be super quick and simple to play. I was hoping that by starting at something known and simple, I could then transition into another aspect to keep it interesting.
That aspect was going to be falling (and dodging obstacles). While not exactly original either, I hadn't seen a game that that combined the two styles before, and it lead naturally from the running gameplay and the theme image. However, it would've been another day for animations and background art, and maybe another day for coding. Needless to say, it was the first thing that got cut when time started to run out.
I had intentions to bring it back if I could. At one stage it looked like I might be able to get about a day's worth of time back, but in the end I had to struggle with a huge amount of bugs stemming from browser compatibility. As it turns out, not all browsers support shaders (via WebGL), nor do all of them support GameMaker's new sound system. Further to that, for some (still) unexplained reason, global variables don't work in HTML5 as they do on in a regular executable.
Tracking down why these things were happening, and then coding and testing workarounds, ended up taking up that recovered day plus some of the time that would've gone towards UI. Even then, some of the workarounds weren't enough (Attempting to run anything to do with WebGL on Internet Explorer crashes, you can't use the new and old sound system together to cover multiple browsers). I was hoping HTML5 would be an easy way to reach a wider audience, but I swear it ended up making it less simple than just uploading a windows, mac and linux build.
In addition, this was the first game I did as a collaboration. I suspect I didn't really communicate enough of the details to my team mate. It was harder to work long distance than I was anticipating, and particularly because we were both busy during the early part of the jam. At least communication is something I can easily improve if I do another jam collaboration.
I kind of feel like I'm just going on and on at this point, so the other things that need work but aren't quite as as big:
- The UI doens't have a lot going for it, and doesn't have a lot of bells and whistles either. Kind of not such a huge deal for a jam game, but when you're trying to up the graphic quality, things like this stick out.
- The sound effects really blow... It was way harder than I was expecting to get decent sound samples, and in the future I think I'd just prefer to record my own stuff or rely on beep-boops and music.
- The way the difficulty scaling was implemented works, but it could've been tweaked a little more. As it stands, its too easy just to keep sliding forever. Ideally the lying enemies should probably start shooting earlier than the other enemies in an effort to make slides seem less godlike. Similarly, there probably should've been some kind of enemy/obstacle that you couldn't jump for to prevent hugging the right wall and jumping.
- While the main character is a pretty good representation of the jam theme image, I totally missed hitting "height" as a theme because that aspect of gameplay got dropped. It's annoying because I spent time coding in variable floor height (as seen in one of the earlier build versions), but in the end it's just all played on a static floor height.
- The game runs/doesn't run correctly depending on browser. Ideally I'd want at least a functioning game with little effort from the player. At least after this game I know what does and doesn't work in each browser.
The Ugly
The rush I was in to make the most of the time I had, plus all the other external factors, makes it hard to remember exactly how much I spent on everything (I should probably write stuff down next time). But roughly:
1.5 days - Player animations
0.5 days - Enemy animations
1 day - Foreground/Background art
0.5 days - UI/Splash/Menu implementation
2 days - Main mechanics (jumping, sliding, hitting, dying) + Screen scrolling + Enemy placement
0.5 days - Sound effect sourcing and implementation
1 day - Testing and fixing (mainly browser specific issues)
Development wise, I had a pretty good idea in my head where it was going to go and then just gradually dropped scope as I ran out of time. I really should've spent an hour at the start to do up a quick doc or flow chart for my collaboration partner though.
A Fistful of Dollars
I think from now on out I'm going to start recording "Things I've learnt from this jam" for the sake of remembering them for next time. So for this jam:
- In HTML5, Chrome and Firefox can handle WebGL (and therefore shaders). Safari can supposedly handle it but only if you call a HTML window from within an official iOS/MacOS app. Internet Explorer Crashes whenever a shader is included in the progam (even if it's not being called). Chrome and Safari can use GameMaker's new audio system, although Chrome can't use some of it's features (messing with master_audio_gain or whatever seemed to kill sound entirely). Legacy audio should work on all.
- There is no way to play video in GameMaker, but you can convert a video file into a series of stills and then strip the audio and put it in separately. This ends up taking up a lot of space though and may cause lag. I wouldn't recommend this if possible.
- For some reason, global variables in GameMaker do not work the same in HTML5 as they do normally. It seemed to me like you couldn't set a global variable in the room it was created (but even that might be wrong). The work around seemed to be to have a initialization room at the start that does nothing but sets these variables and then transitions on to the next room.
- Jam games need to be simple to pick up and grab someone in the first 30 seconds. Difficulty probably needs to scale harder than a normal game. For someone to keep playing on past that point, they need to add something drastically different (mechanic or art) every 20 seconds. Players will sit and wait through stuff if they have control of something and its clear something is going to happen. Getting someone to replay a game looks like it might be really tough, so looking specifically at that might be a good idea. (This is based on comments/watching videos/livestreams of people playing the games... I should really set up tracking next time though).
- Jam games probably also need their rules explained quickly and obviously within the game as well. There's not a great deal of time left in 30 seconds to leave to ambiguous or adaptable play strategies. Most players will try one way of playing, it'll either work or not work for them, and they'll move on. It's important that they play in a way that makes the most of the mechanics involved and still remains exciting.
- On the flip side to that, considering most of the players are designers/programmers, they will probably also be looking at how they can optimise/"break" they game mechanics. There's no shame in this, but make sure if somethings going to look "breakable" it's actually fun rather than monotonous.
As far as tracking goes: Apex Diver is currently doing slightly worse view-wise than the other two jam games. Ascii Bird is a bad comparison since it got Wired coverage and the Flappy Jam was generally more popular, but it would seem Scrolls of Candy had slightly more natural draw. I can push the view count higher by reviewing and commenting on other games, but even that returns slightly less than it did on Scrolls of Candy.
Presently I'm sitting on 13 ratings and 7 comments for Apex Diver, compared to 14 ratings and 11 comments for Scrolls of Candy. The quality of those ratings are still a mystery, but at the moment I don't see me making the top 10% in any of the categories, least of all overall.
And a Few Dollars More
Since the graphic quality is pretty good, and I need to test releasing for mobile/adding tracking/adding advertisements, I'm going to use Apex Diver for that. I'm already in the process of adding in touch controls, and then after that I need to work out view scaling, but it shouldn't take long.
I also have the option to continue on development and add new backgrounds/gameplay features, but I'm not sure if that's something I want to spend a lot of time on. I think with this, I'll probably make some small changes based on feedback from the jam and sit on it for a while, get some more feedback and then revise again. That being said, if you have any comments or criticism about the game I'd love to hear it so I can work off of that as well.
