RoboForge was a video game released in mid-2001 by Liquid Edge, a small start-up company created to develop and sell this game. The game could be played offline, but it was primarily built around its online component, so should be considered to have died on Jan. 31, 2004 when the company officially shut off the tournament server. Some fan sites seem to exist, using the game's test simulator to run tournaments and competitions manually, but these are few and far between; the vast majority of them (all that I could find at the time of writing, in fact) are out of service. The game is no longer available.
RoboForge had a fascinating concept: build a robot on a limited budget, then enter it into an arena with one other robot in a full-3D simulation in one-on-one combat until a robot's CPU is destroyed, a robot's chassis is destroyed (which necessarily destroys the CPU, more on that later), or time is called, in which case the robot that did more damage (percent of opposing maximum HP, as taken by total component HP) wins. At the "High Accuracy" level of simulation, collision detection was quite accurate with very little clipping, with one critical exception.
RoboForge was a purely intellectual game. An eye for sturdy robot design and a brain for careful robot development were required, but no reflexes. Robots did not fight in real time. In a visual, block-driven programming language strongly resembling RCX code from Lego Mindstorms but having strong influences from the Java programming language the game was written in, contestants would program their robots to automatically compete, based on knowledge of every single variable in the game, and positioning of the opponent in zones that were defined as part of the programming process. For moves other than basic commands to the chassis, robot motion was created by a sequence of snapshots, by which motors were moved by the user to given positions; the robot would then move those motors to that sequence of positions to execute the move. Programming was fairly easy mechanically, but it was frequently a challenge to write an AI more intelligent than "approach enemy... smash big time." This programming was very usually sufficient, with the exception of the odd robot designed to do some damage early on and then run like hell to keep the HP percentage advantage. This strategy never won a tournament.
RoboForge tournaments ran weekly, with contestants uploading their robots on the server across the course of the week, to come back after the tournament for videos of the matches- any of their own, plus the semifinals and finals- for information about the outcome. Matches could be watched as soon as they completed, but matches being simulated could not be watched until they were complete.
The same was largely true of matches run in local simulation. This may have been one of the reasons the game failed and found only a small audience that was not enough to keep the company going. To reach that supreme level of simulation accuracy, the program could not simulate a match in real time (on computers of that day; a recent computer should be able to pull it off). A three-minute match could take upwards of half an hour to simulate.
Initially, tournaments came in two classes: amateur and professional. Amateur tournaments were free to enter and had nothing but bragging rights to win; professional tournaments, until the company stopped doing them, cost five dollars to enter but gave $100 to the owner of the robot that won. For approximately a third of the game's life, amateur tournaments had a 30,000 credit limit for robot cost (every compontent cost a certain amount, so robots were constrained in size); this was later brought up to 40,000 credits, making the only difference between the two tournament levels the money. (Professional tournaments always had a 40K limit.) These limits led to some very interesting design trade-offs, as robot designers discovered what corners they could cut and what were disastrous. It was discovered that only one sensor could be used if it was on a rotator and the robot did not require particularly accurate attacks; many spin bots used this strategy very effectively. Shields were often used as construction components, instead of basic components which were then covered with shields; this design had a sharp disadvantage, however, because it did provide one less chance for a robot to get hit and not take critical damage.
Part of the reason of the slowness of simulation was that every component had its own HP, and every component had damage tracked individually. When a component ran out of HP, it was destroyed, as was every component built upon it. Robots were built in tree-like structures: any given component was "built onto" exactly one other component, with the exception of the chassis, which all parts were built from. Components were frequently connected to more than one other component, but only one component was the "supporting" component; all other connected components were supported by that one. Therefore, destroying a central component could be catastrophic, with half of the robot exploding in a nicely-rendered cloud of smoke.
The game began to fall into its decline when strategy began to stagnate badly and one of the it's not a bug, it's a feature elements became mandatory: passthrough abuse. "Passthrough abuse" is the simulation element that if two components started out touching each other or passed through each other, they did not count as colliding until they moved out from contact and then back in. Abusing this led to very effective ways to protect and secure robots that were never intended by the software developers, leading to nigh-invulnerable designs where all the vulnerable components were hidden deeply within the high-HP chassis and the shields mounting them backwards were themselves shielded many times over. It got to a point where the only way to have a reasonably competitive robot involved exploiting this bug, and the developers declared that it would never be fixed because a complete rewrite of the system that worked the motors would be required, and for that matter all component connections, because every single joint had overlap.
The shield pass-through stagnation was much less important than the spin-bot stagnation. It became obvious that, like in the real-world BattleBots, Robot Wars, and similar contests, spin bots would unavoidably dominate. The rotational intertia of spinning parts overcame hammers every time, and with no mechanism for a robot to ever be flipped over, wedge bot designs were stricly impossible. (For that matter, there was no wedge chassis- only two of them were even wheeled, although the hover chassis tended to be the most effective for many designs.) This was partially derailed early on when rotator components lost their double edge connections, so they could not be easily stacked. It was quickly discovered, however, that the 360-degree turn possible out of the Standard Omni joint, especially when several of them were stacked together to turn at the same time for unrealistically high speeds, was more than sufficient to get a strong hit in before hitting motor limits and requiring a reverse spin.
The essential problem was that it became clear that there actually was such a thing as a definitively best design, and the only improvements over the basic spin bot were incremental. This was actually a very fascinating process to watch, but it hit levels where only the absolute best mechanical engineers could figure out how to improve the designs and compete. The user known as Shiva became famous for a robot known as Thai Mai Shu, one of the earlier truly effective spin bots. Thai Mai Shu won a disproportionate number of tournaments.
Some unique designs were successful for a time, but spin bots were eventually modified to handle them. Hung Lo Charlie was a fairly successful one; it relied on being taller than its opponent and spinning vertically with a stunning amount of inertia. Hung Lo Charlie, like most spin bots, exploited a bug in the physics engine: the torque required from a motor was related only to how unbalanced the motor was; a typically balanced spin bot could get stunning speed and power unless it lost an arm and got unbalanced; if it took that much damage, however, the robot was generally screwed anyway.
Game stagnation caused people to lose intrest, and provided an intimidating barrier for would-be newcomers who might not have gotten past the 14-day free trial as there was no such thing as a "newbie league" for new players to get their feet wet; there were some competitions that were listed as for new players, but the enforcement on this did not actually work and was widely ignored.
The game was a very intellectual game of engineering, logic, and programming. That was a lot of fun if you like that sort of thing, but it did not appeal to the mass market crowd needed to justify the original development costs, much less the ongoing costs of running a server that needed to be capable of a large number of high-fidelity 3D simulations to run the tournaments.
With niche-only concept, a high bar for entry, and stagnation setting in, the game failed, another example of a well-executed game that was fun for a reasonably large audience, but, unfortunately, could not hold its own in the market. It was fun while it lasted, however, and I as well as many other former RoboForge players hope that someday, a RoboForge 2 could rise from the ashes, fixing the flaws with the game, running simulations in less than ten times their run time, and live to rule the world again...
Information about dates comes from http://www.roboforge.net, which is somehow still alive. Information about the game itself comes from many fond years of playing it.