Campaign stuff

For AI and campaign script related discussions and questions
Post Reply
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Campaign stuff

Post by aubergine »

There was a previous topic (I found a few but not the one I was looking for) where I was chatting with Emdek about my proposed changes to <campaign>.ini...

(@Admins: If you know where that topic is, pls merge this topic in to the older topic)

EDIT: If that older topic can't be found, here are the proposals I refer to throughout the post below.

Anyway, having thought about Emdek's comments more, specifically regarding mission unlocking idea -- whether it should be handled in .ini or .js -- I now agree with Emdek that it should be in JS.

But this got me thinking that maybe we are taking wrong approach to porting campaign scripts to JS API. Maybe we should leave existing campaign as it is for now, and instead develop a new leaner infrastructure for Campaigns 2.0.

As I've said elsewhere, I thoroughly believe that all game modes should be based around a map and associated .ini file, and that the .ini file should be the same format regardless of game mode.

We already have <challenge>.ini and <mapname>.ini, but they are different formats. And Campaigns currently use some completely weird oldskool approach that is mind-boggling to say the least.

My proposal is summed up as follows:

* <mapname>.ini is the main template to use.
* Challenge games have a challenges/<challenge>.ini in the exact same format as <mapname>.ini
* Campaign missions have a campaigns/<cam>/<mission>.ini in the exact same format as <mapname>.ini

The <mapname>.ini is optional, and can be bundled with a map to define defaults on game set-up screen.

A <challenge>.ini simply overrides <mapname>.ini for a challenge game. The old <challenge>.ini format can remain for backwards compatibility reasons, but as of WZ 3.2 all new Challenges should use the format of <mapname>.ini in their <challenge>.ini. It should be relatively easy to spot which format of file is being used just by looking at the sections in the .ini file.

As for Campaigns, we need the additional <campaign>.ini which lists all the missions in the Campaign and macroscopic information about the Campaign that doesn't fit logically in to a <mission>.ini.

Then we start porting campaigns over to new infrastructure one map / mission at a time, dealing with each roadblock as it arises.

By doing things this way, the old campaign can be left intact and the new version of it developed alongside. This will make it easier to compare the old campaign to the new format to make sure we've retained the original gameplay.

One of the big things to implement in the new Campaigns 2.0 system will be how data is stored and in particular how data from one mission is available to other missions (even other campaigns).

Even Goth isn't sure how to do away missions in the campaign, and I'm guessing nobody else is really sure how it's done. Instead of trying to port whatever weirdness is used in the Pumpkin code (which might have been cutting-edge back in the '90s) it would be better to just implement some new way of storing the data.

In particular, it would be very useful to have some sort of 'session storage' object that persists between games. This will be massively useful not just for campaigns, but also AIs in skirmish games -- eg. they could remember what sort of units a player makes, or where battles happen on a certain map, etc.

In the context of a campaign, the session storage will need to be player specific and campaign specific. So if on a single PC there are 3 players, each doing all 3 campaigns, there would be 9 of these session storage files in total (3 players * 3 campaigns).

Once session store system is in place, any mission should be able to access data from other missions -- not just the current campaign, but any campaign. This has no particular benefit in the canonical campaigns as far as I can tell, but is opens a bewildering array of creative options when it comes to custom campaigns that the community will develop over time. For example, someone might make a series of 3 campaigns in which there are some missions where you return to an old base from a previous campaign/mission and it will be just as you left it.

There would then need to be ways to transfer stuff from one mission / map to the next. Things like droids, technologies (researched or not) and power. Thus, if I transport a droid from one map to another, or even one location to another, that droid actually gets moved there in the data store. If I go back to that location at a later date, the stuff I left there should still exist.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Goth Zagog-Thou
Regular
Regular
Posts: 1582
Joined: 06 Jan 2007, 08:08
Location: Delta Base
Contact:

Re: Campaign stuff

Post by Goth Zagog-Thou »

Well there seems to be some weirdness in loading up away missions (and any mission in general tbh). I think it's WAY more complicated than it needs to be.

In the gamedesc.lev file, the format is:

Code: Select all

/******************************************************/
/*     campaign 4 dataset and levels                  */

campaign	CAM_4
data		"wrf/vidmem.wrf"
//data		"wrf/vidmemc.wrf" // might not need this
data		"wrf/basic.wrf"
data		"wrf/cam4.wrf"
data		"wrf/audio.wrf"
data		"wrf/piestats.wrf"
data		"wrf/stats.wrf"
data		"wrf/cam4res.wrf"

/* Campaign 4 1-7 "The Gauntlet"  */
camstart		CAM_1A
dataset		CAM_4
game		"wrf/cam4/cam4-1.gam"
data		"wrf/cam4/cam4-1.wrf"

/* Campaign 4-9 9-13 "Reckoning" */
miss_keep	CAM4_9
dataset		CAM_4
game		"wrf/cam4/cam4-9.gam"
data		"wrf/cam4/cam4-9.wrf
While in the .slo when you go to load it up, it's:

Code: Select all

startMission(OFF_KEEP, NextLev);
and could even be:

Code: Select all

startMission(OFF_CLEAR, NextLev);
It can be confusing, to say the least.

I'm all for specifics, but there's got to be a better and more direct way to do it.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: Campaign stuff

Post by aubergine »

Yup, sounds like you are hitting the same problems I was, and you know waaaay more about campaign structures and all the other stuff than I do.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Goth Zagog-Thou
Regular
Regular
Posts: 1582
Joined: 06 Jan 2007, 08:08
Location: Delta Base
Contact:

Re: Campaign stuff

Post by Goth Zagog-Thou »

Oh, and I forgot that you actually need scripts in the specified folder(s) for it to load. And the .wrf for EACH map. And the .gam file (and other files that get made when the map is compiled).

If you plan to have any beacons on this map, you'll need a something-prox.txt, a something.txt, AND a campaign-something.txt for subtitles and what one sees when they click the beacon itself.

Map multi-loading, on the other hand, seems to work just fine with a minimum of fuss (and yes, it screwed up before due to how I scripted it).
Post Reply