Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/6/d299465488/htdocs/sa/blog/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 77
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/6/d299465488/htdocs/sa/blog/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 87 Sam Atkins | game development
A bunch of things to talk about, which is what happens when I don’t post at all for 2 months! Oops.
In April, Ludum Dare 32 happened, the theme was “An Unconventional Weapon”, and Food Fight! was my entry. It… didn’t turn out very well.
I was away from home, so was using my Eee netbook for development. It’s pretty limited in what it can do – OpenGL won’t work at all on it – so I chose HTML5’s canvas for the target. The big mistake though was deciding to roll my own framework rather than using somebody else’s. That seemed OK, until the deadline had passed, and people started reporting that the basic keyboard and mouse inputs were plain broken for them. Apparently they only worked on the exact combination of software and hardware I had been using. So, yeah.
Catsteroids, however, I’m much happier with. I finished a new build of App 2, sent it off to my tester, then realised I had two days left in May and no game for 1GAM. So I made a really dumb Asteroids clone with cats in it, using Unity. Is it a good game? Maybe. Does it make me laugh whenever I play it? Yes. You should give it a try for the soundtrack alone.
Impressionable has progressed a little, but without much to show for it yet. I’ve rewritten it in C/C++ after getting annoyed with Java’s memory management, and I’m still getting used to low-level programming. A problem I’ve had is the aimlessness of making an “engine” rather than a game, so I have a new plan now: Make a series of small games, aiming to take around a month each, which will gradually expand the engine’s features. For instance, the first game is going to be inspired by SimFarm, stripped down to the basics of placing fields, planting them, harvesting, and balancing a budget.
This past fortnight, I’ve been working on something different again! Specifically, on an update to Snowman Sumo, which I was in the process of selling to a games site until I saw the terms of the contract, which I disagreed with. So, it’s now somewhat in limbo. Compared to the playable version, there are new single-player and three-player modes; you play multiple rounds, with the winner the first snowman to reach a certain score; and I’ve given the UI a complete refresh. Because of the previous interest in the game, I’m intending to put it up for sponsorship on FGL, and see how that goes.
For the sake of 1GAM, I spent a couple of hours this week quickly putting together a memory game. It’s nothing much so far, but I have some plans for it. Nearly 3 years ago when I briefly attempted making 49 games (I made 1. 😉 ) the second was to be this memory game. Now, I’ve never liked it as a game, so inspired a bit by Pongs, I thought-up 39 variations on it to make it more interesting… and then never actually made the thing! I was easily distracted, and arguably still am, but more so back then. I’d still like to make it, so maybe I will now that I’ve made a small start.
Edit: Turns out that all I needed to do was update my snõwkit install and it all works, huzzah!
Spacelunky came from my admiration of Spelunky, and the fact I’ve not really made a platformer before. So at the beginning of the month I outlined my plans for what I thought was ambitious for my 1-week time limit, but felt I’d be able to complete a decent chunk of it. However… I barely finished anything. It feels like a 48-hour game jam’s worth of work.
What went well
Let’s start with the good! I tried to put into practice what Casey Muratori calls “compression-oriented programming“, where you don’t design the code in advance, but write it as simply as possible, and see what structure naturally emerges. The result is that I’ve written much less code than I normally would, but with the same effects. It’s quite liberating, but does take some practice.
I wrote music! It’s mutated a little as I converted it from in-my-head to on-the-computer, so it doesn’t really feel appropriate to the game, but it’s not actually painful for me to listen to, so I’m making progress from my previous attempts. Still very rough though, I hope to be much better by December.
I’m also pleased with the art. OK, the tiles are a bit horrible, but whereas I usually don’t animate things, this time I put some effort into doing so. The player and aliens have walk and death animations which I’m really pleased with.
Finally, and this will make more sense in a minute, I kept going, and made sure I had a playable game now, even if it’s not a very good one. I was really worried about meeting the deadline, and nearly just gave up on the whole thing, but I’m glad I finished something.
What went poorly
The first problem was over-scoping: the game design was too big. I knew this before I started, and hoped that as most of the design was optional, it wouldn’t be a problem. It wouldn’t have been as much of a problem as it was if it wasn’t for…
Having a terrible week! Many of you will be aware that I suffer from depression, and this week was not a good week. I don’t know why, but I just felt rubbish. I would sit down, intending to work, and just stare at the code with no idea of what I was doing. Not great.
I’m not at all happy with the generated levels. The algorithm I think is fine: it creates a 5×5 array of chunks, with connections between them, then slots in a pre-defined tile layout that matches the connections. (e.g. a chunk connects up, down and left, so it finds a layout for it with those connections.) The problem is the levels are dull and repetitive. Partly this is from the lack of available things to put in them, but also because of a poor decision I made early on that the layouts should be 10×10. This is much too small to fit anything interesting in, once the appropriate corridors are added.
What I would do differently
Definitely next time I will shrink the scope of the game significantly. In February I’ll aim for the sort of game I would attempt for Ludum Dare, and see how that goes. I’ll try to look after myself better and hopefully avoid feeling so low.
Anyway, if you want to check it out you can do so on Itch.io. It’s a free download, but does require Java.
The Ludum Dare 31 results are in, and Snowman Sumo has the best ratings I’ve ever had in all but two categories! I even managed to creep into 63rd place in the humour category. I’ve made a little graph of all my results, embedded below:
This is my most polished jam game to date, and I’m really happy with it. You roll around, picking up snow to increase your size, then knock the other player’s snowman into the water. I won’t know how well other people liked it until a couple of weeks’ time when the voting period ends, but there are a couple of things I thin k went particularly well.
Firstly, using my voice for sound effects and music was much quicker than doing it “properly”, and hopefully makes it funnier. Every LD, I make the mistake of jumping into a music program that I haven’t tried to use since the last jam, and inevitably get confused and waste time, before giving up. Going a cappella is much simpler for me, and next time I’d like to do something more interesting with the music.
Second, I used Inkscape to draw the game logo and other text. Usually I scrawl something in GIMP, which generally looks horrible. I’m not hugely comfortable with Inkscape, but it’s so much easier to get some text that looks nice, with a gradient and outline. Makes things look much smarter.
I cheated a little with the 3D models… I’ve tried to use Blender and Milkshape before, and failed miserably to get anything usable. So, I ended-up constructing the land, water and snowmen out of Unity’s prefabs, and texturing them with materials. This worked better than I’d expected, but I really need to spend some time learning to create models properly before I attempt something 3D again. I happened to get lucky with a game that didn’t need anything complicated.
Making such a simple game meant I had a lot of time for polish, and to explore Unity features I wasn’t familiar with. SS has particles, sound effects, physics, the input system, and even a shader for the water, none of which I’d tried before.
No More Games!
With regular game bundles and dramatic sales, it’s easy to build-up a backlog of games you’ll never play. I think this is even worse when you develop games, as you get exposed to a lot more of them. Mid-November I decided enough was enough, and it was silly to keep spending money on games I’ll never get around to, so I decided not to buy any more for the rest of the year, regardless of any sales. I’ve now decided to continue this for all of 2015. This is partly because I’m going to spend the money I would spend on games on a new graphics card to replace my ageing one, but I think it’s generally a good thing to try. It’ll force me to finally play some things I have been meaning to for years. Let me know if you’re going to try this yourself,I think it would be fun to all do so together!
This week has not been a good week for getting things done.
Monday was decent enough – I finished the import/export quote-items feature for Quick Quote, felt pretty happy about that. That afternoon I began on the ‘About’ screen that QQ has been lacking all this time, both to point people to my site/other apps, and to properly display the open-source licenses that I should have been displaying all along, but didn’t realise at the time.
Tuesday though, I felt really off and emotional and weird, and later realised it’s because I was coming down with a horrible cold. Yay. So the rest of this week, I’ve felt rotten and slept poorly, which isn’t conducive to programming of any sort. It’s starting to clear-up now, and there’s still some time left before #PROCJAM ends, but I’m fully in bum-around-feeling-sorry-for-myself mode at this point.
So, no actual game-dev to speak of, but I still have some things I’d like to write about. Firstly, TRI was finally released last month, and I’ve had the chance to play it a bit. It’s excellent. I’d played parts of it a few times over the course of its development, and the improvements I could see from about 6 months ago got me thinking – maybe continuing to polish a game for months when it’s already “done” is hugely important to its success. There’s certainly the temptation when you’re near the end of a months- or years-long project to release it and move on as quickly as possible. Development follows a curve a bit like this:
(“Game quality” is a vague measure of how good the game is, how much it appeals to players, etc.) To start with, you make a lot of visible progress with a small amount of work, but as time goes on you get less and less improvement based on the time you put in. Assuming that your living costs are the same week-by-week, the tiny improvements near the end are pretty expensive, and this create a balancing act: how early do you stop development? If you spend too long on it, you’re wasting time that could be better spent on a new project. But throw it out too early and the low quality will attract a much smaller audience, or none at all. There’s even the issue of “will anyone buy this game at all?” Perhaps it’s safer to test the waters with a small, rough prototype rather than diving into a long development cycle.
What I’m beginning to think, though, is that a longer development is more likely to produce a game that is a success. With the huge number of games being released now, there’s more of a need to stand out, and putting more time in helps to separate your game from the mediocre. To graph it, I think it’s something like this:
My point being that sales aren’t linear, but a more polished game will get drastically more sales by standing out from the crowds on stores. While an extra few months on a game might make it only 5% better, that could still make a big difference in how successful it is. Admittedly, spending that time in this way is still a potential risk if it doesn’t pay off. I’m still learning to balance my development time.
Of course, I don’t have a lot of experience, and I’m basing this on impressions of how other people’s games are doing, and there are no guarantees in game development. I’d love to hear if people have evidence in favour of this idea or against it.
Starting today, and lasting for 9 days, is #PROCJAM 2014, a game/software/whatever-jam around “making things that make things”. Procedural generation is something that fascinates me, and a game project I’m planning would rely heavily on generating buildings so that I don’t have to spend forever creating them myself. So, I’ll be endeavouring to write a building generator in Unity. Previously, I wrote a basic system that generates a generic house, but it’s very limited, with no variation:
Wheee, this is fun! 😀 You can now tweak the size, roof angle, and roof overhang. Still veeeery simple, though. http://t.co/JlwMg03P4A
What I’ll be attempting to do is introduce variety through randomness, and creating more interesting buildings with multiple floors, more complex footprints, little details such as windows. And not just houses, but shops, factories, and tower blocks as well. Hopefully I’ll have something cool to show off over the week.
The first update to F!shing since release, version 1.4 introduces combo-multipliers, and makes the game more varied by randomising more things. Plus, the game now has a permanent lower price! As always, you can pick the game up from the F!shing website, or the widget below!
A full change-list is available at the bottom of this post, but first, let’s get technical!
In game development, sometimes things don’t work out. Maybe a game mechanic isn’t fun, maybe an effect looks bad, or maybe you just don’t have the budget and have to cut things. In the case of F!shing, I can’t get disco mode to run smoothly enough on Android – I had hoped that it was only on devices with high-res screens, but it appears to be bad on everything. I’m not comfortable putting a game out there that runs so slowly it’s unplayable. However, I do want to release all of the other improvements and bug fixes I’ve made to the game over the past few weeks. Even without disco mode, it’s a much better game now than it was. So, version 1.4 will be releasing soon but without the ‘night’ and ‘disco’ modes enabled.
If all goes well, I’ll come back to F!shing in a month or so and get disco mode fast enough that I’m happy to release it. Hopefully taking a break from the project will enable me to find a solution when I do return to it. In the mean time, I’ll be experimenting with snõwkit for a week, and then making some improvements to Quick Quote. Busy busy busy!
So, what have I been doing the last couple of weeks? Firstly, the disco modifier!
The spotlights sway back and forth, the colours cycle, and the little dot lights spin around. (I want to show a gif of it, but the file-size is enormous. :() My current plan is to have it be pretty rare, but once you’ve seen it once,it unlocks as a secret option on the main menu, so you can enjoy it in all its glory whenever you want!
I had to learn a bunch of new shader tricks to get any of this to work. I was pretty happy, and then I tried it out on my Nexus 10 tablet and it ran at 11 frames per second, which is pants. Once I’d added an FPS counter, I discovered that even with only the subtle water ripples it was running at 55FPS, and the night shader at 33. So, a lot of time was spent trying to make these things faster. The end result is that with just the ripply water, 56FPS; the night shader at 48; and the disco shader at 20. (Disco reached 24, but then I added the player-light-circle because it was hard to see where you were, which dropped it to 20.) Optimising shaders was… interesting, as I barely know enough to make them work at all, and shader performance is almost a dark art. Simple things like using if statements to avoid doing work can be slower than just doing the unnecessary calculations. Someone explained somewhere that operations don’t really have a time cost: if a sin() takes 4 cycles, and a matrix operation takes 4 cycles, sometimes both together also take 4 cycles. So, my method was almost entirely trial and error.
You can save a bunch of time by doing calculations in the vertex rather than fragment shader, but the interpolation it does isn’t always what you want. For example, the weird blue lines on the water in the above screenshot are supposed to follow the spotlights, but the in-between values it calculates are wonky. You can see where the background is composed on two triangles from where the sharp bend is. In the end, I decided to leave it like this as, after all, it’s supposed to be a disco so goofy lighting is appropriate.
20 frames per second is not really good enough. I wouldn’t be happy unless the entire game always ran at 60. But, it seems the high-resolution on my tablet combined with mobile GPUs not being great might mean it’s impossible. I’m not trying to make excuses – I genuinely don’t know whether it can be any faster, or whether the hardware prevents that. On my desktop PC, with a graphics card that was OK in 2007, it’s fine. I’d love to be able to make it better, but ultimately I have to ship the game, and it’s not the end of the world. The 48/55 fps aren’t noticeable unless you’re looking, and 20 isn’t as awful as it sounds. I’ll have to see how it performs on other hardware.
I had one last idea for speeding the game up: using the depth buffer. To explain briefly, OpenGL can store a number for each pixel on screen, representing how near what’s drawn on that pixel is to the camera. Then, it only draws pixels that are closer than what’s already drawn. This way, you can avoid drawing on the same pixels over and over, wasting time. Now, currently the game draws back-to-front: first a fat blue rectangle is drawn, then fish, then the water’s surface, then the ground, then the player and plants, and finally the score and pause menu and such. Using the above screenshot as an example, this means that some of the pixels are drawn five times: behind the word “Score” is a tree, some grass, the water surface, and the blue background, and each of these is drawn onto those pixels. With the depth buffer, I could instead draw front-to-back, with “Score” being drawn first, and then skipping the tree, grass, etc. as they’re behind. (Not exactly, as semi-transparent things need to be drawn after what’s seen through them, but it would definitely cut out a lot of wasted work.)
So, why didn’t I do this? Because I discovered that the 2d-rendering parts of LibGDX are incompatible with the 3d rendering parts, so that I couldn’t swap things out, but would have to rewrite a significant portion of the library before I would know if this rewrite would make any difference. Unfortunately, I can’t devote that amount of time to this. Especially as this multi-week patch was supposed to be a minor fix to the Lake of the Day being stuck on a single game mode! I’m susceptible to feature creep, but not quite to that extent.
So, current plans: I have a few things left to clear-up before the next F!shing release, and then onto all the other projects I’m supposed to be doing! Some improvements to Quick Quote Professional are planned, to help with managing large numbers of quotable items, and multiple devices. Then, the business app that I barely started before F!shing distracted me. Once that’s done, I’m not sure, as I’ll probably have changed my mind multiple times before I get to it.
I’m also in the process of writing-up my month’s worth of shader experiences, things learnt and mistakes made. Not because I’m an expert, because I’m not, but because it’s such a confusing topic and I’d like to help other people be less confused. I’d been wanting to try writing shaders for ages before I finally dived in.