this should be the last of the basic outline stuff before i get into some actual development specifics, but i’d like for this to stand alone for any of my friends who may be inclined to help me on this little project. thanks for the patience while i set up the context. the way i thought to approach this, at least initially:

1. implement a javascript/svg version of the game playable in a single browser, unconnected to a server
1. this standalone game should still be multiplayer
2. implement a server abstraction so we can plug in the real server later … just “fake” the actions of the server for now
2. implement the gameplay actions of the server, based on the javascript mockup server actions above
1. i’d like to put this together with a python web framework like django, to make user tracking and other common tasks easier in the future, but we’ll see
2. urls should be RESTful, and the whole thing should be agnostic about the type of client making the api calls. we want to leave room for mobiles, tablets, vcrs … whatever.
3. wire the clients up to the server using ajax calls from the clients and comet calls from the server (probably XHR long-polling to start)
4. set up some account management possibilities, document the hell out of everything
5. consider generalizing the whole shooting match into a “map game” framework others could use for their projects

that’s pretty much all the big-picture thinking i’ve done to this point. next time i’ll get into some of the work i’ve done on the client, and get some code up here.

now that we know (the basics of) the game we’re trying to ape, how do we want to structure the web version? here’s what i came up with, with a bit of the rationale, in very basic terms for the beginners amongst us:

1. the game should be web-based — the entire player experience will be within the browser. almost everyone has a browser, and it leaves things open for mobile devices in the future
2. a server will mediate games between players, which will entail some type of login/player-tracking, even if it’s just on a per-game basis. this allows for multiplayer through a browser, and avoids the hassle of peer-to-peer connections (especially challenging with more than 2 players). it also opens the door for long-term tracking of statistics, etc.
3. the client (the app in the browser) should communicate with the server using ajax. this sets us up for “app-like” behavior, no reloads, and is compatible with many client-side libraries
4. the server will communicate with the clients with comet/server-push. this is a little more exotic, but common enough if you look at a lot of modern web apps. it’s necessary because (later) we’ll need players to be able to “interrupt” each other asynchronously, which we can’t do without some type of “push”

i also had to choose some languages/libraries/technologies to use at each level, and decided on a few to start with. i’ve been doing my initial work on the client using svg graphics (they scale well at all resolutions, and they’re free, as opposed to say, flash). the programmatic work on the client’s all in javascript so far, heavily employing the excellent raphael library, with a dash of jquery for good measure. i chose raphael over jquery svg and some other competitors because it has sick demos as well as nice documentation. i’ll get into specifics of each in later posts, describing some of the issues and successes i’ve had so far. until then!

to insulate the inventors from initial wrong turns, i’ll leave out specifics (premise, branding, unique mechanics) for a while. say we just call it “map game” for now? it won’t matter much until we get some fundamentals working. suffice it to say: the basic mechanics of the game are similar to a simplified version of risk, like so:

1. it’s played on a map (of the u.s.) where each state has a “rank” from 1 to 4
2. each state starts “neutral”, with a number of armies equal to twice it’s rank (2 – 8 total armies)
3. each of the 2-5 players choose one or more states to control (according to a “draft” we can get into later)
4. during their respective turns, each player may attack with any number of armies from states they control into adjacent states (neutral or enemy controlled)
5. each attacking army destroys one defending army, and each defending army destroys one attacking army (there’s no element of chance). for example, if five armies attack and three defend, two attacking armies will remain after resolving the battle
6. if there are attacking armies left after the battle, the attacking player takes control of the attacked state — otherwise it retains its previous owner
7. armies that attacked and “survived” can’t do anything else for the rest of the turn (move, attack again, etc.)
8. after all attacks are complete, the player may move any number of their armies (that haven’t attacked!) into adjacent states they control
9. when a player’s turn is over, states they controlled at the beginning of the turn “reconstitute” by adding a number of armies equal to the state’s rank

in a list like that, it seems more complicated than it is. ignoring some details, it’s similar to risk (without dice) on a u.s. map.