On my to do list there is a bunch of bullet points guiding me towards something that resembles a game, even if it is not even a sliver of what we hope to end up with.

However, if I had a middle name it'd be "Side Tracked" so first I went off implementing fog of war (more on that later) and then I decided I could no longer bear to look at the mish mash of placeholder icons I was using in the UI.

In web development, it is common to use icon fonts: a collection of small images packed into a font file, wihch you can easily put onto a page just by entering the correct character. Font characters are scalable vector graphics, so they render beautifully at any scale. The biggest downside is you only get a single color, but that happens to be fine for the minimal look I'm going for.

I realized that would work just as well inside the Unity game engine, especially now that TextMeshPro comes free with Unity.

For now, I've decided to go with the font from icofont.com for the open source license, the good looks and the great selection of icons (seriously check it out). Their website makes it easy to find suitable icons, and then it's a matter of either copy/pasting the character (when entering text in the editor) or copying the Unicode code point (when entering text from code).

And there we go: I still need to apply different colors to each icon, but it's looking a lot sleeker already! Of course, I wanted the "toggle" arrow to actually swap from left to right, so that meant a little dive into animation, but luckily that only took an hour in the end. Now, it's back up to the previous level of side tracking: launching probes to scout out hyperspace!

A quick update because I have something to show you!

​A while ago, I mentioned space is big while working on the UI for our space game. Well, I have the full-scale zoom function working! Check out the video below -- we start off in hyperspace, zoom into the Sol system, then visit the third rock from the Sun all the way down to viewing a space station in orbit. Then, it's back out, all the way back into hyperspace, a few lightyears to the side, then down into the gravity well of another star system.

You can also see the "hyperspace flux density" landscape. It's currently just a couple of layers of Perlin noise (well, simplex noise, actually - courtesy of the wonderful FastNoise library). I'd like to have more large scale "features" like valleys/basins and ridges, but it'll do for now!

Edit: the embedded video wasn't working well, so I replaced it with one I uploaded to Youtube.

So I (Michiel) have a toddler who likes to mash buttons on my keyboard, which I highly encourage but preferably without her deleting all my email or mess up my source code while she's doing that. Also, pushing buttons is of course much more fun when something happens in response, so I figured I'd whip something up for her to play around with.

I'll grant you, there's not much in terms of gameplay, story, or characters. However, it shows the letters you type while it goes *bloop bleep bloop* and if you click or move the mouse, it spawns flowers, so hey, five star review from at least one tiny person :)

A year ago, I knew nothing of how the procedural generating of maps (or any other content) works. I first tried my hand at this with Key, Shovel, Treasure, our small pirate game for kids. And with the help of Michiel, that game now generates maps that are fun to play on and visually interesting enough.

Key, Shovel Treasure generates maps in this relatively simple way:

• Assign land or sea to each tile at random.
• Remove land tiles that touch another land tile on a corner without being connected in any other way.
• Assign sea to the four tiles in each corner.
• Check whether the number of land tiles is within the limits for that map size. If not, restart the prcess.
• Check whether all sea tiles are reachable. If not, restart the process.

Not the most elegant or advanced procedural generation system ever, but it gets the job done:

For the current prototype (name needed), I had to dig a little deeper. There are currently three types of terrain; water, grassland and mountains that have to be put on the map. Also, as I wrote last week, there are all kinds of resources that have to be spread on the map.

For both of these, I use Perlin noise. The general consensus seems to be that Perlin noise isn't enough to generate good maps, but as a start it works fine for my purposes. As I understand it, Perlin noise works as follows (in 2 dimensions):

• The basis is an infinite 'sheet' of waves stacked on top of each other. Every point on the sheet has a value between 0 and 1. This sheet is always the same.
• In order to create variation, you can use a different part of the sheet. So in order to 'randomise' your Perlin noise, you don't change the waves, but you change the position on the sheet from which you read.
• To change the frequency of the noise, you zoom in and out on the 'sheet'. You don't do this directly, but by varying the size of the steps you take. To do so, you can apply a modifier to the x and y you feed into the function; less than one to zoom in (and get larger waves)  and higher than one to zoom out (and get smaller waves). I'll call this modifier frequency here and hope this isn't too confusing :).
• So basically, Perlin noise gives you a value between zero and one in return for an x and a y coordinate.

In order to generate the tile types on the map, I assign a height to each tile with Perlin noise (with a frequency of 0.1). Any tile with a height of 0.25 or less becomes water and a tile with a height of 0.75 or more becomes a mountain tile. All other tiles are grassland.

​I then place the resources on the map, using Perlin noise for forests and rocks and simple random placement for the other resources. For forests, the frequency I use is 0.15, so slightly more zoomed out than for the map generation. Each grassland tile for which the value lies below 0.3 become forest.

For rocks, I use a much higher frequency, 0.7, which means there is much more variation at small scale than for the tile types and forests. The chance that a grassland tile has rock on it is 0.2 (below which the tiles has rock). For mountain tiles, this chance is multiplied by 2.5.

As a side note, I arrived at these values through selecting a likely one and then tweaking until I had a value that worked for the game :). After placing everything, a full map looks like this:

This works pretty well for the game. The only thing is that I don't like the artificial border that the edge of the map represents. There are multiple ways to solve this issue. One is to build the map in chunks and load extra chunks as needed. While that's something I'll want to (and have to) dive in eventually, I don't think that's the most productive use of my time at the moment.

Another way to solve this is by turning the map into an island, which is much easier and which I was planning on doing anyway. So that's what I've been tinkering with. My initial idea was to simply add a paraboloid in the middle of the map and subtract those values from the heightmap. I say simply, since the function for a paraboloid turns out to be not very difficult:

Here, z is the height above point (x, y). The constants a and b indicate how much the paraboloid is stretched in respectively the x and the y direction. If both are 1, you get the 3d version of the standard parabola, y = x^2.

To translate it to the middle of the map, I just had to subtract half the map size from x and y. Figuring out what a and b had to be took a bit more thought, but I decided to set them to half the map size (after some tweaking). This makes the island scale when I generate a larger or smaller map, which suits my purposes for now.

What gave me more trouble was that simply subtracting this value from the height gave me maps with too few mountains. Simply increasing the chance a tile is a mountain would add mountains mainly in the middle of the map, which would both be boring and not good for game play. Another option, only subtracting this value if it was above a certain threshold didn't work either. It gave me maps with enough mountains, but that were too circular (not completely, but too obviously round for my taste).

Eventually, I settled on only subtracting the modifier if it's larger than the height value from the Perlin noise. This produces maps I'm quite happy with:

On these maps, the occasional (lonely) mountain will pop up from the sea. I'm not yet sure whether to see that as a bug or a feature :P. Also, the percentage of land tiles is obviously much lower on the new maps. So I went from a standard size of 55 x 55 to 85 x 85 to keep the land surface roughly the same as before. Eventually, the size of the map and other game variables will become tweakable.

There is one more thing I want to add to the map generation before I call it good enough for now: ocean tiles. As it is, you could build a bridge all the way to the edge of the map. Besides potentially leading players into a one way street in the name of exploration, there's something quite illogical about building long bridges to nowhere. Surrounding the island with ocean tiles, on which you won't be able to build bridges, should prevent that. I'm not yet sure how I'll do that, but I'm looking forward to building, tweaking and testing it.

I hope you enjoyed my little foray into procedural generation. There certainly is a lot more to learn for me about procedural generation. But what I have already learned is that I'm having fun putting this together :).

- Willem -

Last week, I wrote about our projects, focusing on the prototype I'm building. From now on, I'll be keeping you up to date about what I'm doing through this blog. Before I do so, I should probably tell you what this game actually is. It was present in the last post, but not very clearly.

The main idea is that you build up your town using the resources around you. Each building has a benefit for your town and the more advances buildings require that other buildings have been built first. By placing roads and outposts, you can explore the land around you, uncovering more resources. You can only harvest a resource if you have a road connection to it. Also, there are no moving units in this game (where have I seen that before?).

But just building your town and exploring the land isn't all. Sooner or later, you'll run into the blight. This corruption slowly spreads across the land, making buildings unusable and preventing you from harvesting resources. You can defend yourself by building special walls and blight-reducing towers, but eventually you'll have to venture out and remove the spots where the blight originated, the primal blight.

And that's the game in a nutshell. Now for some more detail.

This is the start of a test game I played yesterday. The maps are randomly generated and this start happened to have a lot of rocks close by. The two basic resources are stone and wood. Also visible are iron ore (dark grey), copper ore (brown) and Goop of Life (the bright green stuff). You need iron and copper pretty quickly and they can be gotten from their ores by building smelters. Goop of life comes into play later and can't be harvested before you build a goopstorage, a special building that requires quite a lot of copper.

In my test games, I found that sometimes the stone runs out. It then becomes really difficult to get more stone both because of the blight and because roads, like all other buildings, require stone. In the game pictured above, I didn't have that problem, but eventually the stone nearby my town ran out and I had to venture farther afield to get more.

Obvious solutions to this problem are to either add more rocks to the map or to increase the amount of stone from each rock. But since resources block roads, this spawns other problems such as getting hemmed in. Also, if adding enough stone for a worst case scenario makes it too easy to get in a normal game, the game becomes less fun. So I've been mulling this over for a while.

The solution came to me somewhere over the holidays. As you can see in the picture below, it's possible to construct mines on mountain tiles:

These are used to extract copper ore, iron ore and crystal (the red stuff, and a resource I hadn't mentioned yet). It occurred to me that it's silly to have a shortage of stone even though you're digging mines into mountains. So the solution I'm implementing now is that you can use a depleted mine to gather stone indefinitely, basically giving you an unlimited amount of stone. The catch is that it takes much more work to find good quality stone and bring it up from a mine; normally, harvesting stone occupies 5 people, but in this case, it will take 25.

Sometimes I drive myself crazy because I can have trouble accepting a less-than-elegant solution for a problem. At times like this though, I'm happy that my mind won't let go of this until I've found something that really fits and preferably does work on multiple fronts. I guess that what I'm trying to say is that I like this solution :).

I'm also considering whether I should add the possibility to plant new forests, making it less likely that you'll run out of wood. But I'm not really sure yet about that. The main thing stopping me there is that it takes a very long time for a forest to mature enough to have produced a significant amount of wood. I'll probably have to test this to see whether there's a sweet spot for the amount of time this should take in the game.

Back to the game from the first picture. In the picture above you can see that I managed to wall off quite a large area around my town before the blight came too close. I also built towers along the perimeter to make sure the blight stayed out.

It was about this point in the game that I realized that I was enjoying myself. I think this is a good sign. At the very least, there's one person who has fun with this game ;). And since I don't consider myself to be particularly unique, there's a chance others will like it too. (I think. Perhaps.)

This did make it all the more annoying when I 'found' a bug which crashed the game. I wasn't sure whether to be happy that I found a game breaking bug or cranky that my fun was brutally cut short. Although I must say that having the possibility to fix something like that yourself is a pretty good antidote for the crankiness :).

Anyway, that's it for now. I'll keep on tinkering and showing that here.

- Willem -

There are many types of projects. Main projects (of which you can have multiple, like the space transport game Michiel wrote about), side projects (like Key, Shovel Treasure), prototyping projects (like the pen- and paper games I throw together and test with my kids), upgrading projects (like the challenge missions for Powargrid), restartable projects (which should be named discontinued projects) and many more (I've only named gamedev projects here; kids, dayjobs, houses and spouses are also prolific project spawners).

As most people know (I assume), it's very easy to start up too many new things and very hard and time consuming to really finish something. Both Michiel and I are no strangers to this phenomenon. That's one of the reasons we're proud that we finished and shipped Powargrid.

At the moment we're working on multiple gamedev projects, as mentioned above. Today, I'd like to tell you about two projects, one large, one very small. But first a little explanation of where we're headed with Wee Free Studio.

We have lots and lots of ideas for games and it's impossible to even create working prototypes for all of them. So we obviously have to choose which ideas to pursue. At the moment we're working on two prototypes. First, the space game Michiel wrote about:

This occupies most of Michiel's Wee Free Studio time. This game has great potential, but is also very ambitious and complex. Michiel is building a very solid foundation for the game. The risk of over-engineering the prototype is mitigated because many of the components (and skills for that matter) can be re-used in other projects. Also, Michiel is having fun building it, which is a very important factor too (and too often underestimated in my opinion). I've also done some work on this prototype, but for now, my main focus lies elsewhere.

And that leads me to the first project I'd like to look closer at today. I'm spending most of my Wee Free Studio time on a project with the working title Building Game. Not very inspired, I know, but if I don't start a project until I have a good name, chances are I'll never start it at all. I've teased a few images from this project and now it's time to reveal a bit more about it.

Where our space prototype is based on a vision of a cool game we can work towards, this game grew from the bottom up. I started it as a small design + programming + Unity exercise. Building Game (I'll keep calling it that for now) generated a map, allowed the placing of buildings and the harvesting of resources. I thought it was fun enough to keep tinkering with it, and it expanded to more building types, more resources and a couple of terrain types (and thus  map generation).

At that point, it was still much more a toy than a game. And building it was much more an exercise than a real project. This changed when I started to introduce time into the equation. Once it takes time to build buildings and harvest resources, there is a payoff (in time) to thinking about what you do first and your decisions take on some more meaning. But still, a game it was not.

To make it into more of a game, I'd been thinking about more traditional enemies. With units or armies that move across the map, making it either tower defense-ish if you don't get moving units of your own or more traditionally wargame-ish if you do. But this felt both too standard and too far away from where Building Game seemingly wanted to go. Luckily, I got hit by a particle of raw inspiration and decided to add a blight that slowly creeps over the land.

You can counteract the blight with special towers and slow it down with walls. To win, you have to remove the blight from the spots where it originated. With the addition of blight, it started to feel like a game. I decided that I'd at least show my tinkering to my friends, to see how they reacted.

This meant doing a lot of UI work to make the game playable for people who aren't its creator :). Tooltips turned out to be the best source of information. So they tell you whether buildings can be placed, what buildings do (when hovering over the buttons), whether tiles can be harvested / mined and more. Also, buildings with multiple versions show a tooltip for each version and if any resources are missing, they show up in red. Getting all of that to work was much more complex than I'd thought and at one point I entirely rewrote the tooltip code.

But eventually, the result was there. A playable version of Building Game, with all the tooltips in place. Like this one for the blightwall:

What's more: my friends ended up liking Building Game. I got a lot of useful feedback, which I used to debug and improve the game. I created four 0.1.x versions before other things (projects) came along that drew my attention elsewhere (such as the Powargrid multimultiplayer update and some piratey stuff).

Fast forward to now. I've picked up working on Building Game again, but I've mainly been busy reworking and cleaning up its innards. Both to get some structure in there to make the code easier to work with and to prepare for future features. Mainly, I'd like to see if it's possible to get a multiplayer version to work. I'll certainly need Michiel's help for that, but that's OK, since the code that's needed for that should be largely the same between our two (main) projects.

As for the future, my plan is to create a couple more builds to test out on my friends. If they still like it (and if I can come up with an acceptable title), I think I'll put Building Game up on itch.io as an work in progress. It will start off at a low price, which will slowly increase as the project progresses. When that happens, you can certainly read about it here. In the meantime, I'll write some more blog posts about the development of Building Game and also about the gameplay.

And that's it for Building Game for now. I hope you like what you've seen so far :).

Then the other project I said I'd tell you about. This is one in the category of sidetrack projects, blending over into family projects. My son wants to do a typing course. An actual typing course is out of the question, since chances are he'd look at that twice and then never again. And with the very valid reason of being six years old.

So I did a quick search for free typing games. But what I found were mainly flash games (which you don't really want to begin with) and most of them didn't appeal to me (quickly enough). On top of that, there's a language barrier since we're not native English speakers here, but I don't see that as much of a problem in this case.

Anyway, I decided that throwing a typing game together that was acceptable for my son shouldn't be too difficult. So I did just that:

In all, I think it took me about a day to get this working the way I wanted it to. It's simply a monster that moves towards the player. Typing the word above its head despawns it and spawns a new monster. Each level adds another letter to the word. I found a database with a lot of Dutch words, about 150k of them, which was usable after some tinkering (removing words with accents on them for instance).

A fun thing about the dutch language is that composite words are written as one. So game design in Dutch 'spelontwerp' and not 'spel ontwerp'. This means that the game goes up to level 33. The word in the right most screenshot means 'uranium enrichment program'. It's actually doable for me to keep up with the typing at level 33 (I'd say I'm a moderately fast typer in Dutch, a bit slower in English).

All that remains is that I'll get my kids to draw some monsters on paper, take photos of those, crop them in paint.net and add them to the game. I think they might like that. Or not. They're kids after all :P. I had fun throwing this together and my son now has his very own typing game (typspel in Dutch). I won't do anything else with this (other than the self-drawn mosters). Building Key, Shovel, Treasure taught me to steer clear of that rabbit hole.

Anyway, that's that for today. And for this year too :). May you have lots of fun projects in 2018! (But not too many.)

​- Willem -

We have a short update for you today, since we're trying out something new: we're participating in a game bundle sale. The Monday motivation bundle by Indie Gala.

This is a new thing for us and we're of two minds about joining a bundle like this. So we've decided to jump in and run the experiment :). Both to see the effects on sales and other stuff and to see how we feel about this. A small note: when I talk of bundles, I mean pay what you want-bundles where people can get games for extremely low prices. Not the bundles you sometime see on Steam with, for instance, all games from one publisher for half price.

First off, joining a bundle with a game of which the sales have slowed down makes a lot of sense form a sales perspective. You get (some) money directly from the sales in the bundle. You also generate attention for your game, both directly from the sales and indirectly because people will see their friends playing your game on Steam. On top of that, those who have the game on Steam will be notified when you update your game, generating another round of potential attention (thus Steam activations are never bad from that perspective). And on top of that, we just want people to play, and preferably enjoy, our game. Joining a bundle gets Powargrid in the hands of players :).

On the other hand, there are also downsides. The immediate question is whether you may hurt the sales you would have otherwise made for a higher price. While this may be a problem for better known titles, this effect is negligible for Powargrid. A more important downside is that people who have bought Powargrid at full price, or even during a sale, may feel cheated. We'd really hate that, since we're especially fond of the people who have decided that this game we made is worth their hard-earned cash. We never felt that way ourselves when seeing games we own appear in bundles, but we can imagine that could be different for others.

On top of that there's the indirect effects. Looking at bundles from a market perspective, they could trigger or hasten a race to the bottom. If that happens, there will be a point where it becomes foolish to pay full price -or even half price- for a video game. Why that's bad for the market needs no additional explanation I assume :).

So the conclusion is that it's in the interest of the individual company to add your game to bundles, while it's in the interest of the market as a whole to not join in bundles (and the same goes for subscription based game services). This is pretty close to the definition of the tragedy of the commons, with which I'm quite familiar given my background in environmental sciences. In my day job, I spend every day battling that very mechanism (specifically on the topic of energy / climate, but the tragedy of the commons is applicable to all environmental problems). So my gut instinct is to avoid things that invoke the tragedy of the commons.

Having said that, it's quite possible the analogy doesn't quite hold up. In environmental sciences, it's pretty clear that the tragedy of the commons is at work. For game bundles, there may be other effects. For instance, they may get people who normally wouldn't play games to try them out, in essence growing the market. Gamers may try a game genre they normally wouldn't play. People who can't afford games at full price or who would normally pirate them may be convinced that paying for the real thing is preferable if the deal is so good.

​​Adding everything up, we felt there were more than enough reasons to say yes when the nice folks at Indie Gala invited us to join the Monday motivation bundle. Not least because theorizing can only take you so far; you'll need to experiment to really understand how things work. So we joined their bundle. Be sure to have a look there :).

​- Willem -

So, we're building a space transportation game! The one-line concept is "Railroad Tycoon... in SPAAACE!"

The year is 4242. Fusion drive starships have allowed Humanity to colonize the solar system and spread throughout the stars on cryogenic sleeper ships. With the discovery of hyperspace technology, interstellar trade is budding. As a player, you are in charge of a transport company, with a fleet of ships carrying the needs and wants of a galaxy spanning civilization.

Freshly settled frontier outposts will need colonists, building materials, medicine and terraforming equipment. Rich, established core worlds want the latest fashions, red-and-chrome two-seater racing spaceships and other luxury goods. To get those made, zero-g manufacturing facilities need to be supplied with materials from extractors and mining facilities at gas giants and asteroid belts. Everyone knows the best optronics are made in the GlasTec Corporation crystal foundries in the Arcturus system, and Astrodyne Shipyards Ltd only wants the best for their new line of luxury yachts, so somebody had better deliver!

Of course, all this is just wild ideas in our heads at this point, so no guarantees any of it will actually end up in the game. But if you'll indulge me, I'd like to tell you about the first small steps we're taking.

The problem with space is that's it's really big (more on that in a later post!) and mostly empty, and that's not very interesting to look at. You can have pretty nebulas in the background and a nice atmospheric glow around your planets, but in the end, spaceships are cool but space is a pretty boring place.

To reduce travel time between stars, and make it interesting, interstellar travel will use hyperspace, a massively more compact alternate dimension parallel to normal space, which ships can enter through jump gates.

Our hyperspace will have a property called "hyperspace flux density". Traveling into greater flux density basically means going uphill: hyperspace will have a virtual landscape with "hills" and "valleys". The fastest route between two star systems won't be a straight line, but will have to snake around, using the flat valleys and avoiding high ridges. To add an additional challenge, hyperspace is also very "thin": hyperlanes will not be able to cross without interference. You'll have to carefully route and signal your hyperlane network so ships can move through efficiently.

While we're excited to start creating an elaborate simulation with a complex economy driven by supply and demand, we realize the potential of a game like this mainly hinges on a good user interface. It needs to be clear, and it needs to feel good to carefully thread your routes through the intricate hyperspace landscape. We want the player to sit back and look upon their finely woven tapestry of hyperlanes (or the horrible mess of hyperspaghetti if that's your thing), with each blip on the screen a ship zipping around brimming with precious cargo, and feel like the CEO of a transstellar corporation, taming the extradimensional void for the benefit of cilization (and massive profits).

So that's why I'm working on a prototype for the construction UI, so we can try out what works and what doesn't. Instead of a grid based construction system, I think a curve based system is a better fit for a space game. Players can construct jumpgates where ships transition into and out of hyperspace. In hyperspace, ships should travel in hyperspace lanes for fast, safe travel. Lanes can split and merge at hyperspace junctions. The path of a hyperspace lane can be adjusted by placing nav buoys the lane will pass through. Eventually, there may be depots and warehouses in hyperspace, so ships can transfer cargo and receive maintenance without having to exit and re-enter hyperspace.

It's not even in a state where I can show you a tech demo, so a screenshot will have to do.

The black circles are gravity wells, created by stars. You can't jump into hyperspace from inside a strong gravity field, so jump gates have to be placed far enough away from large mass concentrations (i.e., stars). Hyperspace is red, because it is red in Star Control 2, one of my favourite games of all time!

So far, I have basic mouse input handling (clicking, dragging, snapping, camera pan/zoom) and a very crude approximation of our "virtual tablet" UI concept. With this, we're working out the "flow" for various actions - should you click or drag to place a hyperspace lane? Do you have to push a button in the UI to start editing a lane, or should it be editable right away when you select it in the world? What if you accidentally drag something? There are a thousand decisions to be made, but I'm sure this is a worthwhile investment. We can also do some initial experiments with game mechanics: how big should stuff be? How much room do you need between gravity wells to allow interesting junction networks? What looks good and feels right?

I don't know either, but stay tuned and we'll keep you posted!

Hyperspaghettily yours,
Michiel

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:

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:

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.

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.

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 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.​

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.

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:

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:​

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 -

UPDATE: Key, Shovel, Treasure has been released! It's now available for free (or more precicely pay what you want, starting at free) on itch.io: https://weefreestudio.itch.io/key-shovel-treasure.
​

A very short blog post today. Tomorrow we're releasing Key, Shovel, Treasure! We've added the last features, most notably proper sound effects, and at the moment I'm solving an issue that cropped op at the last minute. Turns out reloading the game scene breaks the music repeat loop, so that needs fixing :).

In the mean time, here's a gif of the release version:

I'll be sure to update this post with a link to our itch.io page once it's up!

- Willem -