DisasterCreator

[Sirbomber]

I've always thought adding disasters to an OP2 level was such a pain.  You need to create a different time trigger for each disaster type you want.  If you want to make the disasters more powerful or more frequent as the level progresses, then you need even more time triggers to delete the old disaster triggers and create an entirely new set.  If you're writing a single player game, you need to define trigger handles to keep track of all of these in your savedata struct.  And don't even get me started on volcanoes!  Well, I decided it was time to end this madness.  So, I've created a new library that should make it a lot easier for mission authors to add disasters to their levels.  There are all sorts of fun features you can use, including:

• Minimum wait time between disasters (with an optional chance to ignore that to keep your players on their toes).
• Configurable weights to make certain disasters more likely (including a "no disaster" option, if you want to give people a reprieve), as well as how powerful they should be.
• The ability to have disasters spawn in a random location anywhere on the map, in a random location within pre-defined zones, or (my personal favorite) specifically targeting the areas around player units/structures.
• Streamlined volcano creation tools.

Not only does this make it easier on the level author, it makes it easier on the players too.  By configuring disasters to only spawn around player units, your players won't have to listen to dozens of pointless warning messages for disasters on the other side of the map.

I've also created a sample colony game, so interested parties can see how to use DisasterCreator.  You can check out the code here, or, if you just want to play the mission (a rare Eden vs. Eden match!), you can grab the DLL for it here.

[Crow!]

I'll definitely check this out as a way to fill out the disasters in the map I'm working on.  Thanks for sharing!

[leeor_net]

Looks pretty good but there are a few ways you can improve code quality by taking advantage of features introduced in C++11. I created a pull-request on GitHub -- you can check out the changes and merge if you like it (or close the request without pulling if you're not interested )

Anyway, this is a useful tool me thinks. You may want to consider pulling the enum's into your main class and eliminating the extra headers but that's a stylistic choice. I do get the desire to keep them out of the main header file.

I did notice in your change notes that you moved to C arrays to maintain compatibility with saving... I suppose this is necessary considering how Outpost 2 was built but you'd think there would be a way to do this without having to drop STL containers. Perhaps a std::array could be useful here?

Ooh, another thought -- you mention in features that you can set timers. What about a timer 'jitter' that could allow for small variances in the trigger times? This could lead disaster spawning being a little less predictable?

[Sirbomber]

The only reason I haven't pulled your changes in yet leeor is I think there's a small error in one of the header files.  Other than that, looks good.  I wasn't aware of std:array but I'll experiment with it.  If it doesn't cause problems with saved games, I'll use it.  Thanks for the tip!

Although there isn't an explicit "jitter" value level authors can define, I believe there's already a certain degree of it in the way disasters are spawned.  I'd be open to discussion though, if you have some ideas you'd like to share!

[leeor_net]

The only reason I haven't pulled your changes in yet leeor is I think there's a small error in one of the header files.

You can request changes. I haven't compiled it, just eyeballed it as I didn't have it attached to a project with all necessary dependencies. I'm seeing how CI can be very useful in a case like this. You can specify any issues in the PR and ask for changes which I can make and look at more closely.

Other than that, looks good.  I wasn't aware of std:array but I'll experiment with it.  If it doesn't cause problems with saved games, I'll use it.  Thanks for the tip!

I figured. You're using a lot of older style coding practices. It's changed a lot in the last couple of years (literally since 2014 on up) -- lots of awesome new stuff, the biggest for me is default initializers in the headers.

Although there isn't an explicit "jitter" value level authors can define, I believe there's already a certain degree of it in the way disasters are spawned.  I'd be open to discussion though, if you have some ideas you'd like to share!

Well, it doesn't help that I really don't do a lot of OP2 mission coding, but that's pretty much all I was thinking about. The jitter value within a range is just a random value added to the spawn time to give it a sort of 'randomness' to it; E.g., if jitter is 10, a random value between 0 and 10 is added. But if that's already basically built into OP2 it could just be a redundant feature.

[Hooman]

That's actually kind of neat. You're right that disaster setup can be kind of a verbose pain in the source code.

Agreed with Leeor that C++ has changed a lot in recent years. The newer style code can look a lot different from old style code. So many wonderful improvements to the language, yet so many more are still waiting to make it into mainstream standards.

[leeor_net]

Well, that's where C++20 comes into play, looking forward to it!

[Sirbomber]

Oh good, maybe I'll have caught on to the modern way of doing things just in time for it to change again! 

[leeor_net]

I get that feeling -- I've barely grasped C++14 features when C++17 came around and I'm still sorting that out... kind of surprising when you think about it that Microsoft started off as lagging behind with C++ features then jumped into the board and are now leading the charge. 

[Vagabond]

I gave the new colony game a try. It took me 3 attempts to beat on normal. Once I made it past the first 2 waves, things went without too much difficulty.

Nice little scenario. Thanks for making it. Might consider naming it something else that doesn't include test as it is fine the way it is. (I know it is testing the disaster creator, but the average player would probably enjoy playing it just for what it is).

Wonder how much more difficult it is on hard. Guess I will have to try it and find out.

-Brett

[Crow!]

Tried the mission on hard mode.  Here's a summary of my attempts:
1: Poked around at the map, surveyed all mining locations, checked enemy starting behavior.
2: Tried to build a tube out to the 3-bar mine.  Enemy attack arrived right as that mine was getting online.
3: Built structures along ore hauling path for free bulldozing.  Killed by a meteor that destroyed both a Tokamak and a University on that path.
4: Built then dismantled the Light Post that comes with the base to accelerate Standard Lab construction.  Did not have time to research, much less produce, lynxes in time for enemy attack.
5: Skipped Cybernetic Teleoperation in favor of getting Laser posts sooner, placing them in the direction I saw the opponent attack from.  Built Smelter right next to mine to secure more income earlier.  Survived the first three laser-only attacks.  Died when I had an inferior number of laser lynxes up against a mixed army of laser, railgun, and EMP for the fourth wave.  Might have stood a chance were it not for a meteor that killed an Agridome and disabled the vehicle factory until it was replaced.
6: Tried tube cutting the Vehicle Factory.  Learned that walls built on tubes magically disappear.  Learned that the AI sometimes, but not always, is smart enough to push a unit that is on the intended building site for a tube off of it.  Was able to delay enemy Lynx production so long the second Lynx to come out was a EMP one (despite the Advanced Lab having never received tube connection.)  Was able to survive the first, smaller-than-intended attack, but died thereafter.
7: Used the Robo-Surveyor to assist in holding the tube cut, and got Laser tech early-ish into the game in order to build a laser guard post in range of the enemy CC.  With the enemy defeated, getting my 40 population colony to gain population in the face of the natural disasters tanking morale all the time was not straightforward.  I built a CC and structure factory in the enemy base to take its rare.  This also really helped when a supermassive earthquake destroyed 2 Smelters, a Spaceport, 2 Tokamaks, and about 6 morale structures at around mark 1200.  Final completion was at mark 1568.  By comparison, my fastest Hard mode Eden Starship colony mission time is 1317.


As far as the disasters themselves are concerned, I already knew but this mission confirmed that I really just don't like big meteors.  Keeping vortices confined to the middle of the map is good.  One feature I would like to have if I made a multiplayer map is for any disasters that land near my base to also have happened with similar severity near the enemy base at around the same time frame.

[Sirbomber]

Nice little scenario. Thanks for making it. Might consider naming it something else that doesn't include test as it is fine the way it is. (I know it is testing the disaster creator, but the average player would probably enjoy playing it just for what it is).

I've updated the scenario a bit, the name is now "Colony Builder - Eden, Civil War".  It will also play victory/defeat cutscenes now (a side of effect of this means you can't save your high score, generally I consider having to type something in more of a nuisance so I don't see this as a great loss).  The mission DLL is attached.  Any chance you'd want to include it in the next update?

[Vagabond]

Yeah, shouldn't be a problem to include it in the next release. I'll try to give it another playthrough in the near future and let you know if I see any bugs. I've never really cared about the high scores for colony games either.

-Brett