Game Characteristics

Games can be characterized as having "perfect" or "limited" knowledge. Also, they can be "deterministic" or "random".

Another important aspect of a game is what sort of "models" one must build for your opponents (and what is the cooperation model).

Chess is a deterministic game of perfect knowledge. So are: tic-tac-toe, checkers, and go. These games are of limited interest to me, because they are effectively searches of a state space. This limits the opponent model to estimating how well they can search the state space. The simplest being, "assume they can search the space as well as I can". This makes the game no different from playing oneself.

Most games include a random element (usually dice, cards, or a spinner). The simplest games are entirely random (they could be reduced to a coin toss to determine the winner). Examples of these are Candyland and Chutes and Ladders, which are really just tools for teaching game mechanics to children.

The only example that comes to mind of a deterministic game of limited knowledge is Stratego.

Also worth mention is Poker, which is often entirely random (stud vs. draw) and may have zero public information (a counter example is Texas Hold'em). Here the outcome of a player model is boolean (bluffing or not bluffing), but coming to that decision requires great skill.


A complex game will include all of these elements: combinations of public and private information, randomness and certainty, complex models of player behavior (driven by a wide choice of possible moves at any point) and player cooperation.

A good game can be built from a simpler set, but this space tends to be better explored (will you make a chess analogue?)

New Space Opera

"The New Space Opera" (ed. Gardner Dozois and Jonathan Strahan) - There were a lot of good stories in here. It's good to see there is still some space opera being written today.

Icons

Getting close!

I've been putting off doing the math for the icons :) Lots of radical threes.

Here we can see the three main icons - * for a city, ! for enemy units, @ for my units. ALH also has icons for ships, taxing, production. It also differentiates between my units on guard vs. not on guard. Not sure how important that is (although I need ships)...
I also still need to add roads and buildings.

Show Production

My goal is to get this thing to the point where I can do my turns. I added exporting orders yesterday, now I can display the region production.

I'm using a wrapping label, which seems less than ideal. But I wasn't sure what else would look good...
Now I need to show whats for sale (and maybe what they'll buy, but that is less useful). I also need to show unit skills somewhere.

Z Problem

Programming is all about assumptions. You have to make certain assumptions about what your software is going to encounter, and how different modules will work together. To do otherwise would require total knowledge, and the development of a system that could handle anything (which would make it smarter than any human, so you'd be developing strong AI).

As long as your assumptions hold, your software will work well. And if new features fit in with those assumptions, they will be easier to add. If they violate the assumptions, you're in for a world of hurt.

When I started the True Atlanteans client, I knew it was possible to have a z coordinate for hexes. But I didn't have any test cases, and I figured it was a long way off. Well, I just got some test cases, so I guess I have come a long way!



Once again, Tcl and Sqlite made things pretty easy. I rebuilt the tables with a z coordinate and added a couple of entries to the right click menu (yea, I have a right click menu, unlike ALH).

I also fixed the one man unit bug in the old style parser. Rereading the last blog entry made me realize that items have [ABBR], while flags do not.

Items Up!

I must say, working with Tcl and Sqlite has been a real pleasure. Adding orders required changes in about 3 places, most being one or two lines of code: import the data from the TON file, pull the data during unit update, build the GUI items.

The items changes were about the same. My original thinking was that I would need a separate table for items, keyed by the unit id. But Sqlite lets me toss a whole Tcl list into a cell, so I just went with that...

The item box is above the old order box. I figured it would scroll pretty often, so I stuck a scrollbar on there right away (orders might need a scrollbar).

This example shows the frustration inherent with trying to parse the old file format. Units with one man don't get that man in the items (Fast Couriers are one man units in my empire).

Why?
Here is the entry for Fast Courier 416:

* Courier - Fast (416), Last Outleans (6), avoiding, behind, revealing
 faction, holding, receiving no aid, nomad [NOMA], 14841 silver
 [SILV], 20 horses [HORS], 5 herbs [HERB], 2 mink [MINK], 4 velvet
 [VELV], ivory [IVOR], mithril [MITH], 2 chocolate [CHOC], pearls
 [PEAR], 2 spices [SPIC], 2 roses [ROSE], 2 caviar [CAVI], 2 cashmere
 [CASH], iron [IRON], silk [SILK], pick [PICK]. Weight: 1089.
 Capacity: 0/1400/1415/0. Skills: combat [COMB] 1 (30).

The star ('*') indicates this is a full data report ('-' is limited data, '+' is buildings). Then comes the unit and faction names. After that are the unit flags, then items.
Everything is comma separated, with big groups period separated (items, weight, capacity, skills).

But there is no way to tell when flags end and when items begin.

My parser is looking for a number (no flags have numbers, and any item count above 1 will have a number). I suspect ALH understands all the men types, and is checking that... or it understands all the flag names and promotes mismatches. I guess I could tell by making a new flag and seeing if ALH promotes it to an item with count 1 :)

Orders are in!

Lots of furious Tcl (and SQL) hacking behind this!


Pretty close to ALH. I just need to capture changes to orders, and add hex decorations. Then it will be on to new functionality!