On a whim, I’ve spent the last week getting Snowman Sumo back into shape and playable again. It’s one of my favourite games I’ve made, so it felt a bit wrong that it’s been impossible to play it since Unity‘s browser plugin stopped working several years ago. Unity definitely is not my strong point, so it’s been interesting learning how it works again. But it’s back, and better than ever!
Unity has changed a lot in the 5 years since I last touched this project, but surprisingly the automatic converter worked beautifully, and all I had to do is tick one box in the editor and it was playable! I did spend longer than that on it though, mostly making the code less terrible. (Game jam code is not good code.) Also a few animations were done entirely in code, and now I’ve replaced them with proper animation assets, which work so much better.
I don’t remember exactly what was in the released game before, because I did modify it after the original game jam but I think I didn’t release those. (I had a sponsorship offer at the time, which I didn’t go through with.) So here’s what’s new compared to the original:
Singleplayer mode against the computer (which manages to beat me quite often)
Up to 3-player local multiplayer on the same keyboard
Games can last several rounds, up to first-to-five-points
A win screen when the game ends
More animations and polish
I’d like to try and get F!shing to work again too if I can, but that’s a whole other thing! We’ll see.
Another Ludum Dare, another little game! This time, by a coincidence, there were two top-voted themes, ‘Growing’ and ‘Two Button Controls’. I went with ‘Growing’, as I’ve wanted an excuse to make a little gardening game for a while now. And so, I present to you the unimaginatively-named Ecosystem.
Ecosystem is a sandbox where you plant seeds and then watch them thrive or die out. Sculpt your little patch of dirt, water it, and see what happens. As your garden grows, it’ll develop its own ambient soundtrack.
A lot of it is very rough. The audio gets messy when there’s a lot going on. There are bugs with how things float on water. It can’t handle underground sections very well. There are only three plant types. But it feels like a good starting point – I say this a lot, but I really think this game has a lot of potential as a background game that you leave running and just tinker with occasionally.
This game also is a bit of a personal milestone. It’s my tenth Ludum Dare entry, and I’ve made a game every month this year. Next year, I’m definitely going to work on fewer, bigger projects, but it’s nice to have done One Game a Month properly once.
Last week was ProcJam 2015, and as I hinted earlier, I took last month’s Pool game and added procedural generated rules to it! The theory is that it’ll invent new and exciting billiards games, but in practice it mostly just makes a mess. I’ve called it B!lliards and you can play it from the comfort of your web browser for free. A bit of a post-mortem after the break.
This past week I’ve made a little 2-player version of Blackball Pool in Unity. Check it out!
The story behind this is that a few weeks ago, I had the idea of making a crazy golf game where players build their own courses out of clip-together parts and then share them with other players. As much as I’d like to make that right now, it’s way beyond my ability, so I put it to one side. Shortly after, I had another idea: a procedurally generated billiards game, where the table shape and the rules could be invented by the computer or specified by the player. I made a start on it, but quickly realised I needed to know 3D modelling before I could do it justice. I’ll be doing a course on that soon so I’ll finally be able to make 3D games using more than just Unity prefabs. Hooray!
Which brings us to this week! I’d just finished the part of App 2 that I was working on, and wanted to devote this week to 1GAM, so for a lack of any other ideas I put together a basic 2D pool game. No AI, no audio, and it’s no pretty, but it’s a start. ProcJam 2015 is coming up so I might use that to experiment with rules generation.
What happens when I’m away for a fortnight with my low-spec laptop and haven’t made a game for 1GAM? Turns out it’s this:
Flibbertigibbet (I couldn’t think of an actually good name, so used favourite word instead.) is a Minecraft-inspired roguelike. You mine, you build, and you craft — all from the comfort of your 80×25 character, 8-colour terminal window. It’s nowhere near as complete as I’d hoped, but I’ll definitely be tinkering with it in the future. It’s just so fun to work on!
Part of what’s made it so fun is that it’s been almost entirely my own code. All I’m using library-wise is PDCurses for terminal stuff, and some simplex noise code I found online because I was in a hurry. Otherwise, I’ve been free to write it in whatever weird way I want! 😀 Whether this results in code that is actually good remains to be seen, but it’s lovely not having to conform to someone else’s idea of what makes sense.
It’s pretty limited right now though. First on the list for improvements would be to replace the terminal with a graphical window that I can fully control. Mostly I’d like more colours, and to show more on screen at once – 80×25 is pretty cramped. I never got around to making the world keep generating as you move around either, and the world it does generate isn’t that interesting. There’s not even any combat or death yet, so it’s hardly even a roguelike! I’ve got a big list with a bunch of other things, so this is only the beginning for my terribly-named ASCII adventure.
I’m far from an expert on game jams, but I thought I’d do a post-mortem to share my experiences:
What went well
I spent some time before the jam considering each of the 20 possible themes and writing down ideas for them. I do this every LD if I have time – it’s a fun game-design exercise, but also means that I can get started right away and not stress about having no ideas. (Except when the winning theme is one I had no ideas for, which has happened before.)
I recognised that my idea was too big, and simplified it before I began. The biggest change was reducing the game down to a single screen. Had I divided things up into multiple windows or screens that you switched between, it would have taken longer to make and been more confusing to play.
I got things working quickly. The game was essentially complete by the end of Saturday, leaving Sunday for balance and polish. Much of the art was still rough stick-figures, and the balance was off, but the game fundamentally worked, and I could have submitted it then. I’ve found this is really important for motivation – I’ve given up in previous game jams when it’s Saturday evening and my game isn’t coming together (even though I probably could have completed it).
I prioritised what needed doing. I can’t remember where I got this from, but I always make a TODO list with a ‘Need’ column and a ‘Want’ column. (Sometimes also a ‘Like’ column for really unnecessary but cool ideas.) Working through the Need list first really helps me to focus. Even after I’d simplified the game as I mentioned above, there were still big features that didn’t make it in – if I’d not prioritised the really important tasks, I would not have produced a finished game.
I used familiar tools. I know it’s not fashionable to use Java, but I’m now familiar enough with it and the library I use (libGDX) that I can work quickly without spending a lot of time reading documentation. As for software tools – IntelliJ, GIMP, and to a lesser extent FL Studio – I’ve used enough that I could concentrate on making the game, not learning to use them.
I actually made some music! I still don’t know what I’m doing music-wise, but spent half an hour or so cobbling-together some notes in a reasonable-sounding order. It’s something I’m trying to get better at, didn’t take that much time, and greatly improves the overall feel of the game. Certainly better than silence.
What went wrong
No sound effects. I find sound effects quite difficult to do, and so kept putting off recording them. There’s also the issue of how to make them work in a game where you can be producing several monsters per second – how can I have sound effects without them overlapping and just becoming a horrible mess of distortion? So I made excuses, and audio was the lowest rating.
Last-minute checking. The last thing I did to the game was add detail to the background, and in doing so I made the text really difficult to read in some places. If I’d paid more attention it could have been clearer.
Odd balance. The monsters and human workers are almost equally effective in terms of work-per-cost, so the choice between them is a bit meaningless. The public outrage also scales in a way I’m not fully happy with – to decrease it costs money, which means selling monsters, but selling monsters increases it – but at the time I was just happy that the game was winnable but still challenging. If I was to spend more time developing it, I’d definitely need to reconsider how everything interacts.
No animations. Entirely a time issue. I wanted to have animate the departments that are working, for visual feedback and to make things more lively. Ran out of time, which means that the Jacob’s Ladder in the top-right looks like unfinished knitting.
Last night I submitted my Ludum Dare 33 entry, Frankenstein’s Monsters, Inc. which besides being a bit of a mouthful, is a fairly minimal management game about running a monster-building business. The theme was ‘You Are the Monster’, and I think you’ll agree that digging-up bodies and sewing them together is pretty monstrous. I say it’s minimal because your controls are only to drag monsters and job applicants to assign them to a department, drag monsters to sell them, and click on buttons to spend money.
It was a lot of fun to work on! I’m happy with how it’s turned-out too – the only thing I didn’t get time for is more art, especially some animations for when each department is working, and more variety for monsters. It started out overambitious, but I managed to simplify the design a lot before I started. I even had time to do some music:
As with any jam game, there are things I’d like to add to it. My original idea gave the monsters statistics which affect how much money they’re worth and how effective they are at different jobs. In that way, you’d be able to gradually level-up your production quality as well as its speed. You’d have a PR department which would slowly reduce outrage over time, which would allow outrage to ramp up without being unbalanced. I also have some ideas about selling monsters – that they’d be sold automatically but only when there was demand, and you would increase demand by assigning workers to a marketing/sales department. I’d like to change how human workers behave too – at the moment, they’re 4 times as effective as monsters and 4 times the cost, so there’s no reason not to hire them as soon as they’re available. So, two different directions it could go in, really! Either more of an “idle game” that runs by itself, or a more detailed business simulation.
The Ludum Dare page is here, or you can go play it here.
The past week and a half, between other things, I’ve made a silly little browser game for the 4th GameBoy Jam. It’s a 3D maze game about healthy eating, called 5-A-Day Fun Maze, which is kind of a joke about terrible educational games, and kind of just a terrible game, but there you go.
This is a good example of what happens when I don’t have a plan. I wanted to do a ray-tracer (Old-school 3D rendering where you fire an imaginary ray through the screen until it hits a wall, then draw a vertical line there based on the distance. It’s what early 3D games used.) so I did so, and then realised I had no idea what the game would be. I arbitrarily drew a strawberry so I could have entities as well as walls, still had no idea, and so it became about collecting fruit. The whole healthy-eating thing grew from there.
The game itself is just a maze, so not that interesting. It’s a ‘perfect maze’ in that there are no loops, so you can follow the left (or right) wall and eventually find all the fruit without difficulty. There is a compass in the corner to help you orient yourself if you do get lost though.
One thing I do quite like is the eating animation: simple, but it works! It also begs the question “Why are we looking out of the player’s mouth?” to which the answer is “Because.”
This weekend is going to be Ludum Dare 33! I hope to take part, but there’s less pressure now that I already have a game for August. Been feeling pretty burnt-out lately, so we’ll see.
Developing for Android, you need to provide a lot of copies of each image you use, for mdpi, hdpi, xhdpi, xxhdpi, and even xxxhdpi screens – possibly even more in the future! Even if you create your images as vectors rather than hand-pixelling them, it’s still time-consuming to get Inkscape, a free vector drawing application, to export the 5 or so different bitmap files. Fortunately, Inkscape has some automation features built-in – for example, you can tell it to generate a PNG from an SVG via the command line:
inkscape source.svg -w 32 -h 32 -e dest.png
I’ve created a little Windows batch file that will take all the SVG files in a directory, and then create all the various sizes of PNG from it and put them in the right places. It’s available here on GitHub. It’s Windows-only, and expects a certain directory structure, but it should work if you’re using the default project setup from IntelliJ or Android Studio. If not, you should be able to tweak it.
One thing to note is that Inkscape does take a second or so to do each export, and that time unfortunately adds-up when you’re doing 5 exports per file, on potentially dozens of files. If I get around to creating a Gradle script that only exports the SVGs that have changed, I’ll make sure to post that as well.
A couple of days ago I released a free little typing web game called Mavis Bacon Teaches Typing. Give it a try – it only takes a minute or two to play.
I’m very pleased with how this turned out – much happier than I have been with a game for a while, so that’s built up my confidence a bit. I did hit a wall as usual, and almost released it without the food flying everywhere, but I’m really glad that I did, as it makes a huge difference to the feel of the game. I guess the lesson there is that silly little details and effects matter a lot. There’s a great talk about this called Juice It or Lose It, which I highly recommend to anyone making a game – it’s embedded below.
Meanwhile, I’ve mostly rewritten the rendering code for Impressionable to use OpenGL. Quite a lot of work, but it’ll be much faster, and allow things like zooming in and out, and special effects via shaders at some point. It’ll also mean way less fuss if and when I start working in 3D.