Rock, Paper, ShotgUnity, Part Five

In this fifth part of my diary chronicling the process and progress of the RPS game I’m making – using the newly-free Unity game-construction suite – I get philosophical as I discuss some of the issues I think Unity throws up, and look at how that might influence my aims for Build 03 and beyond…

Before I get into ShotgUnity, here’s one for a dull Wednesday: Are bugs boring?

If you’re only interested in things until you’ve got a basic handle on them, if you’re less concerned with the details of things than the ideas, should you try to make games? It’s a pretty common trait I think – letting your mind froth with potential is easy, dragging it down to practical matters is hard, but as a solo developer or small team practical matters are 99% of what you’ll be doing when you actually get down to realising that froth. So does it have to work before it can be interesting? It’s been said of me that I like things to be broken, awkward and difficult – most of the games I like tend to be – but is that just the worthwhile price for interesting ideas? Obviously it doesn’t have to be, because there are innumerable examples of fascinating games, flawlessly formed, and that’s the clear and right goal. But what about all the interesting stuff that doesn’t work? We’d be a poorer platform without that, right? So is the opposite true? Would we be richer with more bugs?

The reason I’m traipsing over this fairly well trodden ground is that Unity feels like it has the potential to really lower the drawbridge of Castle Development, letting any old chap who wants in, in. Chaps like me. Now that the indie license is free I can see Unity becoming to games something like YouTube is to broadcasting, or what the web was to print. This is very exciting. There’s this interesting idea in a William Gibson novel – or maybe one of his short stories, I forget – where a character reflects that generations of artists have been lost to the void, unknown because they lacked a medium, they weren’t great painters or writers or musicians, but they saw the world in a certain way. In the story a new technology lets anyone record their own experience of the world and broadcast it, revealing genuine novelty and talent in unlikely, untrained places. Ah, but where’s the skill though eh? The craft? I’m not sure I care. After a few weeks moving around in Unity-centered parts of the net I’ve come across scores of people demonstrating ideas with proto-games, sketches of ideas brought to life in webplayers because, really, it’s been simpler to show your mad scheme than try to explain. I LOVE this. Even on our own forums with the ShotgUnity project we’ve had people posting mini-levels to showcase the functions of a piece of code. It’s something you see all over the Unity forums and as the word spreads about Unity I can only see more popping up. Little spacial experiments that could only make sense as something you DO rather than watch.

There are obviously barriers to this – the ability to code, or model, or animate makes things different from YouTube where we all share, at least in part, a visual language – but as I’ve been pointing out in this series there are an awful lot of assets available for Unity that can just be taken, usually for free, and published. The Unity forums are littered with people offering up code that’ll do what you need it to, or can provide it given some parameters, or at the very least set you along the road to working it out for yourself. If you’re inclined to, third party art Packages for Unity from places like Frogames or Gearworx mean you can buy your way out of problems like a lack of dedicated artists, and Unity have a forum dedicated to bartering and trading for services – code for art, art for sound, anything for money…

So does all this mean we’re about to see an explosion of amateur development? I hope so, do you? (We’ll certainly see an explosion of interesting bugs – Jim)

Anyway, with that in mind and at the risk of destroying all I’ve said about the goodness of this new democracy, back to ShotgUnity and that poser about bugs.

I’m facing a pretty crucial decision when it comes to the progress of the game. At this point, do I stop trying to put in new stuff (for now) and just fix the bugs? Is it better to fix what we have before expanding it? Don’t get me wrong, I actually enjoy the bug hunt – it’s a big kick when you nail a fix – but what would be more interesting for you, reader, to see in Saturday’s Build 03? Hopefully a bit of both, but I’m very interested in a quick RPS poll: What’s more important to you, and more importantly why?


  1. Jonas says:

    I generally find it useful to get a broad skeleton of the game set up to begin with, then filling in the features and assets and fixing the bugs later. It gives me a better impression of how the final product will turn out and how much work is left to do. As a player though, a well polished vertical slice is probably more interesting (and a lot less frustrating and confusing!)

  2. Clovis says:

    You should definitely deal with bugs as early as possible. It will simply become harder and harder to figure out what is causing the problem the more you add to it.

    I guess I’d like to play around with a buggy mess though.

    • Noc says:

      “I think it’s better to fix bugs at the beginning!”

    • jalf says:

      That’s a good point. Bugs are easier to fix soon after they’ve been introduced, and before the game has gotten too big. I don’t think that means that *every* bug should be fixed immediately. But it’s a factor you should consider when prioritizing the bugs.

  3. Fashigady says:

    I think fixing major bugs is important, but it would be a shame if you spent all your time just polishing whats already there

    • Noc says:

      “I think its better to fix bugs in the middle!”

    • Torgen says:

      Yep, it’s a fine balance. I’d say (since this is all new to you and you have no experience to draw on) that it’s important getting a feature/function working good enough that you can tell if it’s going to do what you want, then LOGGING any bugs left so you know that it’s being caused by that function, and moving to the next. Once the skeleton is done, go back and fix everything so that you have a sturdy framework to hang the “meat” of the game on.

    • aldo says:

      I have a vague memory of a statistic whereby the ‘fix time’ of bugs increases exponentially over time if you put off decoding them. Could be rubbish, though.

      Anyways, fix them; any bug left now is not only likely to be obscured by code as you add it in, it’ll also likely contribute to numerous other ‘symptomatic’ bugs. There are few things worse than fixing 3 or 4 bugs with specific workarounds (etc), only to find that they share the same root cause anyways.

  4. Praetor says:

    I think this “explosion of amateur development” is going to be a great thing, it might take a while for people to get past the “omg I’m making a game! let’s cram every feature imaginable into it! and make it an mmo!” stage (oh the memories….), but I think we’ll see a lot of really creative stuff.

    In regards to the bugfixes vs. features idea: bugfixes. As much as you might want to add new features, in my experience, I always end up going a few “I’ll fix it later”-s too far and dig myself into a hole. I’m currently completely rewriting the engine for my current project (Quanta) because it just got too disorganized (partly due to the IGF deadline, but the problems began months earlier…).

  5. jalf says:

    Fix bugs when you need them fixed.
    How much of a gamebreaker is it? Does it prevent the game from actually being played? If so, fix it now. Is it a small annoyance that, if fixed, would make the game better and more polished, but which doesn’t actually ruin the game? Fix it later, when you have nothing more important to do.

    Perhaps set up a Bugzilla or other free bug-tracking software, enter the bugs your aware of into it, and prioritize them. If you have some total showstopper bugs, you should probably fix them ASAP, even if it means delaying new features.

    Basically, every day you should aim to do what improves the game the most. Sometimes that might be fixing bugs. Sometimes, it might be adding new features. Just make sure you don’t “lose” or forget bugs. If they’re there, note them down so you can at least get an overview of how much you need to fix, and so any bugs left in the game are there because you decided they weren’t important, rather than because you forgot about them.

  6. DMJ says:

    When to fix bugs?

    If you want to do it like the professionals do it, the answer is “in a patch six weeks after release”.

  7. 4026 says:

    Noc wins this thread.

  8. Linus Sjögren says:

    Too bad Unity doesn’t have a Linux client.

    I mean, having a Mac client and not bothering to make a Linux client is just a dick move.

    • LeFishy says:

      It isn’t exactly a Mac client. It is originally a mac program. Only since 2.5 has it been Windows compatible.

      Made using Mac tools and whatever. From what I can tell it seems hesistant to build applications for any other system.

    • AngryAnt says:

      Please define Linux as a single target which will not result in hordes of Linux users going “Hey! Why support that distro and not mine? What a dick move!”. Following mission success – please define same for driver base.

      Don’t get me wrong – I’m not saying don’t do Linux. I’m just saying it’s not a simple task – compared to Win and OS X.

      Consider the Mac platform then: One hardware, OS and drivers vendor. Seriously limited number of configurations. In that regard I’d name it the simplest of the three to develop for.

    • Mike Arthur says:

      +1 to AngryAnt from someone who has done the packaging and distribution for Windows/Mac/Linux (for Mendeley, my last job) and used Linux for a long time. It’s much easier to package for Linux but you end up having to have a stupid number of versions of each package.

  9. Taillefer says:

    Bravo, Noc.

    I’d say if you aren’t going to fix them, you atleast need to understand the cause so you can prevent it reoccurring in other places or having a ripple effect on other aspects of the game. If something works only because something else is working incorrectly, it’ll just get messy.

  10. LeFishy says:

    I find I prefer to get the game running as shoddily as possible before I go in and fix everything. Otherwise I get caught up and never finish a damn thing.

  11. Carra says:

    Create a small piece to perfection and then add a new piece.

  12. jester says:

    i agree the new features are nice, but the longer some bug sit, as praetor above said, you could end up with a mess that is essentially unfixable because you’ve built too much band-aid stuff on top of it (i’ve had this happen as well to my own little projects). so any bug that seems to deal with an important element of the game, i say fix first and then add new crazy stuff afterward (and then fix the new crazy bugs that will likely follow).

  13. Flem says:

    I think you should find a balance, and get the skeleton of the game outlined before correcting all the bugs. However, from a gamer’s point of view, I think it would be sweet, if you fixed the bug, that makes you fall of the map if you sidestep into the walls, I gave up playing build 02 because of this.

  14. DMJ says:

    Another thought to muddy the water: The HL2 gunship shooting down incoming rockets was due to an unfixed bug. It was so cool it became a feature.

  15. Collic says:

    I’d try and fix any of the big, game-critical bugs now if you can. By that I mean things that you’re absolutely sure are going to need fixing at some point because they concern broad elements of the framework of the game that you’re unlikely to throw out. Like clipping through walls etc. I’d imagine it’ll just be easier to home in on at this stage.

    The other stuff I’d leave because as others have said sometimes it can lead to something interesting, or you may end spending a lot of time getting something silky smooth and bug free only to end up throwing those elements of the game out entirely at later stages.

  16. Sagan says:

    “We’ll certainly see an explosion of interesting bugs”

    I have got two stories to tell about that:

    1. When I and a couple of friends first experimented with XNA for a university class last year we had a bug with the animations, that somehow meant that the skeleton on which the animations were performed did not match up with the actual model. I think one of the two was turned in the wrong direction or something. The thing was: That actually created a really creepy movement animation. It was as if something had overtaken the character and was trying to move him without knowing how to use the body. The legs bended backwards, and were moving at a really unnerving pace. (instead of quickly forward and slowly back they moved slowly forward and quickly back) Despite looking like crap it was actually rather creepy. Only later did I realize that with a little tweaking, you could probably turn that into a movement animation of a zombie or a necromorph or something. It certainly looked much more interesting than the regular old zombie shuffle.

    2. I was playing around with fluid simulation systems earlier this year, and hadn’t quite got it working yet. I had the particles colour coded to show whichever value I was debugging right now. (so using RGB to represent the XYZ-values of for example the pressure or of the velocity) Before I got it working I accidentally created several interesting phenomena. One where the particles were somehow pulled together until the pressure became too high at which point they would suddenly erupt in a shimmering colourful fountain. If you let it run for a while a cycle would be created, where particles would get shot up, fall down, get sucked into the fountain again and get shot up again. Every time they would get sucked into the fountain they would shimmer in the wildest colours, representing the insane pressure at that point, and then they would forcefully separate according to a rainbow colour scheme. It was a little beautiful.
    Another was where they would randomly get stuck to each other, which created strange vine-like or crystal-like structures if you let the simulation run for a while.

    So yeah completely random bugs can create interesting phenomena. My reaction obviously was to fix the bugs and move on.

  17. Poet says:

    WTF is someone going to make Serenity in this or any other engine so I can Imagine a place without you.

  18. Voice of the Majority says:

    Well, someone boring could say you should first plan the game (and prototype your plan), divide it into manageable, well defined parts, implement them and then integrate the whole thing to get your first working build. Then test and…. yeah it sounds too much like work.

    There’s a so-called agile development method, which works so that you periodically define the next addition or refinement and always aim to have a running build at the end of the period. Sounds more like what you’re doing.

    Planning does help, but I guess the really important part is to track the bugs. If your plan is sound it is less important when you fix the bugs. On the other hand if you have no plan you’ll get a mess in the end.

  19. Morti says:

    It’s easier to fix a one story house than a 50 stories skyscraper. Build on a solid frame, and you’ll end with a solid game. Build on a buggy frame, and you will end with a shitload of bugs.




  20. Emil Johansen aka AngryAnt says:

    Please define Linux as a single target which will not result in hordes of Linux users going “hey! Why support that distro and not mine? What a dick move!”. Following mission success – please define same for driver base.

    Don’t get me wrong – I’m not saying don’t do Linux. I’m just saying it’s not a simple task – compared to Win and OS X.

    Consider the Mac platform then: One harware, os and driver vendor. Seriously limited number of configurations. In that regard I’d name it the simplest of the three to develop for.

  21. Nathan says:

    In the end there will be no larger an explosion of games than when Flash first started making game. If you visit a flash portal then you will see tonnes of crap but you will also see some real masterpieces. Most games won’t go anywhere because they have nothing new or going for them. Others will thrive though in a world bored of killing zombies, great game shall be found.

  22. PHeMoX says:

    “Now that the indie license is free I can see Unity becoming to games something like YouTube is to broadcasting, or what the web was to print.”

    Well, lets just remind everyone that there actually are fully free engines out there you know, some of which really are quite excellent…. They may not have the same kind of accessibility Unity has, but I’m pretty sure no engine that features serious game editing tools and proper scripting, can be truly accessible. All these game-engine tools have serious learning curves and that’s the way it should be.

    Ultimately, I do share the excitement about Unity being open for people that want to really try it and give it a more serious try than most engine demos would probably allow for.

  23. DizzlerD says:

    From my limited programming experience (in ActionScript), and dev experience in other areas, I’ve found that a good guideline is that if you’re fixing a bug so that you can integrate one feature with another, you’ll be saving yourself a lot of pain later. On the other hand, if you’re just tweaking the values of something before you’ve connected it to other bits of the game, then there’s probably something more useful you could be doing.

    Another thing to watch out for is if something isn’t behaving the way you expected it to, even if it’s subtle. You want to understand not only what a bit of code is doing, but why it’s functioning in the particular way it is. Otherwise you’ll be completely lost when something really obvious and bad crops up later.

  24. kikito says:

    Consider which parts of your game are “definitive” and which ones are “experimental/may be removed later”. Fix the bugs on the definitive ones, leave the bugs on the experimental ones.

    From then on, if you want to move a feature from “experimental” to “definitive”, fix its bugs first.