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.
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.
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.
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.
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.
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.