First off, some news on the Key, Shovel Treasure front. I've set up a draft for the itch.io page for KST. The text certainly needs another editing pass, but the look is pretty much where I want it to be:

I first tried a monocolour background, but that was too bland. After some trial and error, I added the KST background, but then a lighter version with much less contrast. The screenshots may need replacing, since there still are one or two more things I'd like to change.

Then the marketing front. As I wrote last week, I'm not really comfortable with that. I think that asking people for attention is annoying if done often. The 'problem' is that for me, too often is not too different from almost never. Which doesn't help. And this goes even for a medium like Twitter, which is much less intrusive than an email (in my opinion).
There are some things I've grown more comfortable with by now, such as posting a link to our blog or to the Powargrid Steam page. And then I still think that doing so twice a day is being rather active and doing so four times in a single day is pushing it. Best if I never try to make a career switch to social media guru :P. As an aside, Michiel has about the same outlook in this regard.

All that is mostly a preamble to our Thunderclap. We currently have three supporters out of 100, two of which are Michiel and myself. That's not a great score in one week, to say the least. I think that a large part of that is that asking people to support our campaign feels too much like bothering people (to me at least). Which means that I'm not active enough by far in trying to recruit supporters.
We've considered spamming our friends and family to ask them to join, but that means the message would mainly be spread in the network closest to us. Also it'd feel like bothering people. Do I sound like a broken record yet? So for now, we'll let the Thunderclap rest. We won't discontinue the campaign, but it's unlikely that we'll be pursuing it very actively any more.

Which is sort of fine. For me, Key, Shovel, Treasure is for a large part about experimenting and doing new things. Something that didn't work is a datapoint too :).

On a more cheerful note, here's a new KST gameplay gif:

And then for something completely different: space colonies! This (obviously) has nothing to do with Key, Shovel, Treasure. But next to that we've been working on some other things we haven't shared with you yet. One of those things has to do with space (SPAAAACE!) and will have colonized planets. Michiel asked me to give some thought to generating background stories for the colonies.

Which sounded like a cool challenge to me, quite compatible with my current skill level in coding :). So I spent a long weekend fiddling around with ideas and writing scripts and I actually managed to produce something that generates backstories for planets. It's nowhere near finished, but it does enough to show it here. In my opinion that is ;). Here's an example of a background story as it's generated now:

Please don't take too much note of the UI design here. This is no more than a testing scene for the story editor. Michiel has been prototyping some real cool stuff for the future UI, which he'll write about in a future blog post.

In order to generate stories that differ quite a lot, I implemented three main features. First off, I separated the potential planets into five different types:

1. No atmosphere.
2. An atmosphere, but no liquid water.
3. Liquid water, but a surface that's hazardous to humans.
4. A surface that's quite benign to humans, so you can walk outside with only light protection (a small breathing apparatus and a thin protective coverall instead of a full spacesuit), but devoid of indigenous life.
5. Indigenous life forms (of the multi-cellular lush ecosystems variety).

While other types of planets or combinations of these are certainly possible, this mostly covers the angles I would like to use for the background stories. Also, five basic planet types isn't so much that there's an explosion of combinations each of which needs its own story considerations. So with these types, things should stay rather manageable.

Secondly, I created a text file for each of the planet types with a couple of colony start stories, one per line. When a story is generated, I pick a line at random and use that as the opening. I also created the same sort of text files for events that can occur in the colony, from new immigrants to a comet strike to the discovery of a natural wonder. Whenever an event takes place, a line is once again picked at random from the correct file and added to the story.
At the moment, there are only a few options per text file. This means that some story elements are quite repetitive right now. But I think that once I have about seven or eight options per file and once more event types are added, this repetitiveness should be mostly gone.

And third, I added synonym markers and variables to the text files. Whenever a word or group of words is placed between these <brackets>, the story parser will choose a synonym for that word at random from a csv-file. I'm not yet convinced that this is a scalable way to work, but for now it's quite an effective way to bring a bit more variation to the stories.
Everything I put between [square brackets] is a variable and will be replaced by the corresponding variable for the planet for the moment the story element refers to. For now, I only use this for the year and the population. But I built it in such a way that adding (a lot) more variables should be no problem.

Here are some more examples of stories this process can generate:

Also note that if the population of the colony goes to zero, it will (have to) start over.

There's a ton more stuff I'll add to this in the future. To create more interesting stories and also to generate more variables that will eventually have relevance in the game. I think it's cool to have a backstory for a colony that explains, or at least supports, the game play elements associated with the planet.

However, since the Key, Shovel Treasure release is only a little more than a week away, on November 9th, that will get most of my gamedev attention in the near future. So I expect my next blog post will be all about KST. After that, I'll certainly be back to tell more about these background stories and other new stuff we're doing.

- Willem -

​
Building the digital version of Key, Shovel, Treasure started as a learning experience for me. First for programming, then for using Unity and on to polishing the looks and tweaking the user experience. Now that I've gotten this far (of course with the indispensable help of Michiel), it's only logical to extend the learning experience to marketing. Especially since marketing isn't a part of being an indie dev I'm very comfortable with (and yes, I know that marketing is much broader than what I mean here, but I couldn't find a better word to use here).

So I've been thinking which marketing things I would want to do (or try) for KST. I came up with the following list:

• Keep on writing this blog (of course). This is something I'm pretty comfortable with by now and I'll certainly keep on writing :). 
• Set up a Key, Shovel, Treasure page on both our own website and on itch.io. The game will be pay what you want, starting at free. This was the plan all along when we decided to clean KST up.
• Set an actual release date instead of just working on the game and trusting that at some point we'll decide that it's done. We've set the date to November 9th. So it's getting real.
• See if I can find an number of people / channels / outlets who might be interested in covering a small game aimed at kids and write them a short email about KST. I don't expect any real coverage, but it's worth a shot. And I can certainly use more practice in this direction.
• Do a Thunderclap campaign. The idea behind Thunderclap is that people can support / back your campaign. If you reach the required threshold, all these people will automatically send a predetermined tweet the moment the campaign ends. I've set up a campaign, which is at the moment waiting for approval. I'll update this blog post when it goes live. [Update: the campaign is now live]

The first concept for the itch.io page is done. One of the things needed for that is a cover image, with an aspect ratio of 315 x 250. Since I wanted something different than just a screenshot with the logo on top. I created this image:

What's nice (I think) is that all the actual drawings are game assets. So putting this picture together went quicker than I'd thought and it turned out better than I'd expected :).

​Other than that, there are a few more things that changed since the last blog post. First off, the game now has real piratey music for both the menu and the game scene. Somehow, adding proper music is a big step in making Key, Shovel, Treasure feel like an actual finished game.

Another indicator that Key, Shovel, Treasure is nearing completion is that small graphical improvements now have a big impact on the entire look. There is more visual cohesion. Two things Michiel suggested have worked really well in that regard. First off, he remarked that the text colour everywhere was still dark grey (which I believe is the Unity default) and that dark brown would probably look better. He was absolutely right. Second, he suggested adding a little more padding, space around the text, to the buttons. We played around with that and eventually settled on not just more padding but also on larger buttons. Both effects do a lot of work for the look of the game.

Especially the text colour looks pretty similar at first glance, but the dark brown text fits the picture much better. To make the difference obvious, here's a GIF which shows before and after:

​Lastly, we finalized the end screen. We couldn't resist mentioning Powargrid, our turn-based strategy game, even thought it's a very different game. When you exit Key, Shovel, Treasure, you'll see this screen:

We had our doubts whether or not to add a screen like this, since people my find it annoying. And annoyance is basically the last emotion we'd like our game to convey. But eventually we decided that this  version is quite acceptable. The button to really close the game is clearly marked, so it shouldn't come across as too pushy. If we get feedback that this screen does annoy people, we'll look into changing the it.

Speaking of Powargrid: if you're reading this and haven't played it yet, you can give it a try for free. There's a demo available, both on Steam and on the Powargrid website.

That was all for now. As I mentioned, we'll be sure to let you know when the Thunderclap campaign goes live. We'll be much obliged if choose you support it. [Update: the campaign is live now.]

- Willem -

Last week, I wrote that Key, Shovel Treasure (KST) was nearly done visually. I also edited the post, since I quickly found out I was wrong. After adding the new background and the game field border, I realised there were more tweaks to be made. I'm not brave enough to claim that KST is now really nearing its final form, so I'll just run you through the changes I made.

First off, fonts. All of KST was still in Arial, the standard font in Unity. I'm pretty much immune to which font is used as long as it's used consistently, but I do know that there's a whole world of subtleties out there which can make text connect from your game if applied well. I eventually went for a font with a balance between readability and pirateyness (which shall henceforth be an actual word). It's called Lobster and looks like this in the main menu:

I'm pretty happy with the way it looks here. As a side note, I also slightly changed the background colour for the text input fields from white to off-white. This makes the input fields more connected to the rest of the menu. Anyway, back to fonts. Lobster works fine here, in the game scene and in the settings menu. The one place where I'm still doubting I should stick to this is in the explanation. Looks nice, but reads a tad difficult. For the moment I'm sticking to it :).

I also re-wrote the text for the explanation. It's much shorter now and should be easier to understand. When writing an explanation, I tend to write out the rules too much. Writing down the game rules exactly is a necessity in board games, but there's no need to do so in a video game. The computer restricts what you can do and you'll learn quickly enough just by trying. One could even argue that there's no need for a written explanation in a simple game like KST, but I'm rooted in board game design too much to let it go just yet :).

Another change is shadows behind the UI elements. They're visible in the menu screenshots, but they're easier to see in the game scene:

the strange thing with these shadows is that they're illogical (I think), since a flat piece of parchment on a table doesn't have a visible shadow and there is no reason the parchment should be floating above the table. And yet it does work visually. The shadows anchor the UI elements to the background and make the full picture easier on the eyes. This disconnect between logic and looks bugs me, but not enough to abandon what works visually.

I also gave the three buttons in the bottom left a wood texture. Unlike the buttons on the parchment, these are placed on the table and need a bit of an object-like look to them to make them fit in with the rest of the game. Small pieces of parchment wouldn't work as well, since the buttons should look distinct from UI elements that can't be clicked.

Other than that, I've made a couple of quality-of-life improvements like no longer having the possibility to access a land tile which holds nothing of interest (to prevent ending your turn by accident because of a misclick or typo).

Lastly, in mostly unrelated news, we made a new cardboard version of KST (with 'we' being my son (6), my daughter (4), my wife (I'm not stupid enough to mention her age) and me (39)). My son's class in school decided to hold a market to raise money for the island of Sint Maarten, which was devastated by hurricane Irma. During the market, my son offered people the chance to play KST with him for a small fee. He managed to explain and lead the game without any help, which I really see as an accomplishment for him. He raised 7,50 Euros this way and told me that the parents and classmates who had played with him had really enjoyed themselves. Needless to say, I'm a very proud parent :).

And that was that for now. Next up for KST are music, sound effects and decisions about when and how to release it. More on those things next time!

- Willem -

A short blog post about Key, Shovel, Treasure this week. There's not a lot of new stuff I can show, both because I've been busy with other things and because part of what I've been doing is behind the scenes stuff. But the big thing is that in my opinion KST has reached the point of acceptability. I mean that in the sense that I'm happy with the way it looks and plays and with the functionality. There are certainly more tweaks to be made, but I think the version we'll release will look a lot like the current version.

Which makes this a nice moment to look back at the visual changes since we decided that we wanted to release this to the world. So below are a couple of before and after pictures. I hope you can spot the differences ;).

The only thing I'm somewhat worried about is that I might have become too attached to the way some things look. for instance, I really like the background as it is, but Michiel has commented that a more stylized version of a table top would work better. Experience tells me that there's a greater than even chance that he's right, but I keep finding other things to do than look for another background :P. So there actually is a good change that the look of the game will actually change quite a bit between now and release. For which we haven't set a date for by the way. We should probably start thinking about that.

- Willem -

Edit:
It seems that writing about avoiding changing the background helped change the way I look at it. And / or it get the creative juices flowing. Anyway, I set about creating a background. And while I was busy I also created a border for the game board, which was another thing Michiel already thought necessary. I still have to fidget with the colours, and perhaps I won't stick to this look, but this is what the game looks like now:

Different? Certainly. Better? I'm not sure yet, but I'm leaning towards yes. I certainly like that the background now more closely resembles the simpler-than-reality style of the rest of the graphics. Also, the border adds a nice bit of definition (and it hides the waves when they go outside the playfield).

Lastly, I'd like to give credit where credit is due. I found a great tutorial video by Jester of None, on how to create a wood grain texture in Paint.net. It's clear, short and the technique works like a charm. I recommend taking a look at his video if you ever use Paint.net.

Next time I'll let you know what Michiel thinks of this change (I haven't shown it to him yet; I only just finished this and he's at a concert) and whether we've decided to keep it :). 

​Another week and there is more progress to show for Key, Shovel, Treasure. As I said last week, that's one of the advantages of working on visual stuff. Actually, the visual stuff is nearly done now. For the in-game sprites, only the treasure is left:

So what's new compared to the last update? Mostly, the lands have had an overhaul. Here's a comparison of the old and the new look:

​As you can see, all lands were square and had no texturing. In order to make the land tiles look better, they at least need shore lines that aren't straight. Also, some subtle surf around the beaches helps to soften the transition between land and water. So I spent an afternoon figuring out how best to create these effects.

One disadvantage of having better looking shorelines is that repetition becomes an issue. As long as all your shorelines are straight, with sharp 90 degree corners, this is no problem. But if a more wavy coastline is repeated, it becomes more difficult to ignore that some shores are the same. Apparently there has to be a balance between naturalness and repetition for things to make visual sense.

The solution is simple enough: draw multiple sprites for each type of land and randomly select which one to use when generating the map. I figured that three sprites per type of land would be a good number, which turned out to be correct for all lands except the peninsulas (peninsulae?) that have one land neighbour. Tose requires six versions to prevent repetition. But that did mean drawing 24 lands and also 24 covers for the undiscovered tiles. I wanted the covers to exactly overlap the lands so the surf is also visible around undiscovered lands.

Even with a good workflow this is a lot of work, so I spent some time looking for a way to automate the process. I use Paint.net for creating artwork, which works really well but doesn't have a macro function. And as far as I could find, there's no plugin that adds macros. This led me to search for an external program. After some experimentation, I settled on AutoHotkey.

As the name implies, AutoHotkey allows you to create new hotkeys for general use. You can add scripts to these hotkeys and sends things like key commands and mouse clicks. I created an AutoHotkey script that creates a land, the surf and a land cover starting from an outline of the coast.

Of course, this wasn't as simple as I would have liked (nothing in gamedev ever is it looks like). For instance, it took me some time to figure out that some operations in Paint.net don't get completed instantly every time. This causes problems, since AutoHotkey sends the next command immediately. Having your script fail only part of the time instead of consistently makes it a lot harder to figure out what is going on. Adding some 100 millisecond sleep commands in a couple of places fixed this issue for me. But it's quite possible that with a different (faster?) PC, this wouldn't even have cropped up.

Another problem was that my script kept clicking in places that were not at the coordinates I specified. A logical culprit was that the script was using the Window CoordMode, which calculates the coordinates relative to the active window, instead of the Screen CoordMode, which looks at the absolute coordinates on the screen. The fact that the colour palette in Paint.net is its own window pointed in that direction as well. But I also found that the default setting for CoordMode is the correct one: Screen. So the CoordMode couldn't be it and I searched on. What I should have done instead was test this by adding the line "CoordMode, Mouse, Screen". When I did that, it quickly became apparent that the default (for my script at least) wasn't set to Screen and the bug was fixed. I guess  that's another programming lesson learned :).

Something that came in really handy was an Autohotkey script that displays the current cursor coordinates (by Jackie Sztuk_Blackholyman on the AutoHotkey board), since I needed a way to determine where to have AutoHotkey click. Makes me realize that  having an active and engaged community is one of the greatest assets a program like AutoHotkey, Paint.net or Unity3d (or many games for that matter) can have.

Eventually, I got the script to work 90% (or so) of the time. Which is good enough for my purposes, since I'm not planning on using the script regularly. The time I saved probably is insignificant, but I did learn a lot about scripting with AutoHotkey in the process, even though I hadn't heard of it before last weekend. Funny where gamedev can take you. The big advantage of having this script is that if a land shape I made doesn't really work in game, I can now easily redo it. Also, if I want to change how the lands look, for instance change the colouring, I can simply change a part of the script an re-run it for the lands I made.

Seems I'm more and more getting into the habit of thinking like a programmer. And looking at things with the eye of a (nit-picking) artist:

This is a comparison of two options for the lands: with and without a border between the tiles. I was wondering which of these looks best, so I asked Michiel for his opinion on this. He told me he preferred the version without the borders, but also that in the (full game) screenshots I sent him, he was hardly able to tell the difference. I'll just tell myself that looking at smaller and smaller issues is a sign of progress.

Speaking of progress, the palm tree pictures were also updated:

Again, drawing better pictures meant that repetition became more obvious and more versions were required. In drawing the new versions, I decided to do some research into how palm trees actually look. This led me to first draw a way too detailed version, which turned out way too blurred in the game. After that, I found that more realistic colours didn't stand out very well against the land tiles I created, so I moved much closer to the colours I used in the old image. Hence the evolution of the KST palm tree:

Those are the Key, Shovel, Treasure updates for now. I'm happy with the progress over the last couple of weeks. In a couple of weeks more, with a bit of luck, we'll be able to provide you with a link to the finished version.

- Willem -

Another week, another update on Key, Shovel, Treasure. Slowly but certainly, I'm getting the hang of this graphics stuff. The upshot of that is that I have things to show :). Here are the new versions for the key and the shovel:

And here is how they look in the game:

I also updated the menu for team play. You could choose between teams 1 and 2, but those numbers mean nothing in game. So I changed the numbers to the I cons I've also used on the sails: a skull and a set of cutlasses.​ So the menu now looks like this when teamplay is toggled on:

I think this is much clearer than using numbers. And the icons make sure that the selection here is linked to what you see in the game.

​I've also fixed a transparency issue in the menu. It helps for clarity if the menu items for players who are not in the game are transparent and non-interactable. And the same goes for the team selection elements if teamplay isn't on. When I first put that in the game, I used a hack by simply covering those menu items with a semi-transparent image of the same colour as the menu background. But that no longer worked after I created parchment for the background.

So I set about trying to find a way to actually set the alpha of the menu items. Turns out that you can loop over all the children of a game object, which looked promising. Not having to separately set the alpha for every individual menu item sounds good to me. But then I ran into the problem that accessing the alpha works differently for the various types of menu items like texts, buttons and images. Which meant more work than I'd hoped.

And then I found out about Canvas Groups. Which do exactly what I wanted. You can use them to set both the alpha and interactability of a menu item and all its children. I guess the lesson here is Google first, code later :).
​

One thing that Michiel has been commenting on project-wise is that hitting the play button from the game scene in the editor doesn't start the game properly. So testing always involves switching back to the menu scene before starting. Today, my own annoyance at having to switch back finally got to the level that solving this moved to the top of my list of priorities. After some (more) Googling, I found a great solution for exactly this thing on Unity Answers.

Turns out you can add menu items to the editor by placing a script in a folder named "Editor" in your project. And the script that you need for this is really simple, courtesy of the people who put in the time to figure this out. You can find the relevant thread here. This may just become a standard addition to my Unity projects.
​

Last but not least, something about Powargrid (and yes, I couldn't resist using KSP as a title for this post). It's been a while since we've said anything about Powargrid, but we certainly haven't forgotten about it. As we've said before, we're running Wee Free Studio next to our day jobs (and our family lives of course), so the time we can invest is limited. But having said that, we're still working on the next Powargrid update.

The main part of this update will consist of a number (we're not yet sure how many) of missions that can be played independently from the campaign. We're calling them Challenge Missions, since they're supposed to be a challenge for players who have finished the campaign. But they will have an easy setting if that's more to your liking. And a hard setting for if you're feeling particularly masochistic.

These mission will have dialogues, just like the campaign, but no overarching story line. So the order in which you play these missions won't matter. Story-wise these missions are set after the campaign. Having said that, we're do try to keep the spoilers to a minimum.

Speaking of which, here is a screenshot of one of the challenge missions (obviously a work in progress):

​We'll certainly write more about this update when it gets closer to completion.

Until then: remember that to err is human, to arr is pirate!

- Willem -

As I wrote last week, doing graphics and art(ish) stuff is slow going for me. But there is a bit of progress to show you on Key, Shovel, Treasure. Which, come to think of it, is an upside of graphical stuff: you've got something that's easy to show afterwards :).
First off, I added the parchment backgrounds to the UI elements in the game. Getting them right took quite a bit of tweaking, but I'm happy with the result. Here are a few examples from before and after.

Next, I experimented with the look of the sea tiles. Uniform blue tiles do a good job for clarity, but it is nice if the sea looks a little more watery :). So I created five water tile images with different swirly patterns (yay for Paint.net plugins and cloud rendering). When the map is generated, each tile is assigned an image at random and is turned a random amount. The result is rather subtle, but does the job of breaking the monotony.

A while back, Michiel suggested (for another project) to slightly vary the colouring for the tiles using Perlin noise. This could add a bit of variation on a larger scale. I may give that a try as well. And here I am, still wondering how it is that one always gets lost in the jungle that is gamedev ;).

The last thing I'd like to show you today is a work in progress. I'm re-drawing the boats for the game, so they'll look more like actual pirate ships. In the gallery below, you can see where I started and where I'm at now.

The skull and cutlasses will be added to the sails in team play. I'm uncertain whether I should keep the skull white or whether I should make it black as well. I think black looks better, but white probably makes for a (even) better visual distinction between the teams. Oh, and of course there will also be a skull on the main sail. Other than that, I still need to add the steering wheel and perhaps some more decorations such as a band along the ship in the player's colour.

And that's it for now. Slowly but certainly we're getting closer to a finished game :D.

​- Willem -

Here's another quick update about Key, Shovel, Treasure, our pirate game side project. Progress has been slow, mainly due to other fun stuff like a festival and a LAN party eating away at my gamedev time, but there are a few things we can show. First off, the logo for the game clearly needed an update. I'm quite satisfied with the result:

Doing graphics stuff is always a slow process for me, mainly because I don't do this often enough to really get it into my system :). However, I did learn a lot about using Paint.net. Mainly thanks to people who have been so nice as to write tutorials. I'll be adding the same sort of parchment-y look to the backgrounds for the menus as well.

I've also added localisation to Key, Shovel, Treasure. This turned out to be more work than I'd initially thought, just like most things in gamedev (or programming (or life for that matter)). But I've now made it so that adding an extra language only requires an extra column in the localisation.csv file, two text files to be translated (for explanation and credits) and a new version of the logo. There is no need to do anything in code, since the game now auto-detects the languages that are in the csv file and adds them to the languages dropdown menu under settings. The fun of automating things aside, this prevents headaches from trying to find out how I programmed this stuff if, a year from now, I'd like to add another language like French (Clef, Pelle, Trésor anyone?).
Of course, the language I've translated the game to is Dutch. There's something to be said to translating this game to a language that my mom and my kids can actually read ;). Here's the Dutch version of the menu:

That's all the progress for now. There are a couple of things I want to do before I think this side project is done (enough). Having said that, I've certainly learned by now that there is no such thing as a quick side project for me. Not if the goal of the project is to build something I'd like to show to the world (by putting it on itch.io in this case). A valuable lesson I'd say. So valuable that I predict that this wasn't the last time I've had to learn it ;)

- Willem -

A while ago, I told you about our small side project, Pirate Game. Over the last couple of weeks, we've made quite a few changes to the game, so here's an overview.

First things first, we thought of a name: Key, Shovel, Treasure. We haven't definitively settled on this name, but I like it so far. The acronym KST has the sound of a fun game (using Key, Shovel, Pirates as a name would have made the reference a bit too obvious ;) and the Dutch translation alliterates nicely: Sleutel, Schep, Schat. Though I guess most of you don't speak / read Dutch. We'll let you know whether we decide to keep this name. I will use it in this post, since I think it's at least better than Pirate Game.

​In the first version of Key, Shovel, Treasure, the map generator wasn't able to produce any islands other than single tiles and straight lines. I wrote code that should, in theory, be capable of generating other shapes of islands, but there was a bug in there I couldn't find. Since the game worked well enough with those islands, I decided, after spending quite some time combing through the code, not to dig any further. Luckily, Michiel was able to help on this front, and together we got the map generating working as intended.

Compare the two screenshots below, form before and after the change:

​Before we made this change, I thought that this would primarily be a visual thing, making the map look better. I hadn't considered that this would also have a positive effect on the gameplay. With larger and differently shaped islands, it's no longer possible to access all land tiles from multiple sides. This means that on the new maps, you'll have to think more about where to go and when. If you don't, you probably won't be able to reach an undiscovered land tile every turn, thus losing opportunities compared to your opponents. On top of that, blocking your opponent becomes a real possibility. So fixing the map generator actually made the game more interesting.

And sometimes this made the game a bit too interesting, generating littoral corner cases as Michiel calls them:

Oops. That's not really a balance​d (or even fair) map. As is clear from this, a few iterations were needed to get the map generation to work as intended every time. A floodfill looking for sea tiles was the remedy for this specific bug.

Another thing I've been working on is a co-op mode. As I mentioned in the previous post about Key, Shovel, Treasure, my son and his friend wanted to play together against the computer. Of course I can't ignore a feature request from my son, especially since we designed the game together :). The gameplay only required two changes: the possibility to team up with others and the ability to transfer your key and / or shovel to a teammate.
Transferring items between players was pretty trivial. But adding teams to the game was much more work. Since I started Key, Shovel, Treasure as a programming exercise and didn't foresee that playing in teams would be a possible addition to the game, none of the code was made to handle team play. So I've had to make changes in nearly every script, from game logic to the map to the UI and the settings. Eventually, I got everything working (again).

On top of that, the AI needs to know what to do when in a team. I kept this pretty straightforward. The AI will hand over a key or shovel if it thinks that enables a team mate to claim the treasure the next turn. Other than that, the AI behaviour is still the same. Playtesting will show whether this is enough to ensure that the AI doesn't miss the most obvious opportunities.

Adding team play also meant that I had to redo the menu. This was on my list anyway, since it wasn't intuitive enough. The old and the new menus are here:

This works a lot better than the old version (imho), although some testing will be needed to see whether it's good enough. Also, I (obviously) still need to change the game name / logo to Key, Shovel, Treasure :). Changing the menu did take more time than I had thought it would. Part of that is due to the fact that I simply don't understand UI design very well. Another part is that I'm a lot more comfortable writing code than using Unity. Crating this UI was good practice on both counts. Michiel has much more of an eye for -and experience with- UI design than I have, so I'll recruit him to help me out here.

Beyond that, I've also made numerous small changes. Some more visible than others:

• The auto end turn code is now smarter, so if your turn doesn't end automatically there probably is something you can still do (if you don't want to do anything you can always end your turn by hitting enter).
• If the treasure is found by a player who doesn't have a key and a shovel, the treasure chest is still closed.
• Added the player colours to the settings screen
• The active player now has waves next to his / her ship.
• The default names for the four captains now are the blobbie names that correspond to that colour in Powargrid.
• You can now see a ship move, instead of having it skip from tile to tile instantaneously.

And on top of that, there are numerous changes deeper in the code, keelhauling bugs both new and old :).

That's it for now. There's quite a bit more on my list of things to add, so I'll keep you posted on further progress.

- Willem -

​What exactly does it take to draw one screenful of Powargrid? Quite a lot actually, which is why I've been working on making it faster. To make the game run smoothly, we would like to redraw the screen 60 times per second. A screen redraw is also called a "frame", so it's often referred to as "60 fps". Most monitors only update 60 times per second, so faster than that doesn't really buy you anything.

Simplifying a little (well... a lot), drawing the screen involves sending the geometry of everything in the scene to the graphics card, then telling it how to colour in the bits.

This involves your CPU repeatedly telling your graphics card, "take this can of paint and paint that wall." Now this is magic cartoon paint: you can have plain coloured paint, checkerboard paint, grass-and-flowers paint, and it can be dull paint, glossy paint, transparent paint, etc. In computer graphics, it's called a "material".

Each of these instructions to draw something using a particular material is a "draw call". Now, the graphics card is a very, very fast painter, but each draw call (changing paint cans) involves a noticeable amount of work. In short, it's much faster to paint many walls with the same paint (material) than it is to change cans for every wall.

In the beginning, we were painting every object on the screen with its own can of paint. That's not just each building - each building consists of at least four legs and a body. Even though all the legs of a building have the same colour, they still got their own can of paint, so we were quickly up to thousands of draw calls, making the game run quite slowly unless you had a fast CPU. In the meantime, the graphics card was sitting there, waiting for the CPU to hand it more paint cans.

The first step we took was to redo our models and make sure all the matching bits (like the legs) actually share a single material. Then, Unity can use dynamic batching to draw all the blue bits with the same paint can (one single draw call). Then, all the red bits get drawn in one go, etc. Big win!

However, then we wanted to use shadows, because shadows look neat. In our case, with a single light (the sun) casting shadows, everything needs to be drawn twice: once from the viewpoint of the sun, to know which parts of the scene are in shadow, and then from the viewpoint of the camera.
​Unfortunately, with dozens of buildings on the play field, all consisting of several pieces, rendering shadows for all those little bits meant it was still too slow. We couldn't just rely on Unity combining the draw calls for us. We needed to draw less things! We don't actually have to leave anything out, because graphics cards are so fast these days. We just need to draw bigger chunks at a time.

​So that's what we do now: we take all the bits that make up the game grid, and combine them into larger parts that share the same material. For example, all the powered red legs get combined into one big "everything that's bright red" object.

​When something changes (say, a building gets blown up) we quickly rebuild the combined mesh to take the changes into account. Some details were a bit tricky, and I was occasionally looking at "the ghost of buildings past" because something had been destroyed but was still in the combined mesh, or stuff would turn invisible for a fraction of a second as the mesh was rebuilt. However, in the end it was only about 200 lines of code, and the results are nothing to sneeze at:

​And that's just a simple scene, at the start of the first campaign mission. Without combining objects, the CPU had to make 574 draw calls, even though 733 were prevented by dynamic batching. With combining, the exact same scene takes only 179 draw calls!

So there you have it. Powargrid should run a whole lot smoother, with nice shadows, even if you don't have a very fast PC. Enjoy!

-- Michiel