Ben Rose on Google+ taught me a great new word skeumorphism when I discussed, in a previous post, the intended layout for the Character Editor. I hope I’ve found the right balance here. I like the tactile nature of representing parts of the gaming table with their real-world counterparts.

In this alpha version of the Character Editor, you can:

• Load templates created in the Character Sheet Editor
• Edit any unlocked fields, including images
• Roll dice
• Add custom player notes

Rolling up characters this way makes we want to gather up my friends and play.

Character Editor Alpha from C. Lewis Pinder on Vimeo.

 
Also available on YouTube.

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 ...

While I haven’t kept it a secret that intend to launch a Kickstarter campaign for the project once I get to a solid alpha, I haven’t made much noise about it either. Given the availability of cast and crew, I took a break from development to shoot the Kickstarter video.

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.

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.

You can only work in a vacuum for so long, before hands-on feedback is necessary. And this is that time. Now’s your chance to take some miniatures out for a spin and let me know what’s working an what isn’t.

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.]

Every now and again you have a shower moment, one of those moments where you’re not thinking about the problem at hand and you stumble onto the answer. I had one of those serendipitous occasions the other day. Reflecting on the die rolling mechanic, I was wondering absently why I couldn’t just “look” at the die to determine the value. And then, quite suddenly, I realized that I could.

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.