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.

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.

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.

I’d like to take a moment to thank Aaron Carver, Cary Brown, Casey Ross, Emmanuel Plascencia, Jarod Caitlin, and Nicole Williams for all their time and effort.

It was good to step away from coding for a bit, but now I have to get my head out of editing mode and back to the software.

I think you’ll all enjoy the video when the campaign begins.

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.

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.

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.

Miniature controls
Left-click on mini – selects mini
Left-click and hold/move left or right – rotates mini
Left-click and hold/move up – lifts mini

Camera controls
Right-mouse button or Left ALT key – orbits camera
Middle-mouse button – moves camera
Scroll-wheel – zoom camera

Dice
Left click on any die to roll two of that die. (Note: the d4s do not return the correct result.)

Map
The visible portion of the map is determined by the line-of-sight and by distance. The mini can “see” up to 120′.
Any part of the map that has been “seen” will be shown as a 2D map when no longer visible.

Click here to launch.

I’m looking forward to any and all comments. [Edit: A quick note based on some feedback that I've had so far: 1) the final product will be a standalone program, it's running in the web player so I can get comments; 2) the ALT orbit is a workaround for the Unity player pop-up that appears when clicking the right-mouse button. If you right-click and choose full-screen, if pop-up goes away.]

The solution is to cast a ray down from above the center of the die at rest and get the texture coordinate at point of intersection. You can then use the u value of the texture coordinate (the u value goes from left to right, zero to one) and based on that determine the up-facing number. The math is pretty straightforward, (u + (1/number of sides)/(1/(number of side). That’s it. With one function you can roll arbitrary dice. Except the d4. There’s always an outlier.

Unity – Rolling d20s from C. Lewis Pinder on Vimeo.

Click to enlarge.

I learned a few things from this test (other than I need to replace the cyan ink in my printer). The first is that drawing the terrain on top of a 2D map looks like good solution. The map is broken up into a grid that matches terrain, so any part of the map can be hidden. I’m still leaning towards revealing only portions of the map that the player has seen as the default behavior.

Click to enlarge.

And second, I can’t write the level editor soon enough. The levels are currently stored in a text file, which has worked up to this point. Inputting larger maps, however, is a tedious exercise in data entry.