OK, I started coding a bit on the random mission builder discussed here:
http://www.hard-light.net/forums/index.php/topic,24234.0.htmlNOTE: I have not finished anything yet, DO NOT MAKE MISSIONS FOR THIS, they will probably not work, since standards will change. Now, BW and I have kind off set up the basics for standards to do this. I'll be leaving next monday though, for 3 weeks, so I won't finish it soon. I thought we could let you guys list features and ideas about it. Black Wolf and I will try to explain everything, here we go:
A mission is first made in FRED. Then, someone opens the mission in notepad, and changes all the things that have to be randomized to $VarName (for text), or %VarName (for random numbers), were name is anything you want. Then, at the start of the file, right after #Mission Info, you put something like the following:
#Mission Info
;NoOfPasses=3
;RndDefine{
;$VarShipName1 = $RndTShipname
;$VarShipClass1 = $RndTDest
;$VarWingName1 = $RndWingname1
;$VarShipClass2 = $RndTBomb
;%VarLocX = %Rnd(1,1000,1)
;%VarLocY = %Rnd(50,250,1)
;%VarLocZ = %Rnd(2000,3000,2)
;}
What you're doing here is telling the builder you want all instances of $VarShipName1 replaced by a random line out of the file TShipname.ini.
The ini files have a list of valid values.
In this context, the ini files pretty much just list the ships that fit into the categories you want to use, eg. you'd put all the Terran destroyers into one ini file, all the shivan cruisers, etc. They can be as general or as specific as you need them to be. For the test mission, the fighters for example were split into Terran Heavy and Terran Light. If you choose, you could also put in stuff like SOC fighters, and include things like the banshee and Erinyes. This means the mission can remain fairly balanced, while still have something of a random feel. This type of ini based system also makes converting the system (if not the mission templates themselves) for TCs a matter of a few minutes work rewriting the relevant inis.For the numbers, you list a start, an end, a step for the randomizer. So with %VarLocZ you'll be getting a number, anywhere between 2k and 3k, but only one devideable(sp?) by 2.
NoOfPasses will be explained later.
Now, what if we want the user to do some of the choosing?
There is also a CnsDefine line, placed above the RndDefine. Example:
#Mission Info
;NoOfPasses=3
;CnsDefine{
;!"What species?"
;$CnsSpecies1 = (Terran, Shivan, Vasudan)
;!"What ship to protect?"
;$CnsEscort1 = (Orion, Fenris, Levyathan)
;}
;RndDefine{
;.. same as before
;}
Now, the ! defines that everything after that, minus the " will get outputted to the user. The $CnsSpecies1 bit pretty much works the exact same as a $Var thingy. The stuff between the rounded brackets will get outputted too, and the user will have to make a choice between them.
NoOfPasses will be explained even later, first, onto the ini files. Here's an example:
Tlightfight.ini
@version=000001
@reuse=1
GTF Perseus
GTF Myrmidon
GTF Ulysses
GTF Loki
@version always is the first line, followed by a 6 digit number. It'll be needed for the builder to know what value is expected were. Version changes will be highly documented, if everything goes as planned.
@reuse is for now a value to say if a value can be used twice. Meaning that if you do a list of possible wingnames, putting @reuse=0 in there makes sure you only have one Cancer, and not 3 of em. Off course, for ship classes, you do want it to be reused. When there are more vars needed than lines in the file, the program will have to reuse the lines. Make sure you have enough entries.
The rest of the file is pretty straightforward. Each line will get copied verbatim into the file.
Now, for random backgrounds, you need more then one line, right?
This is what I thought of for that:
Bg.ini:
@version=000001
@reuse=0
$Fle=bg1.txt
$Fle=bg2.txt
$Fle=bg3.txt
Now, what happens here is that the program first goes through all the normal routines, and then, after everything is replaced, it'll do another pass,
and it'll copy all the contents of the files here into the mission. This is what NoOfPasses is for, to tell the program how often it needs to do this.
NoOfPasses has another, (IMO) more interesting use aswell. With the ability to use multiple passes, modular briefings can be written and randomized, but reference things like $ShipName1. For example, the first briefing ini might say:
The NTF has been active in this system, and we have recieved word that they intend to attack the $ShipName1.
OK Pilots, listen up. Local sensor stations have picked up intel suggesting an imminent NTF attack on the $ShipName1.
We've received a distress call from the $ShipName1. She's come under attack from the NTF!
[/size]
During the first pass, the program will choose a briefing stage at random. During the second pass, it'll insert the name of the destroyer into the briefing. The same applies to debriefs, mission goals and objectives, even messages.[/color]
Now, I'm not sure if we can do randoms twice, but I'll try to make it so even that is possible. The uses for this can be better explained by someone who knows FRED, so Black Wolf will list some possible uses.
Unfortunately, this isn't what you'd call a true Random Mission Generator as such, it's more an Existing Mission Randomizer. It relies heavily on mission makers input, and making a mission for this is a little bit more complex than making one for standard FRED, but you'll ultimately end up with more playtime from the one mission.
Release, when it happens, will probably be with just two basic mission templates - a capship defence, and a capship assault. Ultimately, I'd like to increase the random factor by providing more than one base template for each mission type, but this is in no way the limit of the concept. The beauty of the idea is that you can change literally anything that you want to in the mission, since the ini files are so simple to create. Say, for example, you wanted to do a convoy guard mission. The type of ships in the convoy, as well as the attacking ships could, of course, be changed. But so could their destination (Could be randomized to be an installation, a destroyer, or a jumpnode, for example). And, using some of the SCPs new sexps, especially is-ship-class, you can link things to the changing circumstances dictated by the randmizing. For example, you could have a cruiser arrive if-ship-class of $ShipName1 = GTD Orion or GTD Hecate, whereas if it equals a deimos or cruiser, the hostile cruiser does not arrive. Similar things can be applied to stuff like AI behaviour and the like.
You can also change things relating to the environment of the mission. The background system relies on the ability to place large chunks of text - this system can also be applied to place all the neccesary information about using a full nebula, or an asteroid field. You can even select the frequency this happens by placing more than one copy of the chosen data into the ini file. If you want a 1 in 5 chance that the mission takes place in a full nebula, then you place four entrys in the ini file linking to a non nebula text file, and one entry to the nebula data.
There's a lot more that can be done with this system. I'll admit, making templates for the randomizer requires a lot of datawork, certainly more than making a standard FRED mission, and a lot of mucking about in the mission file. It's something that requires almost an entirely new style of FREDding, because you have to take into account a lot more potential outcomes, and in many cases you'll need to do some pretty complex Sexping. But ultimatelym you get a much more replayable product than a standard, single use FRED mission.
One caveat however - these missions will never be able to replace properly FREDded missions in campaigns. A particularly well designed template might be able to spew out the bare bones of a campaign level mission, something that, with a lot of polishing and rewriting, might be able to be turned into a campaign level mission, but it's not going to replace proper FREDders or anything. Sorry guys - we've still got work to do. 
