Research Across Campaigns

[Sirbomber]

For those curious, the AI's research transfers between missions, just like the player's does.

Nothing too spectacular I guess.  I just thought I should mention it somewhere.

[Hooman]

Ahh yes, that was one of the first things I noticed about Outpost 2 that I liked.

I'd forgotten about it remembering research after a while, and eventually just assumed the mission objectives forced you to research everything, and then just gave you that same set at the start of the next missiong. It does however actually work as you say. I've read through the save and load code for those mission details. If you check the GameStartInfo struct and the MissionResults struct detailed in the ForcedExports project you'll see all the data that gets passed between levels.

I don't remember for sure how it decides whether to use the smaller GameStartInfo struct, or the larger MissionResults struct, but I think it depended on the campaign flag.


Actually, there is a function you can pass that struct to if you want to start a new game from custom code. I believe I saw it used by the multiplayer game start window. I'd thought of calling it directly, but that would have involved rewriting the whole game start window, which seemed like too much work at the time. I was kind of considering replacing that too though, so some things could be changed easier without having to cancel and recreate the game, such as changing the game type or the max number of players. Replacing the game start window could also have been interesting for custom maps that need their own special start settings.



Edit: Wait, the AI too? Ahh, misread that. But yeah..., the code does affect all players in the same way. At least the research part. I suppose there are some differences with GoAI calls, but those don't affect research.
 

[Spikerocks101]

After that spiel, thought you would have read his post XD

Any ways, kewl

[Hooman]

I read it, I just sort of didn't pick up on the "AI" part for some reason.


If you're curious, two functions of interest are:

Code: [Select]

00487F80 >/$  5>PUSH EBX                                                                           ;  Function: TApp.StartSingleGame(GameStartInfo* gameStartInfo)

Code: [Select]

004893B0 >/$  8>SUB ESP,12C                                                                        ;  Function: TethysGame.StartGame(GameStartInfo* gameStartInfo):bool bSuccess

[Sirbomber]

I wonder if this could be adapted to work for special multiplayer missions...  Combined with a haxed game start window, we could have a multiplayer campaign.

[CK9]

NOW THAT would be frik'n AWESOME!!!!!!!!!!!

[Sirbomber]

Coding 202 topic anyone?

[CK9]

That would be a good one to do it on...if you already knew it

[Sirbomber]

Coding 202 will be more "let's work on a tough project together" and less "let me tell you how this is done".  Ideally it will attract all types of people interested in whatever topics we work on, and not just beginners.  But we're kinda getting off-topic here?

[Hooman]

You probably wouldn't have any easy access to saved games, and you'd also probably have to write all the network code to go from one mission to the next without disconnecting. I have no idea how hard that might be.

It is neat to think how close to a human player the AI could be made to function as.
 

[CK9]

yea, it can be made almost as stupid as some

How dependant on player progress is the "AI" in regards to technology?

[Sirbomber]

I'm pretty sure that in the original campaigns the AI is just given all technologies, so it wouldn't come up normally.  I only found this out through my own curiosity and experimentation.

[Kayedon]

I'm pretty sure that in the original campaigns the AI is just given all technologies, so it wouldn't come up normally.  I only found this out through my own curiosity and experimentation.

Up until you said that, I was wondering "How does that affect us?"

[BlackBox]

You probably wouldn't have any easy access to saved games, and you'd also probably have to write all the network code to go from one mission to the next without disconnecting. I have no idea how hard that might be.

It is neat to think how close to a human player the AI could be made to function as.

Could accomplish it in a different manner I suppose. Just have some mission that reads in some data to decide what "mission" to start on with proper settings and etc. The data could be stored by way of some generic file (missions are DLLs so just read and write a file using the standard APIs) obviously making sure that data is being written and loaded symmetrically on all machines.

As far as continuing a campaign the easiest method I can think of probably involves one mission = one "session" of multiplayer, and at each new session you load in the saved data file I talked about and set up the level properly.

So for example, players starting a campaign:
1. Host hosts a game using special "multiplayer campaign DLL"
2. Players join, game starts
3. Special DLL sees that save file doesn't exist on the machine so it starts with mission #1
4. Gameplay commences, players complete the level, victory condition occurs
5. Game terminates like a normal multiplayer game

Now players want to do "mission #2", so the following happens:
1. Host hosts another game with the same "multiplayer campaign DLL"
2. Players join, game starts
3. The DLL sees the save file and therefore knows it should start at mission #2 with certain data (completed techs and whatever else you want to save). It could call Map.LoadMap and Research.LoadTechtree to load a different map and techtree (this is completely possible, proof of concept is in the OP2 game recorder that I created a long time ago) if you wanted; you could either have all code for all missions in the same DLL or you could get creative like I did with the game recorder to load a second DLL and "patch through" trigger calls and so forth to the actual DLL that contains the mission.
4. Gameplay starts on mission 2, players complete level, etc.
5. Game terminates

Now obviously there would be some special cases to deal with, for example what if all the players don't have the saved file or its contents don't match (might be able to abuse command packets to send arbitrary chunks of data between the clients, I believe that there is some working code that allows sending new command packets over the network, so for example you could transfer checksum or other information)

It would probably be a good idea to checksum things like maps and techtrees if you are loading them after InitProc is called (and somehow send these over the network for comparison), in case these differ / are missing between multiple players.

You would also have to deal with checking to make sure the same players are in each game (or provide some means for their recovery, for example if 3 players did mission 1 but the 3rd player is absent for mission 2 either abort or somehow allow the game to progress with only 2 players). You would have to deal with players in different spots as well (depends on the order of joining the multiplayer session) and check for this (maybe just compare against ASCII names or whatever) and assign the right starting states to the right players.

Finally there might want to be a way to ask if you want to resume if it finds a saved game file (probably display it to the host, and again use commandpackets/whatever to communicate the decision to other players).

The other possible way for continuation between levels would be to somehow reset the simulation at the end of a level (for example victory condition fires, reset game tick to 0, load a new map, load a new techtree). This seems like it would be opening a whole new can of worms and is probably not very easy, so I think the other method I described would work well.

TL;DR -- I think a multiplayer campaign is completely within our reach based on what we already know, a lot of the stuff I learned when building the game recorder/player is applicable here

[Sirbomber]

Alright then.

1) How do we re-checksum the map and techtree?  Can we trick OP2 into doing it for us, or will we have to do it manually?  Though we'll probably need to do our own checksum for save files anyways, so yeah.  (Speaking of, do we want to "encrypt/protect" save files, or should we just rely on the honor system?)

2) Rather than figure out who's who based on their names, which can and do change (I'm looking at you Arklon/Tankn0[size=0] [/size]0b/Duke Nukem) we do something like:
  - Assign each player an ID.
  - Save only the local player's ID.
  - When starting the next game, OP2 "asks" for each player's saved ID.
  - Now that it knows what belong to who, OP2 gives players their techs/resources/units/etc back.
We can also build in a check to ensure two people don't have the same ID and refuse to load if they do since it means they're

3) If a campaign loses a player, the other players can wait or go on without him/her.  But once they do that the campaign becomes 2P only, so the lost player can't come back.

[Hidiot]

3) If a campaign loses a player, the other players can wait or go on without him/her.  But once they do that the campaign becomes 2P only, so the lost player can't come back.

Or any new player gets the standard kit (techs, units, resources)

[BlackBox]

1) How do we re-checksum the map and techtree?  Can we trick OP2 into doing it for us, or will we have to do it manually?  Though we'll probably need to do our own checksum for save files anyways, so yeah.  (Speaking of, do we want to "encrypt/protect" save files, or should we just rely on the honor system?)

You can call ResManager::ChecksumStream to checksum a file. However it would be completely up to the mission to compare the checksums and abort if they didn't match (OP2 only automatically checksums the actual DLL that is first loaded; it wouldn't be aware of this situation where you are loading another DLL from within the first). The biggest hurdle to solve is sending arbitrary data to other players in the game when you want.

2) Rather than figure out who's who based on their names, which can and do change (I'm looking at you Arklon/Tankn0[size=0] [/size]0b/Duke Nukem) we do something like:
  - Assign each player an ID.
  - Save only the local player's ID.
  - When starting the next game, OP2 "asks" for each player's saved ID.
  - Now that it knows what belong to who, OP2 gives players their techs/resources/units/etc back.
We can also build in a check to ensure two people don't have the same ID and refuse to load if they do since it means they're

There's the net ID but I believe this changes at every session; the method you suggest is probably a good idea (perhaps could even combine it with some central server based at OPU or elsewhere).

3) If a campaign loses a player, the other players can wait or go on without him/her.  But once they do that the campaign becomes 2P only, so the lost player can't come back.

That makes the most sense, as Hidiot mentioned you could just give any new player some standard set of resources but this might not be necessarily the best way to do things.