# Multiple Mice Support for Games

Some time ago, we had a two-player game whose most natural input method was the mouse. That’s too bad, because most OSes make it exceedingly difficult to handle two mice separately; they just clump the mice together, so both mice control the same cursor.

Today I stumbled upon a teeny little cross-platform library called manymouse, which handles different mice separately! The interface is really easy (a little low-level, but workable); I got it incorporated hackishly into our SDL sword game in about twenty minutes. So, that’s cool.

# Lenga Formalized

I just wrote up the rules and made cards for Lenga. You can print them out. Enjoy.

# Lenga Development

Namaste, Jude and I played a game of Lenga last night, which was an interesting experience, especially considering that Jude was not familiar with the notation of formal logic (he is more familiar now — and I hadn’t intended to make an educational game :-). Degeneracy (the “dicks” rule) is not an issue: there was no lack of interesting statements.

One of the biggest problems was that Namaste and Jude had trouble coming up with interesting ways to twist the game. I think this is more about people learning how to play the game than a flaw in the game. Namaste took 5 minutes on his turn when the only thing on the board was “There exists an object called 0”. What needs to be understood is that the game will not start twisting until we have some significant assumptions, so it’s better to just start writing some stuff down than to come up with something clever for the second move of the game. It’s kind of like playing pente: you can’t come up with a clever move for the second or third move of the game, because there are not enough pieces on the board yet.

Aside Jude’s frustration at the notation, the game was decently fun. It got fun when we got to something like 20 axioms, and the properties and operations started to become concrete. There was a problem with the competitive portion of the game, however, since if you were in a tough spot, you could just make a new definition. We tried to solve this by only allowing each player to introduce three new symbols throughout the game (if you said “∃x blue(x)” and blue hadn’t been mentioned before, you have introduced a symbol). We never finished that game because of dry-erase marker delerium.

Anyway, the biggest problem was the tyrrany of choice. At any stage in the game, there were far too many statements you could make. Namaste was thinking of making it a card-based game, and I tend to agree. More instructional cards than entire statements that you would play. Here are some examples of cards:

• ∃x blue(x) — write this statement when this card is played.
• ∀∃ — you may write a statement of logic with exactly these two quantifiers in this order.
• commutative — state that a binary function already defined is commutative. If no such function exists, introduce one.

On every turn you have to play something (and probably draw something). This means that you may just get screwed if, for example, there is only one function defined and the axioms already contradict it’s being commutative.

I’m going to make some cards now, so maybe we can play this game during GameDev.

# Logic Jenga

I’ve always wanted to make a game where the rules are dynamic in a way, but better than that stupid game Flux. I’ve decided that the game would have to somehow rely on formal logic. Well, that lead me to an idea for a game whose rules are constant, but also based on formal logic. I call it Lenga (for Logic Jenga (I considered Longa, but that makes the game sound long, and nobody likes long games)). It is not a computer game (yet, mwahahaha!).

Each round starts with an empty paper. On each player’s turn, he can do zero or more derivations, followed by writing down a new axiom. A derivation can be:

• Show that another player’s axiom is in fact a theorem of the axioms written before it. At this point, the player who showed this gains a point, and the player who wrote that axiom is eliminated from the round.
• Derive a contradiction from the stated axioms. At this point, the round is over, and the player who derived this gains two points.

Play to ten or something. The game is over and everybody loses infinitely many points if people are being dicks and not writing anything interesting (for example, “an object X exists”, “an object Y exists”, …).

Note, by mentioning objects such as “sets” and “numbers”, you are importing that subfield of mathematics into your axiomatic system. At the very start of the round, anything goes, but if you say “a set X exists”, you are now working in ZF.

# Telegnosis Cryptography

Usually, a programming project needs to have problems that require clever or interesting solutions in order to keep my interest. That’s one of the reasons I have mostly lost interest in the Ichor codebase (though progress also sparks my interest, so I could regain it for a little while). The reason I have been interested in telegnosis for so long is because I have added a design constraint to the project which creates interesting problems where there would otherwise be none.

In all popular multiplayer online games there has been a problem with cheating, especially in open source ones. I’m not saying Telegnosis will be popular (I’d like it to be, but board games usually don’t catch on). Nonetheless, I want cheating to be impossible in Telegnosis. The exact design constraint: it is impossible to write a client or server for the game which is capable of cheating without being caught by another player using the standard client.

The telengosis client currently enforces this in all but one area: time. I haven’t come up with a way to securely record times yet, assuming one is possible at all. I am planning on refactoring the crypto logic out from the rest of the game into a “crypto gaming” module. So, to concretify my ideas, I’ll jot down what I’m doing and what I plan to do in this entry. I hope a cryptologist reads this, so that any flaws in my algorithms can be pointed out.

# Telegnosis

I have implemented the game I just described. It is rough around the edges, but the concept is there, and it’s a nice LAN party game. It can be seen at Soylent Software. Linux users will have to work with the repository for now, until I can find a way to nicely package ruby files (is there something like PAR for ruby?).

Next steps: LAN IP search, public server, polish presentation.

# Transactional Board Game

A few months ago, I wrote about an idea for a game based on transactional moves. I just played a board game tonight (something about vampires) at GameDev which used the lag effect well. It sparked that idea again, so I fleshed out the details and made a game. Namaste and I played a round of it, and it is pretty good in concept. It needs a few tweaks, and I will discuss the way we played it along with the tweaks I am considering. Overall it was a deep strategic game.

There are two players (I plan on generalizing to more) who play on a graph. The graph we used had about 45 nodes and 40 edges. Each edge was marked with a unique identifier (such that starting from any node, you could uniquely identify an edge connected to that node; I used numbers from 1 to 5, nothing higher was necessary). I wish I could show the board, but I don’t have a camera. Each player had three “supply centers” (a la Diplomacy) and three units. Supply centers were special nodes which lay at the coasts of the graph.

On each turn, a player could move one unit to a connected node. No two units can occupy the same node; moving in to a node where there is already a unit is illegal. You may move into supply centers that you own, but not that the opponent owns. In order to conquer a supply center, you must attack with strength greater than their defensive strength — Diplomacy style with support orders. I’ll cover the details of that in a bit.

The interesting twist: each player keeps a private pad of paper. On your turn you write down an order on your paper identifying a move (for example, I would write A3 which meant unit A moves over edge 3 connected to its current node). This represents a command in a “transaction”. After you have written down a move, you have the option of “committing” all the moves you have thus far written: you scratch them out on the paper and execute them all in a single turn, in order. However, if the opponent commits a transaction which involves (either enters or leaves) a node which your transaction involves, you scratch out all the moves in your transaction. You lose those turns. You may also voluntarily abort an entire transaction. Of course, a transaction which is just a single move and a commit need not be written down.

To attack a supply center which is defended with strength n (how that is done I wll say in a moment), you move n+1 (or more) of your units adjacent to it. Then, for all but one unit, you write a “support” order in a transaction (if this is committed before the final attack is made, the support orders do nothing). For example, “AS3” meant “unit A supports the attack against the node over edge 3”. After all the support orders are complete, a move into that supply center may be issued into the transaction. When the transaction is committed, the move is made and the player who made the move takes control of that supply center.

The defensive strength of a supply center starts at 1. If there is a unit inside the supply center, add 1. For every unit belonging to the owner of the supply center adjacent to it (connected by exactly one edge), add 1.

A special case: when a player gets down to one supply center, he loses a unit and his opponent gains a unit. The player who has 1 center selects a unit, which will from now on be controlled by the opposite player. If the losing player gains another center, then the same unit switches back to his control.

That’s how Namaste and I played it. It might have been the level design (very important), but the game felt a little bit “rigid”. It was too easy to trap units, and it was too easy to hold choke points. So I plan to add the ability to dislodge units (a la Diplomacy again), and also to make all supports automatic. So all you have to do to take a supply center or dislodge a unit is to have more adjacent units than the opponent does. This will make it harder to hold choke points. I also plan to make the graph a bit more dense: a larger edge/node ratio. This will make it easier to navigate the map, since one of the problems is that it took so long to get from one side of the map to the other; however I would still like an interesting topological structure, as opposed to a simple lattice. I also plan to add more units and possibly supply centers, since one of the problems was that it felt like you needed to engage your entire (three-unit) army to take a supply center, leaving you defenseless.

I plan on a networked computer implementation pretty soon. It should be pretty easy to write.

# Ichor

Flamethrowerflies is now called Ichor, thanks to Namaste and WordNet. I just switched it to use automake and autoconf, which is my first use of these tools ever. The upshot is that if you’re on a unix, presumably you can download it and do the standard configure, make, install process and it will work. Post a comment or email me if it doesn’t, please. The game is getting quite entertaining and is worth a try. After a few more weeks of work I intend on putting it into gentoo’s portage for some publicity.

# Next Steps on the Strategy Game

I’ve come to some sort of block on my strategy game. I’ve had plenty of time to work on it in the past few days, but instead I’ve been just watching TV and stuff like that. Currently it draws a large (256×192) which has a zoomable and scrollable viewport, just like you would expect an RTS to have. It also draws a truck on the screen, which can be selected and told to go places, using a pathfinding algorithm. There are four kinds of terrain implemented: dirt, road, and shallow and deep water. What is the next step? There are several directions I could go:

• I can currently support multiple units on the screen at once, which can be separately told to go separate places. However, if their paths cross, they simply drive over each other, not acknowledging each other’s existence. I need a way for them to avoid each other. The current best algorithm I have in mind follows: each player has a list of “forbidden squares”. Whenever a unit is told to go somewhere, it marks the five seconds or so ahead of it as forbidden. Every five seconds, the pathfinding algorithm looks through its path and checks to see if it has been blocked. The forbidden squares would be seen as blocking the path, so the unit would have to go around. I should also just consider a friendly unit-unit collision to be just like a wall collision, where the engine reconsiders its path and starts again.
• None of the many things that will make this game unique has been implemented. If I wanted to start on one of those, I should start on the “formation pathfinder”, which allows you to move a group of units in formation. That is, they never take separate paths from one another and if faster units start out in back, they never drive to the front. It should be a loose formation; i.e. it should allow a little bit of variability just so it isn’t stubborn. That requires the invention of a new algorithm, or a modification to the A* I am using now. I’m thinking of using A* over the graph of possibile complete formation positions on the board; i.e. where everybody can fit in formation. The weight would be based on both the time required for the slowest unit to arrive and for how long they had to be out of formation to get there.
• There are two more pathfinding projects. The first is another thing that will make the game unique: drawing pathfinding. The user draws a curve stating roughly what path the unit should follow, and the unit does its best to follow it, maneuvering around small obsticles and the like. I’m thinking the best way to implement it is to precalculate a diffusion map over the board for the path and access it during pathfinding. I’d like to get formation pathfinding working first, though.
• The last pathfinding project is to distribute the algorithm over multiple frames. To find a path across the entire map, sometimes the algorithm will take up to a second, which is far too long to wait. The algorithm should not take up too much time, and should send the units toward its best guess when it has not completed.
• Finally, I could add some more unit types and get some guns working.