[Devlog] Timely Transports

Ever since inventing a new genre of board games (the One Paper Games), my mind has been overflowing with ideas for innovative types of games.

In this devlog I proudly present the first result of all those ideas: a hybrid board and computer game!

(I don't have a strong name for this type of game yet. A comboard game? A "smart game"?)

The game itself is played on a physical board with physical pieces, but all players must also have their smartphone on the table and use that for many actions in the game. It took me a long time to figure out how to make this work, and accessible, and as fun as possible (instead of people just staring at their phones all the time).

So, in this devlog, let me explain the original idea, my steps in pursuing it, and how it finally let to the first game of its type: Timely Transports

(I'll explain the game in detail later. All you need to know for now, to understand the text below, is that it's a game about transporting goods across a jungle. The game boards are randomly generated on the website and you need to start a timer on your phone for each movement of your vehicle(s).)

How the hybrid idea works (taken from rulebook)

Where did the idea come from?

Lately, I played a lot of "Magic Maze" games. In that game, the sand timer is instrumental. When it runs out, you lose. During the game you can "reset" it, but only four times, and you usually need all four of those if you want to be successful.

Magic Maze (on Mars) in action

It reminded me of my love-hate relationship with sand timers. It is very easy to miss it when they run out. They can get knocked over by an enthusiastic player (certainly in a cooperative, all-around-the-table game like Magic Maze). But they also automatically add a time limit and a sense of urgency to any game, which is very useful.

So I thought: why aren't there any boardgames where all your actions are timed? Where you need to place a sand timer for doing something, and you must wait until it runs out to complete the action?

Turns out those games exist! I stumbled upon Kitchen Rush and Medic Rush.

The first game is basically the analog version of Overcooked (in case that game is familiar to you): you must gather ingredients, combine them, cook them, and then deliver them to customers for points. All of these actions work by placing a sand timer on the appropriate spot and waiting until it has run out.

I'm still waiting for these games to ship to my country, but when they do, I'll surely try them out, because they seem to be amazing, cooperative, family-friendly, accessible games.

Anyway, this got me thinking: instead of including twenty sand timers in a game box ... why don't we let the computer do this?

Computers are amazing at timers! (And numbers in general.) Instead of having loads of physical timers (with fixed lengths), I can just start a timer of any length on my phone with the press of a button.

And that's where the original idea came from. I wanted to create a regular board game, but with the addition of a computer/smartphone component that gives me great new possibilities, such as easy and precise timers.

Update: I just learned about the game Pendulum that Stonemaier Games is releasing. Seems like everyone is discovering the use of timers in games these last few years :p

Do we really need a smartphone?

In the rules of Magic Maze, it states that you should NOT use a timer on your smartphone for the game, as the experience is noticeably different.

And I like the inclusion of that warning, because I agree with it.

If I made a game which required only a single timer, yes, I would just include a physical sand timer. It's faster, easier to use and understand, keeps you in the game.

So, for my hybrid idea, I needed a very compelling reason to include smartphones. We're still in the early idea stage now, so if I couldn't find a good reason, I would've just thrown this idea into the bin and worked on something else.

The first thing I did was list the pros and cons of this approach.

Advantages of using a digital component

These were the main advantages I could find before and during development.

  • Memory. A computer can store and display loads of values, so players don't have to keep track of anything or calculate values in their heads. Most noticeably, it can keep perfect track of score.

  • Dynamic. Instead of having only a limited set of timers with a fixed length, I can create as many timers as I want, with varying lengths.

    • In fact, instead of having only one stage (full -> empty), I can chain stages. In this game (Timely Transports), when a timer runs out it goes into a second stage: overtime. This gives you 10 seconds to either click off the timer or upgrade your vehicle.

    • Of course, the possibilities go far beyond timers, but I want to keep it simple for now.

  • Fast Setup. Most people always have their smartphone at hand. With these games, you only need to take out your phone and visit a website, and you're ready to go. (As opposed to board games, where you'd need to take things out of the box, arrange them, perhaps hand out cards, etc.)

  • Sound. Surprisingly, this only occurred to me halfway development. Phones can play sounds! I can play a sound whenever something interesting happens in the game, and I can provide a general background track that suits the game and the theme.

    • This is a far greater advantage than you might think: when you're starting at the board trying to decide your strategy, the sound of an alarm bell is sure to bring your attention back to a new event on your phone.
  • Endless Possibilities. Seriously, I can display anything on a phone, and even make it interactive or use the internet! This allows countless innovative mechanics that have never been done before in gaming, which is at least worth exploring.

An aside about Timers & Psychology

An additional advantage to using timers specifically, is that the game is guaranteed to be quick (and end after a short amount of time) and simultaneous, without any dead moments.

If there's one thing I've learned over years of game playing and developing, it's that quick and (near) simultaneous games appeal much more to people than any other game. What turns people off, usually, is the "waiting on your turn" or "I don't want to risk spending the next 2 hours sitting at a table". Just a small nugget of wisdom.

(Additionally, if you have a general crowd instead of frequent gamers, cooperative games are your best bet. Many people are like "I'm just not a competitive person" and only want to play those types of games. And when they do, ironically, they become extremely enthusiastic and competitive :p)

Disadvantages of using a digital component

And these were the main disadvantages I could find before and during development.

  • Hard Requirements. It's highly unlikely, but possible, that someone doesn't have their phone, or doesn't have internet, or my website is temporarily down. This would render the game unplayable, as the digital component is absolutely necessary.

  • Too Many Screens. People are already sitting behind screens enough these days. I don't want to make "placing your phone on the table when playing a game" a normal behavior. I play board games (instead of video games) most of the time, because it's not behind a screen and because it's a live social interaction. I don't want my games to have a bad influence on people's habits or expectations.

  • Size Restrictions. Smartphone screens are quite tiny, simple as that.

    • When building the interface for Timely Transports, I had to completely rethink my design (and rewrite the code) three times, because the first three versions were just too small. It was hard to see icons at a glance, and it was easy to click the wrong thing.

    • So, lesson learned, I really cannot expect to have more than 5 or 6 elements on the screen. (Where an element can be an icon, or a score counter, or an event popping up.)

  • Loose Links. I cannot "connect" a smartphone with a piece of paper ( = the game board). I also don't want to connect multiple smartphones with each other, as that is hard to program and maintain, and makes the setup considerably harder. So, I can only design games where a loose link is enough to make them work.

    • For Timely Transports, I eventually decided to give each game board an identical number of cities (with identical names). That way, phones would automatically shout city names that existed on the board, regardless of the game board you printed or your player count.

    • Additionally, most of the information is on the game board itself. At first, I wanted the phones to determine which goods a city wanted to have. (For example, it would say "City X now wants Fruit for 3 points!") But ... this allowed the accidental possibility that, for example, all cities wanted fruit, and they wanted nothing else. Which would make the game boring or simply unplayable.

The First Version -- Space Shenanigans?

With a strong idea about how such a game might work, I went on a hunt for simple gameplay ideas and accessible themes.

My first pick was a cooperative game, where everyone is on a spaceship together. During the game, you can place tiles to extend the ship and send people on missions, but all those missions and extensions cost time.

Additionally, events would regularly occur, such as space pirates entering your ship or a meteorite damaging it.

The rewards for your missions (space credits, probably) could then be used to buy things in the shop on your phone.

The idea is still promising ... but I was already making it way too complex. This has at least four or five interconnected unique systems, whereas I still didn't know if the original idea would work at all.

So let's simplify. Let's think.

What always costs time? And what has an immediate negative impact when it takes too much time?

Ah, I know: traveling! (Or, well, my first thought went to: hmm, packages that arrive too late are annoying. But even that lead to a more complex game design than I wanted for my first hybrid game.)

The Second Version -- Timely Transports

So here's the reason I think this theme is ideal.

In the real world, traveling takes time. Additionally, different vehicles or routes take different amounts of time.

If you take too long, the negative consequences are obvious. Someone else will arrive before you, stealing your points. Or your cargo will go bad (if it's something edible or fragile or whatever). And if you are slow once, that will lead to a chain reaction where you're constantly too late.

Without any extra rules, such a game would work and heavily rely on timers. People understand how it works and why there's a timer to everything.

(That's also the reason why I think those cooking games work wonders. People know cooking takes time, so it's only logical to put a timer on it, and force them to do something else in the meantime ... possibly causing them to forget their original project and let the kitchen burn down.)

There are many games with modern transportation or semi-modern vehicles (like the old steam trains in Ticket to Ride). Let's do something different. Let's go ... traveling through the Jungle!

(This was partly inspired by the font I chose. It just gave that Jungle/Rainforest/Indiana Jones vibe, and I liked that.)

Finally, we've arrived at a working concept: you are transporting cargo across the jungle. For each movement, you start a timer. Once it runs out, you can finish the movement and go to the next space. Delivering goods to cities that want them yields you points. The first to 20 points wins!

To give you a preview, this is how the game board and interface looked at the end of development:

Randomly Generated Board (taken from rulebook)

Game Interface on phone, right at the start of the game

The Obvious Inclusions

With a game like this, many of the early choices I made seemed kinda obvious. Nevertheless, they were very easy to add and explain, and make the game as good as it is today:

  • I need different types of routes on the map. Why? So you need a specific kind of vehicle to travel it. (Only boats can move over water, only trains over railroad, etc.)

  • I need different goods with different characteristics. Why? A low-value good will appear very often on the map. A high-value good will only be accepted by a handful of cities. This automatically adds variety, an interesting choice, and a fallback decision if you're having a tough game. ("Man, I just keep missing out on those high-value ones. Maybe I'll just very quickly deliver five low-value things.")

  • I need events. With everything fixed on the game board, I need some more variety. Prices should fluctuate, weather should influence traveling, that kind of stuff. I decided to make events pop up at random that say something like "City X doesn't accept any goods anymore", which automatically went away after 30-60 seconds.

  • I need upgrades/stuff to buy. This would add a necessary sense of progression to the game. After moving 5 goods in a row with your boat, you want to do something else. So I wanted to include the possibility of upgrading your current vehicles or buying new ones (which would be faster).

Overview of all basic vehicles + upgraded version (taken from rulebook)

All these things were immediately put into the game, and stayed there, because they worked. (Nevertheless, I do try to push myself to diversify, as I introduce these concepts a lot in all my games.)

I did eventually make several "difficulty levels", and only introduced the more complex mechanics on higher difficulties. This works all the time, in my experience. It makes the game super simple when you play it for the first time (or with a new group of people), but doesn't take away any of the super fun and interesting stuff I also wanted to add.

Problems, Problems, Problems

And then, as usual, problems started to appear.

Problem 1: Too little space! The game board was getting cramped (the one you should print and play on), as well as the game interface (on your smartphone).

So, let's forget the idea of buying new vehicles, because I simply don't have room for them. Let's cap it at four vehicles, which you can upgrade.

Let's also reduce the number of routes and airports. In fact, let's not display an icon for airports, and just display an underline below the city name.

While we're at it, let's zoom in on the board on lower player counts, so everything is bigger and clearer.

(I tried, but with 8 players you'll have so many cities on the board, I can't make it any bigger than it is. I propose printing on A3 paper if you can.)

The work I did on randomly generating a playable jungle with cities is a whole topic on its own! So I'll probably write a separate devlog or chapter on that alone. (Spoiler: it's really hard, and messy, and takes a lot of experimentation to get right.)

Problem 2: Loose Connections! Remember when I talked about this disadvantage?

It might seem obvious now, but at the time I really didn't know how to proceed. How to make sure the phones said sensible things? Even if they didn't know the game board at all?

It took me a while to acquire the current solution:

  • Given a certain player count + difficulty, the board will always include the same cities (with the same names) and goods. The board is still entirely random, but at least there's the name of cities and goods that will always exist.

  • Each city's desires are printed on the board. (But events can change this temporarily, to an extent.)

  • Airports are only placed when they are necessary to connect all cities. (Otherwise it was too easy to just fly anywhere. Also, airplane connections are the hardest to visualize for players. All the other connections have a clear line from A to B, but plane connections are just "yeah, teleport from A to B")

    • In fact, as I write this, I'm wondering whether I should move planes to a higher difficulty level. I can easily imagine people getting overwhelmed by learning how four vehicles work on their first game. Even if they are extremely simple and intuitive.
  • Forests! Surprisingly, placing forests in the world gave the board a lot of clarity. Routes were easier to follow, because they had less space to wiggle around. It was easy to see where a city was, because it surely wasn't anywhere in that big forest.

    • It also sped up the board generation, because I didn't need to check any possible paths through forests. But that is, again, a whole topic on its own.

Problem 3: Too little space, again!

When I thought I had the space problem figured out, I found a few new issues with the game board by simply thinking it through.

I was like "Okay, so, how many cities do I need with each player count? Suppose we have ... 6 players, would, say, 6 cities be enough then?"

Then I remembered each player had 4 vehicles. With 6 players, that's 24 vehicles, moving around the board all the time. Not to mention actual goods lying around as well. I don't think 6 cities is enough.

Thus, I invented a (very scientifically sound) rule of thumb: on average, there should be at most three things on a city. With 6 players, that means 24 vehicles, and about 6-12 new goods per minute. (The time between new goods is slightly less than a minute, per phone.) So, worst case, 32/3 = 11 cities.

For what it's worth, all tests and generated boards so far have been quite balanced, so I have reason to believe this will all work out in the end!

Vehicle Movement

Now the final aspect. The most important aspect to get right, because moving vehicles is all you'll be doing in the game. (When writing the rules, I realized it's literally the only type of action. Which is always a good thing, as it made the rules super simple.)

In my head, there is always this four-sided die of navigation: car, train, boat, plane. (Which also happens to rhyme.)

I used this again, because even after all my research into jungles and their transportation, this still seemed the best option. (I mean, I considered making people hop on the back of monkeys, but that just didn't work out. For too many reasons to mention.)

So everyone has four vehicles. This means we need three road types and airports. When moving, simply start the timer, wait or do something else, and when the timer finished, actually move to the new location and stop the timer.

You can always take one good from your current city with you. And while you're moving this good ( = it's placed on your vehicle), nobody else may touch it.

How to move over the board, with a timer (taken from rulebook)

Thankfully, the hybrid setup helped me here. I didn't need to give vehicles any other properties, because the computer could take care of that.

The different vehicles have slightly different timer lengths, but players don't need to have that explained to them. They just click on the matching icon, and a timer will magically start and do everything for them!

Also, because each vehicle was unique (you couldn't purchase a "second boat"), you always knew exactly what each icon (and timer) was referring to. Tap it to start the timer. Tap it to stop the timer. Simple stuff!

One Last Problem

There was just one problem left: how do I get a boat from A to B ... if there's no route that's 100% over water?

(More generally, how to move vehicles to cities if there's no route towards the city they can travel themselves?)

I found two solutions this time, which are both in the game!

First solution: vehicles can also be used as goods. So, you can literally transport your boat to another town using one of your other vehicles. This automatically turned the game into a much better and bigger puzzle, as you now need to plan ahead to get your vehicles where you want them to be.

Second solution: each player receives a capital. I needed that anyway, to give players a city to start from, and to make the world feel more alive. (Players want ownership and customization! Give them something that's theirs.)

Moving a vehicle as a good (lower half of the image)

(This image is taken directly from the rulebook, so it also includes another rule I will talk about soon: bumping other people off the board.)

But this allowed the Teleportation Rule to be added: at any time, instead of moving over a regular connection, you can teleport your vehicle back to your capital. (This follows all the same rules as moving: you still start a timer, wait, etc.)

It's an extremely simple addition, but it helps out a lot. When you're stuck, you can always just decide to go back to home base and navigate your way back into the world.

Before the playtest

Before I test a game, I always have some things I want to check or confirm. I have doubts about certain mechanics, or ideas for more interesting rules, and I need to see if they hold up.

This time, this is what worried me:

  • Space! Still! I just don't know if, on larger player counts, the board will become a huge unplayable mess. It could be fine, I just don't know yet!

  • Stress! I don't know if the timers add more stress than some players can handle, or if players will go the other way and just ... relax and do nothing while they wait for one specific vehicle to finish moving.

  • Strategy! The game hinges on fast-paced decision making. The person who wins, is the one who can manage their time (and vehicles) better than the rest, and who is more alert to the current board state, new goods and other events. I don't know if this is enough, or even very interesting after several plays.

    • As such, I was toying with this rule: only 2 vehicles may occupy a city at the same time. (And maybe, in expansions, different cities could have a different capacity.)

    • This makes the game much more strategic. If somebody is blocking your path, you must go do something else or find the quickest way around it.

    • It also solves the space problem.

    • (An additional rule could be: during movement, place the vehicle halfway the route you're moving on. This would remove them from their city and spread more evenly across the board.)

As you can see, all these things could be fine, you just can't know until the first few playtesting sessions.

So let's go!

A Quick Intermezzo

Update: I just had this amazing idea!

It's quite easy to reduce the stress level and the number of mistakes people make ... if I just build a "break" or "time-out" function into the game! Just spewing my first thoughts here:

  • Option 1: the interface is programmed to always start a break after 5 minutes of play. To end this, either wait 30 seconds, or press "continue playing" on your phone.

  • Option 2: there are squares/locations on the board. If you pass them, you can call for a break. All players can pause their interface, and you can collectively have a break and discuss things for as long as you like.

  • Option 3: breaks are completely voluntary. It's a button on the corner of your device, so anyone can press it and yell "Time-out!" so the rest does the same.

I think this would be a wonderful feature (if I make it optional in the settings). I can already imagine people relaxing when I explain the game and tell them "don't worry, in this first game, you can start a time-out any time you like".

By the way, this is the primary reason I write devlogs and would urge anyone else to do the same. I only got the idea(s) above while writing this devlog for an hour, but not in all the weeks of development before. Writing about your thought process and reasons why you did (or did not) do something is so useful for figuring things out and getting new ideas.

First Playtest Session!

Finally, finally, the time has arrived for the first official playtest!

(Of course, as I develop, I try the game, check if anything's wrong, etcetera. But this is the first play test with the full game, with everything finished and working, with a new group of people that have never seen the game before.)

IT WENT AWESOME! (... is that even a correct English sentence?)

The game was really fun, easy to explain, easy to get into, fast, (mostly) intuitive. I played a handful of games in succession, each time changing the rules a bit to test my doubts I wrote above.

This was the conclusion:

  • Starting with all four vehicles on your capital ... is overwhelming and actually a dumb idea. Let's gamify it: you start with only one vehicle on your capital. To add a vehicle (from your supply) to the board, you must use a timer as well! It has the exact same rules as moving a vehicle, now you're just moving it from your supply to your capital.

  • Everyone forgot the rule about "you always get 1 point for moving a good". So I just removed it, because the changes below made sure it wasn't needed anymore.

  • We really need a timer on the "New Good!" message. Otherwise, players will miss it or simply ignore it (because they're busy with something else), which is unfair. It means they get an advantage while putting the other players at a disadvantage ( = there are fewer goods on the board).

  • Yes, it's way more intuitive to put a vehicle halfway between city A and B, when you're moving from A to B. It also frees up lots of space on the cities. (And when moving a plane, just put it in front of you or whatever.)

  • That rule about a maximum of vehicles per city? I know something even better now! Whenever you enter a city that already has a vehicle ... bump that vehicle off the board! Because I added this simple rule about "adding vehicles back to the board", I could allow vehicles to be removed from the board all the time.

Especially the last addition is a huge one. (As in, it's a really simple addition that solves almost all problems the game currently has.)

It gives a lot of space and clarity on the board, whilst introducing an interesting game element: will you go for the good, or will you bump a player's vehicle off the board to set them back in time? And if you want to prevent that, you need to keep all your vehicles busy with something all the time, which is even more challenging.

(It also removes that "Teleportation Rule", which means one less rule to explain and one fewer nasty exception in the rulebook.)

Lastly, I saw that people became really enthusiastic and engaged whilst playing. They were 100% focused on moving goods, checking what's new, checking what the hell their airplane was doing in that city, frantically pressing timers on/off on their phone, and just having a good time.

People also became better at the game, within just a few rounds. They learnt to make better choices, use more vehicles simultaneously, position them at locations where goods are more likely to be useful, etcetera.

Our first game, we quickly became overwhelmed by the sheer number of resources on the board. In the last game, there were a few moments when everyone was so efficient, that all resources were off the board. (Which caused me to make the resource timer slightly faster.)

Bugs, bugs, bugs

Of course, when creating such a complex interconnected game with both physical and digital components, there are going to be some first-time problems.

Some example problems:

  • Some phones did not play audio. (Apple ... why don't you just update your technology like the rest of the world?)

  • The phones were using all cities, even on lower player counts, which was confusing (because it kept giving us goods to place at cities ... that didn't exist on our current board).

  • The board generation always placed an airport at the first city (Al Riz). That's not only a bug and boring, it also gives the first player a huge advantage, as their capital has an airport while the rest probably doesn't.

  • Some elements of the game weren't paused when you won. (Which means you could still lose points after winning, bringing your total back to a value under 30, creating a mess.)

But after 60 minutes of programming, these were all fixed!

Additionally, I noticed that larger player boards were actually ... more fun? I thought it would become a mess quickly, or just too hard (because there were so many cities to go to), but the opposite was true. I played one game with 2 players on a 4-player board, and it felt more engaging, because you were actually exploring a larger world and occasionally bumping into players who were traveling all over the board.

It just felt like actually moving through a jungle, discovering new paths, sometimes bumping into friends (or, in this case, competitor transport companies), and planning ahead (to optimize your vehicle movements through this large space).

So, I might just increase the default number of cities and connections, on all player counts.

The airport was a bit hard to see. Then again, I printed everything in black-and-white, and I keep getting surprised by how dark everything becomes. As such, I'm currently working on all the icons again to use brighter colors (and testing it with a black-and-white adjustment layer to see how it would look).

Luckily, I did plan ahead for this, and my randomly generated "print friendly" boards looked very good. Easily readable, as little ink wasted as possible, I don't think anyone ever had a hard time finding a city or route.

All in all, this is a big success!

(It feels ... kind of arrogant to say all of this, but I really mean it. I'm happy that this very experimental idea actually works and speaks to people. I cannot wait to fix all the bugs, improve all details that need improving, and play the game again. And then the expansions!)

A Quick Intermezzo, again

Man, I just keep getting the best ideas while writing devlogs.

Remember when I talked at length about how hard it is to "connect" phones to a board game?

Well, stupid me somehow forgot the most important tool in random generation: seeding.

A seed is a number you feed into your random number generator (in your programming language), which determines the sequence of numbers that comes out.

If you randomize the seed as well, by e.g. taking the current time on the computer, that's how you get random numbers.

But if you keep the seed constant ... any device should get the exact same sequence of numbers. If I tell my game "use seed 10", it should always reproduce the same sequence of numbers, which means it should get the same results during generation.

See where I am going with this?

I can print the seed used in random generation on the game board. Then players could type this exact seed into their phones, and both should know exactly what the board looks like and what they can and cannot do!

(To make this more straightforward, I could use a random word as seed, and then just convert that to a number behind the scenes. It's way more fun to type "JUNGLE" into your phone before playing a game, than "1903910690928")

I could go even further and ask players to enter their player number. (A simply prompt at the start of the game saying "which player are you?" with a dropdown list of numbers 1-8.) Then I could show different events at different times, based on player number.

How can this be useful? Well, currently, new goods are announced completely randomly. This could mean that all players get this message at the same time, creating a bit of chaos on the board. It could also mean that, just by chance, nobody gets this message for two minutes.

If I know which player is which, I could time these events and space them out nicely. First show one to player 1, then another to player 2, and so on.

I don't know if I'll use this in Timely Transports. It would require rewriting a ton of code, whilst I don't see pressing benefits at the moment. But future hybrid games will certainly use seeds for cool features!

Second Playtest Session!

Fortunately, everything I explained above are indeed improvements to the game!

The board is clearer (fewer vehicles doing nothing and creating a mess), you need more strategy and simultaneous vehicles to win. It's a simpler game, but harder to win.

I also got to test some expansions.

The first one (Vehicle Fun) adds upgrades to vehicles. For example, your canoe can become a kayak, which will travel way faster ( = always has a shorter timer). I'm not sure if the current price for upgrading (5 points) is worth it, but it added interesting choices to the game, and I eventually won by getting a kayak and zooming across the water all game! (But I only won by a few seconds.)

The second one (Extraordinary Events) adds events to the game. These were also fun, although I can see them becoming overwhelming on high player counts. That's why I eventually decided to implement the setting above that spaces out events evenly.

The third expansion remains to be tested, although I'm quite sure it will work (given that it's the least experimental/complex of all the expansions).

Lastly, I noticed that the board is way too small for high player counts. A single A4 paper (or Letter paper size in the US, if I'm not mistaken) is just too small for more than 4 players to play on concurrently. Additionally, I'm quite liking the boards my website generates -- so I added an option to print a larger board!

The website cuts the board into 4 pieces for you, which you can just print separately, and then combine on the table.

Update: another thing I noticed, but I'm still not sure how to fix, are asymmetric starting positions. On each board I generated, there was always one capital that was just clearly a worse option than the rest. Maybe it had no airport, or only 1-2 connections, or you could only deliver 1-2 (of the four) goods in that section of the board.

It's not such a big deal, as fewer connections also mean you'll be left alone (instead of being harassed by vehicles from other players), and you can plan a strategy to use this to your advantage.

But I'm leaning towards this addition: the computer calculates a value for each capital. It creates a "connection group", which contains all cities with a direct connection (no airport needed). It then counts the number of cities/connections/goods -- the higher this value, the more valuable the capital, because you can go anywhere and do anything from there!

Finally, the capitals with the worst value get a bonus. Just a simple "+2" or "+3" mark on the board. This is the head start that these players receive by having a worse position.

Final Playtest Session!

I did a final series of playtests with the game in its full glory.

It was great!

The game just ... works? I'm quite surprised as well, usually it takes way more playtesting rounds. (My previous game, Wondering Witches, took a looooong time to develop and get right. That might also be the reason it was probably the best game I've made so far.)

But it's just a simple and fun game, whilst being innovative and the first of its kind (as far as I can see), and accessible to anyone. Anyone understands moving goods and getting points for it, and everyone understands that such a thing takes time and thus requires timers.

The rulebook is only 2.5 pages, including images and examples and extra clarifications. (The fourth page is for expansions.) As I develop more games, I come to see 3 pages as a maximum for these kinds of games, so I'm happy with that. (More difficult/strategical/long games can go over, but surely not longer than 6 pages.)

Does that mean the game is perfect? No. It still lacks some spicy interaction, because everyone is watching their phone (or other player's phones) quite often.

The game mechanics are somewhat imprecise: what do you do if two players arrive in a city at the exact same time? (I've learned to be lenient in those cases: just allow them both. But it's still an annoying issue to have.)

And I don't feel like I've gotten full use out of the smartphones or the original game idea, but that's to be expected for a first game of this type. As I'll explain below, this is just the first step towards discovering how to make these games as good as possible.

For example, the game is not as chaotic/hard as it could be. It rarely happens that someone lets a vehicle or good timer run out, because with a bit of focus and planning you can achieve quite a lot. (On the other hand, I usually play with experienced gamers, who are up to any challenge. More than someone who's played fewer (board)games in their life.)

But hey, that's fine, because the game is still fun and it's still hard to beat your opponents! I just think that a game with a higher skill ceiling should be possible with this system.

Where to go from here?

Yes, this hybrid idea has some drawbacks. It introduces screens into board games, when many people play board games (instead of video games) to get away from screens. In all the games I've played, there were moments where people were too enveloped in their screen and not even looking at any other players around the table.

I try to combat this all the time. I try to watch out for this and keep my work as "analog" as possible, force people to come together in real life to play my games, to socialize -- all things I hold in high regard. So it's not perfect, but in my experience so far, games like this do not tip the balance in the wrong direction (yet).

Such hybrid games also add some requirements (such as having a phone and an internet connection, even if only for a second to open the website) and a slight disconnect for some people (who aren't as comfortable with games or devices).

But it also has clear benefits. This game I made is a lot of fun to play, extremely easy to setup and explain, and has infinite replayability (with randomly generated maps, events, and more). All of that, just by connecting game types from two different domains (analog and digital).

The future looks bright! (Yes, I know, I'm being dramatic.)

I'll continue working on these hybrid games and exploring their possibilities. Most importantly, the next game will probably only require one device (instead of everyone needing their own device) and be way more connected (learning from my mistakes during this development).

As it stands, I'm thinking about a simple "cooking" game. The restaurant itself is completely analog: it's a set of tiles on the table, with chips/cubes/whatever as food and ovens and waiters. But everything you do costs time. So a single device should be placed on the table which can take up to 10 concurrent timers (and keep track of score and all that good stuff about these hybrid games).

As I said in the intro: it's been done before, but it's just such a good application of the idea to a theme, and I need something to hold onto whilst doing these experimental games :p Seriously, I keep doing projects where I have absolutely no examples or previous projects to learn from, and it's hard.

As for this game? It's as good as done, because everything works and looks good and it is fun to play and easy to learn, and that's really all you can ask for in a game.

Nevertheless, being a perfectionist, some improvements might be made in the future:

  • More diverse map generation => now it's just three route types (car, railroad, boat) and three terrain types (land, water, forest). There's way more to do. Could even include pre-designed buildings or cities that just look really good.

    • Here's a very fun thing I discovered while coding! My code generates random numbers for the terrain. If a number is below a certain threshold, it is water. Otherwise, it's land.

    • I have a variable called waterLine that controls this. It's currently -0.4. But, if I set this to a higher value, suddenly the whole map becomes a sea with cute islands!

    • This completely changes the look and feel of the map, which is something I can experiment with more.

  • Connecting everything more (using the "seed" idea explained earlier)

  • More events and varied situations on the board. For example, I might add special locations halfway routes that trigger when you cross them. These might do positive things (you may carry two goods over this route!) or negative things (your vehicle breaks down!)

Anyway, until the next devlog,