Split Safari (Devlog)

Welcome to this diary with my thoughts and process for the game Split Safari. It will be a short one, because the idea came together very quickly and I only have interesting things to say about some parts of the execution.

What’s the idea?

I was assembling a list of game ideas for the topics of Comparing & Grouping. They’re the final topics in Level 1 Mathematics and very common skills to practice and explore with 3–5 year olds.

I had basically finished the list—and already thought I had too many ideas and would have to skip some—when I had a game night with friends. They presented some new games. Even though we didn’t play them, we still discussed how they worked and/or read the description at the back.

One of the games was built around the well-known “I Cut, You Choose” mechanic.

• One player cuts a group of things in two. (Cards, Points, Tokens, Whatever)
• They present this to another player, who chooses which of the two parts they want.
• The other part is then returned to the first player.

This is a simple mechanic for interaction and resource distribution, which has the nice property that it “balances itself”. When cutting, you have to try and make two equal groups. Or, at least, one group that you want to have and one group the other player wants to have. As such, no matter what cards you’re randomly dealt, you will be able to do a meaningful action with it and try to get the most out of it for two players at once.

And so I suddenly realized: wait a minute, this is perfect for a game about comparing and grouping!

• You have to create 2 groups yourself.
• And then you have to compare the groups you are presented and choose which one you like the best.

And so I wrote down an idea to turn this into a game. And it became so good that it was actually the first game I fully designed and finished for this topic.

Scoring Troubles

There’s one major issue, however, with all games designed for young kids (who can’t count yet). How do you score points? How do you track score, or whether you’re winning, in any way?

Over the past few years I’ve discovered several ways to get around this. For this game, I picked the “racing” solution.

• We add a map to the table, with spaces showing different types of nature. (Different “biomes”.)
• The cards in your hand are all animals. You move over the map by simply playing the right animals: a sheep gets you onto a grass tile, a penguin gets you over snow, etcetera.
• The first player to finish wins!

This is basically the whole game. Every round you draw new animal cards, cut them into 2 groups, and your neighbor picks the one they want (and the other returns to you). Then, you may use the cards you have to move your pawn.

The fact that moving is optional started as just an intuitive decision, but it turned out to be the thing that actually pulls the game together.

• There’s a good chance you just won’t get anything useful on a single turn. It would be annoying if you have to throw away those cards and do nothing then!
• Instead, over 2 or 3 turns, you can collect a few more cards and it actually becomes very likely that you can move in some way.
• But remember … every turn you cut all your cards in 2 groups, to present to your neighbor. So the longer you wait with moving, the more your neighbors are going to pick those extra cards off of you. It balances itself!

This is the entire base game. The expansions simply add more possible biomes, more animals (with special abilities), and a few variants for cooperative play and such.

Great! Let’s make that!

Picking Animals/Biomes

When I started to design the actual cards/map, however, I had some more decisions to make.

• When introducing the game, we want to have a low number of animals/biomes. Certainly no special cases or abilities.
• Buuut the game quickly becomes boring/monotone if there are only 3 or 4 different cards, or different ways to go on the map.
• Okay, so we can perhaps give animals multiple biomes they can walk over. This allows us to play the game even with a small (sub)set of animals.
• Buuuut this makes the game slightly harder for young kids to understand, while ruining the distinction between biomes. It doesn’t matter that we have TUNDRA and SNOWY MOUNTAINS … if both can be crossed by the same animal at the same cost anyway :p

So, I decided to split the material into “A” and “B”.

• For your first game(s), only use “A” map tiles and animals. Those map tiles only contain a few biomes, and the animals are all one-on-one too. (“Sheep = grass”, “Penguin = snow”, etc. Much simpler than explaining “some animals can move over 2 or 3 different biomes!” in a first game.)
• Once that is understood, you can include “B” tiles and animals too. Those map tiles contain the full range of biomes, and it adds a lot of unique animals (that might only appear once or twice) with a unique thing they can cross.

Because there are so many animals now, I decided to put the biome which they can travel on each of their cards. Pretty clearly visible, too. As large as possible, in fact. (They used to be small icons in the corners, but that’s just not good enough now.)

I had ~15 biomes planned, but I always knew that would be too much. With pain in my heart, I brought it back to 10 in total. Some of them are very common, others very rare. And for the “A” version, it’s just 5 biomes and 5 animals.

I was also reminded of an old game called “Elfenland” where different routes had very specific costs. (Like, pay 2 of this and 1 of that to go through the mountains! Or pay 3 of this same thing!) They had this nice “reminder” card with a table of all costs, which everyone constantly used throughout the game.

As such, I also added something similar: “Travel Cost” cards. They are optional—you can play just fine by just looking at your animal card and seeing where it can go. When added, though, they show a table of what everything costs. This allows far more dynamic and creative costs, like “You need TWO bunnies to go through grass”. Having 10 biomes, however, they don’t all fit on one card (in a nice way). So I simply added the rule that “any biome not mentioned can be crossed by paying any one animal”.

Start & Finish Tiles

If you know the game Quest for El Dorado, then you can clearly see how that inspired the design and look for this game.

That game uses hexagonal map tiles that are 4 spaces “wide” on the edges. At first, I simply copied that, and it looked good … but wasn’t practical for my specific game.

• It made spaces quite small, which meant pawns had to be small, which could be an issue when playing with young kids.
• Because my game has a higher variety of biomes/movement, it made the tiles look quite busy.
• On the other hand, because movement is much simpler (“1 animal = move over 1 tile of that nature” always + players DON’T block each other in the base game) … it doesn’t make much sense to have large areas with the exact same biome on the same tile.

So I shrunk them down to be 3 spaces “wide” on the edge. I also simplified by having only 4 “A”-type tiles in total, and just telling you to use them all for your first game. (As opposed to having 6–10 “A”-type tiles and saying “Pick however many you like! But about 4 is recommended!” to new players)

Additionally, Quest for El Dorado simply has a “starting tile” and “finish tile”. Again, that game can do this easily because of its rules and logic, which is why I copied that setup initially. But my game can’t really do this.

• Players don’t start with a default “deck” of cards. So there isn’t one biome that players are guaranteed to be able to travel, so I can’t make my first tile 90% that biome.
• I want to support a high player count. With fixed starting locations on a tile, it would mean some players start behind other players, which can be perceived as messy and unfair.
• I generally design game for maximum variety and dynamics, so I dislike having “fixed” spaces on tiles or “fixed finish spaces”. It would allow you to simply memorize the final moves of the game, and then … wait until you randomly get the right cards (or be annoyed if you don’t). Which isn’t great.

So, instead, I created separate “strips” of hexagons. Start strips and finish strips. You pick one of each and simply attach it at the front and back of the map. This means the map is truly completely different each time, and we don’t have to compromise on space or fairness or anything else. It also simplifies the setup again because I don’t need to explain which specific tile is the “finish tile that should be placed last” and so forth. (And it opens up opportunities for special actions/powers such as “move the finish strip to another spot” :p)

Creating Everything

Now I just had to create the actual map tiles and cards, which meant deciding how often something appeared. (And what 2/3 biomes the “advanced” animals could cross.)

Sometimes I create actual simulations or spreadsheets for this. When it’s feasible and practical.

This time, however, I just tried to make unique and good-looking maps. For example, one map tile that is a mountain range with two different biomes on the two sides, and one map tile that’s ocean with some islands. After making that, I have a rough distribution of biomes, and I can simply let the animals match that.

The “A”-type animals obviously appear the most. We need that deck to be thick enough to easily play the game without all the extra cards. In the end, I settled on 48 cards for that. It means, in a 4 player game, that you can go 3 whole rounds without anyone moving before you’re out of cards. At which point you’re all forced to move. I tried to make this a little higher, such as by adding one more animal that appears a lot and can move over all terrains. But it would balloon the material requirements and make your first game slightly more complicated, which just wasn’t worth it.

Let’s hope people understand that, after a few games, they should add all the other cards! (Which brings the total number of cards, at time of writing, to 96. Which is the absolute maximum I’d ask anyone to print and cut out, even if the cards are small and pretty.)

It took quite a while to actually get all these materials ready and polished. But there’s nothing interesting to say about that, so let’s skip to the end.

A Note About “Expansions”

Most of my game ideas nowadays have a really strong “core system”. In fact, I believe getting good at game design is all about understanding systems and designing good systems, and everything should start from there.

In this game, the “core” is obviously “split cards, pick the group you like the best, use that to move over map”.

When a core is so simple yet powerful … it is very easy to use it like a coat rack and hang absolutely every other idea on it too. Special animals? Check. Special action spaces on the map? Check. Multiple pawns? Check.

It’s so easy that I’ve also had to learn when to stop! I had even more ideas for modifying and expanding this core system, but after some thought I decided to move those to a new game. One that could share the same art and name, sure, but it would be a unique standalone game with those new ideas.

For example, an “obvious” expansion would be to allow players to modify the MAP. Don’t have cards to go through water, but you do have cards to go over mountains? Use THIS ACTION or THIS RULE to change those water spaces to mountains!

This is certainly fun and powerful. It’s a kind of reverse race: “Your journey is already set in stone, you have to terraform the map to make it work.”

But it’s also very far removed from the actual core of this game. It would require loads of new material (extra hexagons to cut out, so you could place them on the map tiles you changed), a complex new system of rules for how to deal with this, etcetera. It’s just not the same game anymore, so I planned to create a “Dig Safari” or something at a later stage.

In general, after creating tons of games (also for the online store), I’ve landed on the following practical limits for my rulebooks.

• 1 page for the entire base game (setup + objective + play, including images)
• 2 pages for all expansions, variants and other modes (such as a cooperative mode in an otherwise competitive game)

Any time I went beyond this it turned out to be a bad idea. When my rules exceed 1 page, I usually find ways to simplify and streamline later. When my expansions exceed 2 pages, I usually realize I’ve just tacked an entirely different game on the end of this one.

And so, as stated, all those extra ideas went to a later Safari-themed game and the current one stopped after 2 pages of the most sensible and related expansions.

Conclusion

As is so often the case, my greatest struggle here was with the fact I wanted to add too many cards/animals/biomes. I tried to find a balance that keeps your first game(s) incredibly simple but still playable, while later games can blossom into longer routes and a wide variety of ways to travel. I’m not sure if I succeeded, and I feel there’s still slightly too many biomes and unique animals. Until the final time I hit “Export to PDF”, I kept tweaking ways rules were phrased or details on map tiles.

At some point, however, you have to say “I’ve worked on this long enough, it’s done, let’s move on!”

I think the game looks really good. Colorful, varied, attractive to kids without overdoing it. Yet the cards and map tiles are very simple, and setup + explanation should take no more than 5 minutes (even with really young kids), and I’m glad I was able to rein in my worst habits and keep cards clean and simple. Just the animal, the biomes it can travel, and a very subtle layout detail, and that’s that.