Creeper World 3 Suggestions Initiative

[Shrike30]

Also inspired by the Bertha video, and some of the concepts involving firebases, resource drain and networking that are starting to crop up in my head.

Toggleable relays
In a larger map, the number of units involved could become staggering.  A rear artillery firebase might have a dozen or more Berthas in it, with the associated impressive energy drain if they should choose to fire for effect.  It might be desirable to be able to Activate and Deactivate relays, such that a portion of the network could be isolated from the rest of the network temporarily, without requiring the destruction/rebuilding of the connections between the two networks.  This would allow a rear firebase to contribute its energy production to the frontline construction when not firing, but also allow it to be isolated from the frontline network (and therefore not placing a drain on it) when that firebase IS firing.

Limited relays
Similar to the toggleable relay but requiring less micromanagement once established, a relay connection could be limited with regards to some or all of the packets/energy/ore/AC ("materiel") that passes along it.  This would allow for a similar network arrangement to the one above, where the rear firebase is able to contribute "excess" materiel to the frontline base, but cannot draw from the frontline network when it needs more than it can provide locally.  This can currently be done with guppies, but would feel very kludgy as it could involve more than a half-dozen guppies set to fly very short distances if both networks have ore/AC being handled on them, and removing the supply "lag" of that flight could conceivably involve dozens of guppies.

This could be done by clicking on a relay, clicking a "make limited connection to..." button, and then clicking on the other relay involved (or, if that's a coding problem, allowing the placement of a new relay that becomes the other half of this pair).  Each relay in this pair, when clicked on, would then have toggleable radio boxes which define what kind of materiel they will pass to the other relay in the pair, defaulted to "on" for all types of materiel.  

Dedicated relays
This is a type of relay that will only "pick up" connections to the next dedicated relay in the chain.  This would allow commanders to establish isolated networks that cross over/through the same geography, without having to use guppies to do so.  Similar to my suggested implementation of Limited Relays, this would be done by clicking on a relay, clicking "Build dedicated relay" and then clicking where you want the next relay in the chain constructed.  This new relay would only make a connection to it's parent relay, and any "child" relays of its own.  Ideally, this would also automatically select that new relay and allow (even if it's not built yet) for the selection/placement of the NEXT dedicated relay in that chain, to make long chains of dedicated relays easy to build.  Clicking "Build nondedicated relay" from a dedicated relay would make the next "child" Relay make connections as normal, thus ending the chain.

Reconfigurable storage units
In the same way that Guppies can be switched to carry different materiel, allow Storage to be switched over to storing different materiel.  This could allow a firebase to store its ammunition packets/AC locally without putting a demand on the larger network for resupply, should the commander choose to temporarily isolate it from his network, and could smooth out demand-over-time by refilling all of the local Berthas/Bombers quickly, leaving the larger network only a few storage units to refill rather than the many weapons systems.  This would also create a more elegant means of providing a remote base with a larger "buffer" of supplies for times of peak usage than running dozens of guppies to it.  While a similar effect can be produced by dropping a command node in that firebase, there will be times when that is not desirable or you've got all of your command nodes busy elsewhere, and would let the game scale to larger maps without having to allow for the deployment of more than three command nodes.  Weapons would preferentially draw from local storage units before requesting packets from the command node.

Transformers
Transformers would be structures with an AOE that draw Energy from a network and produce packets specifically for reloading weapons/shields within that AOE.  Transformers would NOT provide packets for construction.  Weapons would preferentially draw from the transformer before requesting packets from the command node.  These would primarily come into play on larger maps where a commander has already deployed all of his command nodes and the distance from the command node is becoming a major problem for maintaining pressure at the frontline (those instances where a weapon runs its magazine dry before the replacement packets for the FIRST shot arrive, and the weapon only fires in bursts because it won't continue to request packets once the replacement packet for it's LAST shot has been sent).  The current means of preventing this involves either having several guppies leapfrogging packets from the rear to the front to provide a forward "capacitor" for packets, or relocating the command node further forwards (something you might not want to do, or which might not even be intended to be possible in CW3).

[Chawe800]

Anti Creeper Torpedo Station

Spoiler

Oh yeah, this baby launches a anti creeper torpedo at the front lines of your defense against the creeper. This has a fairly short range. But it can be really powerful. I just feel their isn't enough anti-creep weapons.

[close]

[Mr.H]

Also inspired by the Bertha video, and some of the concepts involving firebases, resource drain and networking that are starting to crop up in my head.

Toggleable relays
In a larger map, the number of units involved could become staggering.  A rear artillery firebase might have a dozen or more Berthas in it, with the associated impressive energy drain if they should choose to fire for effect.  It might be desirable to be able to Activate and Deactivate relays, such that a portion of the network could be isolated from the rest of the network temporarily, without requiring the destruction/rebuilding of the connections between the two networks.  This would allow a rear firebase to contribute its energy production to the frontline construction when not firing, but also allow it to be isolated from the frontline network (and therefore not placing a drain on it) when that firebase IS firing.

Limited relays
Similar to the toggleable relay but requiring less micromanagement once established, a relay connection could be limited with regards to some or all of the packets/energy/ore/AC ("materiel") that passes along it.  This would allow for a similar network arrangement to the one above, where the rear firebase is able to contribute "excess" materiel to the frontline base, but cannot draw from the frontline network when it needs more than it can provide locally.  This can currently be done with guppies, but would feel very kludgy as it could involve more than a half-dozen guppies set to fly very short distances if both networks have ore/AC being handled on them, and removing the supply "lag" of that flight could conceivably involve dozens of guppies.

This could be done by clicking on a relay, clicking a "make limited connection to..." button, and then clicking on the other relay involved (or, if that's a coding problem, allowing the placement of a new relay that becomes the other half of this pair).  Each relay in this pair, when clicked on, would then have toggleable radio boxes which define what kind of materiel they will pass to the other relay in the pair, defaulted to "on" for all types of materiel.  

Dedicated relays
This is a type of relay that will only "pick up" connections to the next dedicated relay in the chain.  This would allow commanders to establish isolated networks that cross over/through the same geography, without having to use guppies to do so.  Similar to my suggested implementation of Limited Relays, this would be done by clicking on a relay, clicking "Build dedicated relay" and then clicking where you want the next relay in the chain constructed.  This new relay would only make a connection to it's parent relay, and any "child" relays of its own.  Ideally, this would also automatically select that new relay and allow (even if it's not built yet) for the selection/placement of the NEXT dedicated relay in that chain, to make long chains of dedicated relays easy to build.  Clicking "Build nondedicated relay" from a dedicated relay would make the next "child" Relay make connections as normal, thus ending the chain.

Reconfigurable storage units
In the same way that Guppies can be switched to carry different materiel, allow Storage to be switched over to storing different materiel.  This could allow a firebase to store its ammunition packets/AC locally without putting a demand on the larger network for resupply, should the commander choose to temporarily isolate it from his network, and could smooth out demand-over-time by refilling all of the local Berthas/Bombers quickly, leaving the larger network only a few storage units to refill rather than the many weapons systems.  This would also create a more elegant means of providing a remote base with a larger "buffer" of supplies for times of peak usage than running dozens of guppies to it.  While a similar effect can be produced by dropping a command node in that firebase, there will be times when that is not desirable or you've got all of your command nodes busy elsewhere, and would let the game scale to larger maps without having to allow for the deployment of more than three command nodes.  Weapons would preferentially draw from local storage units before requesting packets from the command node.

Transformers
Transformers would be structures with an AOE that draw Energy from a network and produce packets specifically for reloading weapons/shields within that AOE.  Transformers would NOT provide packets for construction.  Weapons would preferentially draw from the transformer before requesting packets from the command node.  These would primarily come into play on larger maps where a commander has already deployed all of his command nodes and the distance from the command node is becoming a major problem for maintaining pressure at the frontline (those instances where a weapon runs its magazine dry before the replacement packets for the FIRST shot arrive, and the weapon only fires in bursts because it won't continue to request packets once the replacement packet for it's LAST shot has been sent).  The current means of preventing this involves either having several guppies leapfrogging packets from the rear to the front to provide a forward "capacitor" for packets, or relocating the command node further forwards (something you might not want to do, or which might not even be intended to be possible in CW3).

Woah, that's a lot of good economy suggestions. I've added them all as well as chaw800's Torpedo idea and the salvo fire for Berthas.

[4xC]

What's also interesting is that recent forum posters and members seem to have more elaborate, detailed, and inspired ideas than a lot of the veterans here. Then again, I hear creativity is so rare in organized competitions, it's almost a factual relief to find it in places like here.

[Mr.H]

Anyone up for map making suggestions?

Hot-keys
Self explanatory, however they should be short and closer together.

Advanced Simulation
Type in a custom time frame, choose the rate of simulation, pause, undo, rewind, fast-forward, multi-colouring for better clarification(the field in CW2 got confusing), have fancy numbers to give you the speed of movement(effected by wind remember?) and densities. Better simulation= more refined maps.

Quick-Test
Hate having to open the game, find your map, then test it only to find you made the simplest of mistakes? Well no more, with quick-test you can easily load your map in sandbox mode allowing you to play it as a real-game but be able to edit it as you play! Very handy for any map maker, making the process more effecient and more refined = more epic maps for players to explore.

Hero Units
The ability to place 'special' units, with a custom name tag and possibly slight variations in colours would be very appealing indeed. These units could require safeguarding since they can be tagged as 'Mission Essential' I.e. If they die you lose, however modifications to the unit statistics can be made(to an extent) e.g. a slightly higher fire rate, or a heavier punch. Also availible is the ability for characters to be 'embedded' in the unit from the storyline, these units can say things when you select them and can be essential for certain 'trigger regions' to move forth in your endeavours.

[Lord_Farin]

Nice suggestions Mr H.! Only thing that I expect will be impossible is to "Rewind" because it requires remembering all previous game states, a very memory expensive operation.

[lurkily]

Toggleable relays
Limited relays
Dedicated relays

Very micro-intensive.  I think I'd prefer to just make it possible to disable relays,(Which solves the toggle problem instantly,) and rely on the player building only what energy drain he's willing to support.  After all, why would you build ten berthas if you're only willing to permit the energy drain of nine?  I realize supply and demand fluctuate, but it seems to me that it's just as easy to be sabotaged by a mishandling of limited relays, as it is to be sabotaged by a mishandling of your own energy demands.

It doesn't really introduce more capabilities, it's only an alternate way of managing them, and to me it's a very confusing method of doing so, compared to just disabling a few units.  I wouldn't want new players focusing on relay limits as the main means of handling their power consumption when it's really only supplemental to a simpler solution.

I'm not sure I understand dedicated relays.  It sounds like basically a single chain of relays that forbids any packet not following the chain from using that relay.  Why is this desired?

EDIT: Had to step away.  I wanted to comment on Transformers and storage, too.  I would like to be able to establish local storages of all types, though guppies would jury-rig into this very effectively if they were able to auto-dispatch with incomplete cargoes.

I don't like transformers because I don't think CN's should be absolutely critical all the way from alpha to omega.  Right now, the one thing that is critical, uniquely done by CN's, and in my opinion, sacrosanct, is the barrier between pure energy and packets - only CN's provide the means to cross that barrier.

Advanced Simulation
Quick-Test

I'd rather just have the editor in-game, with the in-game creeper sim operating as you edit.

[Mr.H]

I do think three types of relays gets confusing, but disabling it doesn't solve everything either. I'd go for limited relays if I were to choose one, opens quite a few possibilities for networking.

In-game editor, that sounds fancy :) ! Although the advanced simulation features would still be useful in that case, since playing normally doesn't reveal all the minute details of a map in one clear sweep as a map maker would want it to be.

Mad mag madea  few maps, so I'm guessing we already have an editor. Any hints/clues on it's features Madmag?

[lurkily]

I do think three types of relays gets confusing, but disabling it doesn't solve everything either. I'd go for limited relays if I were to choose one, opens quite a few possibilities for networking.

It provides a toggle relay instantly.

Honestly, I think limited relays could be useful, but it creates more opportunities to mismanage when things get hectic.  I don't want newbies thinking that's the primary way they should be dealing with energy demand, either.  It makes the management landscape much more complex for a newbie, and I'm worried that'd be a turn-off for a casual player.

Right now, you have the chance of maybe using too much energy, and the solution is disabling some units.  The risk is forgetting to re-enable them.  To me, that seems like a comprehensive and simple solution that'll be clear to all players, even if it doesn't have the wealth of detail that make up some more hardcore RTS games.

[Shrike30]

I'll hit Limited relays in their own post, because they're a bit more complicated.

Toggleable relays: I didn't intend for a toggleable relay to be a special kind of relay, just for the Disable/Enable functionality on the existing Relay to disable/enable passing resources across it.  I think we're on the same page on this one.

Dedicated relays: It currently appears to be possible to have more than one network/economy running at the same time (unconnected command nodes with their own energy networks appear to be completely independent of each other).  Normally, placing the "bones" of a network (collectors/relays) next to the bones of another network causes them to merge into one network and normally, this is desirable, but I can imagine that a commander might want to keep his networks separate despite their connections running adjacent to each other.  Dedicated relays would make this possible.  I only really see them coming into play in niche situations, but it seemed like an interesting and different piece of functionality to add to a pretty core tool.

Configurable storage/transformers: In my mind, these both will primarily serve to solve the same problem, namely that weapons systems located far enough forwards from your Command Node can only shoot in bursts, due to the delay between when their magazine runs dry, and the first packet arrives from the command node.  Since the weapon won't request more packets once it's entire magazine's worth of packets are en route, some method of providing a source of packets closer to the weapon system than the Command Node is desirable.  As a Storage node supplying nearby cannon has a significantly larger magazine to resupply (and therefore will be continuously requesting packets from the Command Node) it'll smooth out the interruptions in weapons fire that distance from the Command Node would normally cause.  The Transformer is a (less desirable, to me) means of providing the same functionality (continuous forward ammo resupply), and so in the event that we get configurable storage, would be completely unnecessary.  It's worth noting that the Guppy can be turned into a sort of configurable storage already: 2-3 guppies flying packets forwards to a remote-but-still-connected base will provide a more continuous stream of ammunition packets than the land-line alone, but this has the feel of a strange workaround for a missing piece of gear.

[4xC]

Honestly, I don't see a point in altering our current relays. They have packets travel down them if they get to their destinations faster that way and allow all packet types to go down them. As for the energy/packet situation, Base hearts have always managed the conversion between the two and his looks evolved enough already what with the packet AND energy guppies for one thing.

I would also know better about these things if the info regarding them in the past few posts were a lot more concise because all I see is paragraphs of details that make it hard to distinguish the abilities, tips, and benefits from each other.

[Shrike30]

Limited relays:

I'm sure this is a scenario that commanders encounter, as I've hit it myself many times.  You've got your "backfield" of energy generators established, your "frontlines" are filled with weapons keeping the creeper at bay, and it's time to expand and go on the offensive.  This can require careful management, though, as you may only have a few points of energy per second to spare.  There's a few ways of doing this:

The "Classic" method: CW1/CW2 style, building 1-2 structures at a time, or pushing one front at a time.  The sheer energy drain you'd encounter if you were to push forwards, build more reactors, AND set up a few Berthas simultaneously would crash your energy economy, letting the creeper overrun your frontline and destroy your base, and so commanders are forced to micromanage their construction effort, placing one structure every few seconds for the next forseeable chunk of time to avoid a burst of demand.  This is a lot of annoying clicking and watching energy bars, IMO.

The "Split Network" method: CW3 already appears to have this option, since it appears that unlinked networks with their own Command Nodes are capable of autonomous actions.  Drop a Command Node near the frontline, drop a few reactors near it to support your frontline structures power needs, and then sever the connection to the original Command Node and the energy sources hooked up to it.  Your Frontline network is going to be primarily providing power to weapons and shields, and the energy demand for these systems is fairly predictable.  In the meantime, your Backfield network has little or no continuous demand on it as the nearby Creeper has already been controlled, and so you can safely build, say, 12 Berthas at the same time, go back to monitoring your Frontline network, and check back in every once in a while to see if your Backfield has gotten out of energy debt and finished its construction.  There's significantly less micromanagement involved in this approach, but it has the problem of surplus energy going to waste across two networks, not just one.

A Limited relay joining these two networks, permitting the flow of excess energy/packets from your Backfield to your Frontline but NOT in the other direction gives the advantages of a Split Network without letting all that surplus in the Backfield go to waste.  When that battery of Berthas is firing, your Backfield network will rapidly exhaust its packet supply; once they've stopped firing, the Berthas will reload and the Storage on that network will fill back up, and then once those are all full the Backfield will start putting it's surplus into the Frontline rather than simply letting it go to waste.  It's easier to manage than the Classic approach and more efficient without micromanagement than the Split Network approach.

[Shrike30]

I would also know better about these things if the info regarding them in the past few posts were a lot more concise because all I see is paragraphs of details that make it hard to distinguish the abilities, tips, and benefits from each other.

My bad, I tend to get a little wordy.  How's this?

Adding Disable/Enable functionality to Relays will let you toggle parts of your network on and off at a single location, rather than having to select every single structure downstream of that Relay and Disable them.

Adding the option to build Limited Relays will allow commanders to pick and choose how resources are shared between two otherwise discreet networks, using a landline rather than guppies.

Adding Dedicated Relays will allow commanders to keep two discreet networks separate from each other despite passing through the same locations, should they wish to do so, without strange workarounds involving guppies.

Allowing Storage to be set to store Packets would let Storage units serve as local "batteries" for weapons and shields, allowing for a more consistent supply of packets in remote locations, without strange workarounds involving guppies.

Adding Transformers to produce Packets for Weapons would also provide a local source of packets for weapons and shields located far away from a command node without strange workarounds involving guppies, but I find the idea less attractive than Storage as it makes command nodes less cool.

[lurkily]

Toggleable relays:

Yeah, we're probably thinking the same way here.

Dedicated relays:

I can see only really rare edge cases where I can see witholding resources on a network that has them, from going to a network that needs them, as desirable.

Configurable storage/transformers: In my mind, these both will primarily serve to solve the same problem, namely that weapons systems located far enough forwards from your Command Node can only shoot in bursts, due to the delay between when their magazine runs dry, and the first packet arrives from the command node.

You want forward storage that will actually redispatch the packets from that source, then.  With the potential amount of storage on a very large map, I can't imagine that many packet dispatchers and destinations are a great idea.  I know that memory access speed was the main limitation on CW1 and 2 on not having more packet sources in CW1/2, and though memory access is much faster, I imagine it's still a point of burden.

However, assuming that by release, we can get guppies to automatically launch with a partial load, there's a solution in existing units.  Put a guppy on the front lines, and put its destination right next to the pad.  Any supply will pour as fast as it can possibly be requested into the pad.  That pad on the front will provide close-dispatch to the units there, and the transport time will be virtually nil.  If it's not requesting fast enough to supply front-line units, place two guppies.  Then your front-line dispatch pads will request twice as many packets in the same time.  As a bonus, packet guppies request packets much faster than other units.

[Shrike30]

Yeah, the guppies would do the same job, it just feels like a workaround.  And I can't imagine the memory usage for multiple guppy pads requesting packets/sending out packets/flying back and forth would be less than the memory usage of a Storage unit requesting packets/sending out packets (doing exactly the same thing, basically, minus flights).  Maybe port over the idea from Transformers of having an Area Of Effect around the Storage unit configured for packets (maybe roughly the size of a Mortar's range), so that weapons won't be searching the entire map for Storage pods to drain?