LD31 was my best yet!

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:

There aren’t really any patterns, so who knows how well I’ll do next time, but this is a lovely way to end the year. πŸ™‚

2014 in Review

So, we’re coming to the end of 2014, which is a good opportunity to look back at the past year, and forward to the next one.

I’m trying not to let this post be too down, but looking back, I can’t help but feel disappointed about this year. I’ve worked hard, and improved at motivating myself and being more productive, but I’ve actually released very little, and with similarly little success.

The biggest thing this year was releasing my first commercial game, F!shing. I learned a lot from it, but also made some really dumb mistakes. At some point I might do a full post-mortem on it, but a key things is that when it didn’t sell, I kept obsessively working on it, hoping that the next update would convince people to buy it. I still feel that way! I still think that it would do really well as a local multiplayer game, but I really need to move on.

I’ve also found myself working on Quick Quote some more, even though I’d told myself before (multiple times) that it was done. It’s done pretty well for my very low standards – 149 current users counting both free and paid, out of over 550 total, and those numbers do continue to go up. I’m hoping that this next, and absolute last, feature update will help convert some more free users to paying customers, but even if it makes no difference, I’ll be able to say it’s the best I can do. In some ways that’s more important than the money.

With both of these, I’ve struggled to move on when they were unsuccessful. I feel like I can’t have all the work I put into them go to waste, even though I’m wasting more time continuing on them. I should hardly expect my first attempts to be well received, but I keep telling myself that a little more effort and they’ll take off.

In contrast, I’ve been far more pleased with the handful of jam games I’ve made this year. Procedural Death Racing is very rough, and I doubt I’ll ever expand on it, but I stretched myself with it. SWAN QWOP is pretty terrible, but it kind of works! OK, these first two are bad examples. K!cking was fun to work on and turned-out alright, even though I didn’t manage what I was hoping. Lorries In SPAAAAACE! made me realise how good Unity is for prototyping, and it was pretty well received. Snowman Sumo, though, feels really polished to me. There are a couple of things that would need adjusting for a proper release – such as some proper music – but I’m so pleased with it. Ludum Dare judging finishes at the end of this week, so I’ll soon know how well it does, but the feedback I’ve had for it has been really positive. A nice thing to end the year on!

So, perhaps my goal for 2015 should be to make more, smaller things. Simple things, self-contained, and if they don’t work I force myself to move on. I attempted One Game A Month before, and it didn’t really work for me, but maybe I need to try it again, or something else along those lines. Maybe even devote a day a week to side projects. I’ll have a good think about it. πŸ™‚ In the mean time, I’ll probably put out a small K!cking update, mostly to fix some bugs that I never got around to, but maybe some polish too.

I also need to sort this website out. It looks a little horrendous, and I’ve not kept things like the games page updated. I was really pleased with how the Quick Quote site turned-out, so hopefully I’ll have something better here soon.

Game Design Lessons: Paradox’s Limits

Game Design Lessons is an irregular series of little things I’ve noticed in games, which I think are worth sharing.

For this first article, let’s talk about limits in Paradox Development Studio’s grand strategy games. A lot of games treats limits as solid barriers. For example, you might have a cap on the number of units you can have – perhaps with ways to raise the cap, but you are unable to ever exceed it. In Paradox’s strategy games though, this isn’t the case, and I think it makes things a lot more interesting.

For example, in Europa Universalis IV, there are a whole host of limitations: you can only have strong relations with so many nations at once, you can only have so many units of soldiers, you can only declare war if you have good reason and without a truce. Except… all of these limits can be broken! Breaking each of these limits has negative consequences: each diplomatic relation you have over your limit costs you one diplomatic point per month, which could otherwise be spent on improving your technology or on a variety of other things; having too many soldiers costs you far more money to maintain them; declaring war without a reason, or during a truce, will destabilise your nation, opening you up for rebellions and a variety of other troubles.

Each one of these trade-offs (and there are many others) is useful in some circumstances. They give the player more interesting choices to make, and more options when things are tough. Whereas with a hard unit cap the best option is always to have the maximum number of units, with a soft cap the player has to weigh-up the benefits of exceeding it versus the penalties of doing so.

Dev Log 20th of December 2014

The Quick Quote reorganisation work continues. In fact, I’ve just about finished it- a couple of minor things that stopped working that need to be reimplemented, then test the upgrade system until I’m confident it’s stable. Doing this sort of conversion is a little nerve-wracking as it has the potential to completely erase the user’s existing data if it goes wrong. It also looks like it will have taken 5 times the estimated time, which is pretty terrible. I’m still working on estimating though, so I’m not going to beat myself up about it.

One thing that makes all this conversion worth it is that I’m having to learn all the database code that I’ll need to use in my next app. Sometimes mistakes are OK, if only because you know not to make them in the future! I’m no longer convinced this update will be done this year, but it should be out before the end of January.

I think I’m going to need a game side-project soon, I’m getting itchy!

Last Saturday I had a new graphics card arrive, a Radeon R9 290, which is enormous and shiny and will hopefully end the various crashes and visual glitches I was getting. My old card had 512MB of RAM, which I think was causing the problems, along with it being old enough that it’s not supported properly by Windows 8, and I had to find some fairly old drivers to even get it to work at all. The new one has 4GB, and runs anything I’ve thrown at it at maximum settings with over 60fps, so it should last me a long time. πŸ™‚ Unfortunately, Firefox was still having the same problems as before, so I’ve swapped to using the Nightly build because it actually has a 64-bit version available. It seems… a bit flaky, but as it hasn’t had any catastrophic failures yet it’s still an improvement. If all else fails, I’ll switch back to Chrome, but I do like Firefox.

There are a couple of little articles I’m planning on writing, examining little things in games. The first, about limits in Paradox Development Studio’s grand strategy games will be out in the middle of this week. I had been working on a longer article about shaders, but it got a bit long and meandering and muddled, and was going to take a forever to finish. So, shorter articles and dev logs until I can figure-out how to write an outline and then stick to it. πŸ˜‰

No More Games! Also, Here, Have Another Game

So, two things to talk about today. Neither of which is Quick Quote, because I’ve not had much time to work on it this week.

As I previously mentioned, last weekend I created a game for Ludum Dare 31. It’s called Snowman Sumo, and is… a game about sumo-wrestling snowmen. My game names are nothing if not self-explanatory.

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!

Dev Log 5th of December 2014

This week, it was back to work on Quick Quote. There are a bunch of improvements I want to make with how quotes are handled, such as adding customer details, and marking them as an invoice. On Monday, I added the ability to attach a note to a quote, which appears when the quote is sent to the customer. However, when starting on the other features, I ran into difficulties with the way quotes are stored internally. It’s caused me problems in the past, and I’ve finally decided to spend time reorganising things.

Technical Debt

“Technical Debt” is a measure of how awkward the code is to work with. When developing software, often you don’t fully understand a problem until you’ve already solved it once. At that point, the solution works so you move on, but it might be overly complicated, or slow, or less versatile than it should be. As this debt builds-up, development takes longer and certain tasks become impossible. Paying-off this debt takes time, but makes things easier in the long run.

In this case, when I began on Quick Quote, in my inexperience I decided to store quotes as XML files, rather than in a database, as it would be simpler. Up to a point, this has worked well – I’ve been able to gradually add new things to the quote files in a backwards-compatible way without having to do potentially messy database changes. The downside is that files have limited metadata – they have a name, and the last time they were edited, and not a lot else. For the saved-quote list to display or sort by anything else, such as whether the quote is an invoice, it would need to read in each file and process it, which could be very slow if there were a lot of quotes. This is the main reason I wanted to switch to a database, the other being that Android’s data-synchronisation system is poorly suited to working with files, so I’ll be in a better position to implement that in the future.

The biggest hurdle for this change is that everything needs to be converted the first time that Quick Quote launches, and that’s what I’ve spent the rest of this week on. It’s been slow work, as there are lots of things I’ve not done before, but it’ll all be useful for when I make future apps.

Ludum Dare

This weekend is Ludum Dare 31! LD is an online event where people create a game from scratch over a weekend. I’m hoping to participate, in which case I’ll have a new game for you by Monday. I’m hoping that the theme will be ‘Deep Space’, so I can make a rocketry game, but we’ll see.

New Quick Quote Website

For a while now, Quick Quote‘s web page has been essentially just a glorified blog post, on my very orange website here. So, this week I gave it a proper home: http://samatkins.co.uk/quick-quote/

I’m really pleased with how it’s turned-out. I’ve never considered myself to be much good at design, but I’ve had positive feedback about it. It’s also responsive, unlike the website I did for F!shing – as a mobile app, it was important that it would work well on smartphones, even more so than on desktop browsers.

The one thing that really sticks-out now is the trailer, which is quite old now and only demonstrates the free version’s features. I’ll be recording a new one after version 1.5 ships, sometime around the end of the year.

Quick Quote 1.4 Released

Quick Quote version 1.4 has now been submitted to Google Play, and will become available some time over the next 24 hours. Version 1.4 brings a couple of new features, and some general improvements. So, what’s new?

Both Free and Professional now have an About screen, which links to this site and the various open-source libraries used by Quick Quote. This isn’t a big thing, but it’s good to have.

All the forms have been updated to use proper data validation and error messages. What this means is that if you’ve entered something invalid, it will tell you and won’t close until you fix it. Previously, forms would just close, pop an error message up, and just guess as to what the value should be, which was a pretty bad experience. I’m glad to have fixed it. If you’re a dev and curious, this article gives a decent overview of Android form validation, and this StackOverflow answer explains how to stop dialogs closing, because for some strange reason there’s no simple way to do so.

For Quick Quote Professional users, there are two new features about making things easier when there are a lot of quotable items. Firstly, you can now arrange items into categories. There’s a new category management screen, available from the quote item management screen. Items are grouped by category in the ‘add item’ dialog of the calculator, which can make finding things much faster. Search is still available there, and works for both category and item names. The second new feature is you can now import and export quote items and categories to a file, from the menu in the item management screen. Previously, users with more than one device, such as a business with multiple employees using Quick Quote, would have had to enter the quotable items once for each device. Now, they can enter them once, export the file, copy it to another device, and then import them again.

Next, I’m going to be jumping into development of version 1.5. This will be focused on improving the exported quotes, with customer details, quote numbers, notes, and being able to mark them as invoices or receipts or anything you like.

Quick Quote is a time-saving Android app for creating quotes and estimates while on the job. Feel free to try out the free version for as long as you want, with no limitations.

Dev Log 15th of November 2014

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.

PROCJAM: Procedural Building Generation

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:

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.