[Campaign] Main map vs away mission ideas

[Emdek]

I would like to discuss some ideas related to how currently the concept of main map and away mission is implemented.
1. Let script decide what is allowed to build on away missions.
I've not heard that someone is working on that but I find it possibly useful thing for mods. For example someone could decide to create some extremely long / difficult away mission, with map that includes own power sources etc. So player could be allowed to built some certain structures other than defenses, like power generator and factories (it would be also useful to have some kind of unit able to transport, so it wouldn't be required to use hacks like producing very expensive units to transfer power back to main base). Also there is currently an issue when Command Relay Center is available to be built on one of away missions (that one where we recover its artifact)...
2. Allow to all environment of main base function properly after going to away mission
Unless something changed recently (I've not tested campaign since possibility to save at mission end was removed) behavior of main base environment changes after leaving it. For example build queues for trucks are stopped (and AFAIK also erased, so they won't resume when we return), units produced by factories doesn't move properly (so we usually end up with more than one unit on one tile) etc. That shouldn't happen, it all shall function as if we were at main base. That way is maybe more expensive for CPU but at least fully logical.
3. Allow to switch between main base and away mission at will
This would be pretty big change (that is, would give much more opportunities) that would allow some other changes. It's extension to previous suggestion, instead of just relying on order queues it would allow player to actively manage main base, for example prepare it for expected invasions or let to effectively recycle just specified units when they become obsolete (like after we recover and research some important artifact) without need for one additional transport cycle.
4. Make transporting of units fully manual
This is one of most annoying simplifications in campaign, which also leads to some issues due to automatic placement (like more than one unit on one tile or units sporadically ending up on unaccessible cliffs - which ironically can be fixed only using mechanism that caused it, simply load it from next away mission...). Also the way it currently works makes it far harder to keep organized groups of units on main map since you don't know which unit will get loaded. Not to mention that this is totally illogical, especially that first batch is always loaded manually anyway.
This one is pretty big conceptual change (although not really changing the game play) which solves some issues, but there are some new possible ones, like returning units to main base, because due to the way how WZ works (and if power would be shared or there would be a way to transfer at least some part of it to main base) some users would like to simply recycle them and rebuild at main base (if we would allow to build factories on away missions then they could use it to bypass transport limitations by recycling them at main base an remanufacturing at away mission). To fix that issue and already existing ones (like bypassing limits in gamma missions, when some of your units get stranded away for some time but you can simply recycle them before mission ends...) there should be some limitation added, like to disallow recycling units on away mission at all (seems most fair and logical to me), to not refund full value or to decrease their experience (both only for away missions).

[aubergine]

1. It's possible to do that with JS API, but currently it would apply the limits at player-level not, uhm, "level-level" (would likely need tweaks to loadLevel() function). In other words, the limits get applied to the main map as well as the away map.

2. That sounds difficult - it would basically require both maps to be active at the same time, along with any AIs or other scripts running which could cause performance or memory issues.

3. Love this idea!

4. From vague memory of the campaign, you get to choose which units are loaded on to the transport, although you can't see any details about them other than what sort of unit they are. There's no way to see where the units are, what group they are in, what their health is, etc. Your idea #3 would solve that issue somewhat.

In my own dabblings with transporters they are currently very difficult to work with from a scripting perspective. I'm confused, to put it mildly, as to how they are brought on to a map and moved off a map, etc. There is currently no way to determine how many units are on them, or how much capacity they have left, etc.

It could change the gameplay in that on some away missions you are so busy doing other stuff on the away map that jumping back to the main map could be a major distraction.

IMHO, on an away mission, unless you plan to build a base and set up a permanent residence in the area, all units should be sent back to main base after mission ends, particularly on things like intercept or rescue missions.

Maybe having really big maps, with the ability to enable multiple areas (rather than just a solid rectangle) of the map would deal with many of these issues. Indeed, most away missions aren't that far away from where you start, they are in the general area. Currently separate maps are required for a number of reasons:

* overcome space limitations on the current max 250x250 map size
* apply different scripts to new enemy bases
* apply specific mission objectives (currently done at map level)
* deal with different terrains (if applicable)

With really big maps, certain areas of the map could be designed for actual use, with other areas just wasteland between the tactical theaters. Thus, you would actually see your transport fly all the way from your base to the other location on the map. Difficulty here would be ensuring there are enough directions for a transport to fly for it to avoid flying over currently-disabled areas of the main theater.

[Emdek]

1. It's possible to do that with JS API, but currently it would apply the limits at player-level not, uhm, "level-level" (would likely need tweaks to loadLevel() function). In other words, the limits get applied to the main map as well as the away map.

So it is partially possible.
We would need cleaner way.

2. That sounds difficult - it would basically require both maps to be active at the same time, along with any AIs or other scripts running which could cause performance or memory issues.

Surely it would require more CPU and memory usage, but it's worth that.
Also the biggest overhead is rendering, and we only need to render one environment.
In case if we would have better optimized engine, which would allow for full abstraction of logic and rendering (also required for dedicated servers) then it wouldn't be noticeable (even on Pentium 4 grade hardware, like mine ).
And it's of course requirement for next ideas.

4. From vague memory of the campaign, you get to choose which units are loaded on to the transport, although you can't see any details about them other than what sort of unit they are. There's no way to see where the units are, what group they are in, what their health is, etc. Your idea #3 would solve that issue somewhat.

Yes, you can choose, but if many of them has the same configuration (propulsion, weapon, experience) then you cannot distinguish them in that "load transport" screen. And idea 3 is not enough, unless for example selecting units on main map would somehow mark them in that screen (which would be illogical and hacky anyway).

In my own dabblings with transporters they are currently very difficult to work with from a scripting perspective. I'm confused, to put it mildly, as to how they are brought on to a map and moved off a map, etc. There is currently no way to determine how many units are on them, or how much capacity they have left, etc.

Such things are "must have" for API.

It could change the gameplay in that on some away missions you are so busy doing other stuff on the away map that jumping back to the main map could be a major distraction.

For such cases was invented option to control game speed.
In Earth 2150 (which is my main source of inspiration since it's a game from the same time and with many similar concepts) you need to do all of that manually but you can't bypass it through recycling (I find that as the only major drawback comparing to Warzone 2100) but you are allowed to build production facilities on away missions (that game is all about harvesting limited resources, you have to extract them and transport to main base in almost all missions).
Also that could be only an option, to allow for finer control for those that needs it. But still that should require some kind of compensation for units that are far away from landing zone to be fair and logical, so it would be hard to get useful compromise on that issue.

IMHO, on an away mission, unless you plan to build a base and set up a permanent residence in the area, all units should be sent back to main base after mission ends, particularly on things like intercept or rescue missions.

Yeah, that would make more sense to be left automatic, but needs improvements to avoid those issues like more than one unit on one tile or units on unaccessible cliffs - better positioning of unloaded units. Manual returning of units could be boring, kind of solution could be partial automation, like you select group of units (bigger than transport capacity) and order them to go to transport and after transport gets full it leaves to other map, unloads them and automatically returns for next batch.

Another simplification that I don't like is that all units are unloaded at the same time, do we have some kind of one way teleport?
Jokingly it could be used in that way for explanation why we aren't allowed to create new LZs or build new transporters, since they use technology which we aren't allowed to research and use for different purposes.

It's important to be consistent, and the way how transports works in campaign is really inconsistent. You need to load first batch manually, one after one, then they are "teleported" out at destination, next batches "teleports" into transport after manual selecting of nearly random unit (since you don't have possibility to distinguish units with the same properties) and after mission ends all units are magically teleported to main base.

[aubergine]

Rendering isn't the biggest overhead - if AIs were still active on the main map, there's still all the pathfinding and other maths taking place. Sure, rendering is likely the biggest use of resources, and there would only be one map getting rendered at a time, but I imagine having two maps running at once, even if only one is rendered at a time, would cause some performance issues.

Regarding LZs, currently (from a scripting perspective at least) they can only be placed on the map using the setNoGoArea() function (which is super weird way to create an LZ). The setNoGoArea() function marks out an area and somewhere within that area (or perhaps whole area?) creates the LZ. It would certainly be nice to be able to construct an LZ. I think a lot of pondering is required for transports in general though. For example, in a campaign or challenge type game, is it desirable to allow transports to go anywhere and land anywhere? IMHO it is, but it makes scenario development more difficult as you won't know where the human player will land their troops.

BTW, in terms of shipping resources back to base, maybe oil barrels could fulfil that role? I always found it odd that things like oil barrels and artifacts were instantly "consumed" as soon as your droid gets near one. In revised cam1a script, Per has the player getting extra power if they finish early, which I think is a good motivating factor. I've been trying to think of ways in which that might be explained to the user so it makes sense. It's a bit like watching a movie and you spot Bruce Willis' t-shirt changing colour every few scenes, or something happens with no logical reason, it niggles the mind. So I was thinking of having a transport deliver oil barrels if it's safe to do so, with more oil barrels being available because the transport hasn't had to use as many due to circling around the LZ waiting for scavs to be defeated. Maybe there could be something that takes oil barrels and converts them to power, or takes stored power and puts it in to oil barrels for transport. And maybe have trucks responsible for moving oil barrels around (and maybe artifacts too) - eg. imagine if you have to always send trucks in to get barrels or artifacts and then transport back to base...

[Emdek]

aubergine, if other parts of engine consume so much resources then something is wrong with it. For my master's degree thesis I've created event driven logical circuits simulator using QtScript (each element is defined by set of ECMAScript functions executed when some specified event happens, like change of value of input or variable, connecting and disconnecting elements etc.) and CPU usage wasn't noticeable on 2.8 GHz Pentium 4 HT (Prescott) even for more complex circuits (including rendering of SVGs for state changes of elements) on execution step set to 50 ms (there is need to have such step so output is usable instead of changing so rapidly so it's not usable for users ). If I would need to create logic similar for that of WZ then I would go the same way and I don't find nothing except path finding to be able to consume so much CPU in normal conditions. On my machine WZ constantly eats one whole virtual core and if there are lots of structures that do nothing (like in prefinal mission in gamma campaign, when I'm usually spending more than 250 000 on various defenses so Nexus can have better targeting practice ) and even no units (I've recycled all to check if that makes any difference), so nothing to path finding, it gives only around 7 FPS on Radeon HD 5570.

Being not able to build LZ even in MP (so you can load and unload units anywhere...) is shame, but my above description of insanity caused by oversimplification is worse.
Also if LZ would be kind of destructible structure (but allowed to be built only at specified spot(s)) then it could be considered to replace irritating "LZ compromised" message by need to really defend it, a structure and not visibly defined area (since enemy doesn't need to go directly to that marked point anyway to trigger that) and in case of destruction don't fail but allow to rebuild / reactivate it (if player was smart enough to load trucks).

Transporting of power resources is another area of big simplification but since WZ is not focused at all on resources harvesting then it's partially acceptable, let it be that there exists some kind of globally available WiFi for electricity (something like that is needed to explain ability to power transfers, both in campaign and MP).
Let me describe how it's done in that another game.
There is no direct substitution for oil, to get electricity you simply need to build power plant (depending on faction coal, nuclear or solar based) and electricity is not immediately available on whole map (you can see range using keyboard shortcut), you need to build power transmitters or simply new power plants close to other structures (all require electricity to function, except landing zone, small towers, elevators / small teleporters and of course walls and bridges). The goal is to harvest and process ore which is available in form of fields, where you (again depending on faction) need to build mines and use dedicated units (or more precisely, units with installed special turret) to transport output for processing, build mines with built in output processing, or use harvesters that have ability to transport output to refinery. And from refinery it is automatically taken (by non controllable unit) to main base (from where is shipped to orbit, since ultimate goal is to build evacuation fleet). Also you can use transporter for shipping some amount (main base and away missions do not share credits, you get some initial amount to spend but it's good idea to return it later since it will be lost otherwise). Credits are also required to built units (where total value limits their amount, with exceptions to some kinds of units which you takeover or get for free in some missions) and in some instances (like nukes which cost more than most expensive unit configuration) for munition (instead of long wait times).
Another simplification in WZ is magical creation of munition.
Although replacing it would give biggest gameplay change since it really makes difference. In that case all units (and structures) that fire projectiles require transporters (air units, available form beginning) to ship them munition when depleted or at will. Exceptions are units firing plasma or lasers, they only need to reload (like cannons in WZ).

I've described the above not to encourage all of these changes in WZ itself but it would be extremely nice if engine would allow to create mods that would allow for all of that or even more.
As it was stated many times, WZ is not war simulator but it would be nice if it would be able to be one.

[aubergine]

Wi-Fi for electricity: http://www.nuenergy.org/alt/tesla_energy.htm Basically all buildings and units would just suck electricity straight from the air around them (assuming they found a way to avoid adversely affecting the earth's magnetic field, or maybe they just like aurora borealis appearing worldwide?).

I'd prefer to avoid any concept of credits or anything else that can be considered "money" or "tender" in wz. An obvious first step to rebuilding the human race post-Collapse would be to exterminate all banksters, because nobody would want to sew the seeds for yet another Collapse. I imagine decapitated bankster heads would be good commodities to barter with because they'd prove you've done your bit to make the world a better place.

When I think about oil resources, I always imagine that they are vents to alleviate the disastrous environmental impacts of humanity's folly in to fracking. They'd spew a dirty mixture of oil, gas and fracking chemicals. But, always innovating, humans found a way to turn that to their advantage...

It could be that the oil from derricks is used to produce the compounds required for reprap, rather than electricity? Power gens convert oil in to "reprap power". Run out of that and everything stalls. In Warzone, reprap compound is power.

Thus, magical creation of munition is a simple concept in WZ -- a smaller version of the reprap tech that's used to construct buildings would easily be placed in vehicles to create their ammo. Land units augment their supply of raw materials from the ground beneath them, whereas VTOLs have to return to a rearm pad to get fresh supplies. Bigger / more deadly ammo takes longer to reprap, hence longer reload times for certain weapons.

Still doesn't explain how oil gets from derricks to power gens though, and for minds like mine that need a logical-ish explanation for everything, that's like a brain tumour.

Regarding oil barrels, instead of containing oil, they would contain reprap compound. Hence, you find 100 "power" when you collect one. They'd be pre-collapse remnants of an advanced reprap-based construction industry. Having barrels full of power would make construction a lot quicker, you wouldn't need to process stuff from the ground to make fresh compound, you'd use the ready made stuff to speed things up.

Anyway, I seem to be rambling on about stuff that has nothing to do with the original post in this topic...

[Emdek]

aubergine, those could be good enough explanation if we wouldn't need to research far simpler technologies.
At least those are mostly consistent through game, I don't see any exceptions (well, maybe except VTOLs, but that would be too big balance issue, unless all weapons would be able to shoot them and they would be extremely vulnerable ) from those concepts (no need for electricity, power turning into matter, munition made from thin air etc.).
But not the way how transporting units works or stopping all activity in main base except power production and manufacturing (plus recycling units on away map).

To be clear, in Earth 2150 credits aren't money, it's kind of virtual unit of raw materials, refined ore. But name is misleading.

There is another factor for campaign case, apparently nearly nobody plays it (especially comparing to multi player), it was broken for at least months and nearly nobody noticed that. When I've tested how it works in 3.x line one year ago I've encountered at least 3 missions that simply couldn't be completed due to bugs that were reported long time ago or wasn't reported yet, due to fact that it was impossible to discover them before completing previous missions (moreover it seems that some of these missions are again broken for some players)... Except those critical issues there were (and some most probably still exists and will be fixed only during current scripts rewrite, I guess) some other, like missing enemy attacks (like nearly total lack of enemy VTOLs attacks in beta missions, probably already fixed).
I believe that there wouldn't be much cry if there would be introduced bigger changes in some places or in some mechanisms, more probably some enthusiasm since it could become more interesting. Like removing separation between balancing of single and multi player, probably no one would notice that (but there would be need for testing to ensure that of course) and things would be simpler and more consistent.

Still doesn't explain how oil gets from derricks to power gens though, and for minds like mine that need a logical-ish explanation for everything, that's like a brain tumour.

Regarding oil barrels, instead of containing oil, they would contain reprap compound. Hence, you find 100 "power" when you collect one. They'd be pre-collapse remnants of an advanced reprap-based construction industry. Having barrels full of power would make construction a lot quicker, you wouldn't need to process stuff from the ground to make fresh compound, you'd use the ready made stuff to speed things up.

Personally I think that it was mistake to name it oil, that doesn't make sense in many ways (except being familiar concept). It could be simply named "resource" and it would be enough. And transportation issue could be avoided by using single resource extractor / converter structure built a top of source. The only possible advantage from using term "oil" is to allow it burn to avoid easy capturing of sources...

Anyway, I seem to be rambling on about stuff that has nothing to do with the original post in this topic...

Such discussions are needed, this one reminds me of that topic where it was discussed if units are manned or unmanned.