Category Archives: Advice

Advice, Games, Sprite Lamp

Sprite Lamp, lessons, conclusions, and the future

So, it’s been a little while since I’ve written about Sprite Lamp (or anything). There’s still activity at my end, mostly in the form of responding to email requests for tech support and other advice. Sprite Lamp is now out and about on the three desktop operating systems, and I thought I’d mention a few things that have happened, reflect, confess one or two things, and talk about the future.

Cool things

Unity shaders

First off, Sprite Lamp’s Unity shaders have always been a bit of a thorn in my side – always mostly working, I’ve never been quite convinced that I am doing things the way Unity wants me to. Well, thanks to an email from a customer prodding me to fix light cookies, I have revisited this, and I think finally gotten it to work the way it should. I admit I’m still daunted by Unity’s inner workings, but for the first time, I feel like I get how I’m supposed to be using the lighting system. I imagine most people who use Sprite Lamp with Unity are mostly using plain ol’ normal mapping at this stage, but for those still using the official Sprite Lamp shaders, they have been updated, I believe substantially for the better.

Hive Jump

So, for obvious reasons, this is very exciting to me: A game made with Sprite Lamp is officially out on Steam! Hive Jump is a multiplayer 2D shooter that feels a lot like days of old, but of course, everything gets illuminated all nice. I’ve probably mentioned Hive Jump at some point, as I’ve been in touch with the developers since way back in the day. If you want to get an idea of what Sprite Lamp can do in the right hands, check it out!

Things not done

So this is an important section for me, and I think anyone who’s ever done a Kickstarter campaign will be able to relate. There are a few features from the original Kickstarter that remain undone, and will likely remain so. This is for a couple of reasons, and I didn’t want to let them just disappear silently. It’s my belief that these features mostly aren’t really going to be missed, but more on that at the bottom of this section.

  • There was never a Steam release for Linux. I tried to make this happen, I really did. Because of how Steam’s version of Sprite Lamp works, it’s necessary for Sprite Lamp to communicate successfully with Steam, so that it can check if the user owns the Pro update or not. I just… couldn’t get this to work. Obviously it’s good to go on the other two operating systems, but some combination of my inexperience with Linux, the Steam API being different in that situation somehow, and not getting much in the way of responses when I was looking for help, just bogged this one down. The Linux build is available from the Humble widget, so Linux users aren’t completely out in the cold (and the vast majority of people who own Sprite Lamp got it from the Humble Bundle at this point).
  • Mesh exporting never happened. Once upon a time, I intended to have Sprite Lamp export a mesh based on a generated depth map. The further I got into the development process, the sillier this feature seemed. There isn’t one universally accepted mesh format, so I would probably have needed to integrate several libraries just to export to things like fbx, obj, etc. More importantly, it doesn’t seem like anyone was even close to wanting to use this feature (this is true of a lot of the depth stuff in general).
  • Custom shaders never happened. I originally had a plan of allowing users to write their own shaders and have them display in the Sprite Lamp preview window. A minimal box-ticking style implementation of this wouldn’t be so difficult, but the interface between Sprite Lamp and a custom shader is so convoluted that it seems extremely unlikely that it would see any use. Furthermore, it seems that most Sprite Lamp users are content with the existing shaders, and are generally not shader programmers themselves. Finally, if someone really wants to do this for a particular pipeline reason, they can edit the built in shaders to achieve a similar effect.
  • Generally not great engine integration. This is the one that I regret most. I underestimated how much pain engine integration would cause me in several ways, and it was foolish of me to think that keeping up with multiple engines was feasible (especially since I’m not especially adept at any existing game engines).  I also communicated badly about the situation with what an engine integration actually means (that is, that it’s only for the fancy Sprite Lamp-specific effects – you don’t need an engine integration just for basic normal mapping). As of now, there’s a fairly good Unity integration, and a useful but not as complete Game Maker integration. I also didn’t foresee the extent to which Unity and Unreal 4 would take over everything, and the fact that PBR (physically-based rendering) would make it infeasible to actually do Sprite Lamp shaders at all.

I think that’s the end of my list of confessions. As I say, for the most part, this is stuff that I wasn’t expecting to get much use (and in most cases, literally none). However, if you are reading this thinking “God dammit Finn, I backed your kickstarter because I wanted to export depth maps as meshes, how dare you”, please contact me! I genuinely don’t mean to leave people out in the cold – I just don’t want to put myself through a bunch of programming work for features that literally nobody cares about.

Speaking of which, another thing that could have gone better was… in general, I think a lot of the features (particular stretch goal stuff) were just not that useful. More on this in the ‘lessons learnt’ thing, but yeah. Most of that stuff did get implemented, in the end, but I think doing so was in large part me tilting at windmills.

Lessons learnt

About crowd funding

I’m not exactly champing at the bit to get another crowd funding campaign going. Why? Well, a lot of it is my particular psychology, I suppose. But there’s a really important thing that I want people to know about crowdfunding.

If things crash and burn – and they might – it will feel like there’s no honourable way out.

I consider myself to have gotten off lightly with Sprite Lamp – perhaps I’m flattering myself, but in spite of the rather long tail for certain features (coughOSXcough), I consider it a fairly successful project. However, it kills me when I occasionally get a heartfelt email from some game developer who I backed on kickstarter years ago, on a project I’ve long since forgotten about, who’s thrashing about in development hell on a project that would have been cancelled ages ago if it was a normal publishing deal. Often they’re fighting tooth and nail to finish the project, giving up years of their life to develop on platforms that are no longer relevant because they promised, or whatever. I wish I could tell them “seriously, don’t worry about it, go work on something else”, but unless every one of their backers tells them that, they’re still on the hook, and it sucks. If you’re considering a kickstarter campaign or something similar, please, seriously consider that this might happen to you. I feel like Sprite Lamp has given me just enough of a taste of what that would be like that I’ll probably never touch crowdfunding again.

Furthermore, I say this as someone whose backers have been basically 100% wall to wall lovely the whole time. If your backers are shitty to you, that probably wouldn’t help much either.

About my own habits

I’ll just come out and say it. I suck at, and hate, communicating with large groups of people. I suppose this is what people would call ‘community management’. Maybe it’s just my latent shyness, I don’t know. But god damn, I was not expecting to stress more about tweeting that I’ve launched a new build than I did about actually doing the build. As a game developer, I don’t know what my long term strategy for this is. It seems the conventional wisdom right now is that to have any success as an indie developer, you need to maintain a fairly active social media presence. My current strategy about that is to really really hope the conventional wisdom is wrong. Plan B is probably to become a farmer or something.

Related to that, having some kind of weird broken comment/forum system on this website that basically never saw any use really didn’t help. The forums are gone now, and good riddance. If you asked me something there at some point and I ignored it, I’m sorry. If you email me I’ll get back to you much much faster.

One on one is fine, by the way. Anyone who has emailed me for tech support or whatever over the years: you’re cool, no worries at all.

The Future

So, right up there in the title, this blog is for Snake Hill Games – and while it’s true that Sprite Lamp is game-adjacent, I’ve always wanted to get back into making games rather than game tools.

A while back, I started fooling around with a simple base for a project, to relearn C++ (I was teaching C++ but hadn’t used it for years, so this practice was very much necessary).  It hadn’t really gotten anywhere, but I learnt a bunch, and it was around this time that I rebooted Sprite Lamp in Qt. That was the major project focus for a while, and there has been quite a bit of tying up of loose ends there.

However, as of now, I am officially Working On A Game. I’m not really going to say much about it for now – it doesn’t even really have a name. I’ll mention that it doesn’t make major use of Sprite Lamp (sorry – it doesn’t really fit well with the required rendering system), but it does contain some unconventional lighting systems that I think people will get a kick out of (it did start as a programming exercise, after all). More on that coming soonish.

Final thoughts

If it’s not obvious from the above blog post, people are welcome to keep contacting me about Sprite Lamp (and other things). If you need help with getting something to work, or advice about using Sprite Lamp, or need an explanation of how normal mapping works, or whatever, get in touch. I’m pretty responsive via email and generally happy to help.

The other thing I will say is, a final thank you to all my backers. Not so much for backing my project – although that’s much appreciated, I’ve said that already – but for generally being a pleasant bunch. Keep doing what you’re doing, and making cool stuff.

 

Advice, Low-content rambling, Sprite Lamp

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.

Godot

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.

Advice, Low-content rambling

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.