I know Panda in person outside these forums and spoke with him about it. He's interested in helping. We both have the requisite skillset, well more or less. I don't want to get your hopes up until july does actually roll around and I find the time to start, but should I start, I can promise I'd at least see it through. We'll need access to an appropriate server; I have some personal ones we could use, but something more community-run would perhaps make more sense (I don't know if your fleet-commander.net system has php or mysql, but that's what we'd need, server-side).
Also, when the time comes, I can provide access to a coding repository (SVN) so that if anyone else wants to work on it with us from the community, they can.
I'm going to use this space to roughly sketch out what I've thought about so far, and see what other people think about how to structure the source. We certainly want to make this object-oriented, and store most of the object data in the database. Please note that while I do coding, I tend to not use proper pseudo-code or break things down in a way that professional programmers would, so bear with me.
The system will be storing two different types of data in the database itself: meta game data like what the stats are for a given ship or weapon, and then game-specific data, such as where what ship instances are located, orientation, etc. I will try to refer to things that are overall stats as 'playing pieces' in the database (aka what is a Rapier) and 'game pieces' (how badly damaged is the rapier piloted by Avacar in game X?) The latter is a 'game piece' the former is a 'playing piece', the 'template' if you will.
We need a top-level class, maybe called 'piece' or 'indicator' that would have map-related features to it. For instance it would track:
-x-y coordinates of the 'indicator' on the map
-orientation within the hex of the piece of the map
-velocity of the object (note, I don't think we need acceleration here, because only ships have that thus far)
-basic methods for moving the piece around the map, including smart checks for map-edges (i.e. indicator->move(2,1) for 'move 2, turn right 1' as a move order and have it update x-y appropriately)
-a reference to a transparent .png file set for various orientations of the piece (or maybe just 1 and use the php draw libraries to rotate it; gotta think on that)
-an 'explosion' method which determines what happens when the indicator is destroyed
-a reference to a transparent .png file for the explosion picture
-some amount of 'volatility' (aka when it goes boom, does it take anything with it, and in what radius; default for all our current indicators=0, but this could be useful down the road for things like the mace)
-a default target roll (TR)
There would be at least 3 classes that inherit from the indicator class, they would be:
-ship
-missile
-environmental_object (aka asteroids)
We also need 2 more classes, which does not inherit from 'indicator' which is:
-weapon
-pilot
The ship class would need *at least* the following properties:
-all the ship stats (including acceleration, current/max hull and shield, shield regen rate, note that all indicators have a TR, so this was inheritedetc.)
-an array of weapons on the ship (note that in the database of playing pieces, it would have to store the weapons AND their orientation w.r.t. the ship 'forward' direction. The weapon class' constructor would take in weapon names and orientations, but once this was done, orientation data is stored on the weapon object)
list of each weapon on a given ship class
-a 'constructor' method which would, knowing what type of ship it is supposed to be, pull the base stats out of the database of possible pieces
-a reference to which pilot object is flying it
-counters for chaff pods and afterburners (max values and defaults set by constructor)
-a number of methods for special movement a normal indicator can't do (banking, all the afterburner related moves, all the pilot-skill related moves)
The 'missile' class needs:
-damage done on hit
-a calculation against chaff pods/hit avoidance
-health? (just put hp=1 so they can be shot down by point defence?)
-a 'death' timer (aka after X turns, you just vanish)
-an intended target (blank when not applicable)
Note carefully: 'missiles' are the things we see on the map itself, whereas 'weapons' are a ship component that fires missiles. The rules for things like heat-seeker, df, etc. are all stored in the weapon, done when you try to fire the weapon at a valid target. The 'missile' itself just knows who it is going after and how long it sticks around.
The weapon class needs:
-damage, range, orientation vs. ship, firing arc width, refires
-a method for determining if a target is in range of a weapon (aka rapier->weapon[0]->range(Panda) to see if my #0 particle cannon can hit him drivers can hit panda)
-a method for firing the weapon at a target (same as range, but does damage.. hmm, maybe we can just merge them, and have it return the damage and the range, and if you happen to fire at something way out of range..well you're stupid)
-targetting requirements (if you're firing a missile)
-a field which says 'I'm a missle launcher' to toggle on special firing requirements
-a field which references which missle-indicator 'playing piece' needs to be spawned as a game piece if successfully launched
Note that down-the-line, if component damage is better fleshed out, then we would likely introduce a top-level 'component' class, of which 'weapon' is a sub-class, and the ship would
have an array of standard components, not just weapons. In this case, we would want to
also add a few lookup methods to the ship class, that can find one of its components based
on a keyword 'aka rapier->lookup(particle cannon)' to have it return a reference to both
particle cannons, which could be items like 13 and 14 on a list of 'ship->components[]' which
was populated by the server's database of playing pieces.
Okay, on top of this, clearly we have a 'game' class which doesn't have any 'playing pieces' to be stored in the datatabase, but instead only 'game pieces' per se (okay this terminology is getting cumbersome since the game itself isn't a piece, but whatever). The 'game' would store things like:
-all pilots
-all current indicators
-current turn
-eliminated indicators
-grid size
-background image
-"slow player" countdown timer value (auto-kick-from-game system anyone?)
-current turn number
-current phase number
-human readable game name
-unique game indicator (likely integer)
-methods for reading/storing the game data from the database. note that this would involve
creating and loading all the ships from the 'playing pieces' info, and then updating them based on stored 'game'-class info to their current 'game piece' data. I am not sure what's best here, to store all the changes in the 'game' class, or to separately store a whole table full of actual incremental ship updates. Certainly no reason to re-store 90% of the ship/indicator data on a per-turn basis; only really orientation, position, health and consumables are necessary)
Each 'game' instance would be stored in the database, meaning each turn would have
a database entry with all the above info, possibly with references to a side table for the game-specific piece data (note that for everything discussed so far, I'm talking about the php end of things, and not at all what the mysql tables look like, for the most part. They would obviously have cross-references all over the place, so a ship 'game piece' knows what 'game turn' entry it is associated with, if we store the data that way).
Okay things I haven't covered here but could have:
-pilot classes
Things I haven't covered here that aren't directly related to the core classes:
-the entire UI (player mode, game administrator mode, add-new-'playing piece' mode to do the initial setup of the server as Ironduke adds new rulesets or features)
-player login/authentication system
-handling players in multiple games, players controlling multiple ships in a given game
-I did not point out where much of the game code resolution takes place, how it handles turn
calculation etc. (much of the actual combat code I think ends up on the 'weapon' methods, but that's up for debate)