Intergalactopol retrospective

Posted by (twitter: @@arplynn)
August 28th, 2014 6:43 am

Intergalactopol retrospective

Well, my team and I shipped a game that I was pretty pleased with this Ludum Dare. Check it out!

Intergalactopol: now in screenshot form

The time has come to dissect the game (and the process) and look at how it worked—I hope you find this interesting.

The Good

I was very pleased with how the sound turned out in Intergalactopol. Having got tired of the identical-sounding sfxr noises, I did the sound effects in Logic Pro, and made sure to keep all the sound effects centred around the key of E, so that they would fit with Mr. Simon Porter‘s music.

The sound of the tractor beam is actually a choir sound taken very low, and most of the “hits” are drumkit or drum machine noises. The music brought it all together.

This time we were working as a much smaller team. Usually we have a team of at least four; it was just Olly and me for this Ludum Dare(plus Simon for the music on the last day). It’s a quite different experience. Much quieter, certainly, though much more immediate. The absence of our game designer and overlord Aaron was felt quite strongly—more on that anon.

Once again we turned to the superb libGDX to power the whole thing. libGDX has recently switched to using Gradle for builds, which means (among other things) builds are much easier to automate. This time around I had Travis CI set up to automatically push builds to my server, which saved a lot of time—in our previous efforts it’s always been a pain having to take a moment out when the non-programmers on the team need a build.

We kept the scope very focused this time around and as a result were effectively finished on Monday morning. We’ve never had this much polish time before, and I think the game feels pretty good as a result of the extra time we were able to spend on the little things.

The Bad

There is a classic problem in game development—as a developer, you know your game too well. If you have the difficulty about right for you, it is way too hard for anybody else. Since my hubris knows no bounds, I thought that even despite that golden rule the game was about right. I was wrong.

The control scheme of the game involves just the mouse: you right-click and hold to grab a planet, and left-click to shoot at a target. This sucks. In fact one bit of feedback that I got was from someone who found the easiest way was to not swing around the planets at all: just to shoot and pray they didn’t crash into anything.

Quite a few people suggested a forward cannon rather than mouse-aiming, but this doesn’t play well. If we’d had more time and more testing (and, let’s be honest, more Aaron), we’d have figured out a control scheme that doesn’t drive you insane—maybe spacebar to latch to the nearest planet and the mouse just for aiming and shooting?

The other problem which I didn’t get time to solve was size. The jar is ~24MB, which is ridiculous given the size of the assets inside. It includes a lot of superfluous libGDX code which I didn’t find a simple way of removing. ProGuard seems to be the standard jar optimising solution, but I couldn’t get it working at all.

In Conclusion

Difficulty with controls aside, I think Olly and I managed to ship a pretty neat game for this Ludum Dare. Let me know what you think about the game and what you think we should have done differently—and I hope this has been an interesting read!


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]