Alexander SquidLord Williams

Mmm, probably worth noting that it'd be a good, if minor, thing for the Scenario Creator to be able to name the sides based on Scenario. (If only because I'm tired of being Blood or Water, when there are so many more creative or informative names, like "Agressor" and "Defender.") Most wargames have had a "Campaign Series" in either the core book or a suppliment that could create a linked set of missions based on a simple set of rules. With the descriptions of scenarios in XML, we can probably go as arbitrarily more complex as we want. As poesel says, we likely need the ability to modify the inventory based on programmatic constraints, both adding, removing, flooring and ceiling-ing-ing-ing (hard word to finish). That is to say, "If RedFor beats BlueFor by 200 points, they should add 20 ion turrets available, maximum 40, minimum 10." Mind you, there are probably a few conditions we can guess up front we might want: </font> Point values: Pretty obvious how they'd work, keying both inven and scenario selection. "If RedFor's points exceed BlueFor's by 500 or more, go to Scenario Deep Push. ElIf Points(RedFor) > Points(BluFor) + 250, goto Scenario Shallow Push. Etc." "If Points(RedFor) > Points(BluFor) + 100, increase inv of Thors for next scenario by 10, minimum 5, max 30."</font>Positions Held: Some scenarios should branch based on whether one force or another held a certain area at the end. This is an outgrowth of the Objective play, checked at the close of play. "If RedFor holds the base, go to Base Defense." "If RedFor controls the factory complex, give them 10 more Thors next scenario." "If RedFor controls the edge of this map, next scenario gives them the west edge as a reinforcement zone." (This is really just a selection of next scenario map, but it'd look like a scrolling map progression if the maps were designed so.) Multiple objective impacts could lead to a lot more variety in gameplay over the same maps.</font>Element survival: Something no scenario currently depends on but could be interesting is whether or not an element or elements survive to the end of the scenario. I don't think there's even the means to track the survival of elements; the implication is they simply won't, given the fluidity of the battlefield. But without survival branches, we can't have scenarios which hinge on whether a convoy makes it across the map or whether the defenders, overwhelmed, can survive with enough forces to be reinforced. "For each 'truck' (unarmed Paladin) RedFor gets to Checkpoint Bravo in the next 20min, they get an extra Thor and five extra 120mm turrets next scenario." "At the end of the scenario, giben this point table per vehicle, each 10 points gives RedFor a 4% faster recharge on their Mercury artillery calls."</font>A lot of this goes into making two areas a bit more flexible: </font> Pre and post scenario time: Time to get longer briefings, time to form up platoons and companies, the ability to review the events of a scenario, if only via chat with more scenario event statistics. To make the scenarios flow better, there'll need to be some pre and post scenario group comm time. Longer scenario briefings might help, too. (I'm not above ripping some format ideas off of Steel Beasts; I'm not too proud.)</font>More complex scenario objectives: We need the ability to describe the things we want in XML, turning it into some kind of perverse DSL. But that's what XML was designed for, building little languages to describe what you need for a given domain.</font>Put all this together with better command and control capabilities and things really just get better all the time.

I'm actually wondering how many elements we can get on the field at once with an "average" system. The demo is cranking out 10 on a side and doing alright. I'm sure the new turrets probably eat a bit more in resources than the old ones, so ... Mainly I'm wondering this because the idea of a Scenario designer actually setting things up with all the elements on the board at once and no dropships or drop pods with reinforcements (drop pods for infy ammo and Galaxies still present) is kind of intriguing. I'm sure that's the kind of scenario Dark_au would find more plausible in many ways, and with solid reason. Of course, what we really need is a slightly better way to run the deployment phase, with no bots assigned vehicles, yet, the ability to group elements into units, and then the ability to pick which elements the players want to drive and which bots get while putting them on the board ... That might be of somewhat more utility than what we have now, with the bots grabbing all the Thors lest micromanaged and having to put together groups and positions on the fly.

Putting this in the context of the vat-nano tech level of DropTeam, at least as far as I can glean from the background as far as I can find ... It makes some sense for personality enneagrams to be imprin ted on LiveShips as the ostensible "crew." We know at the height of Mu Arae technology, they had full bore nano and high-energetics (the Hellbore would require even more energy output than LiveShips seem to use a lot as is). Personality-patterns uploaded from the original colonists are a lot easier to cart around than squishy fleshy folk. Of course, the enneagrams are just computational entities, but there are only so many and they tend to be one-instance programs (probably by design). Burst data updates pulse from the elements on the ground to the main copy back on the LiveShip, keeping them updated, but the copy commanding on the ground doesn't have to be aware of the backups. They just go until they get eliminated, then re-buffer in a new element. Since we know there are some pretty broad-band transmission options to get the data back up to the LiveShip, so that's not much of an issue. It also helps answer part of the "why" of this raiding; its obviously not for farm land or the like, its for a supply of more vat-nano because either the LiveShips don't produce it fast enough or at all. Thus why all the raids on and around Mu Arae sites.

Certainly a reasonable idea given how ... cantankerous they can be when given any scope at all for their commands. Coding up battle damage as a pain-analogue for training purposes is something only a truly sadistic designer ... like me ... would do. "You feel that Montard? That's me shooting your turret! You like that, punk? Huh? Do something about it!"

As an aside, the softest layer is the most likely to crumble and collapse around you as you tunnel in. Probably not where I'd choose to start doing serious blasting or digging. The layer above plus one would be good, though, if its significantly harder.

I think we actually have to start with a more elemental question. Who do we, as players, represent? Are all the elements down on the surface bot driven, and we're remote-operators who stay on the LiveShips directing the forces from relative safety? That would make sense given the extreme difficulty it seems they have with jamming all transmissions on the battlefield. Are we tactical AIs in low-orbit, who manage the combat for the raiders who don't actually leave the LiveShips? If we're actual flesh-and-blood humans who're doing the drops, why do we keep popping back up to tac once we die? Some kind of nano-backup of our personalities that gets uploaded back to the ship? If so, how do we just jump into the cockpit of the bot elements without a pause on the other side of the battlefield? Right now, we totally lack context about what we're actually supposed to be. I think the evidence of play actually weighs against there being real people in the sense we know them piloting these vehicles. I'd more likely believe they're saved personality enneagrams from the Mu Arae era that uploaded to the LiveShips when they were created and along the way. The LiveShips seem to exemplify their own kind of alien, malleable sentience; it certainly fits with the backstory. But, really, we need to know something about who we are beyond Space Vikings to put together plausible scenarios beyond very basic shapes.

And its hard to deploy them turret down. What I need is the ability to say "For this target point, show me all hull or turret down positions for this element," then lock the drop to those bands.

I almost want to suggest the DS come in at an even more insane rate, at least for everything but the terminal drop. Note that this is "insane" in the sense of a longer, flatter trajectory that starts at the altitude it does now. Because DS no longer drop straight down, its harder to predict where they're dropping off, making it even harder to get a mortar round in the right place. If we're going to make it hard, we might as well make it look cooler yet. The obvious problem is that the DS have a tendency to not do well with picking a NoE flight direction ... Deploy into a valley and watch the distance you deviate if it just happens to pick "over the wall" or anything off 40o from the valley direction to come in. This can probably be checked by tossing a cone up and out from the targeted landing zone inverse from the randomly selected entry vector. If it hits something, reselect a random vector and retry the collision. Bounding-box collision is done pretty quickly in DT so that should cull the bad vectors quickly save the worst of worst-cases. Bottom out after ten tries, and it should be quite doable. Doing something like this should let the DS drop in at a much shallower angle from further out, with commensurate speed so drop times stay the same. Looks cooler, the DS stay nap of earth longer and possibly longer behind mountains, and you can land in tighter spaces. Of course, for all I know this is exactly how things are working now, and I'm asking for crazy things.

OK, now that would be fun to drop in some out of the way place if other elements could spot for them indirectly and get a reasonable inbound time ... That's so oogy it makes me quiver in bad places. That'd be just fine with me. HE can pop wheels on the annoying Paladins and damage bits elsewhere when they get lucky. Plus, vibration and disturbing images when they unload! Speaking of turrets, and more concisely, the way they're delivered ... are drop pods just entirely too huge once they land, or is it just me? I can see being a big, bulbous thing as you streak into the atmo, but once it hits, shouldn't it unfold for a lower profile and less screaming, "Hey, I'm a target! There's a squad or a turret near here!" The turret-delivery pods should self-destruct on delivery instead of sliding over to the side, and the squad-delivery pods should fold outwards or in some way get less conspicuous. As is, they beg for shooting, even if you don't know why its there. Its hard enough keeping deployed turrets intact, the last thing I need is two pips jumping up and down excitedly.

Oh, Clay ... Can we get an approximate face / edge / vertex count for the current models in DT? I figured I might as well give it a whirl, at some point, but I don't want to get excessive, over what we have now. (Really, what I want to do is create a set of alternate frames for the present designs that look more techno-organic. Wings3d is disturbingly good at creating organic forms, and its what I know. Now, don't ask me if I'm any good at texturing the things ...)

Could be. The old Plasmas used to unload their bolts pretty far out, so a farm of them, while really vulnerable to arty, made an impressive show of it. The new 76's, not so much, though I'm sure they end up doing more real damage.

Hey, if I can't run in a window, I can't juggle three IM conversations and my Skype voice comm at the same time!

Ah, a ctrl-combo. Figures. Doesn't let you change your facing, though.

And there needs to be a fast way to move the unlocked PoV by clicking on the tac or on the minimap. And a way to rotate view once unlocked if running in a window. And I have a weird bug where, when Observing a bot, it unlocks me from the view after something between 1 and 15sec, every time.

Actually, I wish that targets that appear in an element's visual cone would be called out automatically, or that you could do so manually and there's an increasing chance for every second spotted that a bot'll do so. Probably with a different pip than sensor-recognition. (This hearkens to the way you can spot elements in Battlefield 2, possibly the most under-pursued part of being a useful part of the army there, ever. If only infantry could do this, it'd be fine enough, I s'pose ... An inherent counter to the Hermes on the maps with wide fields of fire for defenders and attackers alike.) But, yes, I'd totally support having more types of turrets available. Absolutely. And Dark's list thereof is a fine starting place. Maybe the ion turrets would actually shoot something before they get popped, unlike my experience with the new 76mms, to date.

The thing I love about this is it lets me pick my turret facing before I land, so I can have some better sense of situational awareness. This makes a huge difference. My only personal feeling is that drop pods come in to land a little slow on the terminal end. They should do some slamming right there at the end. The sounds are absolutely wonderful.

Er, I think that was me. Dropping mines is a lot more responsive now. But, man, it means you run out of mines really, really quickly. Brutal and ugly, those. The number of AA turrets for the defender is way down, too, which means that its harder to defend the area from drops. Now with the faster dropships, that is kind of spicy on the defense.

Mines are a deployable, so they should be drop-podded down now ... I need to go test that. In, like, er, minutes.

I'm looking forward to getting my 6mm ion into a building and annoying everyone in LoS, Clay.

Dropping mines directly on approaching attackers from the defensive command position is something I've actually been practicing, because its quite hard against human attackers. Bots tend to drive straight ahead, so hitting them hard with scatterable mines is a reasonable thing to do. Humans are a lot harder to drop on. Given the increasing prevalence of artillery-deployed mines in modern battle, this isn't a terrible imposition. Add to that the fact that mines are both limited in supply and in their effective radius (and the pairing means that you find a lot of pain just deploying them in places that aren't natural chokepoints ... which is as it should be), and I just don't see "direct mine-drop" to be a terrible thing, even with increased responsiveness from drop-pods. Purely a defensive side move, and Hades knows they need all the help they can get given the current point-allocation rate. Obvious problem with this: Its not much fun for the defenders, once the zone is taken. If you're out of or even just low on dropships in the new system, once the deployment zone is conquered, you've got nothing you can do but call for an end to the battle. That's it. So, really, unless you intend to force endgame strategies through implimenting it, I don't see a lot of use for it. (The only reason I can think of doing such would be if the DZ is set in a scenario such that reinforcements come to and through it faster than dropship, and the DZ-using side has an effectively unlimited but slower ability to call dropships from the LiveShip. In that case, taking the DZ would cut back reinforcement speed as such, without making it impossible to counter defensively. Unless, however, the DZ has an advantageous and sustainable advantage, I don't see much reason to defend it if it could be conquered.) Actually, unless I'm under AAD interdiction, I try to always extract rather than suicide. Keeping the vehicle in the inventory, especially for things like the Herpes, the Cutter, and the Mercury, is absolutely ideal and even for things like Apollo 120's, its useful. Thor 120's, however, are always out before I get around to needing one because the bots are frackin' imbeciles about extracting.

Took a day or so to actually spend time with the relationships. Humans. Not nearly as interesting as blowing things up. Regardless, however, I had something pointed out by my girlfriend as she peered over my shoulder, watching me drop mines and sensor jammer deployment bases around a recently captured AA emplacement. "What are you doing?" "Uh, creating a forward deployment base. I can't exactly just have my team falling down in plain view of the enemy without some defense, right?" "Do you get anything for it?" "Well ... my team thanks me. I help push my folk to victory. You know, like in First Clash on Saturday." "So, no." "No points, as such, no." "That guy just ran into your mines! He blew up! You score that, right?" "Well ... not so much, honey." "This isn't nearly as cool as you playing Battlefield 2." (Where I've recently found myself, with my battle-buddy Eric, gaining top billing on some servers purely from leaving mines at base entrances and using DropTeam / Steel Beasts-derived skills to blow stuff up real good in armour.) So, all that to say this -- yes, I think the girl has a point. Playing a deliberate support role in DropTeam doesn't really get you much "hero recognition" as even the bots get for suicidally dropping Thors into places they are just going to die in. Maintaining rear defenses, building emplacements, even being commander and bot wrangling while calling arty, none of these rather essential things show up on the scoreboard anywhere. In that sense, this is something Clay's previous request about AAD replays would help with. Folks reviewing the bout could then at least see you weren't just sitting around while they were pushing on the enemy bases. I don't think there's an obvious solution for this, save possibly to keep stats for more things. Vehicles damaged / killed by deployables you dropped, taken out by called arty, etc. Basically a bit more "team contribution" architecture. Thoughts?

I'll try to slide on. My shift starts at 9p, Easterm so I free up for a while then if calls are slow. Of course, I can't shoot to save my life, but ...

I find its really hard to deploy ground turrets and to keep them anything like concealed. You'd think they'd be the ultimate exemplars of "hull-down," but no ... they pop like candy in the microwave from anything that wants to reach out and touch them. Maybe Ground Turrets, when dropped from drop pods as they will now, should "dig in" a bit harder, throwing up a ring of crater wall and peeking just slightly over it. This would certainly make them effective from a defensive point of view, but also provides hollows for firing positions for infantry, Shrikes, and maybe Paladins, tucked just so.

We probably need sliders for a wider variety of volumes than just attenuation. Music, Voice, Firing, Impact, Engine, probably covers the gamut. Possibly "Bot" as well, just to seperate "I'm defending!" from the rest of the voice, but not necessarily as low as other things.

The great thing is that improvements to bot wrangling will, by necessity, bring in more ways to communicate things to other players in-game in ways that speech doesn't convey well. A platoon leader, for example, could plot the platoon's movement for everyone to see, so you know what your job in the platoon is coming up. Or the company commander (for lack of a better term, currently) could direct player-led platoons in a more integrated way, with the platoon leader deciding what "Attack Here" means with the voice comm aiding. Really, its all about creating parallel communication opportunities.