Default disaster duration/strength for multiplayer scenarios

[Vagabond]

Hey everyone,

I was looking for some opinions on the average strength/duration of different disasters during a multiplayer scenario.  I'm most interested in balancing them for something like a Last One Standing scenario in particular.

They should probably be strong enough that they are noticeable to the players (or else why would you turn on the disasters), but weak enough they do not typically throw the game. What I mean is an electrical storm damaging a Tokamak and making you repair is a good example. A vortex starting on your CC just throws the game unfairly.

I think vortices should not be on by default as they are just too powerful. Even if they are set not to hit your starting base, a vortex appearing at a satellite mine and destroying 2 smelters, the mine, and half the trucks is too much. I was thinking that if vortexes were added, they could be relegated to vortex corridors represented by rectangles on the map where it would be reasonably appropriate to place them. IE not next to mining beacons but maybe somewhere where no one would usually travel to.


The specific values I was thinking are:

Disaster Weights (Over an interval of time say 15-25 marks one disaster will be cued to occur. Below is the percent chance of what that disaster would be):

• 15% of time no disaster occurs (skip)
• 35% of time meteor
• 20% of time electrical storm
• 20% of time earthquake
• 10% of time vortex

For meteors:

• 40% small
• 40% medium
• 20% large (unless disabled)

Safe Zones
I was thinking about setting safe zones for each person's starting base (or anywhere else on the map that it makes sense). This keeps some of the nastier disasters from throwing the game early. For example a large meteor destroying your Tokamak or a vortex through your starting mine beacon/smelters, etc. Safe zones would not allow the following disasters to occur within them:

• No large meteors
• No Vortices
• No Earthquakes (an earthquake on the edge might cause minor damage within a safe area, but the earthquake wouldn't originate on say your Structure Factory and destroy all three of your waiting ConVecs.)

Vortex Duration (If allowed):

• Min: 5 marks
• Max: 20 marks

Electrical Storm Duration

• Min: 10 marks
• Max: 55 marks (or until it leaves the screen)

Earthquake Strength

• Min: 0 (still does damage, but least settable amount)
• Max: 4 (I think about 7 is considered base destroying sized) I think 4 is weak enough it should not destroy a smelter, but would probably knock out a lot of the trucks in a satellite mining operation. I should test this.

I know that most people play with disasters off for competitive rounds. But since it is an option to select for every map I think it is important to include with at least a little bit of though. Hopefully one of these days I'll get a multiplayer scenario out.

[dave_erald]

Disasters have always been a love/hate relationship for me with this game. That being said disasters absolutely should be a part of multi-play but I can certainly understand the stigma related to them and why they normally get shutoff.


So of course yes, if certain disasters can be ensured to stay off of spawning right on top of your Command Center than all the better and absolutely giver hell. Meteors are great to have but the warning/detection system is garbage, like seriously, if nobody is looking for them (i.e. observatory) how do you know they are coming and how did you detect the impact (especially the really tiny ones) that quickly? I call shenanigans on that bull...

I would love to see an OP2 update hack the "meteor impact detected" out of the game for any meteor impact smaller than a basketball. Just let them happen and move on. Good grief.


As far as your numbers go I'm fine with all of them. Nothing feels unreasonable or over done, nothing is overpowered, the %chance of storms over the span of a 300-500 mark game you would see enough of everything and not be overwhelmed.



Whats the best way to mark out safe zones around bases to avoid anything spawning directly over top or very near it?

Good write-up

[Arklon]

I would love to see an OP2 update hack the "meteor impact detected" out of the game for any meteor impact smaller than a basketball. Just let them happen and move on.

Even the smallest meteors are capable of one-shotting Common Ore Smelters. What should be done is make disaster warnings work like the "warning: incoming missile" one, where it only alerts you if the disaster is nearby. For meteors that'd be trivial, but for things like electrical storms or vortexes you'd need to determine if any of your units are within its path. Volcanic eruptions might as well keep global alerts since they're rare map-specific events and might make you want to keep units on the move from pathfinding into the lava.

[leeor_net]

Really when I think about it, that's kind of the risk you take when you sign up for disasters. You risk having a disaster literally tear through your colony. On the flip side, you could be on the lucky side and have a disaster tear through your opponents colony.

It's one of the reasons I tend to not play with disasters turned on -- that's one risk I'd rather not deal with.

[Vagabond]

Dave, Leeor, Arklon,

Thank you for the replies.

Even the smallest meteors are capable of one-shotting Common Ore Smelters. What should be done is make disaster warnings work like the "warning: incoming missile" one, where it only alerts you if the disaster is nearby.

A small meteor shouldn't be capable of destroying a Common Ore Smelter unless it is previously damaged. When I tested small meteors on common smelters, it took a healthy one that was not idled or DIRT protected down to 650 hitpoints. A medium meteor is capable of destroying a fully healthy structure factory in one hit though, so I think I'm going to keep both medium and large meteors outside of the safe zone.

I really like the idea of moving earthquakes and meteors to proximity warnings. Perhaps this is something I'll try to implement in the future with the current SDK.

...
like seriously, if nobody is looking for them (i.e. observatory) how do you know they are coming and how did you detect the impact (especially the really tiny ones) that quickly? I call shenanigans on that bull...
...
Whats the best way to mark out safe zones around bases to avoid anything spawning directly over top or very near it?

Dave, I always thought that it there was a bit of a plot hole with the meteor detection research before the observatory was built. I suppose the same could be said about the other disaster warnings though. Like where is the weather station / weather satellite predicting all the vortexes and electrical storms?

For keeping a base safe from disasters, I'm basically making the programmer pass the class DisasterHelper rectangles that represent the footprint of each base. I then choose a random point and see if it is in a safe zone. If it is I pick another one. If one cannot be found outside a safe zone in about 40 tries, I give up to keep from causing performance problems. So as long as you are not setting 90% of the map as 'safe' it should work fine. There might be a better way then this sort of brute force approach, but I haven't found it yet.

I don't think tracking the size of asteroids the size you are seeing in Outpost 2 is unrealistic (if you had observatories that is of course). See this excerpt below from NASA stating they can already track softball size and larger stuff in Earth Orbit.

From https://www.nasa.gov/mission_pages/station/news/orbital_debris.html

The Department of Defense maintains a highly accurate satellite catalog on objects in Earth orbit that are larger than a softball.

NASA and the DoD cooperate and share responsibilities for characterizing the satellite (including orbital debris) environment. DoD’s Space Surveillance Network tracks discrete objects as small as 2 inches (5 centimeters) in diameter in low Earth orbit and about 1 yard (1 meter) in geosynchronous orbit. Currently, about 15,000 officially cataloged objects are still in orbit. The total number of tracked objects exceeds 21,000. Using special ground-based sensors and inspections of returned satellite surfaces, NASA statistically determines the extent of the population for objects less than 4 inches (10 centimeters) in diameter.

Leeor,

Definetly true there is no way to have disasters on and be completely fair (except that anything unfair could happen to any player I guess). I do think there is a difference between an instant win due to disaster destroying a CC and winning because I could not make up the ore production I lost due to the disaster. If that makes sense?

[Arklon]

A small meteor shouldn't be capable of destroying a Common Ore Smelter unless it is previously damaged. When I tested small meteors on common smelters, it took a healthy one that was not idled or DIRT protected down to 650 hitpoints. A medium meteor is capable of destroying a fully healthy structure factory in one hit though, so I think I'm going to keep both medium and large meteors outside of the safe zone.

I'm almost positive I've had small meteors one-shot my smelters multiple times. Could be wrong. Either way, I don't think it's proper to not alert you about small meteors - what if one is on top of a bunch of clumped-up vehicles? It should definitely one-shot vehicles in a small radius.

I really like the idea of moving earthquakes and meteors to proximity warnings. Perhaps this is something I'll try to implement in the future with the current SDK.

Not possible without ASM hacking. I could probably do it.

[Hooman]

I love the idea of proximity warnings. Or possibly text only warnings unless it's close.

I like that you're testing meteor impact strength.

You could potentially allow for a time delay for large disasters in the initial base area. Eventually you'd expect someone to expand, or build redundant structures. I think disasters should hit the original base area, but not right away, certainly not big ones.

[leeor_net]

Leeor,

Definetly true there is no way to have disasters on and be completely fair (except that anything unfair could happen to any player I guess). I do think there is a difference between an instant win due to disaster destroying a CC and winning because I could not make up the ore production I lost due to the disaster. If that makes sense?

Fair enough. In that case I would simply put a 'safe zone' around the CC and leave it at that. But that's just my humble opinion. As stated in another thread, I'm not a current multiplayer veteran, I just used to play friends way back when and a bit on the WON servers when they were still active.

[Vagabond]

Hooman,

Thanks for the suggestion on a timer until Safe Zones expire. I like the idea and it really easy to add to the class.

I'll just make it so that if you set the timer to 0, safe areas are always in effect, and if you set it to a positive number, the class disregards safe areas after that mark is reached in game.

It would also be pretty easy to call ClearSafeRects() if someone wants to control when the safe areas disappear with a custom property. Maybe such as when the colony reaches X population in a single player round or when rare ore is researched or anything else.

[leeor_net]

Side note -- I would define a constant that represents "never expires". Something like:

Code: [Select]

class DisasterHelper
{
public:
	static const int NEVER_EXPIRES = 0;

public:
	DisasterHelper();

/* etc. */
};

That way it could be called with something like:

Code: [Select]

DisasterHelper d;
d.setTimer(DisasterHelper::NEVER_EXPIRES);

Haven't thoroughly looked over the disaster helper code so hopefully my explanation is clear.

[Hooman]

A constant is a good idea. Very nice syntax leeor_net.

Might I suggest using MAX_INT instead of 0? Then everything would work out without special checks.

Code: [Select]

if (intVar > MAX_INT) {
  // never true
}

You can find MAX_INT in a standard header. I believe <climits> is where you should look, unless you have a really old compiler in which case it might be <limits.h>.


I'd be tempted to use unsigned integers for time counters, since negative values don't make sense, in which case MAX_UINT would be more appropriate. I don't recommend that here though, since the game just declares most stuff as int. Better to stick with the datatype that is actually being used.

[Vagabond]

Leeor & Hooman,

I'm adding the Timer as indicated in the following code. I'm setting it to expire by default at 250 marks. This is a bit of a shot in the dark. If anyone has a better default time for when to drop the SafeZones, please suggest it. Perhaps I'll find some time to test a couple of Last One Standing rounds to see from experience what the number should be when the player is pretty established. The people I usually play with are not big on LoS though. Thanks for the ideas!

Side question, is it a good practice to use this->someClassProperty = someClassProperty? This way if I make the variable from the function setting the class property the same name as the class property, there is no confusion. I do this all the time in C# using this.someClassProperty = someClassProperty and I think they are kind of equivalent.

Code: [Select]

public:
	// Sets a timer value in marks where base safeZones expire, allowing more dangerous disasters to hit bases. 
	// To make SafeZones never expire, set timeInMarks to the const TimerNeverExpires.
	// To disable SafeZones without clearing them from DisasterHelper, set timeInMarks <= 0
	void SetSafeZoneExpirationTimer(int timeInMarks)
	{
		this->safeZoneTimer = timeInMarks;
	}

	static const int TimerNeverExpires = INT_MAX;

private:
	int safeZoneTimer = 250;

[Hooman]

It's perfectly normal to write this->attribute = attribute, especially in a constructor, or setter method. Sometimes I see stuff like attribute = newAttribute in setter functions, but don't get overly creative with renaming things just to avoid using this. You want to avoid situations such as attribute = seeminglyUnrelatedAttribute. If you give something a different name, even slightly, you imply it's something different.

Might I suggest using an additional named constant for the default safe time. It might also be good to document the expected unit on the constant, either within the name, or afterwards. (... = 250 // in marks) I would usually assume times are given in ticks, since that's how the game handles things internally. Marks are mainly for display.

[leeor_net]

As a stylistic suggestion, I would use all-caps for a constant. E.g., instead of TimerNeverExpires, TIMER_NEVER_EXPIRES. This is ultimately up to you but is generally how C/C++ programmers tend to style their code. I think TimerNeverExpires type of styling comes from Java/C# which isn't bad, just unexpected.

Of course I could just be getting old and crotchety so take my advice with a grain of salt.

[Vagabond]

Thanks Hooman and Leeor,

Glad to hear I'm using this->attribute correctly. I added the second constant as suggested. Not sure about all-caps constants. See the other post for details.

-Brett