Plymouth / Eden

[Leviathan]

Like Pie Chart i wanna make it so when a player is Eden they get a laser or two, and when there Plymouth there get a mic or two.

Using the code Eddy suggested, then this what hacker suggested (in Main.cpp):

Code: [Select]

  InitPlayerResources(i);

  	//Normal
  	StartLocation &sLoc = startLocation[i];

  	// Make it a Plymouth base instead
  if (!Player[i].IsEden()) {
  	StartLocation &sLoc = startLocation[i+4];
  	}

All bases got a Laser, they used the unitESet's in my BaseData.h file.
At least it didnt crash like b4.

And back to the original question, whats the simpleist way to make each race start with correct GP ?

Code: [Select]

if (Player[x].IsEden()) 

This will need to be used in most new multiplayer coded maps.

[Hooman]

I'd say the easiest way (and the least amount of work for me   ) is to use multiple base layouts. Just copy and paste one and change all the mapMicrowave to mapLaser, or something of that sort. The just use an "if (Player.IsEden())" type of thing during base selection. The easiest way seems to be the current one of just adding a constant to the base index. Just remember not to mix the two base types when randomizing their locations or this doesn't really get you anywhere. Of course there isn't really any quick helper code to handle mutual exclusion for you. The function included in the helper file is used to permute a list. The sample base creation code assumes these lists refer to bases in mutually exclusive areas. There is nothing stopping you from dropping two bases on top of each other if you're using them, other than to make sure only one base at each location is included in the list. To duplicate a base layout by simply changing mapMicrowave to mapLaser presents a slight problem here.

Now, the simple case, where Eden bases are always in different locations than Plymouth bases, you can permute the two base lists seperately, and then just stick with adding a constant offset.

For example, if you have 4 starting locations for each of Eden and Plymouth (which don't overlap) and thus 8 starting locations total, you can randomize the list like so:

Code: [Select]

	RandomizeStartingLocations(4, startLocation);
	RandomizeStartingLocations(4, &startLocation[4]);

This is in contrast to the single line:

Code: [Select]

	RandomizeStartingLocations(autosize(startLocation));

which would normally have been used to randomize all the locations in one big list.

Now, when selecting a base layout to place, use something along the lines of:

Code: [Select]

  // Place all bases on the map
	for (i = 0; i < TethysGame::NoPlayers(); i++)
	{
  InitPlayerResources(i);

  StartLocation &sLoc = startLocation[i + Player[i].IsEden()?0:4];
  CreateBase(i, sLoc.x, sLoc.y, *sLoc.baseInfo);
  Player[i].CenterViewOn(sLoc.x, sLoc.y);
	}

Instead of the usual:

Code: [Select]

	// Place all bases on the map
	for (i = 0; i < TethysGame::NoPlayers(); i++)
	{
  InitPlayerResources(i);

  StartLocation &sLoc = startLocation[i];
  CreateBase(i, sLoc.x, sLoc.y, *sLoc.baseInfo);
  Player[i].CenterViewOn(sLoc.x, sLoc.y);
	}

Note that the above example assumes there are 4 Plymouth starting locations, followed by 4 Eden starting locations in the array.



Now, if you want to solve the mutual exclusion problem, you can use a variant of the above idea. The difference is that you can no longer randomize the order of two seperate lists of base locations since there is no way to guarantee they will be randomized in the same order. If the two lists aren't reordered in the same way, then creating say, base 1 from the first list, might still overlap with the base 3 from the second list. This would mean you couldn't simply add a constant to select which list you wanted to pull the base from. Instead, you could randomize a list of indexes into the lists, but not the actual lists. That way you can ensure the lists have the same relative order (so say, base 1 from the first list always overlaps with (and only with) base 1 from the second list). This can be done using the RandomizeList function in the helper files. So, a better version of the above might be the following. Define your bases so that base i (Plymouth base i) overlaps with only base i+4 (Eden base i). Then define a list of the 4 starting locations.

Code: [Select]

int indicies[] = { 0, 1, 2, 3 };

Randomize that list.

Code: [Select]

RandomizeList(autosize(indicies));

And then alter the base creation code to the following:

Code: [Select]

	// Place all bases on the map
	for (i = 0; i < TethysGame::NoPlayers(); i++)
	{
  InitPlayerResources(i);

  StartLocation &sLoc = startLocation[indicies[i] + Player[i].IsEden()?0:4];
  CreateBase(i, sLoc.x, sLoc.y, *sLoc.baseInfo);
  Player[i].CenterViewOn(sLoc.x, sLoc.y);
	}

Note the use of indicies instead of just i, causing the reordering to be indirectly done through the indicies array. DO NOT use RandomizeStartingLocations on the startLocation array when doing this!


Of course I used a simple case of 4 base layouts each since the current SDK example uses that many and that's the sample code I drew from. You can of course change all the "4"s above to "6"s if you want more of a pie layout.


Also, this is not as general as it could be, but it solves the most likely case of dealing with multiple base layouts. A more general way of doing this is to define a set of mutually exclusive starting locations and an indicies array for them. Then for each starting location, define an array of base layouts. You can freely randomize those lists individually if you truely want randomness, or some other selection criteria depeing on Plymouth/Eden, or difficulty setting. If you need some hard selection criteria and some randomness, you can always solve it with an extra layer of indirection!   That's right, use a secondary indicies array. (I know, some people may want to kill me for that remark due to certain trends to add extra layers of indirection where they really aren't needed.  <_< )


Well, hoped that helped, and maybe even made a little bit of sense. (and ftlog, I hope it's correct  :unsure: ). I'm thinking maybe this would be a good idea for a future SDK example. Think we should do up a map demonstrating this for future inclusion in the SDK?

Disclaimer: I haven't tested running any of this code (yet). I just merely checked to make sure it compiles, so there at least shouldn't be any embarrassing typos in it. But still, it might just crash and burn, which is usually the case with untested code. But I at least hope the idea is sound, and any fixups will be minor.