/home/projects/ftl2.html :: page created - last updated: 02007/08/15 - 02008/07/06
Fall To Life was a free mmorpg which I worked on back in 2004. There were, of course, creative differences, and the project eventually collapsed. More embarrassingly, the only evidence of my participation is an archived copy of the forums. I'm the latest post in the Off Topic subforum, of course.
I wrote rather a lot of material, most of it now embarrassingly obsolescent, but rather liked some of it, and so shall post here what Fall To Life could have been, maybe, a couple of versions down the road.
There are a great many FPS tropes which are entirely nonsensical, yet are required to facilitate gameplay. An example, taken at random, of, say, Half Life 2: Deathmatch. (HL2DM) In this game, both the ragtag rebels and the transhuman, cyborg, and generally badass Combine supersoldiers run at the exact same speed, and can keep it up for, apparently, ever. This is because trying to implement a realistic fatigue system and comparative fitness levels would be a lethal double shot of lousy balancing and crappy gameplay.
And, of course, both the combine and rebel reinforcements appear out of thin air, along with their materiel and magical "health kits", which instantly heal a severely wounded, yet visually unharmed soldier back to his full compliment of one hundred "health points". I could literally go on for pages.
Why are video games such a massive, mind-numbing departure from reality? It's because we already have a word for a place where even minor wounds require weeks of hospital time, where soldiers tire after sprinting for a mere hour at a time, and where logistics is almost as critical as combat operations.
It's called Reality.
But it should be possible, if not trivially easy, to design a game that at least gives a cursory nod towards realism while still retaining significant playability.
For starters, let us examine the simplified human as used in pretty much every FPS. E can run at full speed indefinitely, sustain significant damage without slowing or becoming incapacitated, and never needs to eat, drink, or use the bathroom. (With the notable exception of The Ship) In fact, this simplified human sounds rather more like a robot than a human.
There is even a plausible reason for a combat robot to be remotely controlled by a human. (The teleoperator being you playing at war in the comfort of your own home.) In Leo Frankowski's A Boy And His Tank
Strong realism does not always mean not fun, as recently alleged by an excellent troll on #7chan. Most realistic games are less than exciting because they attempt to closely simulate the limitations of a human body. But, of course, a robot is bound by none of these. There is no reason why a perfectly realistic robot cannot run at sixty miles an hour and leap buildings with a single bound. In practice, this probably wouldn't be implemented, due to a combination of balance and content creation issues. Fast players make large maps seem smaller, which, of course, requires larger maps. It is also damnably hard to shoot a small, fast moving target, which makes it harder to defend your base, which incites frustration in the players. But this is irrelevant. "Fun-ness" is complex and subtle, and depends not on design concepts, which this document is concerned with, but small gameplay details. Fun games are fun because many small things align perfectly, not because someone set out at the beginning to make it fun. (Though someone probably did.)
A good example is of Doom 3 and FEAR. Both are designed from the ground up to be damn scary, but FEAR is fun and Doom 3 is not. It's because, in FEAR, when you pull the trigger, shit goes down. The gun kicks, tracers zoom into the target, there are loud, manly noises, and crap blows out of the target. In a major firefight, things are flying around, people are exploding, gunfire is tearing up the walls, sparks are being kicked off of metal surfaces, shit is blowing up, and everything blends perfectly into a catastrophic melee of death.
In Doom 3, you stumble around in the dark with a shiny nerf gun, and every so often an eight foot tall demon jumps out and tears your head off. It is a tedious, pointless grind, and I played it for maybe twenty minutes before giving up and returning it to the store for a refund.
Think I'm spouting bullshit? Read this wired article. Over and over they emphasize the small changes that make a game fun. You never hear about plot, graphics, overarching themes, mission statements, &c. It's because all this is completely irrelevant to how fun a game is.
Utilizing the robot paradigm leads to interesting conclusions, but first we have to detour a bit. Way, way back in 1999, Unreal Tournament (UT) introduced a mode of play called Domination, where two teams battled over several control points, which awarded points to the team controlling them. Reach a certain number of points before the other team and you win.
Battlefield 1942 (BF1942) improved on this basic concept by making each control point a respawn zone, and spacing them out over a large map. Each control point also produces vehicles at regular intervals, and requires an attacker to first neutralize the control point before capturing it, instead of UT's instant capture model. This makes each point the focus of the match, because they were the source of vehicles, the key to having any fun at all in BF1942.
Since, essentially, robots are small, complicated, vehicles, each abstract "control point" could be implemented as an automated factory, which passively churns out vehicles and combat robots for whichever team holds it.
That is what I've been thinking of as FTL version 1. It could be easily implemented as a mod for BF2142. (The fourth release in the Battlefield series.) It can also be easily expanded.
Since humans are only used to enhance the combat effectiveness of a combat robot (hereto referred to as a drone or remote.) then they would be computer controlled for noncombat roles. One of the major chores of BF2142 is finding a vehicle, which are quickly depleted from the forward control points, since that's where everyone spawns in; and usually end up moldering in some forgotten corner of the map. Since each control point is also a production facility, there's no reason for the commander not to use a RTS-style interface, and order all the unused vehicles to drive themselves to a rally point conveniently near the fight. Each vehicle could be loaded with empty drones, to be conveniently activated by players as the vehicle becomes usefully close to the front lines.
Each control point could also produce automated artillery, automatically firing upon player designated targets, then moving to avoid counterbattery fire; occasionally returning to a control point to resupply. Supply trucks could also transport large numbers of drones or weapons to forward control points quickly, or place NLOS-LS racks or automated defense drones.
Remotes are controlled through an quantumly entangled bit reservoir, which which impossible to covertly listen in on, or overtly jam; but contains a finite amount of bandwidth. When that runs out, the remote falls back on one-time-pad encrypted radio, which can be jammed. When the one-time-pad runs out, then it falls back on public-key encrypted radio, which can be jammed or brute force cracked, and if the encryption is cracked, then the enemy can just hijack the equipment. This introduces an interesting dynamic, in that deep-strike teams or isolated outpost have limited lifetimes, and must reestablish contact or face a two-front war, both physical and virtual.
While version 1 and 2 primarily concern themselves with the tactical level, version 3 would be strategic in scale, covering entire continents, planets, or even solar systems.
In v1/2, autofactories are black boxes, which produce a constant supply of a limited range of units. In v3, factories are revealed to be generic wrappers around often completely different assemblies of individual production elements. While v1/2 autofactories completely ignored resource collection, or handwaved it away by assuming that the relevant equipment was underground; v3 factories producing finished products (rather than subassemblies) will need to draw purified feedstock from numerous resource collection and processing facilities. Automated factories will require different feedstock depending on the product, munitions will require more organic materials than heavy armor, which might require exotic minerals, and thus would have to draw from more RC&P facilities.
The design or modification of existing designs would be available to the player, resulting in corresponding changes in material requirements for the finished product. This would add a whole lot of complex issues, which I'm ignoring right now.
Research could be performed at two different levels. AI expert systems, which require large, expensive computer facilities, could make incremental optimizations of established designs, reducing heat production, decreasing assembly weight, etc. The optimization model also gracefully introduces diminishing returns, which are otherwise arbitrarily imposed game balancing restrictions. Offsite (offplanet, in v.3) human engineers, on the other hand, would produce novel designs; revolutionary, rather than evolutionary, changes. The disadvantage being, that buying their time is expensive, and progress is slow.
In whole solar system scenarios, manufacturing might be easier in orbital facilities, which also adds the possibility of space combat, since all factories are susceptible to damage and fully destructible, unlike in v.1/2.
Computer power permitting, v3 may also abandon the conventional percentage based damage system for a more realistic part based model. Since under the v3 construction model, each product is made of many parts, damage modeling could be based on those parts. Getting shot in the leg would reduce (or eliminate, depending on severity) mobility. if the drone can return to a parts warehouse, then the damaged part could be swapped out for a replacement. The same can be done with vehicles, and weapons.
This might be difficult to implement on a practical level. Different drone variants can easily use the same art, but modeling each individual part would require orders of magnitude more effort than can be expected of a amateur production. The damaged drone could be added to an intake hopper and completely dismantled, with its undamaged parts being added to general inventory, while the player takes a new in stock drone.
Battlefield recycling would be critical under this model. A piece of equipment could be damaged beyond use, yet still have many intact, and valuable, components. A drone that had been shot in the radio would be completely nonfunctional, yet intact in every other component.
Recycling of enemy equipment could add another level of complexity. A hypothetical player designing equipment would want to be able to use as much of the enemy's equipment interchangeably with theirs, while allowing their own equipment to be completely incompatible. This was, IIRC, used in the Soviet rail system, where the gauge of the track was slightly wider than its neighbors. This allowed Soviet equipment to run on the rails of its neighbors, while their engines were completely incompatible with theirs.
A part based damage model, coupled with FTL's enhanced focus on realism, breaks a key part of the Battlefield game design. In the Battlefield series, when the player is damaged enough to pass zero health, but not damaged enough to be reduced to a really nasty stain, they fall to the ground, and can be revived by a medic.
But in FTL, damage is sustained to parts not to abstract health points! Which part, precisely, was damaged sufficiently to cause the player to fall to the ground, but not enough to actually kill them?
This had to be handwaved aside in the Battlefield series; but we are not allowed this luxury with FTL.
The revive mechanic can be, ah ha ha, revived by postulating that whatever compact power source that allows practical combat robots is also shock sensitive. When caught in the concussion wave of an explosion, the battery is destroyed, but the remote is left intact. In this model, the medic is more of a combat engineer than anything else, replacing the batteries of downed remotes and returning them to combat. A contested control point would accumulate a litter of damaged batteries, as well as destroyed remotes.