Prototyping a 3D game-board geometry
Some time in late 2018 I decided that it would be refreshing to create a board game. A role playing game, of sorts. Although such an act would be the epitome of nerdiness, the prospect of working hard to construct a set of rules and mechanisms that would exist to nurture a sense of excitement and hillarity within a group of people seemed uniquely attractive. Undertaking taxing, analytical architectural work, with a goal of fostering good times. It was not simply a notion made enticing by apparant opposites in input and outcome. In actuality, the prospect was novel because the architecture itself would be novel. It would not be crafted to achieve necessity or practicality (like many architectural solutions), but would be spun around the drive to maximise feelings of excitement, hillarity, suspense, frustration, drama, and elation among the "users" that would engage with it and each other. Naturally, the game mechanics would also have to contain recesses in which both a sense of narrative, and player tactics could develop, too.
Although I originally envisiaged the product as a physical board game with a laminated playing area, dice and plastic pieces, I decided to create a virtual version first. This would make it easy to test the game mechanics. However, I ended up deciding that the game would work well in it's virtual form, if combined with a "TV as presenter, phone as controlling interface" mode of interaction.
The game board
The game concept features a 3D playing board that is made up of tiles. Players may move their avatars between tiles during a turn. The range movement is constrained by the numbers that are rolled on a virtual dice, and by the locations of environmental staircases - if they wish to move up or down. This small aspect of the game is similar to 3D snakes and ladders, except in consideration of the fact that the board is non-linear, and moving up and down 3D levels is discretionary.
The game takes place within a castle setting, and depending on alligeance, players infiltrate it either via the front door, or the oceanic caves that initially lead them to the castle sewer and the dungeon. All tiles have a type, which dictates which classes of monster they are likely to be confonted by when landing upon it. These tile types, which affect the character of the board layout, are: Cave, Sewer, Crypt, Dungeon, Forest, Walkway, Kitchen, Library, Bedroom, Lab, Playroom and Prison.
Developing a good game board, with starting locations, shortcuts, danger zones and treasure chests in the right locations is of great importance to the enjoyability of the game. However, initially, I thought it would be a good idea to briefly consider the aesthetics of the board, before myopically focusing on the mechanics.
I imagined the game castle as a typical haunted, vampiric estate. I wanted it to be dark, spooky and foreboding, but also slightly comical and with an element of pastiche - playing on, and indulging in the cliche of this popular but fun concept.
I imagined the castle to sit upon a tall rocky pillar - rising above land on one side, and sea on the other - a situ that was expedient, given that half of the players would enter the castle from a forest, and the other half would enter through an oceanic cave.
I used Blender to generate some simple forms, which captured a basic impression of these ideas. Blender comes with a fantastic tool for generating mountains, cliffs, valleys, lakes and mesas, which I found useful for this purpose: A.N.T. terrain.
Having played around a bit in Blender, I decided that it was a bit too powerful, and inherently, ceremonious for my purpose. I was becoming more interested in the mechanics of the board, and so started to believe that I would fare better with a level editor program. Having become familiar with Half Life's
Worldcraft and Unreal Tournament's
UnrealEd in my teen years, I decided that I could enslave one of them to help me realise the board concept in a more direct fashion.
I began by building the cave and the sewer.
It was coming along nicely, but my desire to be permitted an even clearer focus on the basic level mechanics intensified. In addition, I was having doubts. Would a semi-naturalistic environment, incidentally divided up into board squares really support the best gaming experience? Perhaps it would be better if the board did just exist as clearly depicted squares. It would cause players frustration when formulating tactical movements if they could not clearly perceive the position of themselves in relation to other players, staircases, zones, treasures, escape routes, and so on.
With a desire to focus on the placement of individual tiles within 3D space, logging on to Minecraft was clearly the only sensible thing to do - and I am not sure if I've ever been able to so convincingly justify such an act as thoroughly sensible. I initialised a new world, specifying no terrain features, and a "creative" game mode that would ensure I had access to an unlimited supply of blocks, and the handy ability to fly. Voxellated pigs and sheep looked on as I meticulously errected a veritable labyrinth.
For clarity, I used different coloured blocks to represent different map zones. Among others, I used dark red brick to represent dungeon tiles, pink granite for the crypt, and moss-covered grey stone for the sewer.
Being able to walk around the map helped me reason about the distances between various points. The manual one-brick-at-a-time workflow was not too much of a drag, given the relatively small size of the project.
Building in ThreeJS
Having used a convenient, appropriate and friendly tool to develop the map layout, the time had come to transliterate it into a format that could be incorperated into the real board game app that I was creating. I opted to use a fairly naieve (but, simple, and in the context of this project, unobjectionable) approach to describing voxel maps that I had used before in other projects. This consists of using multidimensional arrays to describe 3D matrices. One key advantage to this approach is that the shapes created by the code itself depict the actual shape of the rendered map.
The snippet below shows the code for the "bottom slice" of the map. The finished map contains 17 of these slices in total. Although the castle only has 5 floors, each floor that is followed by another is 4 slices high, and these interstitial spaces also need to describe the position of staircase "steps".
Note that different letters indicate different cell types. For example,
d represents a dungeon tile, where as
c represents a crypt tile. A full stop character represents a space.
The following map "class" accepts JSON map data, as described in the snipped above, and subsequently creates a map object that consists of real cell objects, as opposed to string characters. The constructor function leans heavily on a
cellFactory function to achieve this.
Finally, the following code shows the portion of the ThreeJS scene-rendering program that renders map cells as variously shaded cubes.Textual structural plan to ThreeJS conversion implementation
The following image shows the rendered scene, which is faithful to the prototype that I created with the help of Minecraft. Although I do now resolve to avoid a cluttered, naturalistic environment, several graphical improvements are still pending.
Below: Carrying out some basic refinements, the camera has now been programmed to focus on a specific square. In the context of the finished game, this will be the square that contains the avatar of the player who is actively taking a turn.
Below: The presence of several floors with relatively low ceilings forces the player to see the map from a low viewpoint, which can slightly obscure the layout. Therefore, I programmed a "High angle" mode, in which all floors - except for the floor that the player occupies - are made semi-transparent, to permit a good view while the camera lifts.
The link below can be used to access a self-contained demo of the game board solution.View board demo
The game as a whole is still under development. At this point, at the start of 2Q 2019, I have devoted about two weeks to the game as a whole. The mechanics of the game have been fully detailed (but will remain a secret until the game is released), UI wireframes have been collated, and all UI components have been written as HTML/CSS/JS web components. About half of the core code is complete.