Monday, March 31, 2014

Apex Diver #1 - Now running on Android


So as I discussed previously, while I'm not exactly enamored with the end product (although it did make it to the top 50 of the Cyber Jam somehow), I'm going to continue a little further with Apex Diver and use it as my first release. Actually getting a project to release is something that I've yet to do, and there's bound to be issues and things that go wrong along the way, so I'm happy to use this as a test not only for getting to mobile, but also for adding in the other important stuff like scaling, stat tracking and advertisements.

Presently: I'm pretty sure I've got the scaling working... The game runs on both my tablet and my phone at the moment, both using different resolutions. I've fixed a new and random bug where the shaders were causing a crash and did a lot of optimisation in an attempt to increase the frame rate. Unfortunately, it wasn't enough to make it run smoothly on mobile devices. I found another way to scale away shaders/effects if the device can't handle whats happening on screen. The best part about this is that I don't need to test all kinds of devices and set stuff manually, but the flip side is that I'm a little unsure of what the baseline device that can handle the game is (although apparently, it's around a 2012 Nexus 7 level).

Still to come: I've gotta look at adding stat tracking, which seems like it should be a pretty easy thing to add, but it doesn't look like I'll be able to use mixpanel which makes me a little sad. Google's tracking seems like a possibility though, so I'm interested to see what that entails. If nothing else, I can use Flurry. As for Advertisements, at the moment I'm happy to use whatever is in there, but maybe Tapjoy would be a better fit (if that's even possible). Oh... and I've got to remember to set the onscreen instructions specifically if it's running on a touchscreen/keyboard (and maybe control pad?).

I'm not too worried about extending the gameplay at the moment, but I do need to store settings and stuff permanently (like what shaders should be left on/brightness levels). I may as well look at adding in highscores or minigoals. If I change the gameplay at all the first thing will be something to discourage sliding all day.

I think I'll either make an .apk available within the week, or put up a private build on Google play or something when I've got most of that stuff done. Then, I'm just going to sit on it and decide what else to do with it after playing it a bit. I've also decided I'm going to work on a couple of other things at the same time (as discussed previously, Mighty Hammer, as well as another project with Drew called Repeat After Me).

I think I'm also going to try and make a point of posting Mondays, Wednesdays and Fridays from now on. If you know me in real life and I miss this, feel free to harass/hurl abuse at me.

Wednesday, March 19, 2014

Cyberpunk Jam #4 - Post-Mortem


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.

Tuesday, March 11, 2014

Cyberpunk Jam #3 - Game Complete!

Admittedly not a huge amount of difference between the previous screenshot and this one, but I assure you, a lot of work happened between them. So I'm not 100% happy with how this Jam went but if nothing else, I learnt a whole bunch more. More of that in the post-mortem in the next couple of days, but in the meantime, why not give the finished thing a go here:

http://bigstompyrobots.itch.io/apex-diver

If you are going to play, I recommend playing in a Chrome browser so you can get the fancy graphics and sound.

Friday, March 7, 2014

Cyberpunk Jam #2 - Leaps and bounds


Not as much posting as I should've been doing, but its mainly because I've been too busy trying to catch up. I haven't, but scopes have been dropped and I'm getting pretty close to a finished thing, as seen in the screenshot above, or if you use chrome, in this latest build: http://www.bigstompyrobots.com/apexdiver/seventh/


Sunday, March 2, 2014

Cyberpunk Jam #1 - Running behind schedule

Another week another gamejam... This time though I'm collaborating with Drew Fellows on the Cyberpunk Jam. While the previous games have been pretty vague in their themes, this one is supposed to be inspired by a specific image.

I was late starting due to some family business and unfortunately I haven't really caught up yet (and probably wont tomorrow either). However, I've finally finished the run loop for the main character, which is pretty important for a run and jump kind of game. Next up: Jumping, sliding, falling, etc.