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