As I mentioned in my last post, I'm going to be spending the weekend brushing up my Unity skills by entering the Ludum Dare 48 hour game making contest, which begins in about 4 hours time.

Since that's around 3am local time, I'm obviously not planning on diving straight into the coding there and then. Haven't decided yet whether I should stay up late enough to see what the theme is and sleep on it or just wait until morning and find out then. Either way, the plan is to sketch out some ideas over breakfast at my local coffee shop, then repair to the Beercave and make a start on whatever I come up with.

Whatever I manage to bash together over the weekend, it's a safe bet that the graphics will be awful (or at best, very abstract), so I guess I'm gonna just have to concentrate on gameplay. Anyway, I'll update in the morning, once I know what's going on.

All's going well so far with the Playing Gods project. After a thoroughly productive (and somewhat beery :D ) series of playthroughs of the board game last weekend to fully clarify the rules, I've got most of a prototype of the logic hacked together in python, and I'm happy enough with it that I'm ready to make a start on the game proper.

For that, the current plan is to use Unity3D for the front-end graphics, backed up with an AppEngine web service for tracking the game state and co-ordinating the players. I'm looking at getting the back-end working first, with a basic HTML UI for testing, then look at adding the pretty stuff later.

So far that's working out well, and I'm hoping to have most of the state tracking logic in place with AppEngine over the next week or two.

Conveniently, this upcoming weekend is the next Ludum Dare 48 hour game making competition, so I'm planning to use that as an excuse to familiarise myself with the Unity engine in preparation for when I get to work on the front-end.

I quit my job Monday. Was planning to write about it sooner but I got a little distracted watching the country in flames...

Anyway.

So yeah, it's been on the cards for a while. Not that it was a bad job or anything but for me at least 'well treated employee' starts to feel a lot like 'well treated pet'. Curse my Rugged Individualism :)

So, now that Mrs. Beerman seems to be pretty well established and loving her job, and we've been fortunate enough to score a 6-9 month cat/house sitting gig that comes with free accommodation, it seemed like the perfect time to make the leap and try and make it solo.

What now? Well, I'm gonna see if I can't bootstrap Beercave Games into a fully-fledged indie game developing machine. Plan is to pay the bills with contract work and use the downtime to work on games.

Luckily, I'm off to a good start. A good friend of mine (and thoroughly talented bastard has picked up the rights to develop video game versions of sacrilicious board game Playing Gods. He needed a coder, I needed a gig, so now I've got my first commercial project.

All being well, we should be launching on Facebook in late October - conveniently, right around the time I'll be finishing up the day job. Obviously that means that Gun Bastard is going back on hold again, but nothing new there!

These are dark times at Beercave Towers...

A brief timeline:

1. I start making some progress on the new improved Gun Bastard
2. Deciding to get a bit more sexified I step up my workout program and decide to cut back on the beers for a while
3. My PC decides it's time to go tits up and stops booting.

So, that's no gamedev, my entire media collection inaccessible and my only internet access outside of work is via the iPod or Vikki's laptop. Which pretty much leaves my only remaining entertainment option being broadcast TV, and like hell if I'm watching that crap sober!

Going by the diagnostic lights the voltage regulator module on the motherboard's popped its clogs. I had a quick google around and I can pick up a replacement for 20-30 quid but since that's the second hardware failure it's had I figure it might be best to buy a new machine. I might see about resurrecting the old one for occasional usage but I'm not convinced it's reliable enough for day-to-day development.

In summary, watch this space - normal service will be resumed shortly...

In s staggering break with tradition, I've been using my weekend to actually get some work done! No, I don't really believe it either...

I started the day off by knocking up a particle system. After hooking it up make the enemies explode when shot it looked a little something like this:

As you might have noticed, it's a bit on the excessive side - I accidentally set the explosions to repeat every beat instead of only firing once. Looks like I'll be able to get plenty of stuff on screen at once though :)

Once I was satisfied I could chuck particles around without any problems, I thought I should see about making things a bit prettier. After fixing the particle size and colour to match the game sprites, I added a motion trail effect to my explosion particles and ended up with this:

Not quite up to OddBob's standards yet, but a definite improvement.

With that done, I spent a bit of time refactoring things to keep the codebase nice and tidy. One thing that was a bit ugly about Sheep Snaggers 2 was the huge chunks of boilerplate code I was using to spawn my game entities and attach the relevant behaviours to them. It works, but as the project gets bigger it's not really sustainable and I ended up with a whole bunch of near-identical 'Spawner' classes for the different entities.

So, to make my life easier in future, I've built myself a generic entity spawner system which takes a folder full of entity definitions (basically a list of behaviours to attach to the game object) and can then generate entities by name. So instead of having

enemy = GameObject(
  x = 0,
  y = 0,
  name="enemy"
)
SpriteBehaviour.Attach(enemy,
  texture="alien1",
  scale=2
)
PhysicsBehaviour.Attach(enemy)
EnemyBehaviour.Attach(enemy)
#etc.

enemy = EntitySpawner.Spawn("enemy")

With SS2 finally fixed up and shipped, I've been thinking about what to work on next. While I'm still pretty keen to make a crack at some of the ideas in there, I can't help but think I should really finish up Gun Bastard first.

With that in mind I took a quick look at the old codebase, went 'uurhg!', and promptly binned the lot and started again ('cos that's just how we roll in indie-land).

What I've got so far looks like this:

Doesn't look like much so far, but the new stuff is a lot easier to work with.

Inspired by this article I thought it might be cool to have the AI synced to an external timer, so I hacked up a basic events system that I could drive with my metronome class. Right now all it does is make the enemies change direction every beat but I'm planning on making it the core of the game AI and hopefully hooking it up to the audio system so that events happen in time with the soundtrack. If it works out, it should be awesome :D

The updated version of Sheep Snaggers 2 is now available for download.

As well as the performance fix for the schoolboy error in the original release, I also corrected a major oversight in the original game.

One of the first questions I was asked when demoing it at Retrovision was "why can't you shoot Markie up the arse?" Seems obvious in retrospect, but somehow during development it never occured to me!

This shameful faux-pas has now been corrected - although in the interests of balance you'll have to deal with Markie's newly acquired rear defenses...

Yes. Yes I did go there.

2 posts in a day - man, I'm on fire!

Before I get started on my next game project, I thought I should address my woeful lack of tool support, since it tends to lead to a certain amount of corner-cutting and inefficiency. First up, spritesheets!

Sheep Snaggers 2's engine code had pretty decent support for rendering from single texture spritesheets, but since packing all my sprites together and working out the co-ordinates by hand was frankly a massive pain in the arse it only really got used for a couple of animations. I ended up actively resisting the idea of adding new animations because I couldn't be bothered with the donkey-work.

Since automating the donkey-work is pretty much what computers are for I thought I should address that by writing something to build the spritesheets for me - so this afternoon I finally pulled my finger out and the result was Spritepacker.py

A brief google suggested that if I wanted it to be really efficient I'd be dealing with a variation on a classic NP Hard problem, which is a bit more than I want to tackle on a lazy Sunday afternoon. A bit more googling found this example for packing lightmaps which looks like a nice simple interpretation of the First Fit Descending algorithm listed on Wikipedia. I tried it out with the Sheep Snaggers sprites and it seemed to do a pretty good job, anyway.

As originally discussed in Keeping Control, I built a fairly handy wrapper class for handling player input in Sheep Snaggers 2. Now that the game is finished, I'm happy enough with the wrapper code to release it into the wild in the hope that someone else might find it useful.

Basically it abstracts out the various keyboard/mouse/controller functions by mapping them to a set of named controls. Each control can map to more than one input format so the core game logic doesn't have to know what controller you're using, it just asks the input module if e.g. a 'FIRE' event happened this frame.

You can find the source code along with a simple example here, or in the sidebar under 'Other Stuff'. The code is released under the Beerware license, so if you like it, why not buy me a pint?

So with Sheep Snaggers 2 all done with (pending bug fixes passing testing), I guess it's time to find a new project to play with. Which of course brings me to the eternal quandary of the indie developer :

Which one of my countless unrealised ideas do I work on next?