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.

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’ve been doing quite a bit of work over the last month, but I’ve neglected to post any updates on my progress. In honor of today being Tabletop Day, I’ll get back to writing updates. Rather than overwhelm you with a single post on all the changes and new features, I’ll break them down and post each individually as I write them up.

The first change was in the map structure itself. Originally I was storing the map in a rather naive fashion, knowing all along I would have to update it at some point. The original method stored the grid squares as either open or as a wall. This worked fine for test purposes, and made maps much easier to mockup. Unfortunately, anyone who’s ever mapped a dungeon during play realizes that the walls are most frequently represented as a line along the grid lines—not in a square, but between them.

To represent this, I have split the walls, storing half in each square. A wall running horizontally, for example, would be stored as a wall running east-west with the north facing half in the upper squares and the south facing half in the lower squares. As line-of-sight is coming on line this has the added benefit of only rendering the side of the wall that is visible.

What, on the surface, is a rather simple change in representation has the knock-on effect of requiring significant additional artwork and the added logic for determining which wall piece is necessary: currently it requires twelve wall pieces when you account for straight walls, end caps, inside corner and outside corners. Thirteen pieces if you include that I have two middle wall pieces to create a 10′ span of wall with 5′ squares.

Next up, miniatures.

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 spent the morning re-factoring much of the movement code into a separate class, all the while giving some more thought on the final method for moving the miniature. I’ve been considering setting waypoints: picking up the miniature, moving it a distance, set it down, and then pick it up to move in another direction. This will let me keep the metaphor of lifting the miniature.

Then it occurred to me, what about traps? Let’s say there is a classic 10′ pit trap in the floor. We certainly need to make sure that the player is intending on crossing over that space and, of course, if the trap is sprung, the rest of the move is rendered moot. Traps aren’t the only thing we need to account for. Any number of different checks might need to be resolved before the planned movement can be executed. For example, a Rogue may attempt to move to a wall and then scale it. Or a Warrior might charge through a door, hoping to break it open.

Time for some Photoshop prototyping. The current method I’m considering is using arrows to indicate the movement between waypoints and a die-roll icon whenever a check is required. (The icon, of course, wouldn’t be displayed on the player’s map for hidden checks like traps). Once the move is committed, we evaluate it along the path. The waypoint methodology shouldn’t be too intrusive, I suspect that most practical movement will be in a straight or nearly straight path.

We’ll see how this survives contact with implementation. Anything else I’m overlooking?