Rock, Paper, ShotgUnity, Part Six

Saturdays are for realising you turned thirty while you slept (in both senses), preparing your Biggles outfit for the flying lesson arranged by your lovely missus, and releasing Build 03 of the now legendary Rock, Paper, ShotgUnity game. (Which we’ve spent the last few weeks making using the free Unity package.)

This week I promised the baddies would get some more bite, that I’d take away your infinite ammo and that, most importantly I’d ruddy well fix some bugs. See how I got on, below

The quick poll earlier this week suggested most of you would like to see me squish the larger bugs before I tried stuffing more half-baked ideas into the game. So, as of Build 03, the occasional walls should be more solid, the trigger bug (which if you remember sometimes stopped the countdown ticking on a dropped rock) should be a thing of the past, and sundry other rock related bugs should be ironed out. I need all this tested though so away to the forums with you! Go on, go and bash your heads methodically and repeatedly against my walls, go on break it! BREAK IT. Don’t bash the noggin too hard though because if you do find bugs I’ll need detailed, clearly reproduceable steps if there’s even a chance of me duplicating and fixing them. This raises an interesting question: How should small/solo developers do QA? It’s grand for me to have a standing army (well, a ragbag band of rebel scum anyway) of RPS readers to slog through the quagmire of my code, but it makes me wonder how other people cope. It’s all too easy to become blind to flaws in something you’re so close to and if you’ve written much you soon learn the value of that second, editorial-eye so I wonder what you should do if you’re on your own.

Perhaps doing as Wolfire do with Overgrowth – freely releasing WIP builds to your community for testing and development feedback – is the way. Or maybe even charging them for the pleasure, as was the case with TaleWorlds’ Mount&Blade, or Steenberg’s Love. Both of these methods seem to foster a sense of belonging, a cliquey clubbyiness that encourages people to chip in, help out, volunteer. That’s certainly what’s been happening with Shotgunity and seems to me to be a powerful weapon in the battle of Making Games. Collaboration is very human thing and we all want to belong, so surely making things not only for but with an engaged and communicative audience can produce better work than could be achieved by people sat alone with their code.

I like this idea a lot, and Unity seems perfectly suited to it as a movement. I’ve talked enough about how good the Unity forums are as a place for finding help and collaboration, and how natural it seems there to prototype an idea with the tools as a means of demonstration, make mini-games and say ‘what about like this?’ but I wonder how that could grow now Unity indie is free and word is spreading. Projects like Mars Explorer offer up more or less the entire project (always read the license, kids!) for use in your own games, slashing the time it would take you to create this stuff yourself and I’m sure this is only the beginning. I can see a time when there’s so much free project material out there for Unity that you’d be hard pushed not to find exactly what you need for your own projects. Why reinvent the wheel? (Go on, tell me…)

But back to Build 03. The bug hunt has meant I got less done in terms of new material this week, but I’ve still managed to get SOMETHING new in there. I’ve taken away the infinite shotgun ammo and created a basic ammo pickup instead. To go with this the baddies are now faster and more aggressive, though still easily avoidable, more an annoyance than a threat. This is just an indicator of where things are headed What I really need now is a few new enemies. Ones that you’ll actually want to run from. Hopefully then the mechanics will start to make more sense. Rather than see your shotgun and ammo as a basic right and fixture, I want their application to feel more judicious, more like a noisy key than a brush for clearing the path…

Oh, one last fix: I’ve also very obviously addressed an exploit where you could hop on top of the Rock O Matics and get onto the walls… The solution is not what you’d call subtle, but I like that. I could have recessed the Rock O Matics inside the wall but I didn’t. I like that a problem was found by a reader, and that the solution doesn’t try to hide the problem as if it were never there, but rather show that the game has grown in some way because someone found something that had to change. Kind of like that building conservation ethic – show the bits you’ve fixed. Which brings me nicely back to that audience participation thing I was banging on about above. Coo it’s almost like I have a plan for these isn’t it?

Grab Build 03 from the forums. While you’re there, why not see if you can lend a hand? Go on, it’s My Birthday and/or Christmas.


  1. DMJ says:

    I’m enjoying this series of posts. It’s got it all – heartbreak, struggle, devotion, and development philosophy.

    • Spacewalk says:

      And racecars.

    • DMJ says:

      It needs zombies.

    • Spacewalk says:

      Nah, mummies. With park benches for heads.

    • AndrewC says:

      Happy Birthday!

      I’m also really liking how you’re using this game to ping off into a wider discussion about Making Indie Games. Very nice!

    • Weylund says:

      All that’s really missing is the insane, cloistered, feverish devotion to tweaking out that last CPU / GPU cycle. That seems to be the nicest thing about Unity. “Fuggedaboutit,” they say. “You don’t neeed those. Jimmy, does they neeed those? No. Listen to my friend with da gun.”

  2. westyfield says:

    Happy birthday and/or Christmas!

  3. fearian says:

    ” I could have recessed the Rock O Matics inside the wall but I didn’t. I like that a problem was found by a reader, and that the solution doesn’t try to hide the problem as if it were never there, but rather show that the game has grown in some way because someone found something that had to change. ”

    This is not the right way to go about fixing gameplay problems. If there is a simple elegant solution, its better to work hard and take it. not leave the corpses of poor design decisions strewn around your game.

    That said, keep at it, I enjoy the updates! :)

    • Saul says:

      @fearian: generally I’d agree with you, but it’s not the RPS way! Paper over the cracks, I say! And when they crack again and fall down, build a yurt out of the rubble!

    • DMJ says:

      @Saul: I used to think a yurt was some form of dairy product. Like a subset of yoghurt. Presumably with less “ogh”.

  4. shalrath says:

    “How should small/solo developers do QA?”

    As a former QA of a small dev, and also a large one, I feel I can answer this.

    The ‘best’ way, in my experience, to deal with this is to use the team as Development Support, rather than flat-out QA. These people would essentially be ‘elite’ QA members, and have their foot in the door of something else, Ie. coding, scripting, design, etc. These are the people who will be finding/reproducing your major bugs, and most importantly, assigning importance to them as well.

    So you have your elite small group of DevSup, what then?

    Hire out. As cheaply as possible. Basically, find a group that will work for free (or nothing) and get them to write up the most awfully described bugs ever. Have them playtest constantly. Then, have them send all their results to your DevSup group to determine validity, importance, etc.

    Oh, and pay your goddamn DevSup group well, because they can and will walk in the middle of a project.

  5. Sajmn says:

    I hear we are at both our physical and psychological peak at 30 years.

    Unfortunately it only gets worse after that…

  6. DJ Phantoon says:

    “Rather than see your shotgun and ammo as a basic right and fixture, I want their application to feel more judicious, more like a noisy key than a brush for clearing the path…”

    Like this? link to

  7. Crispy says:

    “How should small/solo devs do QA?”

    Based on 2 years’ publisher/studio QA experience, and experience on smaller non-commercial mod and website projects, I’d say it depends on the size of your team and the scale of your product. If you have a team of 4-10 people, having other team-members test your work within a working build of the game (testbeds are fine) will catch a lot of the early problems before they become too deeply engrained.

    For a single-person or smaller dev team, it’s probably worth getting an extra member to act as a QA Lead-come-developer (or Development Support, as shalrath described it). They’ll need to be technically-minded, adaptive and motivated enough to take on some of the workload involved in balancing and prototyping the game. Typical tasks you might offload to this member would be creating testbed levels & test configs, creating blockout models and other placeholder art assets (including sound), editing scripts to balance gameplay according to design/feedback, and maybe even delve into the code to fix some of the simpler bugs if they have a programming background. If you can find someone who has a basic art, code or (level) design background you could be onto a winner. But first and foremost they should be managing your project’s bug database, organising (play)tests, collating feedback and being on-hand to test every new internal build of the game. A good tester will only very rarely ever provide you with a sub-100% reproduction rate, so look for someone who has a thorough approach to what they do.

    Either way, as the game becomes more playable you’re going to want to begin looking for an outsider’s perspective, since the team by this point will be too accustomed to (or even ignorant of) the game’s foibles. At this stage getting first-time players to give detailed feedback is key. First you should ask very broad questions, like asking them to describe the game to other people. This will tell you if they are receiving your game according to your vision or if perhaps they are struggling to understand or appreciate the intended gameplay. Next you could get a littlle more specific, e.g. asking for 5 things they liked and 5 things they didn’t like (perhaps in order of preference). Later on your tests may become more largescale. In a Beta Test you could ask for more specific things, like asking for feedback on each unit of a key feature you may be focusing on for that playtest. E.g. for a shooter you could ask testers to switch weapons every 10 minutes and then provide some more in-depth feedback on the ones they used and why.