Category Archives: Advice

Scattershot update

Quite a few things to put out there today.

Mac and Linux progress

This has been my main focus recently, and though I’m aware that this part of the project is well overdue (more on that in the ‘lessons learned’ section later on), we’re down to the last handful of bugs before the alpha releases on MacOS. Rob reports that he’s been having more trouble than expected with various parts of the project – it was a bit of an unknown working with C# and MacOS in the first place, but there have been more unknown unknowns than either of us saw coming. At this point it’s essentially all UI fixes, but unfortunately they’re not the kind of thing that can be handwaved, even for an alpha. It’s been frustrating at our end, since Halley is a Mac user and has been keen on getting this version sorted for a long time, but the end is very much in sight. I apologise for how long this is taking, though – I don’t mean to gloss over the fact that it’s much longer than expected.

As for Linux, because the MacOS version is mostly in Rob’s hands now, I’ve been looking at the Linux build. This isn’t as big a deal as the Mac version (in terms of work, I mean) because it doesn’t involve an entire UI rewrite, but there are lots of problems that have previously been in the too-hard basket because previous releases haven’t been in any way final, which I’m now having to face head on. A big part of all this is packaging and general unfamiliarity with deployment conventions at this point.

A few engine things

Unreal 4

This is an odd one. Lots of people have been asking me about integration between Sprite Lamp and Unreal 4. I feel a little bit like the winds of change are blowing in the indie gaming word – it seems like everywhere I turn, people are talking about their new project using Unreal 4, or the various advantages the engine offers. I don’t know whether Unreal 4 is going to replace Unity in the near future, but it was enough to convince me that it’d be irresponsible to not look into Sprite Lamp and Unreal 4 playing together.

I’ve spent some time recently learning the engine a bit, and… well, beyond normal maps, it’s not clear there’s much I can do with Unreal 4. As usual, it’s a modern engine and can therefore handle dynamic lighting and normal maps just fine. However, because it uses deferred rendering in a very fundamental way, it’s no longer possible to just write your own custom lighting model with Unreal 4 as far as I can see (and the fancier features of Sprite Lamp’s shaders fall into that category). I’ll add two caveats to that – first is, obviously people are capable of achieving amazing things with Unreal 4’s lighting, and that includes nonphotorealistic results, so very likely things like cel shading are still possible. It just means that I won’t be writing the exact shader from the preview window of Sprite Lamp into Unreal 4, because that appears to not be possible. The other thing is that since Unreal 4 has its full source code available, technically it’s not really true to say that anything can’t be done – almost anything is possible. However, I think that trying to maintain a source-modified version of the engine (that would survive integration when Epic updates and so on) is probably more trouble than it’s worth for everyone involved.


Another engine that seems to be picking up steam a bit is Godot. Since it’s completely free and open source, Godot’s appeal isn’t hard to understand. I don’t know a great deal about it yet, but I’ve been following along and it seems that 2D lighting is a priority for them in the near future, which is obviously very relevant to my interests, and perhaps yours. That said, unlike Unreal, I haven’t particularly gotten the impression that lots of people using Godot are also using Sprite Lamp – if you’re a Godot fan and would like me to look closer at its use with Sprite Lamp, let me know.

Real life issues

As you’re probably aware, Sprite Lamp has been out on Steam and Humble for a couple of months now, and though it’s doing okay for itself, taken in combination with the above issues about the Mac port taking way longer than expected, it would be financially risky for me to just assume that I can live indefinitely on Sprite Lamp. This has necessitating me getting myself a ‘real job’. It’s a job that doesn’t consume all my time, and don’t plan on completely returning to the normal full time employment world for a little while yet (not while Sprite Lamp is ongoing, certainly).

Lessons learned

One day, I’ll do a proper Sprite Lamp post-mortem, but there are two important things I’d like to put out there in case anyone might learn from them.

First off, it’s clear to me now that the biggest technical misjudgement on my part for this project was underestimating the difficulty of working with unfamiliar platforms. I’ve only ever been a Windows developer, so (I thought) I had a suitably healthy fear for working with other platforms – that’s why I went and made proof-of-concept stuff for MacOS and Linux before promising those versions on the Kickstarter campaign. Still, I was unprepared for how much work gets bogged down (for me, at least) by not knowing the operating system. As a simple example, I recently spent an embarrassingly long time tracking down some issue with apt-get on my Linux install that was stopping me from progressing, which ultimately culminated in having to install a newer version of Linux (which, to its credit, went very smoothly). That stuff adds up, and it’s not psychologically great when it feels like you spend as much time fighting with problems of unfamiliarity as you do writing code. I’m hoping future projects of mine can be cross platform, but I’m definitely going to be less gung-ho in my assumptions. Certainly I cringe internally to recall my intention to do a simultaneous cross-platform release.

Second off, and a little personally, I didn’t foresee how much being a (very very mildly) public figure would be a source of stress, and how crap I would be at maintaining stuff like this blog, a social media presence, etc. I’m actually not a terribly shy person in real life (although admittedly with game development to some extent you’re grading against a curve there), but apparently I am in the internet world, which seems to be the reverse of how most people feel. This mostly makes me respect community managers a lot more, but also gives me some reason to pause in the goal of being an indie developer, since it kind of comes with the territory. Not sure how I’ll feel about that going forward, but if anyone has actually read this far and has any advice on the same kind of thing, please let me know.


Anyway, that’s it for now, and I’m back to figuring out Linuxy things. To anyone who read this far, I hope you celebrated whatever they’re inclined to to the best of their ability, and that 2015 is as good or better than 2014.

Game jammin’

Last weekend was the global game jam. I was there! Good times were had, presumably by all. I’ve been to a couple of these now, and I’ve heard some discussions of what the point of them actually is. I think that there are lots of possible uses for the things, but it helps to have a good idea in your head of what you’re looking to get out of them.

To prove to yourself that you can finish a game. This is important for the newbies among us. I had some friends at the jam this year who had done a bit of programming, messed around with some tools and such, but never really made a whole game. Now they have. It’s kind of a trial by fire, but whether you finish your game or not, you emerge with a new understanding of how game development works.

To experiment with no consequences for failure. Often, experienced developers haven’t had the opportunity or the motivation to just try something crazy, and hang the consequences. Motivation is key here – it’s one thing to have an idea in your head, but even if you could implement it yourself in a weekend, it’s a different matter to be ‘forced’ to. For experienced developers who are planning to ‘go indie’, this can also be an important lesson in the practice of prototyping – making something, finding that it sucks, and fixing it or throwing it away. May as well get your quota of bad games made before it matters.

To make connections. Personally, I hate making connections. Let me revise that – I hate attending networking events. Frankly, I think a lot of people do. Worse than being unpleasant, though, they also don’t really tell you whether or not you can work with a given person – just whether or not you can stand to have a beer with them. Game jams are a good way of answering that question without going to all the trouble of getting yourself into a potentially long term business situation. Both the game jams I’ve been to have left me thinking “Why don’t we do this every weekend and make a business of it?” and, ill-advised though that thought is, I’m sure I’m not the only one who has turned fellow jammers into co-developers.

To start making a game. Seems kind of obvious, I suppose. You might have heard of NaNoWriMo, or National Novel Writing Month, an event in which a group of deranged individuals (yes I have been among them) attempt to each write a 50,000 word novel in a single November. A lot of people make use of it as a way of just getting a terrible book written, upon which they can then improve – some find the challenge of just getting from nothing to something the biggest challenge of all. Is that you? Having one intense work weekend forced on you can break the back of resistance to making a new game. Particularly in the casual/mobile/whatever space, a pretty big amount of work towards a finished game can be done in one weekend. This works pretty well with the dot point above, too.

To have a party. My motivations for going to game jams these days is a combination of experimentation, networking, and prototyping, but I have to admit that it’s also just because they’re fun. I’m not all that much of a one for drinking or clubbing – when I was younger, people would often ask me what I do for fun, if not that. ‘Game jamming’ seems like a pretty good answer to me. My other reasons for game jamming might deteriorate in the future, but when someone asks me “Do you want to go to a weekend-long party where, instead of getting drunk and shouting over loud music, you make games?” my answer will always be ‘yes’.

Okay, those are the reasons I can think of. Either you’re one or more of those reasons, or you don’t want to go to a game jam. Or my list isn’t comprehensive – a possibility that, for the moment, I will pretend doesn’t exist. In any case, I’m going to attempt to dispense some advice for potential jammers.

Team members should aim to be of similar skill levels. In particular, this is for the newbies. I welcome positive experiences to the contrary – this is just my gut instinct – but the education benefit of a jam is, in my opinion, largely for trial-by-fire nature of it. Having to figure something out, or else it doesn’t get done, is a good way to be forced to learn, and while having an expert around to guide you will certainly make your game better, I think it’s better to make a crap game and learn than it is to make a less crap game and learn less. The other reason for this is… well, lots of people are happy to teach those less experienced than themselves, and some people sign up for 48 hour game jams, but few sign up for 48 hour teaching jams. If someone’s going to be helping you learn for the game jam, you should make sure they’re up for it.

If you’re just there to have fun, you should still care about finishing your game. It’s like a competitive multiplayer game – you don’t have to be cutthroat about it, but the players should at least try to win, or else the gameplay falls apart. Game jams are fun because you’re trying to make the game. If you end up dicking around and not caring, it’ll won’t be fun anymore. Especially not if your teammates have reasons other than fun for being there.

If you are there to make connections, don’t form a team made up exclusively of people you know and have worked with before. Yeah.

If you’re planning to sell your game, make sure you’re happy with your teammates. Finishing off polishing up your game and selling it means these people will be your team mates for a while longer than 48 hours. If you’re not okay with being a potentially weird shared IP situation with them – you can’t always choose your team, after all – consider shelving that plan for the moment.

If you really are only there for the fun, don’t do something safe. If you’ve made a game in 48 hours before, try to make something more ambitious this time. Pick one of the crazier diversifiers, or do something weird and unexpected with the theme. Don’t be that team of experienced developers making the same thing they’ve made before and with no stress or excitement.

Get a somewhat reasonable amount of sleep. I’m not saying reasonable by normal standards – you’re probably sleeping on the floor in your clothes surrounded by strangers, after all. But you don’t want to be falling asleep on days two and three, either. My first game jam, I slept two hours the first night, then the evening after that I spent four hours programming a system that I got so confused and confounded by that I eventually had to scrap it. If I had just slept for those four hours instead, I would have gotten the same amount of work done, and I’d have been more awake at the end of it. If you’re on a team of crazy people attempting some kind of personal challenge, have at it, but let’s not pretend that working for two days without sleep is going to help you achieve optimal productivity.

Okay, that’s the end of my game jam advice. I hope it was of some interest. If for some reason you were persuaded by my advice to not attend a game jam, that’s because I made a mistake, and you should disregard it and go anyway. Seriously, if it seems at all like something you might like, give it a crack – it can really be a great weekend.