This is some further thoughts in relation to the Weekend Challenge over at Psychochild’s blog, related to remaking/re-releasing older, classic games. In the comments there, I left one referring to an old Apple II game named Robot Wars that I have some fond memories of. Another commenter mentioned some of the old BBS door games, and how those might even be used to help spice up blogs today.
Stir ideas briskly, let sit overnight…
The idea here is to create something that can be played “casually”, in a couple of minutes per sitting, yet has enough depth to it to keep people coming back for more. I also want it to be something that can be linked to in a blog, allowing visitors to root for, or even compete on behalf of, the “home team” as it were.
The basic setting is the similar to my fading memories from the old Robot Wars title. Basically, in the “future”, robots battling in arenas becomes a national sport, and you are one of the competitors. Your task is to design the control program that will win you trophies, fame, and fortune.
Obviously, the real world has already caught up to and largely blown past this alternate future setting… but it could still be a fun little diversion anyway.
The basic game play here is to create little scripts that will control a “robot” in an “arena”, set to battle it out with up to 5 other robots, presumably with different control programs, and see which one lasts the longest.
To make things interesting, the tools and data each robot has to work with is extremely limited, and must be essentially discovered over time. The winning robot will thus be the one that most effectively can determine where it’s opponents are, and can most effectively damage those opponents while avoiding damage to itself.
I’m going to take it well beyond the original design, which was pretty straightforward, since I’d like to make it something that can hold people’s interest for a longer period of time, even in an online setting (the original was a stand alone game… even playing it in the computer lab setting with just a dozen or so people, it didn’t take all that long for the bot designs to get perfected and kind of “fossilize”.)
The basic robots in the game will consist of 11 systems: a laser range finder, a rail gun cannon mount, CPU, battery, recharger contact shoe, frame swivel drive, undercarriage tank treads and drive, and 4 ablative armor plate facings.
The armored laser range finder (10 lbs) is attached on top of the robot’s chassis, and can be activated periodically to find out the distance to any obstacle at a determined angle. Swiveling the range finder to a new facing costs 50 units of energy, and the range finder can swing a full 360 degrees in a single tick. Engaging the range finder also costs 100 units of energy, and requires a single tick to obtain a result. Firing the range finder will report the distance to the nearest obstacle: if the obstacle is not an arena wall, the range value returned is a negative value to indicate a potential target.
The rail gun cannon mount and incorporated ammo clip (75 lbs, +1 lb per shell remaining) represent the primary offensive capability of the robot. The rail gun is mounted on upper frame, and thus can be rotated via the frame swivel drive to fire at an angle independent of the drive undercarriage. The ammo clip holds 50 shells, each equipped with both a timed fuse and an impact detonator. Shells will explode upon either impacting something or upon expiration of the timer, causing damage to all targets within a significant radius, based on the distance from the point of detonation. Charging the railgun requires a number of units of energy based on the range the shell needs to travel, and requires a number of ticks to charge relative to the units of energy required. The rail gun can be pre-charged to any level at any time, at an additional energy cost of 10 units per tick cost to maintain.
The railgun can also has basic elevation control: it can fire at a low, medium, or high elevation. Low elevation hits do more damage to undercarriage components (tread drive, recharger contact shoe, frame swivel drive), high elevation hits do more damage to chassis top components (laser range finder), and medium elevation hits concentrate damage on the centrally located elements (cannon, armor, battery, CPU). Elevation changes cost 10 units of energy and require 1 tick to complete.
The CPU (5 lbs weight) is both the heart and brain of the robot: it is the destruction or depowering of the CPU that indicates a loss in the arena. The CPU simply executes the program loaded into the bot at the start of the combat at a rate of 1 instruction per tick. When fully active, the CPU consumes 500 units of energy per tick (mainly to power connectivity to component systems). The CPU can be set to sleep for a number of ticks, during which no activity on the part of the robot is possible, but the energy consumption of the CPU is reduced to 50 units per tick.
The battery unit (40 lbs) is the energy reservoir of the robot: any energy beyond what can be obtained via the contact shoe comes from this component. The basic battery holds a maximum charge of 100000 units, and recharges automatically per tick (up to that maximum) if there is any energy left over from the amount obtained through the contact shoe. Damaged batteries hold less power, and may even lose energy per tick. Warning: overcharging a damaged battery unit will cause the unit to explode with devastating effect if left in that state for 20 ticks (especially if there are unfired shells remaining in the gun mount as well). The battery unit is mounted rearward of the CPU, opposite the gun mount.
The recharge contact shoe is a component that is generally in contact with the arena floor tiling. Most undamaged arena floor tiles can provide some number of units of energy each tick to the robot located on them through the contact shoe. In a basic arena, 1500 units per tick will be available. (Floor tiles damaged by shell detonations may provide less energy.)
The frame swivel drive component allows the upper frame to swivel independently of the drive train. The basic frame swivel drive is capable of a maximum 45 degree swing per tick, at an energy cost based on the total current weight of the upper frame (5 units per lb). Thus, a fully loaded, undamaged basic frame (total weight 300 lbs) costs 1500 units per tick to swivel.
The undercarriage treads and drive train (500 lbs) provide the robot with the ability to move about the arena. The entire system is exceptionally efficient, but the power cost is still substantial, based on the rate of acceleration desired. A slow acceleration rate (1 ft/s^2) costs 10 units per lb of total weight per tick, a moderate acceleration rate (2 ft/s^2) costs 20 units per lb per tick, and fast acceleration (3 ft/s^2) is 30 units per lb per tick. Turning can be achieved at a 15 degree rate of change per tick, for an additional 10 units per lb per tick. (Note that while the robot can certainly turn while moving, all the laws of inertia do still apply.) Slowing down can be achieved either through passive braking (friction) or active reverse acceleration.
The high-tech ablative armor facings (30 lbs each, 1 for each of 4 facings, front, left, right, back) can each absorb significant amounts of damage, offering the robot some resistance to crippling component damage, even from direct hits. As the armor absorbs damage, its weight reduces as the armor powders to disperse the energy.
Additional components might be allowed in more advanced stages of play, including basic components with greater power, larger ranges, differing power draws, heavier or lighter weights, and so on. Other additions might include minelayers, smokescreens (range finder countermeasure), oil slicks, and so on.
The basic arena will be an empty square area, uniformly filled with powered tiles. More complex arenas might incorporate permanent or ablative barriers, unpowered tiles, power-up nodes, areas of differing traction (frictionless zones, mudtraps, etc.), and so on.
Programming the bot
While the original Robot Wars used a rudimentary sequential programming model, since we are bringing it up into the current era, we should probably move it to something more similar to OOP, instead… at least something event-driven along the lines of VB.
The basic object model might look something like:
Properties: Status (% damage), Angle (current setting), Range (most recent value returned)
Methods: Rotate (angle), Activate (obtain reading)
Events: RangeError (if activation fails due to damage, insufficient energy, etc)
Properties: Status (% damage), Elevation (hi/mid/lo), Range (current range/charge), Ammo (shells remaining), Condition (jammed?)
Methods: Empower (add range/charge), Depower (reduce range/charge), Fire (fires shell), Clear (dumps undetonated shell, used to clear jams)
Event: FireError (on shell jam, timer set failure, out of ammo, other conditions due to damage/lack of energy)
Properties: Status (damage %), Charge (current units), AlarmCharge (current alarm setting)
Methods: SetAlarm (unit charge below which Alarm event fires)
Events: Alarm (either on reaching low energy setting, or upon going unstable due to overcharging)
Properties: Status (% damage), Current (amount of energy available that tick), Active (on/off)
Methods: Activate (turn on), Deactivate (turn off)
Properties: Clock (ticks since battle begun), Status (% damage),
Methods: Sleep (# of ticks to sleep)
Events: Awakened (fires upon exiting sleep mode), Damaged (fires upon any component taking damage)
Properties: Status (% damage to frame swivel), Angle (current angle of facing-true facing, not relative to drive train)
Method: Swivel (change angle)
Events: Error (swivel change failed, due to damage or lack of energy)
Properties: Status (% damage), Speed (current rate of speed), Angle (current angle of facing, not motion)
Methods: Engage (increase speed in direction of facing), Reverse (decrease speed in direction of facing)
Events: Error (fires on failure of method due to damage or lack of energy)
Properties: StatusFwd, StatusRgt, StatusLft, StatusBck (% damage on the four facings)
The instruction set would include a basic value setting command (Let), a conditional test (if-then-else-endif), and a conditional loop (while-endwhile), as well as the various method calls.
The core of the game will be writing control scripts and testing them against one another in the “arena”. It will be entirely up to the script to figure out where the robot is, where its opponents might be, and how to damage those opponents while avoiding return fire. Additional tactics might come from trying to selectively disable their movement capabilities, or their detection capabilities. Defensively, the script might try to keep moving to avoid fire, swivel to present different facings to sustained fire, and so on. Obviously, damage on particular facing gives some limited indication of direction to a potential target, as well.
Building on the basics
While the basic script writing and testing of scripts is a fair start, its only one piece of the larger puzzle. To take the game to the next level, I’m visualizing an organized competition schedule, across multiple tiers of challenge, and a corresponding reward tracking system.
Players wishing to compete would establish an account. Each account would be allowed to submit 1 script per day to a daily single elimination competition. The entries that made it to the final round would receive “prize credits”, with the top 2-3 gaining access to a monthly competition in that tier as well. Placing high in the monthly competition would also grant the account access to the next tier of competition.
Accounts could also offer and accept challenges from other accounts. Once per day, each account would be offered a “free” challenge, one basic robot build provided at no cost. Credits gained from various sources (prizes, previous salvage, script sales) could be used to fund additional challenges as desired. In such challenges, the winning robot/account would get limited salvage rights over the losers, the ability to take one component from each robot they outlasted. Salvaged components could be either stockpiled for future fights (if not too damaged) or sold back to the bank for additional credits.
Battles are recorded as they are resolved, and those records can be “sold” to the bank for additional credits (with the permission of all participating players/accounts). The organized competition battles are automatically “sold”. Such recording can be accessed at will by any account, either simply for the entertainment value or as potential research into an opponent’s tactics.
Weekly polls/competitions for “best recorded battle” and similar incentives, with rewards in credits, could be incorporated as well.
Tiers of Competition
I can visualize four tiers of competition without much effort: the basic tier (basic robots in the newbie arena); the gearhead tier (heavily modified robots in newbie and/or “easy” arenas); the expert tier (lightly modified basic robots in various arenas); and the unlimited tier (anything and everything goes). The rewards for both victories and battle recordings would increase significantly at each tier.
The States of Greater Blogistan
This brings us to the potential blog tie-in. Blogs which linked in to the game could essentially each run it’s own individual leagues/competitions. At regular intervals (quarterly?), there would then be a coordinated “Inter-Blog Olympics”, with the rewards being bragging rights and perhaps additional small prizes. Each blog “league” would submit 1 (or more) control scripts, and associated bot “blueprints” for the advanced tiers. After validation (checking for duplicates and/or plagiarism), a competition would determine the best scripts for recognition and reward.
I’m thinking this could be implemented as a relatively straightforward Flash project. Scripts would be plain-text, of course. Battle recordings would be XML documents, easily accessed from Flash. You’d need a host server that could serve up and store the various documents, but it wouldn’t have to be anything spectacular.
The Flash project should have a script “test bed” with both a debug mode and a “battle sim” mode. It’d be nice if there could also be a simulated “Battle Channel feed”, showing various random battles as they get “sold” to the system, maybe mixed in with mocked-up advertisements for advanced robot components, “pre-battle color commentary”, that kind of thing.
Well, that was a long one… good to get it down on paper, tho, even if it never sees the light of day.