On Friday I spoke at Droidcon UK 2012, and it was my very first conference talk, titled The Butler Did It: Continuously building & enforcing app quality using Jenkins.

I did the talk together with Christopher Orr, and the topic was using Jenkins CI and Gerrit to improve app quality when building Android software. It also included a short rant about the Android NDK. I thought it went surprisingly well, especially considering I was fueled by only 5 hours of sleep!

The turn-out was great - every seat was occupied, and we got a lot of interest in the form of questions afterwards. Here you can find the source material for our talk - our slides are pretty light on text, so we also have a version with a more fleshed out version of our speaker notes.

I’ve been told by the Droidcon organizers that they’ll publish the video from the talk. I’ll post an update once that’s available.

In addition, the demo doesn’t have any audio or captioning so far, but hopefully we’ll update soon with a narrated or captioned video.

If you’d like to contact me or Chris, the contact information is on the last slide.

EDIT April 2014: I finally found the video of the talk, it requires a (free) sign-up, and is available on SkillsMatter.com

Here’s the first “dev diary” video for Arcane Deathmatch.

So far the game has:

  • Working networking
  • Simple network lobby
  • Basic UI - leaderboard, spell shop
  • Three initial spells (magic missile, infernal nova, teleport)
  • A very boring level
  • A reward system for kills
  • A round system with a “last man standing” victory condition

Yesterday I asked two coworkers to play Arcane Deathmatch with me, to get an initial feel for what direction I’m going in. It was a great experience, and a great motivator: I finished up a large amount of basic implementations of features in the last week, so that it’d be ready for the playtest.

I highly recommend doing this early for people working on hobby projects - it helps you focus on shipping and creating a real product, and motivate you. During the time leading up to the play-testing, I started thinking of every issue I’ve filed in the bugtracker in terms of “how important is this to testing gameplay”.

Some very useful things I learned include:

  • Controls need to be thought about very carefully, and tested on real people. What seems fine when you’re just testing around the environment is experienced completely differently when you’re in an action-packed fight.
  • While art is not important to the “fun” in this concept, UX is very important - even early on. People need to find the information and actions they care about!
  • Pacing is very important, and hard to get right - there are a lot of factors that influence it, many of which I haven’t gotten around to implementing yet.

There were a lot of other subtle bugs and improvements I found through this little hour of gameplay. As an example, camera movement is currently not animated, which makes Teleport very jarring.

For now, I’m back to implementing some new content (especially a more interesting level and more spells) - and then I can get a better feel for how pacing and balancing needs to be done.

While work is keeping me busy, over the past few weeks I’ve had a couple of good evenings to work on Arcane Deathmatch.

Last weekend I poked around with a second spell, “Infernal Nova”:

This Saturday I added a leader board, a gold reward when you kill someone, and fixed some bugs. Tonight I added a UI for shopping spells, made the leader board prettier, and added a Teleport spell. Woo! Check it out below:

Hopefully I’ll keep making steady progress and I can start very very early tests against real people this week or next.

The last few months it’s been busy with three weddings (including my own) and a vacation. Every once in a while I’ve been tinkering with a game prototype with a smaller scope than Dungeon Fodder - and now I’ve finally reached a point where I can say that I’ll be pursuing this concept instead of Dungeon Fodder. I first had to make sure Unity’s (fairly lacking) networking APIs would be suitable for developing this.

The game is tentatively named “Arcane Deathmatch”, and it’s a third person / top down, fast paced, RPG-inspired multiplayer action game. The gameplay is similar to the Warcraft 3 custom map “Warlocks” (I think?): You control a wizard/warlock on a relatively small battlefield. You’re pitted against a few adversaries, all of you armed with whatever spells you’ve purchased. As you survive and kill off your opponents you’re awarded gold with which to purchase new spells between rounds.

Every time you’re hit by a spell, you lose some health and get knocked back. The less health you have, the easier you are to knock around. If you get knocked off the map, you’ll probably sustain damage wading through a lava pit, be nibbled on by piranhas as you swim to shore, or fall off the map.

So far, I’ve got rudimentary networking and gameplay working - two or more players can connect to eachother and fight it out (armed with Magic Missile!), and getting knocked off the map means falling to your death. It doesn’t look like much - but that’s never stopped me before! ;-)

Vital things that are missing are more spells, rewards, a way to buy said spells, more interesting maps / terrain / obstacles, and a scoreboard. (Probably in that order)

I hope you’ll follow my blog as I post status updates and my experiences developing this game :-)

I’ve attracted some people who are following the progress of this project, so I figured I should give a quick update on my (lack of) progress.

I’m in the middle of organizing a wedding reception, so there won’t be any time for working on my projects until after the 26th of June. I look forward to getting back to it!

So far, updates have been on a weekly schedule. I intend to continue with that pace - or maybe biweekly, depending on how much time I have. Right before this lack of updates began, I started prototyping a game based on some of the same concepts, but with a smaller scope. I might pursue that so that I have a playable, “done” game at an earlier point. If so, it’ll be featured in an upcoming post. :)

Thank you all for your feedback and interest! This is exactly why I publish this publicly!

(This is similar to Requiring a minimum version of the Android NDK, but for SDK versions)

Again, I was tinkering with our build system at work, which is a set of small Makefiles that are responsible for invoking ndk-build (to build our C component) and ant (for the Java component). These files also maintain the dependency graph for the cross-domain dependencies, so things like header files being generated from class-files using javah and APKs depending on the produced shared libraries.

I recently made some changes to the ant build step by creating our own custom_rules.xml, exposing the “hidden” -compile target. What I noticed was that build.xml only did an <import file="custom_rules.xml" optional="true" /> if you were on a fairly recent Android SDK version. This isn’t a problem for our Jenkins builds, since we’ve got an in-house system that ensures a strict version dependency between a specific source checkout and SDK/NDK versions, so they were always using the newer SDK. It was a problem for our developers - we’ve yet to roll this system to our development machines, so developers are responsible for checking out and updating their own SDKs.

To prevent this from getting in the way, I wrote a little snippet of bash that’s run from the Makefile, that ensures that the SDK version is at least the given version.

You can find the shellscript as a gist on GitHub

Put the script into assert_sdk_version.sh, and put the following at the top of your Makefile, and voilà! Builds should now fail with a more understandable message if someone’s using the wrong NDK version. :-)

ifneq ($(shell $(LOCAL_PATH)/assert_sdk_version.sh "r19"),true)
  $(error SDK version r19 or greater required)

If you’re curious how this works: It checks the tools/source.properties file in your Android SDK, looking for a line like Pkg.Revision=XX, and extracts the version (XX) from that.

It’s pretty straight forward, but I couldn’t find anything online on how to check the SDK version from the command line, so I figured I’d share it.

A little busy the past two weeks (Diablo 3 and a lot to do at work), but here’s what I had time to do:

  • Reworked minimap
  • Inventory management
  • New spell, “Barrier”
  • Non-active player switched to Behave-based AI - he now shoots at enemies!

Didn’t get too much done this week, but I cleaned up the minimap:

Minimap before:
"Minimap before"

Minimap after:
"Minimap after"

I also added a dungeon level indicator:
"Dungeon level indicator"

And finally I switched the non-player character to use the same AI engine as the zombies (AngryAnt’s Behave), though with a different behavior tree. So far this just means that the non-player character actually attacks enemies. Woo!

Hopefully I’ll have time to make the inventory management more complete and do a dev diary this weekend. We’ll see.