
Pirate Drawingbeard
This is a devlog for my game âPirate Drawingbeardâ
Itâs kind of a âprequelâ to my game âPirate Riddlebeardâ.
Why?
In the original game (Pirate Riddlebeard), each player received text hints. When combined, theyâd point to the one square containing the treasure.
This had several downsides:
The game canât be played by kids or people with a bad command of English
The text hints take up a lot of space and can be misread
Which also meant it took longer to check the hints or write notes while playing.
As such, I decided that the original game was the âadvanced versionâ. Text hints do allow for more advanced maps and more advanced hints, so I took advantage of that. Especially with all options/expansions enabled, that game can take quite long and be a really tough nut to crack.
But I really wanted to try a simplified version of the game idea.
This became Pirate Drawingbeard.
What do we need?
I learned a lot from developing the original game. Letâs try to prevent making the same mistakes:
Make everything in the map and hints customizable. (I usually start too complicated and need to scale back later.)
Donât create a map where each cell can have multiple properties. Create a map where each cell is one specific thing.
Consider the hint cards from the start. Ensure thereâs enough space, thereâs already a grid for taking notes, etcetera.
Split the visualization and game logic into separate scripts behind the scenes.
Figure out how to visualize a hint with simple images/icons (no text, no numbers) and write some clean code for checking those hints.
I created these sketches to get an idea of how this game will work:


Map
Being somewhat of a âkids versionâ, I wanted this game to be more tactile, perhaps use smaller maps.
After some consideration, I decided: this game should be played with physical tiles.
So you can:
Either download the material PDF, print and cut it, and reuse that for all games from now on.
Or grab an empty piece of paper, draw the board, and cut out the individual tiles.
Yes, the minor disadvantage is that you need scissors at some point.
But that doesnât outweigh all the advantages!
Advantage #1: Better main action
Firstly, the âpropose/changeâ action from the original game can be improved. This is how the original works:
PROPOSE: Pick a tile (A). Propose to change anything about the tile, whatever you want. Pick a tile (B). Ask players if changing A changed whether the treasure could be in B.
The idea behind this is that you can slowly test what hints other players have. Remove a flower from a tile, check a tile close to it. If somebody says âyes, that changes my answerâ, you know their hint has something to do with flowers and distance.
But the action is a bit hard to grasp the first time you play. I mean, you really need the image from the rulebook to understand how it works. The text explanation is a bit clunky.
This can be changed to a âswapâ action.
SWAP: Pick two tiles. Swap them. Now ask players if this changes if the treasure could be in the first or second tile.
The game becomes more tactile, less static. Swapping is an easy way to limit the theories players can test, without limiting it too much.
Want to test if a flower has an impact? Find a flower tile to swap with.
However, because people respond to both tiles, thereâs also a sense of uncertainty to the result ⌠unless youâre smart about picking tiles.
Advantage #2: Rotation
Okay, so we have a map with individual tiles. Each tile is one thing, and one thing only. Hints are mostly about the tile itself or the ones next to it.
This simplifies the game. It also reduces our options.
I wanted to have hints that donât just check your neighbor tiles. I wanted to have an easy way to change what a tile does exactly.
Well, the answer is rotation.
Some tile types behave differently when rotated. The easiest example is the arrow: it will point in a certain direction, and itâs easy to create hints like âthe treasure has an arrow pointing at itâ.
Letâs create random maps
These maps should be way simpler than Riddlebeardâs maps.
Create a grid
Randomly predetermine what tile types we want to place.
Each tile knows two things: what it IS and how itâs ROTATED.
Simply loop through the list and place the stuff we predetermined.
Is it that small? Not really. Iâve learned from the other game to save a bunch of other data in the cells themselves (to optimize performance and because we need a bot player in solo mode that requires this). So, right from the start, each cell also knows: if itâs at the edge, what cells are its neighbors, its own coordinates, what happens if you change the cells around it, etcetera.
Why predetermine? It gives far greater control than picking randomly when we create the cell.
For example, we could say âwe want at least 1 tile of each typeâ, so we add one of each type to the predetermined list. Before assigning, we shuffle the list. Now, no matter what happens, we know that rule is obeyed and the map somewhat balanced.
I thought about âgrowingâ groups of similar tiles again. But that doesnât really make sense on such small maps, where the tiles are not nature elements (those canât be rotated and still look right). So I didnât.
Which begs the question: what is the theme of the game? What are the tiles?
Functionally, itâd be ideal to just use abstract shapes (triangle, square, arrow, âŚ)
Visually, thatâd be terrible, certainly not attractive for kids/families.
In the end, I settled on the standard things youâd expect in a treasure hunt. Treasure, compass, map, key, an island, palm trees, that kind of stuff.
There was just enough there for me to implement what I want. And it ensures any player understands the general idea of the game.
Advanced Idea: Networks
In my original sketches, you see the idea of networks. Tiles being connected by lines running through them.
Itâs a great way to add another dimension, without making the game visually complicated.
(It would be an advanced expansion: itâs harder to see if something is connected on the network, than to check if itâs adjacent to something.)
But if weâre using separate tiles ⌠how on earth will we do that?
The best we can do is print network lines on the tiles themselves, but thatâd mean we need to write an algorithm that ensures these lines all match up on the final map. Not going to happen.
In that case, this game mode would only work if you play the online way (because then you can just draw them on your paper).
Even then, swapping tiles has a low chance of the networks neatly matching. But that isnât necessarily an issue, as you might want to purposely break a connection.
An alternative is to make these connections separate tokens to place in between tiles. But thatâs just a nightmare waiting to happen: any time you swap tiles, you need to lift that network, then put it back. And weâd need extra rules for how to swap/change/interact with those tokens. And itâd be more material. A no go.
As such, I implemented network generation like this:
Start somewhere at the edge. Do a random walk into the map, saving the tiles and directions.
Now do more random walks, but they may also start from tiles inside the map (which we walked through before, already connected to the network)
Visualize all this by drawing lines between the points.
Save which neighbors weâre connected with on the cell itself.
(To check if two cells are connected via the network, we simply loop through our connected neighbors, then their connected neighbors, and so forth until we either find the other cell or weâve checked everything.)
This is okay for now. Weâll improve later if needed.
The result


I think they look great already.
That little triangle on each tile is a very clear way to indicate the rotation of a tile. I also tried to make it line up with stuff (like the arrow).
I think only minor improvements to the maps are needed now. (More tile types, row/column information, debugging tools for myself.)
Finally, I had the idea of placing things on the edges of tiles, and creating hints about whether they line up, or point to something, etcetera. But Iâm not sure if this will become a thing, as it seems like it would mess with visual clarity. Thatâs a worry for later.
Hints
The hints are completely visual to the player.
But behind the scenes, they obviously still need to be text, as computer code is also text and requires that.
As opposed to the original, our possible hints are simplified though, which allows simplifying the implementation.
All hints are only about whether something IS or ISNâT true.
We never need to calculate something or fill in a value dynamically.
Additionally, the original has two different algorithms (I wanted to try both), but we can just use the one I liked most here.
The general system
The result is a system as follows.
We have a dictionary with all the hints:
Each hint has an id
It has a list of parameters and all they can be. For example: âtypeâ means the parameter must be a tile type.
It has a parameter ânegatedâ thatâs either true or false.
It has optional parameters that do stuff like: limit how often the hint can occur, ensure all parameters are different from each other, etcetera.
At the start, we pick our treasure location, then generate all possible hints for it.
When building a hint, we check its id.
We do whatever calculation is necessary. (This is custom code per hint, this is the meat of the logic.)
And then we check the end result with the real result.
(Remember, all weâre doing is checking if some statement is true or false, then adding a âNOTâ if false. No other possible values, no inverse, or âgreater thanâ hints, or whatever.)
Once we have that, we simply pick random hints until exactly one square remains ( = the one we chose at the start).
If weâre happy with that, weâre done!
If not (too few hints, too many, whatever) we try again!
When displaying the hint, we simply pick an image based on its id, overlay it with images for each parameter, and add a big red cross if itâs negated. (I make it sound simpler than it is. Itâs not. There are many edge cases. But this is the general, summarized idea.)
What to look out for
These hints are way stricter and more precise than in the original.
Hints with vagueness like âat most 3 trees within 2 spacesâ are not part of this game. Something is either true or not true!
So my biggest fear is that this simply makes the game too easy or unplayable. The hints are so strict that it will barely need more than one or two to find the treasure.
Besides that, I immediately implemented improvements I also added to the original:
Assign hints to players so that they donât have two within the same category.
Count how many possible tiles remain: ensure this is roughly equal between players (so nobody has a clear head start)
Check if somebody has a useless hint.
And lastly, I mentioned I wanted to split the visualization and the logic. In the original game, this is all one huge file, which is only active when the Phaser game is running.
Now I split the map generation into its own object/file, and the hint generation into its own object/file. Cleaner, shorter, more flexible.
Once my business with the Phaser game is done (drawing the map to the canvas and saving that image), I can completely shut it off without losing access to the game data and the functionality of checking hints.
My fears came true
With such specific (and simple) hints, generation takes a looooong time to find something, because the hints are very unbalanced: some players literally have 3 tiles left over from the start, others have 30.
This happens 99% of the time, so I canât brute force my way through that.
What to do?
Solution #1: I thought, and thought, then realized something: the whole problem comes from hints being too powerful. One hint leaving only, like, a handful of tiles out of the full map.
We can simply not choose those hints.
When generating our hint list, we simply check how much a hint removes when given the whole map, and discard any hint that leaves only 10 or fewer tiles.
I wish Iâd realized this sooner. This is really powerful!
We can always stack more hints on top of each other to lower the number of options left, but we canât make a hint âless powerfulâ retroactively. By already stripping the strongest hints (for a specific location), we suddenly make the generation very happy.
(I also implemented the reverse: donât consider hints that only remove one or even zero tiles. I never realized it before, but they do exist of course: hints that are true for the treasure location ⌠but also true for literally all other tiles. Those are useless.)
Solution #2: Right now, I have two categories with only one hint type. I was being stupid, because that means the generation will always choose that hint (because it tries to alternate between categories for diversity).
That means that it either finds a solution on the first try ⌠or keeps rehashing an almost identical set of hints and failing hundreds of times.
The solution is simply to add more possible hints to those categories. (And forget about alternating if a category has too few entries.)
Solution #3: I made the hint distribution a bit smarter. Currently it assigns hints and then, afterwards, checks if everything is fair.
I can, instead, do that while assigning hints.
Keep a list of âpossible tilesâ for all players.
For each hint, go through all players and try the hint on their list.
Find the player that, when given the hint, creates the fairest situation. In general, this is the player who is furthest behind the others (in terms of âtiles left overâ).
This way, we keep the number of starting options as high as possible for each player, and already balance/check while generating the hints.
And with all those changes, everything works very smoothly!
The result: written hints
First, we need hints to work behind the scenes and output some written text for me to check.
Thatâs working now. Letâs see:


Visualizing the hints
This proved trickier than expected. (Then again, I keep expecting things to be way easier than I have any reason to.)
Different hints have very different requirements.
Sometimes the red cross (to indicate NOT) is centered, sometimes itâs off to a side and smaller (because that looks much cleaner), it can be anywhere.
Similarly, some hints only have one type (âthe treasure is on a KEYâ), others have multiple (âthe treasure is on a KEY or PALM TREEâ)
I also didnât want to redraw the hint every time it was requested.
I wanted to draw all the hints once, save them as images, then reuse as needed.
The common thread is that the hints are square and use the same set of sprites.
After some consideration, I opted for the following:
Ignore Phaser / the map generation code.
Instead, use vanilla JavaScript to create many small square canvases, invisible to the player.
On each canvas, draw a hint, then save as an image.
(We do them all at the same time because itâs faster.)
Each hint has a âlayersâ property where I manually specified which sprites and frames to layer on top of each other (and at which position/scale/rotation). At the end, if the hint is negated (it has a NOT in it), it places a big red cross over it.
Now we have an array with all the hints, per player, as images.
We can place these back into the generation code when we want a nice PDF with hint cards.
Or we can display them in the interface when players are playing digitally.
The result
For now, Iâm just throwing the hint images in the HTML and display them above the map, for debugging purposes.
Hereâs what it looks like:



I think thatâs pretty nice :) Iâm not sure about the clarity of some hints, but I can always change that later. The important thing is that it completely generates a game (map + hint images) within 5 seconds.
Some issues & improvements
Water
I thought itâd look nicer and more natural if water only appeared near the edges. Then the map would really look like an island in the ocean.
A simple change, but I wanted to add this as an option.
When generation starts, it spawns a few water tiles at the edge. Then it extends existing water tiles (by converting a neighbor into water) a few times until itâs happy.
This leads to very natural water surrounding the map.
Additionally, I decided to make water tiles really a âspecial typeâ, so they have a type (water, duh) and a rotation ⌠but nothing else. Anything else a tile can be, especially in the expansions, is simply not possible for water.
It just looked and felt better/simpler that way.

Redundant Hints
The whole idea of the game is that thereâs overlap between the tiles a hint marks as âcould be the treasureâ. So there isnât any check on how much hints overlap.
Unfortunately, though, with certain hints thereâs a good chance that one of them produces a subset of the other.
For example: hint A leaves 5 tiles. Hint B leaves the same 5 tiles, but also a handful of other tiles. Hint A is a subset of hint B, as they say exactly the same thing, but hint A is simply more specific. And thus better.
This makes hint B completely redundant. The player getting it will feel a bit betrayed once they realize hint A exists.
Letâs forbid this!
At first, I wrote a simple loop:
Loop through the new list of options (for the current hint weâre evaluating)
Check it against the lists for all previous hints.
If we are a subset of them (all our tiles can be found in their list as well), forbid this hint.
This, however, is expensive!
We need to loop through loads of lists, multiple times, for every hint.
For example: with 4 hints, on average 20 tiles per list, weâre already looping 20*20 + 20*20*20 + 20*20*20*20 = 168400 times. Not great. Even if we use some basic techniques to break out of the loop early (if an element doesnât match between the smaller and the bigger list), it is slow. A quick test shows it has to do ~1200 loops for the last hint, regularly, and already ~200 loops for the first hint.
How do we solve this?
I realized that these lists are sorted the same. Each hint grabs the same list of all tiles and strips it, maintaining order. Which means two things:
We only need to look ahead for matches, never back. (Because, if a match exists, it will be later in the sorted list.)
When we realize our larger list has become too small to fit all remaining elements of the smaller list, we can immediately stop. A subset has become impossible.
Itâs not a 100% solution, but itâs way way faster in most cases. Most lists will stop checking after a few elements, maybe even before it starts.
For example: The highest values Iâm finding now are ~150 loops for the last hint in the list, but even that is rare. Itâs often near 10-20 loops.
(There was a bug that eluded me for the longest time. The answer was, as always with these bugs, me being absolutely stupid. I checked redundancy when generating the full list. This is obviously expensive and youâre sure to find loads of redundancy when checking hundreds of similar hints. Additionally, these hints are generated in a fixed order, so this would always throw away the same hints.
The solution was, of course, to check redundancy when picking the actual final hints. Way fewer checks to make. It actually makes sense. This list is randomized. All was fine again with the world.)
Edge Symbols
I finally figured out what I wanted the last (advanced) map element to be.
They are symbols (circle, square, or a sort of combination of both) placed at the edges of tiles.
The hints about them are very basic: a neighbor has a specific symbol, symbols match (which is very satisfying, when two edges line up with the same symbol), etcetera.
Itâs different enough to include, yet itâs not too complex and doesnât create too much visual chaos.
(Especially because I did my best to push them as far into the edge as possible, leaving enough whitespace around the tile type icon.)

Speed & Optimizations
The algorithm is reasonably fast. Can find something within the blink of an eye, but takes a few seconds on average.
Some of that is due to my debugging: logging loads of stuff + displaying text on a canvas is expensive.
But almost 99% of the time it fails because of âtoo many hintsâ (itâs currently set at a maximum of 2 hints per player).
On the one hand: thatâs nice. Itâs more annoying if thereâs some vague reason the algorithm is slow or canât find anything.
On the other hand: I donât really like giving players 3+ hints.
So this seems the solution: add an option to create more hints per player and say that this usually speeds up generation.
Itâs the best I can do :p Really, itâs not big deal. Getting a fully completed, functional game in 8 seconds tops is fine.
Rules
I decided to include all possible hints + a (detailed) textual explanation in the rules.
Some of them just canât be expressed in a way that Iâm certain players understand it correctly. And itâd be really stupid if people play the game incorrectly because they are scratching their head about what a symbol means.
So I wrote a script to download the generated image for all hints. Then I just have to arrange those in a two-column layout, and use the second column for a precise explanation of the hint. (And an example if possible.)
This will become an âappendixâ though. Itâs 3 full pages for all the hints. Donât want that in the flow of the main rules.
(Fun fact: browsers do not like it when you queue 100 simultaneous image downloads. I ended up learning how to zip dynamic webpage files and download them. Which, to be honest, was the better solution to begin with :p)
Networks
Right now, networks were ⌠fine, but too chaotic.
It was perfectly possible for a map to just have one giant network. Or a very tiny one somewhere in the corner.
This doesnât look great, but is also bad for hints. If there is only one network, all the specific network hints become pointless. (âItâs connected to a tile with rotation 0â simply means âItâs connected to the one big networkâ.)
So I needed a way to ensure we had 2 different networks (maybe even more) and that they werenât too close or didnât accidentally go through each other somewhere.
I invented ânetwork poisonâ. One in every 4 random walks that we take (to generate the network) becomes poisoned. It will not connect to existing tiles on a network, nor will it allow later random walks to connect to them.
They are poison. Everyone stays away.
This way, the first two random walks will surely be different. After that, it depends on how long the walks are/what random network length weâve chosen.
(With 50% chance, instead of starting on a new tile, a random walk extends an existing one. It only does this, obviously, for the non-poisoned ones.)
This generates separate networks that usually look good and are a good length. The hints about them are now useful again.
(I still added a check to be sure though. If a network hint leaves a list of options thatâs equal to the total number of network tiles (or close to it), I deem it a bad hint and skip it.)


Finalizing the game
Settings
Iâve learned that itâs (usually) good to leave everything to the player, but start with sensible defaults.
As such, almost all hint/map elements are optional or expansions: rotation, edge symbols, networks, special stuff (like the compass).
Yes, even rotation. Again, my experience tells me that a first game should always be as simple as it can be. Using only the two easiest hint types (tile type and row/column) seems the best way to be introduced to the game and learn it.
Other settings are:
MultiHint: by default, it tries to give each player one hint. Enabling this allows up to three. (As discussed before, this speeds up generation as well.)
Advanced: some hints are harder to grasp/calculate, so they are only added when this is enabled.
Use Real Material: enable this when youâre reusing the material you printed and cut out. It limits generation to how much you have of each type and what those fixed tiles look like.
For Printing: puts the generated game into a PDF (map + hint cards) you can save and use later. (I use this option myself to create the âpremade gamesâ that I usually offer.)
Colored: creates colored boards instead of black-and-white (âinkfriendlyâ) ones.
This game was meant as the simplest and most âkid friendlyâ of the whole bundle of deduction games Iâm planning.
As such, there are no real âexpansionsâ or âadvanced rulesâ or anything.
I thought about it. For example, certain tile types might block arrows pointing at stuff. Maybe other tiles must be rotated when you use them in the swap action.
There are interesting ideas. But none of them necessary for the game. And none of them reward the amount of complexity theyâd add.
(Fun fact: I ended up using the idea of a âmaterial limitâ on all maps, even the digital ones, because it creates much more natural and balanced maps. Itâs just applied more loosely.)
Botbeard
Iâve learned from my mistakes.
With Pirate Riddlebeard, I only added a bot at the end. The code wasnât set up for it. It works, but itâs not ideal, and took longer than I wanted.
With this game, I keep complete access to the map and all its functionality. Such as ⌠testing if a hint is true or not!
So Botbeard can fully respond to your actions! If you choose âswapâ, you input the tiles in the interface, and it can just quickly calculate your answer and give it back.
I thought about giving Botbeard actual turns. Maybe even letting them win.
On their turn, they might ask you about a specific tile, and you tell them what you know.
But it seems pointless. The computer already knows the answer, and the hints, and the map. It generated all of that. And thereâs no way for you to outplay it or add strategy.
So youâd just be pointlessly telling the computer random tiles they already know.
There was one other thought that seemed to make sense.
At the end of your turn, you must reveal your answer to one of the tiles, and are always allowed to dig.
This is something you choose and thatâs already in the game. So I can add a button to tell Botbeard which tiles you interacted with.
Based on that, I can do a rough calculation of when Botbeard would have won: when youâve given away too much information, played for too long. This would add a time limit to this mode.
But when thinking about it even longer, this also didnât seem fun. Youâre playing this game, maybe alone, maybe with two players. Youâre close to cracking the code, working on it for 45 minutes ⌠and then Botbeard just says âhey, you took to long, I winâ
Not great, eh?
The original system was the best: Botbeard has no turns and cannot win. It simply responds to your actions and gives away the information you request.
Having Botbeard implemented, though, we can test the usefulness of the SWAP action!
First I did some manual testing. Loaded a game, did the SWAP action many times, checked how often I received a âyes, it changed!â It felt on the low side, but still âoften enoughâ.
So I decided to do some more robust calculations.
I wrote some code to randomly swap 100 pairs of tiles and record how many times that changed the outcome of one (or both) of those tiles.
On average, the result was around 30 âflipsâ. So, 1/3 of the time, when using a swap action on one player, theyâll say yes. Which is great!
However, it did occur quite often that there were 0 flips. Yes, zero. This seemed odd to me. So I checked which hints Botbeard had, and hit myself in the face because of my stupidity.
Of course, this happens when your hint is âthe tile IS (not) somethingâ. Swapping any pair of tiles will not change the tile itself, so of course this never changes your answer.
At first, I thought this was a problem, and I needed an extra action (or some more rules) to fix it.
But then I realized it was actually a feature. You see, there are only four hints in the whole game that canât change by swapping:
Tile IS (NOT) something
Tile HAS (NOT) some rotation
Tile HAS (NOT) some symbol
Tile HAS (NOT) multiple symbols
So when a player keeps saying no to everything, this is also good information, and tells you the hint is probably about the tile itself and nothing else.
Combine this with the fact that players have to give away one of their tiles after each turn, and I think this is actually fine.
I can massage the problem a bit through code, though: mark these four hints as âswapResistantâ and only allow picking one (at most) per game. (If two or more players react with ânoâ to everything, the game stops being fun quickly. And is either very easy to figure out, or very hard.)
Optimization
After running many tests, I realized a major performance hog which had almost no benefit.
When selecting hints fails for a map, I retry 20 times, before completely changing the map and starting again.
Well, those 20 retries only yielded a result <1% of the time. Yet they can take half a second to complete.
So I simply lowered it to a single retry. And itâs much faster now. Which is great, because I was really starting to worry.
(Itâs still slower than Iâd like. But I cannot find any ways to speed it up anymore. Itâs a byproduct of maps being very simple and hints being very exact, instead of the more varied maps with vague hints from the original game.)
Finishing Touches
Some of the hints were a bit inconsistent in terms of iconography. I tried to make them as clear as possible.
I added a hook to the top left corner of the map (and all hints that do something with the whole map). When playtesting the previous game, I realized that some players would view the map upside down (or at an angle), and not being sure which orientation to work with was a bit of an issue.
I added a button so you can always view the map again within the interface. (With Pirate Riddlebeard, for some reason, you only view the map once at the start and then it disappears. Might need to change that.)
Small stuff like that. I think Iâve covered everything now.
Here are pictures of the final maps, including visual hints and expansions.


Testing & Improving
Being a simplified version of a game idea I already made, weâre already at the âtest and finishâ stage. (I keep saying âalreadyâ as if the devlog isnât already 5,000 words long. Making games is hard and takes a long time.)
Timing
First the timing test. How long does it take to go from a blank paper to we can play the game? It takes me roughly 5 minutes:
1 minute to fold the paper
3 minutes to copy the map
1 minute to cut all the tiles
I try to time these at a regular, casual pace. No âtricksâ to go faster. In fact, my workspace is very small and cluttered, so my biggest enemy is actually finding the room and angles for writing and cutting :p
I find this acceptable. You only need 5 minutes + some device + paper/pens to setup a game that will last you 30-60 minutes. (The other modes are all faster, as you reuse material or print something beforehand.)
Of course, some extra time is needed to copy the hints in this case as well. But that depends on the players themselves and the player count, and is negligible in all cases. (Players will usually have one or two hints that are just a simple icon.)
Practical stuff
The rules are very simple and clear. It plays the same as Riddlebeard, only faster and smoother. The chance of winning early at random is slightly higher, but not much, and an unavoidable consequence of simpler rules.
One minor setback is the main swapping action. When reusing material, you obviously donât write on the tiles. You place tokens to indicate playerâs answers for tiles.
This becomes a bit annoying when you start to swap tiles, as you need to move the tokens with them or place them to the side for a bit. Itâs nothing major, but it could be better.
But I see no solution for this, so weâll have to accept it (and maybe solve this with the next variant).
Playing
The game works!
It accomplishes exactly what it wants: a simpler, faster, more streamlined, kidfriendly, improved version of Riddlebeard.
Thatâs the huge benefit of creating variants on game ideas you already spent a long time developing and improving.
Conclusion
There are still some things Iâd like to improve in the next variant, though:
The main action (âswapâ) feels like it could be further simplified. Especially when it becomes impractical as well.
Drawn hints arenât all 100% clear, while at the same time being quite simple. Iâd like to change the setup so that drawn hints donât need any explanation (or lead to any confusion), but allow some numbers or text to allow more complicated hints.
The game is only competitive. Iâd like to add a cooperative mode as well.
Square/grid maps are boring and overdone. I want to try a more dynamic graph map.
So this is it for Pirate Drawingbeard.
But the points above will probably be implemented in the next variant, called Pirate Spacebeard (name might be changed) :p
Until the next devlog,
Pandaqi