11:20 AM

(2) Comments

Building a spec for the Handheld "Wired game" thingie

Mister Nizz

Building a Coding Spec


or trying to...

I've received some enthusiastic feedback from the lads over at The Miniatures Page for the networked/handheld gaming idea lately. The more I think about it, the more I realize that this idea can be done, and it can be done relatively easily and perhaps it won't be that expensive. So I got to thinking about how a program to assist in "wired gaming" would look like. What follows is more of a coding spec than anything else. I've mocked up a screen using a nifty looking product called PDA TOOLBOX that looks like it will integrate with VB Scripting and coding.

Functional Description

The verbiage that follows is an attempt to describe an application that will maintain a list of command "shorthands" that will be used to build a command that will export to a memo that can be beamed from one handheld device to another.

Basics: Environments, Language, Target Users, Deployment platforms

This specification is an attempt to capture the lowest common denominator for deployment.

Platform: an older, obsolete* handheld PDA. My target platform will be the Palm III or V handheld, for cost reasons. They still can be purchased on ebay, usually for under 15 USD. Depending on your budget, you might be able to obtain one for every player in a game using this sytem. The Pocket PC has many attractive qualities, not the least of which is easier integration into the Windows environment, but older Pocket PCs tend to be pricier in the after-market than old Palm Pilots. With that said, there is NO reason this design should not easily port into the Pocket PC development environment.

Platform OS: Palm OS 3.1 or higher. the lowest possible OS is desired.
Platform IR: Each handheld MUST have the capability to transmit memos as a function of the OTS operating system. Most PDAs do this as a firmware capability.
Color Scheme: Mono
Memory: The application should not really take up much more than 40K on a guess, and supporting files should not exceed 10K for database files.

APPLICATION SPEC

There are two elements to the app, which I'm calling BROADSWORD just to give it a working name.

1) The Battle Language Dictionary (BLD)-- the GM defines the command set, using an established tabular format.

1A) The BLD can be typed up, one line per data item, in an ASCII text editor in Mac or Windows. Columns depict the Command Shorthand (three letters), Type (four letters) and Plaintext description of the command.

1B) The GM defines the BLD based upon whatever ruleset he or she is using.. Fire and Fury, Command at Sea, Legions of Glory, whatever. In some instances the GM might have to adapt the rule set heavily to boil actions in the rules down to a very brief command shorthand. See the graphic for some ideas for a BLD:

Battle Language Dictionary

1C) The BLD is converted to standard Palm database or txt file (PDB) on the windows or mac computer. The BLD is then hotsynched to the handhelds being used to play the game.

2) BATTLEFIELD COMMAND PARSER (BCP)

2A) the primary user is the player now. He or she initiates the BCP as a Palm application by clicking on it twice.

2B) the BCP reads the BLD.pdb file that was synchronized by the GM earlier. The fields for the BLD should show up as a scrollable table in a window.

Here is a picture of a notional screen for the "Command Builder". It was built quickly with a development product called PDA Toolbox.

Broadsword Screen

2C) The table in the window below is the BLD. As the user picks command shorthands from the scrolling list, they display in the Command Builder window on top. When they are finished, the Player can tailor it by directly editing it in the window.

2C) when finished, the player presses the "Export to Memo" button, then switches to the memo pad that comes with Palm pilots as firmware. He makes any final changes, and then (using the native beam function builtin) he transmits it to whatever player needs it.

That's it so far!

* Note: As far as I'm concerned, any technology that continues to provide a useful function in an efficient manner is never "obsolete". I use the term in the marketing sense of the word here.