Virophage post mortem (LD 29)

Posted by (twitter: @Eerongal)
April 29th, 2014 8:49 am

Play it here: virophage



All in all, I’m outrageously happy with how this project turned out. The concept and mechanics actually came out really well, and the two other people I worked with knew exactly where to go with their end of the project, as well as working with enough autonomy so as not to hold us up. When the theme was first announced, I was hesitant with it, trying to make sure we steered away from anything to do with water and/or caves or mining. I had a feeling those were going to be the bulk of the things that¬† came to mind when you hear the theme.


Daily recollections


Initially on Friday we had some good, long discussions on what we could do. Ultimately, we came down to two different ideas, the idea we used (virus attacking the immune system), and one that sounded fun, but probably more work than we had the gumption and time for, a sort of rogue-like Fishing RPG. The details of the second one aren’t terribly important, but suffice it to say that your fishing gear was like items you could find and equip in an RPG, and to catch fish, you had to battle them with your lure. We joked about this concept for probably far longer than I care to think about, given our small time frame.


One of our team members was remote compared to the rest of us (all two), so we used a teamspeak server run by a mutual friend. Suffice to say, I’m actually really happy with how the remote communication worked out in this instance. The person who was remote, MechaToddZilla, is actually the person who I participated in my first ludum dare with, this being my 5th one to date. As an aside, I think I’m getting pretty good at gauging what is and isn’t a possibility to fit into these. As I go along, there’s less and less features that need to be cut, and in this instance, adding of new things that weren’t even planned in the first place. Where as the first LD I participated in, there was probably a good 15-20 features we had to cut out. There was still a few things I had to axe that I had wanted to do because I didn’t think it would be feasible to implement well in the timeframe we have.


After some preparations (and a snacks/drinks run)¬† and initial prototyping, of which, the prototype looks nothing like what we eventually ended up with, both in mechanics and design, and that’s ok, we proceeded to call it a day without any real work other than getting prepared.



This is where the bulk of the work happened. I spent most of the day head-down in the code working to bring our creation to life. We ran into several snafu’s with BoxSync working between the three of us, and i don’t know if it was a weird interaction with the newer version of unity, or something up with the latest BoxSync software, but for the entire weekend we couldn’t get it to sync terribly properly. This is both odd and annoying, since I’ve used BoxSync on my last 2 or 3 LD’s I’ve worked on without any issue at all.


Other than the issues we ran into with the other two not being able to really playtest anything most of the day, everything else went quite smoothly. MechaTodd kept adding more and more graphics into the project, and for a while there I thought I wasn’t going to have enough need for most of them in the game at the rate it was progressing vs how quickly I was getting the game implemented. TinariKao added a number of sound effects to the project that he actually made on his own with a microphone and some ingenuity, which, sadly, I wasn’t able to get around to using too terribly many of them. Both from a lack of any real need and due to getting a large portion of the mechanics down.


About halfway through the day, MechaTodd turned his attention to the musical aspect of the game, which I have to say, I think turned out pretty well. I think the small tune on it’s own is fairly evocative of a heartbeat, and complements the game very well. I’ll admit, at this point, I didn’t have the mechanics anywhere near done, and MechaTodd and TinariKao had created a ton of content that I was afraid I wasn’t going to have a chance to use much of. That said, shortly afterwards, things really started coming together within the game. I eventually called it a day with the base mechanics fully intact, but not much actual content to the game other than the white blood cells being a thing.



This is where things really started to pull together.

I started this day unsure of the particular direction I needed to go with the game. The mechanics were all intact, but there wasn’t much to DO in the game. So i started designing a handful of bosses. At this point, the game was relatively unbalanced, and became super easy REALLY fast, so i decided to implement some scaling. To this effect, I made every boss and power up grant you 10 “level” and every normal enemy kill 1 “level”, and I started scaling boss health and damage, as well as normal enemy health and spawn rate. I also decided to up the spawn rate of power ups to make level gaining increase exponentially as you go along, thus making the game start off slowly, and ramp up in how hectic it is. It actually worked out fairly well.


With all this in place, I decided to try to give players a bit more direct influence on their attacks. To this ends, i set about trying to give the player the ability to shoot projectiles, that was earned from defeating bosses. At first, I had planned to simply have you fire at the mouse cursor. I had done this in the past in unity, but I remember it being somewhat wonky and difficult to actually implement. After googling it for a bit, and trying out some stuff with getting relative positions to the camera, i realized it wasn’t going too well, and I was spending way to much time on it. That was when I had what I think was a fairly brilliant idea.


I decided to make the firing pattern fire in a predictable 8-directional pattern. This, i felt, actually works out MUCH better than the original plan of simply firing at the cursor, and was significantly easier to implement. It also gave me some extra tweaks to give to the boss rewards.


At this point, I was once again entirely unsure of where to go with the game, but i felt it needed more challenge to it. It was then i decided to add in the super boss, which was a giant combination of every enemy currently in the game. It was actually quite easy to implement, as the mechanics for the game had really fallen into place at this time. I also talked MechaTodd into coming up with boss music for these fights. From here, things really started winding down, and we moved in to balance mode, trying to make the game get tough later on, but not too tough early.

I went through several balancing iterations, some way too easy, some way too hard. I ended the day unsure if it was going to be balanced well enough for the release on monday.



Going back to my usual day job left me with little time to do much on this project. However, what scant few hours i did have after I got home went straight into playtesting and balance tweaking. I think the results we ended with worked out very well, the game starts simple and ramps up to harder difficulty really starting around level 1000. With that in place, we pulled the trigger, locked in the code, and submitted our entry.


What went right

Overall, the gameplay mechanics really started to fall into place at an early point in the games development, which i was very happy with. Unity, as usual, strikes a good balance between ease of use, portability, and design freedom to allow us to get a good game up and running in a very short window. Teamspeak was also invaluable to our communication, and held up admirably. After our initial design sessions, everyone knew their part, and we set about our tasks, idly chatting between head-down working sessions. This can only be accredited to working with people you really trust to get their part done, and is absolutely essential in such a short timeframe.


What went wrong

Box. Box single-handedly encompassed every single issue we had with this project. We spent at least a total of 3 or 4 hours among each of us just working around issues with box, waiting for syncing, resolving conflicts, wiping out and redownloading the project, etc. We were able to limp along in this aspect and get everything done, but had the process worked seemlessly, we might have had considerably more time to pump into adding things to the game.

Had the rest of the project not been going so well, this very much so could have ended up being a show-stopper when it came to getting our project finished on time. Luckily, everything else ran so spectacularly well.



At the end of the day, I’m very happy with how the project turned out. Despite its simplicity, the game is actually pretty fun, and based on the reviews I’m currently seeing in the comments, people seem to agree. The mechanics, graphics, and sound all mesh so well to create a pretty solid overall experience. As usual, there was more I wished I could have gotten finished, but there’s only so many hours in a Ludum Dare weekend. At least this time i was very good at recognizing my limits, and what would really put us on a time crunch, and was able to effectively mitigate any problems that would have caused. There was still obviously a few concessions made in the sake of time, but not nearly so many as I have done in the past.

Tags: , , ,

One Response to “Virophage post mortem (LD 29)”

  1. Mechatodzilla says:

    I was so happy with how things went and turned out that I’ve even felt pretty comfortable using this go ’round as a way to explain this hobby of ours to other friends and people close to me. It’s easy to get caught up in the community and play to the indie dev audience but this one has actually made some of my uninitiated friends say “Oh okay. Cool. I see what this is all about.”

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]