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.

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.

I dropped in my first “painted” miniature today. Unlike the dwarf and the ogre miniatures, this one isn’t a copy of a Ral Partha miniature. It’s an original sculpt.

It’s really hammered home the need to open up the hood and author new shaders. I’ll be nice and say that the default Unity shaders are “unsatisfactory.” I’ve taken a look at the shader syntax and it’s a variation on cg-fx, so the authoring shouldn’t be much of a stretch. I am, however, a little rusty with shaders and Unity has stirred just enough of their own flavor into the sauce that it will take me a little while to sort it out.

You can see the archer in chain-mail and his pals, the dwarf with broken torch and the angry ogre with club. Right away you may have noticed that this is the first time you’ve seen a party of miniatures, rather than a solo piece.

Those of you paying extra close attention might also notice that we’re seeing an underlying map being shown in areas that are outside of the player’s line-of-sight.

Okay, back to it. I have an idea about polyhedral dice rolling.

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.

As some of you know, I’ve had trouble finding the aesthetic that I want—particularly for the miniatures. I tried a number of approaches, but I never achieved the dynamic poses and “chunky” look of old school miniatures. A few weeks ago, my brother sent me a care package with some of our old gaming gear. In the dice pouch of the package were a few Ral Partha miniatures from 1979. These were definitely the look I’m going for.

Ral Partha miniatures.

I picked two of minis (a dwarf with a torch and an ogre with a large club). I took a ton of reference photos and built a rough representation in 3DSMax .

Rough meshes in 3DSMax.

Dwarf in Sculptris.

That mesh was then imported into Sculptris for detailing. Sculptris was a lucky find. While Z-brush is the “industry standard” for sculpting, the UI was apparently designed by a blind man describing it to a deaf person. I’ve never been able to overcome the dreadful interface to produce anything useful in Z-brush. I’ve tried Mudbox, which is a huge usability improvement, but I’ve given enough money to Autodesk already. Sculptris is both simple and free.

Ogre in Sculptris.

Once in Sculptris, I sculpted in the details and then exported back out to 3DSMax to render the new high-res mesh into a normal map for the original lo-res representation. I’m definitely getting closer to the look and feel of miniatures, but I obviously cannot blatantly lift all the designs from Ral Partha. I ordered some more generic plastic figures from Amazon and they look to be a good basis to add custom details.

Lo-res Minis with normal maps.

Along the way, I wound up writing a custom mesh exporter/importer. Unity’s default support for FBX files is nice, but it carries with it a lot of overhead I don’t need. Worst of all, to convert the 3DSMax z-up models into Unity’s y-up coordinates, the FBX exporter adds a 90 degree rotation to the model’s transform. Carrying around the transform was polluting all of the rotation code for the miniatures in game. Additionally, Unity insists on applying a 0.1 scale on all FBX model imports. This can be changed, but it’s on a per model basis and a new default can’t be set.
I’m not reinventing a perfectly good wheel just to do it. I’ll be setting up groups of vertices in the future to allow the players to change the colors on the painted miniatures and I don’t won’t to try to piggy-back that on an FBX export.

Next up, we’ll talk about line-of-sight visibility and how that kept me up at night.

I’ve wrapped up work on some other projects (The Borderlands and Apollo Zero) and I’m back at the keyboard. When we last left off, I’d just finished putting together a small level based on the Hirst Arts gothic dungeon. It was good to get some hands-on (even if they were virtual hands) experience building a dungeon based on practical models. However, as often happens, I ran into some issues with my implementation and took a different approach.

On Prototypes
Everyone certainly has their own approach to prototyping, but for me—in the early stages—it’s involves a great deal of create, tweak, and restart. At each stage, I start anew. Borrowing pieces of code that worked, but willing to toss away whole pieces that don’t quite fit the bill. Such was the case for this stage of the prototype. read more

I picked up some VFX work, so I’ve been away from the project for a few days. Now I’m back and working on movement again. I’ve made quite a few changes behind the scenes and added some features up front.

On the back-end, the grid and movement have been completely abstracted to separate classes with support for arbitrary grid size and distance. I’ve also added a main game loop rather than lazily attaching the logic to the camera which is what I had done. read more

Today I dug into a few Unity features: instantiating objects in script, moving and rotating objects, and ray casting for mouse interface and object collision. The first test, moving the miniature around the map.

I’m still wrestling somewhat with how to do movement on the map. In this first version, clicking on the miniature overlays a grid of areas to which the miniature can be moved. Clicking on a square moves the miniature there, while clicking on the square beneath the miniature cancels the move.

I’m not sure, yet, whether this is best interface for movement. It maintains the classic battlemat idea of discrete grids, but isn’t necessary. Moving the miniature “off the grid” can be every bit as valid. I could display a radius of possible movement, or track the mouse and show possible paths, or display a grid and let the player set “waypoints.” Certainly this is an area that will benefit from testing and iteration.

Test of Miniature Movement from C. Lewis Pinder on Vimeo.

What interaction with the miniature feels most “natural?”

I’ve made the choice to use Unity as my engine. It’s a Fool’s errand in game development to write your own engine unless the thing you need to do is so unusual and so specific that existing tech won’t match your needs.

Call of Duty is still running a long-in-the-tooth and heavily modified variant of the Quake2 engine. When I worked on Medal of Honor it was developed using EAGL, a graphics library originally intended for use with their sports franchises. When Might and Magic made the final leap to real 3D, it was using the LithTech engine. read more