Using Godot for Rapid Prototyping of a Board Game

Last week I toyed with developing a new board game concept when a game jam that I was considering participating in, Godot Wild Jam, happened to have a theme that seemed a good fit for the idea. To a certain degree, the game itself is mechanically quite simple but the parts require a lot of tweaking of a single design.

Take a card game for example, you may have a title, an image, a classification and some sort of area for abilities. Apart from placing the images for each card it is quite quick to edit a new card file and if the game is VERY large you can likely populate new cards from a mail-merge-like dataset. In this board game concept, however, there is a single tile design with many variations including orientation, actions and colours. These variations would take a lot of fiddling to make in a graphics program such as Adobe Illustrator or Inkscape, showing and hiding various elements then saving a new file. So after the initial layout design, I decided to create the tiles programmatically. My original idea was to use Python to edit and save copies of the base Inkscape SVG file. SVG is a text based image file based on XML that is both (mostly) human readable and editable so this is entirely possible using an XML library. I had come up with a basic Inkscape template before the jam but hadn’t got as far as a program to generate variations.

Jam

During the jam, I decided to use Godot to create the tile variations for the game rather than generate them outside and import them as static images. I set up a basic tile scene with all the parts needed for variation and then set about making some tools to dictate the rules for the generation of the different tiles. I chose a 3D scene for these to get a nicer rotation effect on the tiles and while this worked well it was a fair amount more fiddly than if I had chosen a 2D scene.

Post Jam

After the jam, I was curious to see how this game would play on a table following some mixed feedback of the digital version, largely due to a lack of good tutorial on my part. I decided to spend a little time creating a tile generator that I could use to make print-ready tile variations. I could use Python to create the files from an SVG template but having already done much of the work in Godot, I decided to repurpose the code into another Godot program. The most interesting part about this, I think, is how I created the printable files.

The scene I setup required several layers of tile parts but I had no easy way to output this beyond the screen. However, in Godot you can create viewports, these are essentially separate rendering canvases into a scene with their own rendering settings for things such as resolution and anti-aliasing. Because these are drawn to separately, you can access the data from this viewport as a texture. The image data from this texture can then be saved to a png or exr file. This may sound simple, however actually wrangling the viewports can be quite fiddly, for example, if you request the viewport data as soon as the underlying scene has been created you will often find the output is blank, this is because it takes a frame or several for the viewport to catch up to the fact that it is being drawn to. This is mainly the reason for this article. I found the best way to get a guaranteed image file from the viewports is to generate the underlying scene (the tile), request the texture data from the viewport, yield for 3+ idle frames and then request that the file is saved.

var tex = $Viewport.get_texture() # Begins the rendering of the viewport
var img = tex.get_data() # Returns an Image which has the functionality for saving to a png
yield(get_tree(), "idle_frame") # When no rendering or processing is being done
yield(get_tree(), "idle_frame")
yield(get_tree(), "idle_frame")
# Alternatively you can yield on a timer timeout
#yield(get_tree().create_timer(0.1), "timeout")
var err = img.save_to_png("tile.png")
if err == OK:
    print("File saved")

Due to the sheer number of tile variations I decided to spend a little more time creating a scene that could render all the tiles onto separate A4 sized pages that I could then print in sequence, double sided. This basically involved a Viewport and a GridContainer full of TextureRects containing the saved images of the tiles. It took a little bit of fiddling to be able to generate the fronts and backs concurrently but I feel I learned a decent amount regarding viewports and controls and I think this was a good trade off for the time spent. For future iterations of the game, tile generation and printing will be MUCH faster because of these mini tools.

Future

As prototyping continues, I will likely refine the tile generation program, tweaking the output until I am happy with the selection of tiles. However, while these files are good for print-at-home they aren’t suitable for most production houses (The Game Crafter being the possible exception). As such I will likely have to create the final files using Python to create separate SVG files from a template OR manually create the variations myself but as this game is in VERY early prototype state, this will be a very long time away yet. I do have a tentative theme for the game now but I’m not ready to share it yet.

Conclusion

My focus is still on releasing A Taste for the King but it was nice to think about an alternative board game design for a while. I will continue to develop it in the background while I finalise A Taste for the King and once it is released, this may become my next focus project for tabletop development, though I suspect it may work better as a digital-only board game.

If you would like to try the jam game it is available in very rough jam-based state on itch.io.