The character sheet editor is finally at alpha. Most of the time was split between trying to maintain the “look and feel” of a physical character sheet and struggling with Unity’s UI system. I’ll talk more about Unity in a future post where I’ll discuss the things that have and haven’t work well with Unity. For now, let’s take a look at the editor.

Click to enlarge.

Beginning with a blank page of any size (there are defaults for letter, legal, A4, and A5), you can add several different types of elements: text, whole numbers, decimal numbers, checkboxes, and images. Each of these elements is lockable, meaning that they can’t be modified by the player in the character editor. This essentially turns text into labels and images into graphic elements.

Click to enlarge.

The text, number, and checkbox elements are assigned a name, as well as a default value and text size. This name will be used in dice and chat macros to access entries on the character sheet, e.g. “1d20 + strAdj” to roll 1d20 and add the value named “strAdj.”

Click to enlarge.

While the default is a sheet of notebook paper, any image can be used as the background. You can use a scanned image, character sheets off the web, or something custom you put together in Photoshop.

For the test run, I setup both the classic D&D character sheet and the handwritten sample from the Molday Basic edition.

Tabletop Connect Character Sheet Editor from C. Lewis Pinder on Vimeo.

Also available on, YouTube.

While doing some UI work, I fell down the rabbit hole of rolling dice and, as part of the push to alpha, stayed with it until it was complete.

New Features:

• The user can now add an arbitrary number of dice and type to the dice pool.
• The dice can either add to, subtract from, multiply, or divide the total.
• Dice can be rolled by entering as text with supported math, e.g. “2d6 + 1d8″
• Dice values and the total of the roll are displayed on screen.
• Dice text fades after a set time (currently 5 seconds, which feels longer than it is).
• Dice are cleared when new dice are rolled.

At the moment, the dice macros are not saved anywhere and only math operators on die rolls are supported. E.g. “1d6 + 1d10″ works, but “1d6 + 3″ doesn’t.

Also, the order of operations are the order in which the dice are added to the pool. There’s no support for parentheses.

Adding these additional features is not difficult, but it isn’t trivial. They’ll be coming along as more features reach the alpha stage.

Die Rolling at Alpha from C. Lewis Pinder on Vimeo.

Not all of a game takes place on the map with miniatures. One would hope that much of a gaming session occurs outside the dungeon. There are the practical matters like rolling up characters, picking out minis, and waiting for all the players to arrive; and, of course, all the role-playing that happens before the swords start swinging.

Call it a lobby or the table, it might well be the part that you are looking at most. Working on the networking necessitates that I pay attention to “the table.” I’ve kicked around a few ideas, but the one that I’m leaning toward most is extending the tabletop metaphor into a virtual tabletop. I remember, too well, efforts like Microsoft Bob that didn’t go over with the users. Having a folders and a trash can on the desktop works well enough as long as you can just double click to open a folder and don’t have to virtually mimic digging through a filing cabinet.

I did a quick 2D mock-up, but I think I might be pushing it a little too far. What would you like? How much verisimilitude is the right amount?

Click to enlarge.

 Loading ...

When I was at Electronic Arts there was a legend about a function in FIFA called DoBestKick. It was the ur-function for determining what kick an AI player would do. The story tells that no one really understood the inner workings of the function and that the mandate was “no one touch DoBestKick.”

I have a similar function, WhichWall. It determines, based on the orientation of the walls in a square and the orientation of the walls in the neighboring squares which wall to draw: inner corners, left corner, middle, solo, etc. There are 52 possible combinations with dense conditions such as, if this wall is north facing and there is an east wall and the western square has no east wall and the north-western square has an east wall then this wall is an outside corner skewed to the left. If at all possible, I did not want to revisit that function. We don’t always get what we want.

There were two new features being added to the map editor; 1) adding map objects that are not walls or floors, and 2) saving and loading the maps as XML files. These two forced me to touch WhichWall.

Simple UI added to the right-hand side.
(Click to enlarge.)

During the re-factor of the map code, I concluded that storing the wall conditions as properties of the map square wasn’t very efficient. Moving them to an array of booleans let me access the walls with the same logic I use for pathfinding movement. This let me greatly simplify all of the wall handling. This meant reworking WhichWall.

Adding arbitrary objects to the map meant adding a new class to the map squares to hold those objects, both for rendering and for storing in the XML files. It made sense that the walls would also be part of this list of objects. Reason two for revisiting WhichWall.

The in-game map with columns.
(Click to enlarge.)

At last, success. Though I only have one type of extra object at the moment ( a column), I can now add non-wall objects in the map editor. I’ve also done the calculations for which wall in the editor and save that information in XML file, eliminating the need to determine which walls should be added when the file is loaded.

Time to layout the Big Map in the new map editor, 12 minutes. Not as fast as I’d like, but much better than editing by hand. I have some specific ideas to speed up map editing, but those will have to “go on the list” for now. I have enough of the basic features in place that I have to dive into networking.

As much as I liked the idea of drawing walls by following the mouse—allowing the user to turn corners while adding walls—it was too much like drawing a straight line with a mouse in MS Paint. I’ve opted instead to restrict the wall addition to a single axis. That is, as the user starts adding north a facing wall and moves the mouse either east or west, new north facing walls are added.

A couple of other new additions, when adding walls both sides of the wall are added, e.g. when adding east facing walls, the corresponding west facing wall is added. (See also, Splitting Walls.)

You can add floors now, too. Currently, floors are added when clicking on the center of the square, rather than on edges. I’m considering spltting walls and floors into two separate modes. We’ll see how that plays out when I add new terrain pieces and types.

There’s a new UI element, as well. You can now see what type of piece you’re adding before starting construction. With the right mouse button, you can also remove existing pieces.

Continuing to use the Big Map as my test, the time to build has been significantly reduced. With the new method of adding pieces, it’s much easier and faster to add them with the map zoomed out. The video below has been sped up, so you don’t have to watch it in realtime. The total time to draw what you’ll see is just under a minute.

Unity Map Editor – Day 2 from C. Lewis Pinder on Vimeo.

You may have asked yourself, “can a map editor be written in a day?” It’s a question I asked myself. The answer is, in this case, not entirely; but let’s see how far we’ve come.

I spent some time yesterday teasing apart my mapping code to disentangle it from the “playing surface” and to get a head start on the XML serialization for loading and saving maps.

In the editing module, you can load a reference 2D map and draw directly on the surface.

I did quite a bit of sketching to determine the “hot spots” on the grid that indicate what walls are being added: north, south, and so on. Walls are added by clicking on a “hot spot” and dragging to add wall sections. If you change direction, the wall is continued in a logical fashion, wrapping around the corner.

A significant amount of work is still outstanding, but the ground work is laid for a fully functional editor. The Big Map that I spent an afternoon entering, can now be created in a few minutes.

Unity Map Editor from C. Lewis Pinder on Vimeo.

The one feature that I knew I wanted for dice was rolling the dice directly on the map and watching them clatter about and bounce of the walls, floors, and miniatures. I wanted to avoid using the Unity physics primarily because it’s non-deterministic and, like most physics engines, a bit squirrely and unpredictable.

I spent a fair amount of time investigating other possibilities and I was getting close to a workable solution, but it was ultimately going to consume too much time and effort to develop a custom die-rolling system. I chose, instead, to go ahead and implement dice rolling with using the built-in physics. The Unity documentation specifically calls out scale as an issue with their physics engine. The presumption is that 1 unit = 1 meter and the physics are calculated using that scale. It’s not modifiable.

Fortunately, when I began the project, I knew that the scale of the map may one day be a factor and that day was today. I included a global scale factor that let’s me arbitrarily modify the overall scale of the world. I’ve been working at a scale of 40 (an entirely made-up test number). To get the physics simulation of the dice to look at all correct, I had to set the world scale down to 0.5. To get a true representation of 25mm figures, I’d need to set the scale to 0.025. Unfortunately, the physics simulations fall apart at that size.

The second issue with the smaller scale is that the font rendering in Unity does not like tiny fonts. Fonts that once rendered well, now are all blurry. For dynamic fonts, Unity uses OS specific font renderers and the Windows renderer does not like font sizes that small. I may have to create custom textures for the movement costs. Other than the text, I have a few issues still to resolve.

1) I’m determining the value of the roll by checking the orientation of the die when it comes to rest. Sometimes the simulation results in a “cocked die” that isn’t lying flat on the surface. Currently that is resulting in a value of 0, but it’s addressable. For dice that are really cattywampus, the die can just be re-rolled. For those that are pretty close to flat, I’ll have to adjust the calculations to allow for a greater range of orientations.

2) Sometimes the dice fall off of the table. Constructing an invisible box to contain the dice, or just an invisble plane, should be enough. It’s just on the to-do list.

3) At the moment, I’m only rolling six-sided dice. Determining the facing side of a d20 is significantly more involved. I have some work with pen-paper to figure out the best way to handle polyhedral dice. Worst case is a look-up table. For the standard six dice, this shouldn’t be too bad. It’s only eight if I included the d30 and d100.

Most importantly, rolling the dice is pretty fun. It has much of the same satisfaction of rolling real dice on a table. Take a look as I roll some dice. Lots of dice.

Probably the most head-scratching, frustrating feature I’ve tackled so far has been calculating line-of-sight. It’s something that can’t work 90% of the time, or fail on some edge cases. It has to work 100%. And that’s the part that kept me busy with the graph paper checking the math.

My first approach was to “walk the squares” out from the miniature and test collision with any walls encountered. This “marching squares” algorithm was working well and as expected, but it failed on corner cases. As the LOS rays traversed across the map, there were cases wherein the ray would miss potentially visible squares by passing precisely through the corner and ignoring the squares on either side. I spent a while trying different solutions, but none of them were satisfactory.

I moved on to casting rays from the miniature through the end points of each wall section to the edges to check for collision. The rays were then sorted by angle and the collision points connected to form visibility triangles. When considered all together, these triangles formed the potential visibility. Again it was failing on the edges. This time, rather than a miss, I was getting early rejection. The ray was intersecting the end of the wall segment and stopping. It was working well enough, unless the miniature was standing in a doorway or narrow opening between walls.

I tried a few a few tweaks: shortening the walls slightly at the end of the segments, tweaking the angle of the rays. None of these solutions were 100%. Finally, I settled on splitting the rays—guaranteeing that one ray would collide with a wall and the other, if it was open on one end, would slip past. This has doubled my ray count, but it should be a negligible difference once optimizations are in place. A linear increase is far more desirable than an exponential or logarithmic one.

In order to prevent the player from “peeking around corners,” the line-of-sight is only reset when the player drops the miniature and movement is restricted to those squares that are visible. There is still a slight issue. When a visibility triangle intersects a square, that entire square is visible. So the player can sometimes see slightly around corners.  I have a couple of avenues to address this issue. Real-time shadows and render-to-texture are cleverly disabled in the free version of Unity, so with an upgrade to the Pro version this may no longer be a problem. Additionally, I have the triangles calculated. Those calculation are accurate and could be used to create a stencil, either for rejecting pixels at render, or for creating a projection mask for the spot light that hovers over the miniature.

I am contemplating revealing a 2D map for any squares that the player has already seen, but are not currently visible. This help prevent the player from getting lost. I only hope that it doesn’t spoil the dungeon feel that is achieved by only rendering part of the map. I’m also calculating visibility for 360 degrees around the player and not considering miniature facing. It will be trivial to do so and will likely be an option.

There are number of optimizations remaining. Primarily the walls for collision testing need to be sorted by proximity to the player. As it stands now, the routine runs at framerate for smaller maps, but slows to a crawl on large maps. For now, it is functional and, as I like to say, “I’ll burn that bridge when I come to it.”

Unity-LOS-debug from C. Lewis Pinder on Vimeo.

Unity-LOS from C. Lewis Pinder on Vimeo.

I’ve finally had a break on some of the projects I’m involved in which has allowed me put together a test dungeon. Having never built any practical tabletop terrain for miniatures, I decided to recreate the sample gothic dungeon from Hirst Arts.

This will give me the opportunity to test solutions to number of necessary features: read more

We’re all familiar with feature creep, the adding of features to software until you’ve either bloated the program or significantly deviated from the original intent. Even this early in the process, I suddenly found myself recognizing this happening. While working on some new artwork as I begin adding terrain templates and costs, I realized I was targeting the wrong aesthetic.

First it was lighting. I was considering, as I worked with the art, the effects of torches and other motivated light sources. How was I going represent lighting in the world when, for example, the character is carrying a torch or lantern?

Second it was the miniature. I modeled a quick miniature and rigged it to a skeleton so that I could not only pose it, but do some simple animation.

Lastly, it was the materials. I was thinking in terms of real world materials: stone, marble and the like. read more