It's out there! We put up Key, Shovel, Treasure on itch.io, and the pirates have been combing through many an archipelago since then :). So it's time for some postmortem stuff. I don't intend to write a full (and structured) postmortem here. It'll be more about what I learned and other noteworthy things from the process of creating KST.
But first: if you haven't given KST a try, be sure to do so! It's free, easy to play and you can get it quickly through the itch widget below:
But first: if you haven't given KST a try, be sure to do so! It's free, easy to play and you can get it quickly through the itch widget below:
And that's the first thing I'd like to talk about. My user experience with itch.io was great. Things are easy to set up, easy to preview and everything works smoothly. It's clear that itch.io is a great site and does a great service to the indie game community!
Which brings me to marketing. It turned out to be surprisingly difficult to find outlets that I deemed likely to want to cover KST. It's basically a digital board game and most websites and Youtube channels that (also) cater to kids are focused on rather more action-y games.
Having said that, Vince from DadsGamingAddiction, who also made an oft-watched Powargrid series last year, was kind enough to make a short KST video. Check it out here:
Having said that, Vince from DadsGamingAddiction, who also made an oft-watched Powargrid series last year, was kind enough to make a short KST video. Check it out here:
Cool eh? :) It's always amazing to see someone play a game you've created, especially if they end up enjoying it.
Back to more postmortem-y territory. The big marketing lesson for me from this project is that I'm not good at making lots of noise about a game launch. For instance, I found it difficult to tweet a lot about KST being available (more difficult than tweeting about a blog post like this one). Somehow, I can't get the silly idea out of my head that I'm bothering people with this, even though it's a free game.
And that's a shame, since we did get quite a few visitors here on our blog in the run-up to the launch. The same goes for our Thunderclap campaign, which failed miserably. I had a hard time asking for people's help with that too, which translated in way too little noise about that campaign, so we didn't make it (by far).
What to do about that? First off, I think I have to accept that I'm not good at making that marketing noise. So any (marketing) plan that specifies that I have to make a lot of noise should be re-thought :). Second, we could experiment with running ads, which is something we didn't do for KST (as it is a small, free game). But mostly, I think I'd like to try a strategy where we publish a game (on itch.io) that is in its infancy, but which already is fun to play. Since I don't mind pointing people at a blog post I've written about what we're doing, having a playable game up to which I can link from the post may be a good way to build up something of a following of people who like the game. That way we'd sort of trade the launch for gradual exposure (and we can still do a launch it when it's finished). There are some problems with this strategy, mainly that I can't promise anything about a timeline for when a game will be finished, but I think those can be mitigated.
We'll be sure to let you know if and when we decide to do that. At the end of this post, I'll put in a screenshot of the concept game we might try this with.
Back to more postmortem-y territory. The big marketing lesson for me from this project is that I'm not good at making lots of noise about a game launch. For instance, I found it difficult to tweet a lot about KST being available (more difficult than tweeting about a blog post like this one). Somehow, I can't get the silly idea out of my head that I'm bothering people with this, even though it's a free game.
And that's a shame, since we did get quite a few visitors here on our blog in the run-up to the launch. The same goes for our Thunderclap campaign, which failed miserably. I had a hard time asking for people's help with that too, which translated in way too little noise about that campaign, so we didn't make it (by far).
What to do about that? First off, I think I have to accept that I'm not good at making that marketing noise. So any (marketing) plan that specifies that I have to make a lot of noise should be re-thought :). Second, we could experiment with running ads, which is something we didn't do for KST (as it is a small, free game). But mostly, I think I'd like to try a strategy where we publish a game (on itch.io) that is in its infancy, but which already is fun to play. Since I don't mind pointing people at a blog post I've written about what we're doing, having a playable game up to which I can link from the post may be a good way to build up something of a following of people who like the game. That way we'd sort of trade the launch for gradual exposure (and we can still do a launch it when it's finished). There are some problems with this strategy, mainly that I can't promise anything about a timeline for when a game will be finished, but I think those can be mitigated.
We'll be sure to let you know if and when we decide to do that. At the end of this post, I'll put in a screenshot of the concept game we might try this with.
On to the visual side for the postmortem. As you can see in the images above, KST has gone through quite a number of visual changes since its first inception. But the general idea remained the same. The main thing I've learned in this regard is to constantly look for greater overall consistency. Before, I kind of understood that it's important for a game to look nice, but my mindset was one of 'functional is fine' and I considered myself semi-immune to graphics and UI.
I know better now. I've come to realize that while I really don't mind game graphics that are simple or even not very good, the overall consistency of said graphics is important to me. Also, I've found that looking for this consistency and spotting where it needs to be improved is a skill that can be trained. In KST, I changed a lot of things that I first thought were fine, like the font, the background (table), the menu backgrounds (parchments) and the border around the play field. Each of these added to the overall consistency and made the game feel more and more like a whole.
While there is still have much room for improvement in my visual creation skill set, I'm happy with how KST turned out. I'll certainly look to achieve the same sort of consistency in any new games we make. Luckily, Michiel also appreciates how important this is, and is better at spotting where improvements are needed than I am, so I'm confident that we'll be able to achieve that consistency.
I know better now. I've come to realize that while I really don't mind game graphics that are simple or even not very good, the overall consistency of said graphics is important to me. Also, I've found that looking for this consistency and spotting where it needs to be improved is a skill that can be trained. In KST, I changed a lot of things that I first thought were fine, like the font, the background (table), the menu backgrounds (parchments) and the border around the play field. Each of these added to the overall consistency and made the game feel more and more like a whole.
While there is still have much room for improvement in my visual creation skill set, I'm happy with how KST turned out. I'll certainly look to achieve the same sort of consistency in any new games we make. Luckily, Michiel also appreciates how important this is, and is better at spotting where improvements are needed than I am, so I'm confident that we'll be able to achieve that consistency.
On to the drawing / artsy part of the visuals. As you can see, the drawings for KST improved quite a bit in the second iteration :). I've written quite a bit about creating these visuals, so I'll stick to the higher-level observations here.
On the upside, in the course of creating the upgraded pictures I learned a lot about creating art assets (using paint.net). For instance, I developed more of an eye to what works and doesn't work, I got better at using all the tools available and I learned to look online for tutorials and plugins that help me to create the effects I'm looking for. Somehow, that last one is as easy to forget as it's obvious. For me at least :P.
On the downside, while the artwork is OK - it's both passable and serviceable - it's not outstanding. I'm quite sure that I can improve my art skills, and I'll surely keep working on them, but I wonder whether I should aim to be doing final artwork for our games. Getting it to 'merely' good just takes up too much of that most limited of resources: time.
to be clear, I don't think we should have commissioned artwork for a project like KST, especially since it was mostly a learning experience for me, but it's worth keeping in mind that what we buy if we buy the art is a lot more time to do other cool things. So for now, when creating art, I'll be focusing on becoming quicker at creating art that is good enough for a beta instead of focusing on creating artwork that is good enough for finished games.
On the upside, in the course of creating the upgraded pictures I learned a lot about creating art assets (using paint.net). For instance, I developed more of an eye to what works and doesn't work, I got better at using all the tools available and I learned to look online for tutorials and plugins that help me to create the effects I'm looking for. Somehow, that last one is as easy to forget as it's obvious. For me at least :P.
On the downside, while the artwork is OK - it's both passable and serviceable - it's not outstanding. I'm quite sure that I can improve my art skills, and I'll surely keep working on them, but I wonder whether I should aim to be doing final artwork for our games. Getting it to 'merely' good just takes up too much of that most limited of resources: time.
to be clear, I don't think we should have commissioned artwork for a project like KST, especially since it was mostly a learning experience for me, but it's worth keeping in mind that what we buy if we buy the art is a lot more time to do other cool things. So for now, when creating art, I'll be focusing on becoming quicker at creating art that is good enough for a beta instead of focusing on creating artwork that is good enough for finished games.
On to the user interface. It's always surprising how complex it is to create a good UI for a game (and probably for any piece of software, looking at my often frustrating experiences with custom built software in my day job). Deciding what the UI has to do and allow, and how that should be presented and enabled, is a complicated affair. Not the individual decisions, mind you, but the accumulation of small decisions which all affect one another. And this is especially true when things change over time.
For instance, when I first added a menu scene to KST (or Pirate Game, since it was still called by its working title then) I decided to just make the number of players a variable and be done with that. In hindsight, it might have been better to allow each player to be toggled on and off from their own line. On the other hand, this way it's nice and explicit, which has its advantages as well. And there you go: a simple decision immediately starts to get complicated :).
Related to the number of players are the player colours. If you play with two players you get to be red and blue. Green and yellow are added as players number three and four. Of course, it would have been nice to add more freedom to which colour you play with. But this also is a bit of a rabbit hole. Just adding a drop down menu for each player colour isn't enough, since you also have to block the colours that have already been taken. But the colours of inactive players probably shouldn't be blocked, but should change automatically if their colour is chosen by an active player. And this also means you need more than four colours to enable colour switching when you have four active players.
What I'm trying to say is not that these things can't be done, but that there are about a gazillion things like this and each one takes some time. And more time that you'd think beforehand because of all the interactions, dependencies and follow-up work. This accumulating complexity, added to the difficulty of creating an interface that makes (intuitive) sense is what makes UI design so time consuming.
So what are the lessons I learned? First off, what I've outlined above was driven home to me much more that during Powargrid development, since Michiel did much more UI work there than I did. I also realized that you have to put in the work. UI is obviously not something you can skip, but it's also not something you should do the bare minimum on. So, while working on the UI can sometimes feel like a chore, I'll be sure to keep this in mind.
Having said that, another thing I've learned is that investing time into getting to know the UI tools in Unity is most certainly worthwhile. There are many features that save time, make things look better and reduce the need for special casing. Getting familiar with layout groups, canvas scaling options and such is a real time saver.
For instance, when I first added a menu scene to KST (or Pirate Game, since it was still called by its working title then) I decided to just make the number of players a variable and be done with that. In hindsight, it might have been better to allow each player to be toggled on and off from their own line. On the other hand, this way it's nice and explicit, which has its advantages as well. And there you go: a simple decision immediately starts to get complicated :).
Related to the number of players are the player colours. If you play with two players you get to be red and blue. Green and yellow are added as players number three and four. Of course, it would have been nice to add more freedom to which colour you play with. But this also is a bit of a rabbit hole. Just adding a drop down menu for each player colour isn't enough, since you also have to block the colours that have already been taken. But the colours of inactive players probably shouldn't be blocked, but should change automatically if their colour is chosen by an active player. And this also means you need more than four colours to enable colour switching when you have four active players.
What I'm trying to say is not that these things can't be done, but that there are about a gazillion things like this and each one takes some time. And more time that you'd think beforehand because of all the interactions, dependencies and follow-up work. This accumulating complexity, added to the difficulty of creating an interface that makes (intuitive) sense is what makes UI design so time consuming.
So what are the lessons I learned? First off, what I've outlined above was driven home to me much more that during Powargrid development, since Michiel did much more UI work there than I did. I also realized that you have to put in the work. UI is obviously not something you can skip, but it's also not something you should do the bare minimum on. So, while working on the UI can sometimes feel like a chore, I'll be sure to keep this in mind.
Having said that, another thing I've learned is that investing time into getting to know the UI tools in Unity is most certainly worthwhile. There are many features that save time, make things look better and reduce the need for special casing. Getting familiar with layout groups, canvas scaling options and such is a real time saver.
Talking about time: that's the one thing I went really, really 'over budget' with. The first digital version of KST was a programming and Unity exercise for me. I then figured that it was a shame to let a nearly finished game just sit there and that there was a lot more to learn. And while both are correct, I severely underestimated how much time it would take to go from that first working version to something I would deem good enough to publish.
Part of that is that I haven't truly internalized the lesson we've learned over and over with Powargrid: game development always takes more time than you think, even after you've adjusted for that very fact. Which is something many (if not most) gamedevs run into. Those who don't run out of time during development must have some kind of mystical superpower I am unlikely to ever acquire ;).
The other part is that something I'm making has to be good before I can call it finished. Good in this case means that it has to conform to my own (unconscious) standards, which vary per topic but are usually quite stringent. Using a random screenie as a cover image? Nope, that has to be a custom image. Accepting that there are enough Dutch people to make localization to Dutch unnecessary? Nah, I want to be sure that my son can show the game to my parents. Just have the music restart whenever the game field is reloaded? Not good enough, since this breaks the flow too much (even though I managed to introduce a bug there that came back to haunt me much later). And there are many more examples like that, big and small.
To be fair, all these things do make the game better, so I certainly don't see that time as wasted. But the big question is whether this was the best way to spend all that time. Would it have been more productive if I'd spent all that time working on one of our new prototypes or on extra content for Powargrid? Honestly, I'm not really sure. But since finishing KST -including the publishing part- was a huge learning experience for me and my son loves the fact that our game is now also an actual digital game, I consider KST development to be time well spent.
Looking at that, the main time-lesson I'm taking away from KST is not that gamedev takes loads off time. I sort of knew that. No, the lesson for me is that I should weigh much more carefully whether or not to finish a game. Because once I really commit myself to finishing a game, I'm unlikely to let go before it's done and very unlikely to be satisfied with a product that's 90% good enough.
In order to weigh such a decision carefully, it's good to collect information. This meshes what I mentioned before, when talking about marketing: publish a game that's in its infancy, but that is already fun to play. That way, we should be able to gauge its potential before committing to turning it into a full fledged project. As I said, I'm not certain we'll take this approach, but I'd like to give it a try.
Part of that is that I haven't truly internalized the lesson we've learned over and over with Powargrid: game development always takes more time than you think, even after you've adjusted for that very fact. Which is something many (if not most) gamedevs run into. Those who don't run out of time during development must have some kind of mystical superpower I am unlikely to ever acquire ;).
The other part is that something I'm making has to be good before I can call it finished. Good in this case means that it has to conform to my own (unconscious) standards, which vary per topic but are usually quite stringent. Using a random screenie as a cover image? Nope, that has to be a custom image. Accepting that there are enough Dutch people to make localization to Dutch unnecessary? Nah, I want to be sure that my son can show the game to my parents. Just have the music restart whenever the game field is reloaded? Not good enough, since this breaks the flow too much (even though I managed to introduce a bug there that came back to haunt me much later). And there are many more examples like that, big and small.
To be fair, all these things do make the game better, so I certainly don't see that time as wasted. But the big question is whether this was the best way to spend all that time. Would it have been more productive if I'd spent all that time working on one of our new prototypes or on extra content for Powargrid? Honestly, I'm not really sure. But since finishing KST -including the publishing part- was a huge learning experience for me and my son loves the fact that our game is now also an actual digital game, I consider KST development to be time well spent.
Looking at that, the main time-lesson I'm taking away from KST is not that gamedev takes loads off time. I sort of knew that. No, the lesson for me is that I should weigh much more carefully whether or not to finish a game. Because once I really commit myself to finishing a game, I'm unlikely to let go before it's done and very unlikely to be satisfied with a product that's 90% good enough.
In order to weigh such a decision carefully, it's good to collect information. This meshes what I mentioned before, when talking about marketing: publish a game that's in its infancy, but that is already fun to play. That way, we should be able to gauge its potential before committing to turning it into a full fledged project. As I said, I'm not certain we'll take this approach, but I'd like to give it a try.
There are a few more small things I want to talk about, like music and sound. For music the decision not to create my own was very simple, since my skill level in music making is zero. So I browsed around on Pond 5 and found a couple of cool tracks that are usable royalty free (after paying the initial amount that is).
For sound effects I thought of also buying finished effects, but in the end we decided to semi-create our own. This was something I did together with Michiel, since I had next to no experience with this. We looked around on Freesound for good sound effects. We found a few we could use nearly as they were (just a bit of volume correction for instance) and others we combined, twisted and cut to fit our needs. This worked better than I'd expected, so I think this will be our go-to method for sound effects for the foreseeable future.
One effect I really like is the sound of transferring a shovel and / or key in team play. It doesn't come up during gameplay that often, so here it is:
For sound effects I thought of also buying finished effects, but in the end we decided to semi-create our own. This was something I did together with Michiel, since I had next to no experience with this. We looked around on Freesound for good sound effects. We found a few we could use nearly as they were (just a bit of volume correction for instance) and others we combined, twisted and cut to fit our needs. This worked better than I'd expected, so I think this will be our go-to method for sound effects for the foreseeable future.
One effect I really like is the sound of transferring a shovel and / or key in team play. It doesn't come up during gameplay that often, so here it is:
Something I'm still happy with and which hasn't really changed since the game's first inception is the game design. I've written about that in the first post about KST, so I won't go into detail here. The combination of luck and strategy works for young kids like mine (four and six years old) and even adults have been caught enjoying themselves with KST :).
And that's the KST postmortem for now. There is one more topic I'd like to cover, programming, but that requires its own blog post. This one has gone on more than long enough. As a bit of postpostmortemmortem, I'd like to add that writing a postmortem seems to be a skill that I need to develop. It's not something I'm used to doing and I found it more difficult than I'd thought. I do hope that this post has been interesting for you to read regardless of that.
And now it's finally time to show you that preview I promised. So here it is:
And that's the KST postmortem for now. There is one more topic I'd like to cover, programming, but that requires its own blog post. This one has gone on more than long enough. As a bit of postpostmortemmortem, I'd like to add that writing a postmortem seems to be a skill that I need to develop. It's not something I'm used to doing and I found it more difficult than I'd thought. I do hope that this post has been interesting for you to read regardless of that.
And now it's finally time to show you that preview I promised. So here it is:
This game really is in its infancy, but the first tests (with my friends as semi-voluntary guinea pigs) indicate that it has potential. So you can expect some more posts about this new project in the not too distant future :).
Happy gaming!
- Willem -
Happy gaming!
- Willem -