This is a ybox2. It makes a pretty lousy alarm clock.

Of course, being a weird kinda guy, I have some weird requirements for an alarm clock.

The first problem is that my uncorrected eyesight is so terrible that I can't read 5 centimeter tall numerals from a distance of thirty centimeters. Once you move out of the nightstand form factor, things start getting Expensive. So I bought a couple of awesomely beefy LED numerals, which sat on my bench, unused, since I didn't have a power supply that could supply enough volts to light them.

Sparkfun makes a wall clock controller, which is great, except that at the time it was expensive, was designed to run DIY 7-segment numerals, and used GPS as a time source, which is inconvenient for an indoor clock.

Today, however, it's a hundred dollars cheaper, would work great with regular LED 7-segment numerals, but now runs on an internal time source, which still isn't ideal because I refuse spend money on yet another clock that I have to manually set, and correct for daylight savings time. I hate daylight savings time, the pointless garbage that it is, and if I have to manually adjust yet another clock for it I'm going to have to start murdering.

As for setting the time, well, I'm just lazy.

Now, clocks for people too lazy to set them is a mature market, well served by clocks that can receive NIST time signals or more expensive ones that can receive GPS time. But the problem here is that both of these are government services. Using these for time-keeping assumes that: the government will fund these for perpetuity, the government will always believe that it is in its best interests for its citizens to have accurate time, and that the government will exist.

Rather than depend on that dubious series of assertions, I would rather provide my own time standard, with the option of using another. Unfortunately for my wallet, these requirements are so narrow and oddly shaped that only NTP fulfills them. NTP is pretty damn lightweight, but it still requires a full PC to run.

Embedded-formfactor computers with real linux support are esoteric, and therefore expensive. But I've got full-size computers all over the place, which only my sense of aesthetics preventing me from using one to run a clock.

There is also the ybox2. It's based around an eight core (!) microprocessor, uses any television with a composite video input as a display, and the default widget is a clock, which suggestively "gets its time from a Navy timeserver". But can a microprocessor run a full implementation of the NTP client?

That's an excellent question, one I answered by purchasing it.

The ybox2, like the ybox before it, is designed around the Parallax Propeller, an 8 cored, 80mhz microprocessor, like a mini-Cell processor. That's the good news. The bad news is that it has a phat 32 kilobytes of ram, making it more of a crippled Cell processor. Parallax makes great hay about the Propeller being a 32-bit processor, which is curious, since 32-bit architectures are mostly used for their ability to easily access larger amounts of ram.

In addition, the ybox2 is designed to fit in an Altoids tin. That's cool, I'm down with the curiously strong mint, except the Propeller and the ethernet driver are both DIP chips, and are thus long and skinny. In order to get everything to fit, the cables attach at either end of the device, a profoundly awkward form factor for a set top box.

The pseudo-NTP alarm clock widget, alarmclock.spin, the reason I bought the ybox2, manages to fit a networking stack, a HTTP client, a HTTP server, the actual clock code, and a twinkly little LED throbber all in 32 kilobytes of ram, a miracle of efficient coding. It also features the most egregiously ugly hack I've ever seen in a piece of commercial software.

You see, alarmclock.spin doesn't use NTP to set its clock. That's disappointing, since that's its reason for existence, but NTP isn't really meant for embedded hardware like the ybox2. Unfortunately, it doesn't implement Simple NTP either, which is meant for embedded hardware like the ybox2. It doesn't implement TIME or DAYTIME, either.

Well just how does it set its clock, then?

Good thing you asked, italics man! You see, first it sends a HTTP 1.0 request to tycho.usno.navy.mil. Not HTTP 1.1, since the ybox2 doesn't implement all of TCP. Well, actually, it sends that request to 199.211.133.239, which is hard-coded in alarmclock.spin, since it doesn't support DNS either.

The file it requests from 199.211.133.239 is /cgi-bin/timer.pl, which alarmclock.spin then screenscrapes for the UTC time, which it applies the time zone offset to.

Wow.

Wow indeed, italics man. Let's list the ways this could break.

1. Tycho could change its IP address.
2. Tycho could stop accepting HTTP 1.0 connections.
3. Tycho could stop accepting connections from clients with ybox2's user agent
4. Tycho could move timer.pl, or delete it entirely.
5. Timer.pl could display its timestamp in such a way that alarmclock.spin couldn't extract it anymore.
6. Someone could execute alarmclock.spin's author for crimes against software engineering, resulting in,
7. The ybox being eradicated from the timestream through retroactive causation.

So, the ybox ain't a NTP clock, and never will be one, without porting NTP to it entirely, which sounds like Work.

The search continues!

(It's set in outer space.)

That is, the game is not bad. The title, Shattered Horizon, is balderdash. A horizon is the line between the sky and the ground. Like a rainbow, it is non-physical, but the result of physical objects. There is no meaningful way a horizon could be "shattered".

Boo. Boooooooo.

They could have invested a modicum of meaning in the title,* since the game takes place in space, and there is no horizon, just like in your mind, man; but they didn't.

*: Speaking of Significant Titles, Rainbows End by world class hard science fiction writing bad ass motherfucker Vernor Vinge. Looks like a typo, isn't! You should buy it, right now, from that link.

Horizon is, of course, made by Futuremark. Erudite, but not au courant, nerds will now be going "Huh".

You see, Futuremark, for the last ten years, has been making a series of 3D graphics benchmark suites, starting with the venerable 3Dmark99. Since this essentially entails building video games that don't have controls, and is inherently hard to make money doing, as there are a limited number of hardware review sites to sell enterprise versions to, the natural next step is to make actual, functioning, games.

If you subscribe to the odious practice of describing video games in terms of "like x, crossed with y", then you would probably go on to call Horizon "like Descent, crossed with TF2". You're a guy with a gun, fighting over control points, in a team of identical guys, but you fly in three dimensions, and don't have voice chat.

That's right, Futuremark's complete lack of experience shows in the many little things they get wrong. There's no voice chat, no voice binds, and no chat history. There are, in fact, two different global chat dialogs, one during the pre-mission briefing which occurs in a unmovable dialog box that covers up part of the briefing screen, and one during the game proper. Hilariously, the in-game chat dialog is a single >, which is all that appears to notify you that the game has stolen input focus, resulting in a lot of lines consisting entirely of "wwwwwwwwwwwwwwwwwwwwwwwwwwwsdasdwadddd".

Futuremark, flaunting their experience with making graphical demos, is really over-fond of fiddly UI bits. Little bitmap greebles, and boy are they annoying. Everything is very fancy looking, and not very usable.

The escape menu, for instance, is presented as a screen on your left wrist, and when you hit escape, your avatar brings it up to look at it, which takes maybe 300 milliseconds. This is mildly annoying, but also improves immersion, so we'll call it a wash.

But most of the time you want to adjust settings, you're already dead, in spectator, and thus have no wrist! When you're spectating, it's a completely different, conventional menu, that pops up instantly.

Contradictory UI elements! Yeah! I fucking love those!

Horizon also has interesting demographics. I was playing Moonrise with three other people, and sucking hard, since I kept stopping every five minutes to take notes. When they weren't mocking my ineptitude, the topic of age came up. The ages of those on the server? 49, 41, 40, and 21. Yeah, I'm a rebel. But definitely not your usual Xbox Live crowd.

Speaking of noise, Horizon almost gets sound in space right. Almost. Explosions are noisy, but they employ the standard dodge that these noises are generated by a situational awareness system, and then lets you shut it off to run silently, and not show up on the IFF system, just like in Mechwarrior 2.

Yes!

When running silently, your HUD is disabled, and all you hear is the beating of your heart. Most notably, you don't hear the clanking of your boots when you're attached to a surface, the sound of the suit's ventilation system, the sound of your Orbital Manovering System jets, or the report of your gun.

...No!

Guys! All these things are bolted to your suit, which, in turn, is surrounded by a perfect insulator. They are going to not only be audible, but positively noisy. I love the subversion of this ancient trope, but you took it too far!

You could make a case for your rifle not being as loud, but there is no plausible explanation for the lack of fan and OMS noise.

The silent running mode also exposes some inconstancy in game design. While in silent running mode, you can, of course, still maneuver, since it would be pretty useless otherwise. This can be handwaved by saying that the OMS system has physical controls, and is not fly-by-wire.

But while the suit is booting up right after respawn, and while incapacitated by an EMP grenade, OMS and Attitude Control Systems are impaired, and function erratically. So which one is it? Are they controlled by computer or not?

Even better, while silent running, your OMS jets don't give off light, as they do when the computer's on. This is probably supposed to make it easier to sneak up on people, but it doesn't make any fucking sense.

Even worse, recoil from the assault rifle doesn't produce an equal and opposite force! Man! That would have been so neat, you guys.

(Seriously, outer space. Rocket ships and everything.)

Horizon also limits player velocity. This is because physics is inconvenient, and I've given up hope on it being depicted realistically in anything but a straight up simulator.

The problem is that any thruster that accelerates quickly enough to not feel annoyingly slow and unresponsive will, thanks to v=at, result in very high velocities, very quickly. This is amusing, but tends to result in players, used to friction, zooming off the playable map, and being killed by the border. Not fun.

The way Horizon implements its speed limit is annoyingly incorrect. You can accelerate up to the speed limit, then coast (correct) but thrusting any more doesn't do anything. (wrong) If you're trying to handwave the speed limit as a safety measure imposed by the suit's computer, then it would shut off the thrusters when the speed limit was reached.

More annoying is the implementation of "sprinting". Like every other FPS in the last decade, you can sprint for a limited time, denoted by your "boost" meter, and like those FPSes, your avatar holds his gun at port arms while sprinting.

Except, he isn't doing anything. It's the suit's OMS system thrusting, there's no reason you couldn't continue to fire.

And, of course, when you run out of "boost", you slow back down to the normal speed limit.

No. Wrong.

It would be possible to handwave the speed limit creatively. Say, you're assaulting the enemy base, and your side's hackers have disabled the defenses, but didn't notice how they tie into the asteroid detection system, so the guns will vaporize anything above a certain speed. When behind cover, you can exceed the speed limit, but moving out of cover will then get you killed.

See? That's how you justify a technical limitation.

Let's take a short break here, and talk about motherfuckers.

The reason for this digression into profanity is that, halfway through through writing this post, I lost internet access. As you may already know, I recently switched ISPs. Worldlink, the new ISP, is actually a common carrier provider. They lease the telephone lines from Verizon, the local baby bell, and resell it to consumers. This is actually win-win, since Verizon gets less of my money, and I get to sign up for DSL service by walking into the Worldlink office and talking to Rick Kunekel, a p. cool guy who doesn't afraid of anyone; even if he does use MSIE, for shame.

The downside of this arrangement is that when there is a problem with the equipment, it has to be communicated to Verizon, through Worldlink. This is... slow.

During the eternity I was without internet access, I was also without access to my collection of PC games. This is because I have, ever so foolishly, placed my trust in Steam. Steam, as it turns out, really wants an internet connection. The "go offline" button is a ruse, designed to entrap the unwary, and in actual fact, does nothing at all.

Valve, I would really have liked to be able to use the hundreds of dollars of software I have bought from you, while I was offline. That would have been so great. It would have been just awesome.

Instead your piece of shit DRM-infested malware informed me that going offline was an operation that required an internet connection.

Wow. That's some great design.

When the problem was finally communicated to Verizon, and the great slumbering beast of its bureaucracy was roused into action, it was determined that line conditions were such that they could not support the speeds that I was using. A curious conclusion, as I had been using those speed for six months now, without complaint. In any event, I was to be moving soon, and any internet access is better than no internet access.

He said, confidently, before he actually used the slowed internet connection in question. Slowed, from 8/768, to 2/128. 128 kilobits per second! Yeah! It's 2002, all over again!

What was I talking about? Oh yes, dem vidya gaems.

Horizon has regenerating health, like all my favorite games. This is.... reasonable, considering the setting, but I wish there had been more done with the damage model. There is positional damage, with faceplace and tank hits being instant kills, but no progressive impairment, (get shot in a RCS cluster, and you can no longer turn right) which is unfortunate.

Another thing made conspicuous by its absence is a laser rifle.

Space is pretty much the only environment where laser weapons make sense, thanks to our accursed atmosphere, with some exceptions. The rifle can zoom in, but makes an utterly shitty sniper rifle, thanks to plenty of scope wobble, and recoil that's modeled as a permanent deflection from the aimpoint, rather than a transient one. They probably had a reason for doing it this way, rather than the standard sighting model, and boy, it better have been a good one.

A laser rifle would have unlimited range and hit instantly, but would cycle slowly, and be vulnerable to heat buildup. (Plus, frikken laser beams! Pew pew!)

Heat management would be another easy addition. Getting rid of waste heat in space is a big engineering problem, as any foole with a thermos knoe, a vacuum is a lousy conductor of heat. You do a lot of things that should produce a lot of heat in Horizon, such as conducting OMS burns, firing weapons, and floating around in direct sunlight.

A neat design tradeoff here would be to reduce cooldown while illuminated by the sun, and increase it when you're standing on a solid surface. (Radiators in the soles of the boots, being held in direct contact with the surface by the "align to surface" magnets, could dump a lot of heat via conduction) Silent running mode, would, of course, shut off the cooling system entirely, dramatically limiting how long you could stay silent, depending on how much heat you generate.

Wait a minute, here. Positional damage? Lasers? Heat management? This sounds like another Mechwarrior game.

Really? Gee, that's funny.

They also neglected to include suit leaks, mystifyingly. The whistle of a slow leak in your space suit, while you're trapped outside in the vacuum of space, is one of the most evocative situations in science fiction, and they didn't put it in their astronaut shooter. Man!

There is a general lack of connection to the suit. You can't hear its ventilation system, you fly through dust clouds without getting the faceplate dusty, there's no glare through the helmet, etc.

Horizon should feel like hairless monkeys piloting millions of dollars worth of fragile shell from rock to rock, and dying horribly when that shell is damaged in even the slightest way.

Instead, it's got the soul of a very generic FPS, set in an extraordinary location.

And that's terrible.

But it is not horrible. Horizon is a very good first step, rough and unpolished, but hinting at the overly stretched metaphorical staircase to come. The purely hypothetical sequel will be awesome, (Think of the possibilities. More than one gun! More maps! Classes! Vehicles! Deployables!) but as it stands now, Horizons is merely very good.

SPAWN CAMPING FOR FUN AND PROFIT

But bbot! Isn't spawn camping utterly reprehensible, the domain of poltroons and mountebanks, exclusively the work of grinning thugs from an overwhelmingly superior team, who lack the common decency to switch to the other side?

Well, for one, I think you're not using "mountebank" correctly. And for two, you're completely right! With even teams, spawncamping is typically a losing strategy.

The enemy spawn is a hostile desert to a member of the opposing team. Enemies spawn in groups and are always at full health, and when injured, can easily duck back into the spawn and thus to a resupply cabinet. In addition, there are never any objectives nearby, and the terrain is very rarely advantageous to the attacker, with the spawn room at the end of a blind corridor or its topological equivalent.

Thus, the only reason you would want to hang around there for any length of time is to destroy the teleporter entrances, then run away from the inevitable flood of hostiles who were planning on using that teleporter.

The teleport run is fairly risky, since it requires getting to the enemy spawn undetected, as it takes several seconds to destroy the entrance, which is enough time for a pursuing hostile to kill you. Which is why it is usually undertaken by a spy or a scout, or somewhat more unusually, a pyro.

(An edge condition of the spawn camp is the setup room uber pyro rush. On dustbowl, the setup gates on stages 2 and 3 are not protected by player clipping brushes, which means enemy players can walk right in. This is normally a bad idea, since the interstice is full of angry people, but handily for us, the medic can make people invulnerable. Usually done concurrently with a heavy uber, with the heavy acting as the anvil to the pyro's hammer. This strategy will typically take out everyone who isn't ubered or cowering in the spawn room, and, if the pyro is both using the backburner, and very, very lucky, can kill one or more of blu's ubercharged medics.)

So, under standard conditions, spawn camping is either impossible or extremely unproductive. But what you can do is pepper hostiles with fire as they exit the spawn room, then run away, with hordes of very slightly injured hostiles in pursuit, typically while giggling. This is called Spawn Heckling, a subset of Wasting The Enemy's Time, a grand old tradition; and will usually result in your swift death.

But not always.

Team Fortress 2, broadly, seeks to concentrate combat into fronts. This has a number of advantages. People new to the game don't have to know what the objectives are, because they can just head to where all the people are shooting each other, where they will not be terribly effective, but not actively useless.

Concentrated front gameplay is also more fun, because you spend more time shooting people, and less time trying to get to a place where you can shoot people.

To further this end, TF2 uses two tricks, variable respawn delay, and forward spawn rooms.

Variable respawn delays act twofold, by spawning people in groups, who tend to stick together, and by dynamically adjusting the effectiveness of a team, by making a winning team more effective, and a losing team less so, with "winning" being defined as how many control points are held. This seems, generously, unsporting, but you must realize what when one team loses, the other team wins. When both teams wrestle over a single point for half an hour, alternately losing and gaining it, and eventually ending the match in a stalemate, both teams fail.

To present an even more enormous advantage to the attacking team, most control point maps have dynamic respawn rooms. The more points a team has, the farther forward they spawn.

This is because, in a platonic standard "respawn room at each end", the farther forward team A pushes, the longer it takes for team A to get to the front lines, and the easier it is for team B to defend, perfect for inspiring unbreakable stalemates, and precisely the opposite of what we want.

To counteract this, the winning team's respawn rooms move forward, which evens the playing field, though it may not seem like it in-game, since the winning team is usually stomping the losing team at this point.

The effect is much more pronounced in maps without dynamic spawn rooms, such as cp_toy_fort. Toy fort is a rats-style map, where the players are "tiny", compared to map geometry. Rats is, of course, a venerable HL1 DM map where the players were the size of rats, set in a kitchen, complete with mouse holes a mousetrap that would gib you if you stood on the trigger.

In toy fort every match every game is a long brutal grind, with the center point changing hands several dozen times, until finally one of the teams ends up with enough skilled players to fool the auto balancer into thinking that the teams are even, and thus to victory.

That never happens.

But dynamic respawn rooms, wonderful as they are, have a weakness. They're dynamic.

They're typically embedded in map geometry, which means that there is terrain and health kits for the enterprising Bastard to exploit.

Spawn heckling a forward spawn allows you to retreat into the hills when pursued, to heal up, and to show up again thirty seconds to shout some more insults at their backs.

Spawn heckling can be performed with limited success on any map with dynamic respawn rooms, but shines on payload maps, where the bomb path is long, convoluted, and sees a lot of combat, which means plenty of supplies.

Where spawn heckling comes into its true enemy annoying glory is on pl_badwater. The blu forward spawn is right next to the second point, and is close to no less than six ammo packs and seven health packs, making a sufficiently sneaky spawn heckler immortal.

Like the teleport run, spawn heckling calls for extreme mobility. Since spawn heckling requires peppering enemies at long range, the Pyro is out, (though using the flare gun may be profitable) leaving the Scout and the Spy.

While the force-of-nature in the hands of a talented scout is preternaturally annoying, the Spy is my class of choice for spawn heckling. The Spy is the second greatest threat on the battlefield, behind a ubercharged heavy, and attracts instant attention from any nearby enemy. A spawn heckling spy poses very little risk to any single player,[*] but logic does not so easily override instinct. The electrosapper can destroy teleporters with little risk to the heckler, and the ambassador scores critical hits on headshots, which take very little skill to achieve on players leaving the spawn room.

*: It is rather difficult to backstab a player aware of you, and while it is quite easy to score a single headshot with the ambassador, it is not quite as easy to score a fatal followup headshot if the target is trying at all not to be shot.

The point of spawn heckling is to waste the enemy's time, which typically means not killing them. This is because combat is fairly risky, when returning to your position after respawning takes half a minute of infiltration, which, depending on how lucky you are, may even take several tries. So, the name of the game is long range ambassador shots and cloaking, hit and run, with emphasis on run.

Don't forget to make fun of the other team in allchat.

So go forth, you bastards. Go forth and heckle.

Hello, d20 readers. You may be interested in my review of Trackmania Nations Forever (Spoilers: I wasn't fond of it) or my efforts in map design, or a longer series on water simulation

Or, if you're looking for something a bit odder, a transcript of a a youtube video.]]> http://bbot.org/blog/archives/2008/07/07/fall_to_life_take_two/index.html http://bbot.org/blog/archives/2008/07/07/fall_to_life_take_two/index.html 2008-07-07T05:22:07-05:00 bbot Meta, Game Design ftl2.html updated. You might have not read it before, so it's reprinted below.

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.

Fall To Life take 2, version 1

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 AI was cheap and and sophisticated enough to be indistinguishable from human, but was significantly worse than human at pattern recognition, which is critically important in combat. Thus, human observers were enlisted to provide human skill without actually risking a human.

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.

Fall To Life take 2, version 2.

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.

Fall To Life, version 3.

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.

It seems that to appeal to North America you need really flashy, bright games, and you can see that every eastern European game is very dark. In the end, I guess this just comes down to our culture and history - we're just different people, and that's that.

You know, I'm really skeptical that they had the AI as active as they claim. The final game seems to rely very heavily on set-path and set-location respawns in order to keep the world feel like things are going on. Surely they could have left just a few "ALifers" on to purposefully wander around and stir things up. Right now, after memorizing what the layouts of the zones are, I can easily avoid all conflict because no NPCs will ever stray from their paths.