Category Archives: Low-content rambling

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.

Low-content rambling

Obscure Unity/Surface Pro 2 problem solved

Okay so this is a post that has little to do with Sprite Lamp. In fact, it’s probably not interesting to most people who have subscribed – sorry about that. It’s about an obscure problem I had today that I seem to have fixed, but couldn’t really find anything about it online. So I post it here, on the off chance that someone else has the problem and maybe googles their way to this page, and maybe can waste slightly less time on it than I did.

I’m using a Surface Pro 2 (the 256GB model, though I doubt that matters), and was going to do some work in Unity3D. I hadn’t run Unity for a little while, and when I fired it up today, it had some problems. Specifically, lots of messed up visual stuff. Unfortunately I didn’t get a screenshot, but to my eye it looked like some fairly low level VRAM corruption of some kind… within the Unity Editor, various things were messed up, including button and other UI graphics being busted, text was garbled and screwy, and various texture previews were busted. Interestingly, it seemed to also screw up some of the actual game assets when rendering in the viewport.

Anyway, I tried the usual raindances, restarted Unity, restarted Windows, etc. to no avail. My graphics drivers were up to date, so that seemed all good. However! Long story short, a couple of people have reported that using Intel’s generic drivers rather than the ones Microsoft provides with Windows Update can help with some gaming applications (plus it gives you a control panel to mess with certain options), and I had actually done this on my Surface some time ago – but, I had since reinstalled the OS and obliterated the changes. Also, Unity never used to have this problem… curious. So, I got myself over to Intel’s driver page, navigated to the HD4400 area, and got the drivers from there. And that seems to have fixed it! Happy Unity shader editing since then, and all is well in the world. So if, by chance, I’m not the only person to have ever had this issue, and one of the other poor souls happen to wander here in their confusion, there you go. It’s what worked for me, anyway.

Low-content rambling, Sprite Lamp

Sprite Lamp hits its goal!

Well, I was planning on posting an update when Colour Bind’s Kickstarter went live, but I ended up getting distracted by a bunch of social media stuff, and now that I am actually getting around to posting this, it has a different title.

Sprite Lamp on Kickstarter

That wasn’t quite what I was expecting. Sprite Lamp hit its goal of 6k around the seven hour mark, which I strongly suspect (but can’t prove) makes it the first official Australian kickstarter to be funded. Sweet! The obvious thing to say is THANK YOU to everyone who pledged, and everyone who helped boost Sprite Lamp by sharing the kickstarter on social media (and in general). Because of you, Sprite Lamp will not only happen, but it will happen in a timely fashion, and most likely it will get a bunch more features and be a higher quality product than it would have otherwise been. Also because of you, I get to buy a new pair of shoes (seriously, my old shoes have holes in them).

With that out of the way, it seems I have some work to do. I had put some vague stretch goals in the Kickstarter, but now I’ve got to make them specific much more quickly than I was expecting. I’ve already had some good suggestions. In accordance with one such suggestion, I’m going to set up some rudimentary forum here for talking about suggested features and the like.

I’m also going to make a series of blog posts here about a variety of graphics techniques that will be applicable to Sprite Lamp. I’m going to cover things like how the shaders work, issues with using normal maps that you might not see coming (like the fact that rotating a normal map in Photoshop results in incorrect normals), and a variety of shadow techniques that exist somewhere along the correct/fake spectrum that might work well in conjunction with Sprite Lamp.

Oh, and don’t forget that I need your precious votes on Steam Greenlight – any help there is much appreciated.

Thanks for all the support, everyone!

Graphics, Low-content rambling, Programming

Messing up FRAPS – a warning

Well here’s an interesting thing that I haven’t gotten to the bottom of yet.

I was just recently putting together an entry for a game competition. Since I like to mess with shaders and other odd graphics card things, examples of that activity needed to be collected for the submission. Among them was a thing called the Cave Demo – basically the idea is that it was to be a game where you are exploring a procedurally generated cave, but unlike most such caves, this one has its generation parameters tweaked on the fly, causing it to shift around all crazy-like. Unfortunately, I’m not convinced that this was going to become a good game, so for the moment I’ve stopped working on it – it did result in some really cool -looking things though, at least to my tastes.

As it turns out, rendering a cave each frame is pretty easy – you render a bunch of stuff into a greyscale image, with the map representing some kind of density function, then by rendering with that image as your punchthrough texture you do a sort of automated Marching Squares thing, and bam, you’ve got a cave. You can render greyscale images into the cave buffer additively to get various effects like platforms appearing and disappearing, that kind of thing. It’s neat. From there it’s just a matter of interpreting the density map in a more complicated shader to generate a more impressive looking cave. Obviously this is a really ineffective explanation because how this was all done is maybe a blog post for another day.

Anyway, the key to this is that that’s actually not all that’s required if you want to have actual gameplay that interacts with the cave. This ever-changing cave will be needing functional collision detection, and for that, we need to get some or all of the cave buffer from video memory back into main memory so the CPU can deal with it. This can be annoying to set up, and it’s not the speediest operation in the world, but it’s doable and I did it and I was quite pleased with myself.

Fast forward to the other night, where I’m assembling a bunch of videos of stuff I’ve worked on to prove to people that I can make stuff. I fire up my trusty FRAPS and record what I presume to be some rad footage. I open it up in Media Player Classic and am confronted with something way way less rad than I was expecting. Rather than capturing what was actually on the screen, FRAPS has captured the contents of the cave buffer – a weird-looking blurry image about a quarter the size of the video frame, and wholly unsuitable for entering into a competition of any kind.

This was pretty soon before the competition was going to close, so I didn’t really have time to do much about it other than use a camera to film the footage and hope the resulting low quality doesn’t offend people too much. I did manage to figure out that the act of getting stuff back from the video memory to the main memory was what was doing me in. I discovered this using the time-honoured debugging technique of commenting that bit out and seeing if it fixed the problem. So that gives me something to go on, although it didn’t actually help at the time because of course getting rid of all the game’s collision detection kind of broke things. When I do figure out what’s really going on here and if there’s a way to get around it, I’ll update this post with more helpful advice.

In the meantime, don’t make the same mistake I did! There are things that can trip FRAPS up.

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.