Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: How to make 4 players share minerals + gas
How to make 4 players share minerals + gas
Aug 16 2010, 10:39 pm
By: Warlord_Master  

Aug 16 2010, 10:39 pm Warlord_Master Post #1



I am sure this question has been asked and answered before but I am unable to find any tutorial for resource sharing on staredit, sen wiki or yahoo with keywords Binary Countoff, Shared Resource, Resource Sharing.
I Found a Tutorial by Tuxedo Templar for Binary Countoff but I dont know how to apply that to resource sharing

Post has been edited 1 time(s), last time on Aug 16 2010, 10:47 pm by Warlord_Master.



None.

Aug 16 2010, 11:01 pm payne Post #2

:payne:

Well, a work around could be to use the Custom Score.
Each minerals a player has adds score to Custom Score of Player 1, and the gas adds to Player 2.
Then set all building's cost to free and whenever you detect a building is constructed, scan the amount of score a player has and deduct the cost of the building (or destroy if not enough resources).
Don't forget to show leaderboard.



None.

Aug 16 2010, 11:51 pm Chia-Tyrant Post #3



If you want to use the actual resources instead of scores, the quickest thing I can think of is:

Let Comp be a non-human player who cannot gather or spend resources, "resource" be either ore or gas and "Force" the force (or forces) in which all human players are in.

Trigger A
Conditions:
  • Current player accumulates at least X resource
  • Comp accumulates at most X-1 resource
Actions:
  • Subtract 1 resource for current player
  • Add 1 resource for force
  • Add 1 resource for comp
  • Preserve trigger

Trigger B
Conditions:
  • Current player accumulates at most X-1 resource
  • Comp accumulates at least X resource
Actions:
  • Add 1 resource for current player
  • Subtract 1 resource for force
  • Subtract 1 resource for comp
  • Preserve trigger

Copy those two triggers for X=1...n where n is the maximum amount of resources they could have.

I made that up off the top of my head; feel free to correct me if I made any mistakes or forgot something.



None.

Aug 17 2010, 12:17 am NudeRaider Post #4

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Don't use custom score, use death counters, like explained in Tux's tutorial.

The idea of resource sharing is to subtract everyone's minerals and add it to the a "pot" counter and then distribute the pot count among all players.
I've never done it myself so, I might not use the most efficient method, but here's what I'd do:
The adding to the pot is pretty straightforward:
Make a trigger for each value of 2^n for n = 0 ... 10 that subtracts 2^n minerals for the player if he has at least 2^n minerals and add the same amount to the pot.
Then use P8 (whose triggers fire only after all of P1-P7's triggers have run) to distribute the pot:
Make a trigger for each value of 2^n for n = 0 ... 13 and for each number of active players that adds 2^n minerals for the player force if the pot has least 2^n * [nr. of active players] minerals and subtract 2^n * [nr. of active players] the pot.

You could also create more triggers instead of just 0-10 / 0-13 for n when you think there's times that players own more than 2048 minerals / total pot size could become bigger than 16k.




Aug 17 2010, 12:55 am Roy Post #5

An artist's depiction of an Extended Unit Death

Quote from NudeRaider
Don't use custom score, use death counters, like explained in Tux's tutorial.

The idea of resource sharing is to subtract everyone's minerals and add it to the a "pot" counter and then distribute the pot count among all players.
I've never done it myself so, I might not use the most efficient method, but here's what I'd do:
The adding to the pot is pretty straightforward:
Make a trigger for each value of 2^n for n = 0 ... 10 that subtracts 2^n minerals for the player if he has at least 2^n minerals and add the same amount to the pot.
Then use P8 (whose triggers fire only after all of P1-P7's triggers have run) to distribute the pot:
Make a trigger for each value of 2^n for n = 0 ... 13 and for each number of active players that adds 2^n minerals for the player force if the pot has least 2^n * [nr. of active players] minerals and subtract 2^n * [nr. of active players] the pot.

You could also create more triggers instead of just 0-10 / 0-13 for n when you think there's times that players own more than 2048 minerals / total pot size could become bigger than 16k.
It doesn't sound like you're considering when a player spends resources, unless I'm reading that incorrectly. I believe you would need a second death counter (or reuse the first one) to check the difference for when a player's resources are smaller than the pot (i.e. they spent the resources). Based on whether the difference from the original pot value is positive or negative would determine how big the pot should be on the next trigger cycle.

... Unless the pot is intended to remain completely virtual and not affect the players' actual minerals/gas, which would be rather pointless.




Aug 17 2010, 1:05 am NudeRaider Post #6

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

All minerals of all players go into the pot and then are distributed evenly among the players. When someone spent their minerals this money won't go into the pot.
Keep in mind everything is done in a single trigger loop thanks to binary count-offs.




Aug 17 2010, 1:06 am CecilSunkure Post #7



Quote from Warlord_Master
I am sure this question has been asked and answered before but I am unable to find any tutorial for resource sharing on staredit, sen wiki or yahoo with keywords Binary Countoff, Shared Resource, Resource Sharing.
I Found a Tutorial by Tuxedo Templar for Binary Countoff but I dont know how to apply that to resource sharing
There are multiple different ways to do this. One would be using the minerals as the actual data to manipulate, and the other is to use death counts to store the amount of minerals.

Here is the basic rundown assuming you understand how to use binary countoffs to transfer data types:

You have a singular deathcount that will represent the minerals: DC1. Using a binary countoff, transfer DC1 into the following: Player1Mins; Player2Mins2; Player3Mins (you can have more than three players if you wish); DCReturn. Now transfer DCReturn back into DC1. At the beginning of each trigger cycle you need to set the players' minerals back to 0 so that you can constantly update the players' minerals using binary countoffs.

In order for players to actually spend the minerals you will have to compare the amount of minerals each player has at the end of the trigger cycle to the amount of deaths in DC1. You can do this with a binary countoff that subtracts units from each datatype until one reaches 0. When one is zero (in this system only the minerals should be 0 ever), you can tell how much was spent by the amount left over in DC1. I suggest making a deathcount containing the amount in DC1 for each player so that you can compare the amount in DC1 to the player's minerals without directly messing with DC1.

Once you have your remainder of DC1, you do whatever you like with it within your triggers, and you can use it to detect when the player spent any amount of minerals. I would probably use this remainder to set the rest of the player's minerals lower by the amount remaining. You can do this with yet another binary countoff that subtracts DC1 and the remainder until the remainder is 0. Your next trigger cycle would then distribute the new amount of DC1 into all the other player's minerals.

Possible bugs
  • If two players buy something within a trigger cycle then the team could spend more money than they have.
    • Fix: If remainder of DC1 is 0 then undo any purchase (though this means two people can't spend enough money to where they each spend exactly half).

I suggest just ignoring this possible bug.

Note: I didn't take into consideration of mining minerals. rockz's map should be better than what I just described anyways :(

Post has been edited 3 time(s), last time on Aug 17 2010, 1:36 am by CecilSunkure.



None.

Aug 17 2010, 1:24 am rockz Post #8

ᴄʜᴇᴇsᴇ ɪᴛ!

http://www.staredit.net/?file=2292
With the wiki hard to use, I couldn't find the old article. If you can find a static copy of maplantis, you can read all about this map in the thread.

The basic concept is 4 triggers. The first trigger makes a copy of your minerals. The second trigger determines if you gained minerals. The third determines if you lost minerals. The final restores your minerals.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

Aug 17 2010, 3:07 am payne Post #9

:payne:

Quote from rockz
http://www.staredit.net/?file=2292
With the wiki hard to use, I couldn't find the old article. If you can find a static copy of maplantis, you can read all about this map in the thread.

The basic concept is 4 triggers. The first trigger makes a copy of your minerals. The second trigger determines if you gained minerals. The third determines if you lost minerals. The final restores your minerals.
http://www.staredit.net/?p=oldwiki

And sorry for my sucky proposition. It looks like I've lost some of my sc1 mapping skills. ;o



None.

Aug 17 2010, 6:52 am Vrael Post #10



Just to address Cecil's possible bug, buying something "within a trigger cycle" isn't possible. All triggers execute sequentially according to player number instantaneously as far as the game is concerned. Any non-trigger actions will not occur during the trigger cycle.

Also, what is wrong with Nude's method? Resource accumulation happens so often in a normal game (where mining is involved) that there's almost no point to check whether minerals have increased/decreased. Simply keeping the pot distributed Nude's way should work fine. The only real problem I can see would be the redistribution, since 1/4th, 1/3rd, 1/2 or 100% would have to be redistributed to the players depending on how many are in-game, and even that only really amounts to copying a bunch of triggers.



None.

Aug 17 2010, 9:07 am Lanthanide Post #11



From what I can see, Nude's method does have a problem which Roy mentioned. It's best shown with an example:
instant 1, player 1 mines 200 minerals, p2-4 have none. After P8 trigger runs, P1-4 will now have 50 minerals each.

Player 1 and player 2 spend their 50 minerals, so now only 3 and 4 have 50 minerals each. But at the end of the next trigger cycle, the resources are divided up again, and now each player has 25 minerals, even though it was P1 and P2 that spent their minerals.


Also payne's suggestion for "detecting when a building is created" is actually VERY difficult to get to work flawlessly, especially if you have to deal with multiple buildings of the same type being built at once, and non-instant build times. I have a limited version of this working in my DSNight Fixed map, where when you select 2x mineral mode, the special buildings all cost 2x as much as the listed price. This is done by detecting when a player has started to build the special, and deducting the appropriate amount of $$ from them (or destroying the building if they don't have enough) - it also handles the case where a building is cancelled.



None.

Aug 17 2010, 9:52 am CecilSunkure Post #12



Quote from Vrael
Just to address Cecil's possible bug, buying something "within a trigger cycle" isn't possible. All triggers execute sequentially according to player number instantaneously as far as the game is concerned. Any non-trigger actions will not occur during the trigger cycle.
DCs fire once every two frames. If two players spend money within those two frames, then the bug might occur.



None.

Aug 17 2010, 10:55 am Lanthanide Post #13



What you really mean, Cecil, is "between trigger cycles", not "within". Vrael is correct in that triggers are essentially run instantaneously. But if you have coded your triggers such that the calculations for the current trigger run depend on the results from the previous run, then if the players have acted since the previous trigger run, you could end up with bad results.



None.

Aug 17 2010, 3:05 pm NudeRaider Post #14

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Quote from Lanthanide
From what I can see, Nude's method does have a problem which Roy mentioned. It's best shown with an example:
instant 1, player 1 mines 200 minerals, p2-4 have none. After P8 trigger runs, P1-4 will now have 50 minerals each.

Player 1 and player 2 spend their 50 minerals, so now only 3 and 4 have 50 minerals each. But at the end of the next trigger cycle, the resources are divided up again, and now each player has 25 minerals, even though it was P1 and P2 that spent their minerals.
Isn't that the idea of shared minerals? Everyone has always the same mineral count.
I think what you're aiming at (and maybe even warlord_master) is shared income, where players share the resources they gather, but not the resources they spend.
My method is clearly not meant for "income sharing".




Aug 17 2010, 7:32 pm CecilSunkure Post #15



Quote from CecilSunkure
...

Note: I didn't take into consideration of mining minerals. rockz's map should be better than what I just described anyways :(

You can use the same method of comparison I described above with DC1 and each player's minerals at the beginning of the trigger cycle, and use the difference to determine whether minerals were gained or lost, and adjust the "pot" (DC1) accordingly. I suggest doing this instead of the comparison near the end, like I previously described.

What I described would be a fully functional shared resource pot that would allow for spending of minerals, and for income of minerals.

Full description:
You have a singular deathcount that will represent the minerals: DC1. First, use a binary counter to compare DC1 to the players' current minerals, for each player. You do this by using a binary counter that subtracts from each data type until one reaches zero. Once one reaches zero, you can use the difference in one or the other to determine whether or not minerals were lost or gained. I suggest spreading DC1 into five different deathcounts (one for each player), and then returning DC1 back to it's state with the fifth. You can then use these five counts to compare directly with each player's minerals. For more info on how to do to this specifically, just ask and I'll explain.

Next, using a binary countoff, transfer DC1 into the following: Player1Mins; Player2Mins2; Player3Mins (you can have more than three players if you wish); DCReturn. Now transfer DCReturn back into DC1. Right before doing this you need to set the players' minerals back to 0 so that you can constantly update the players' minerals using binary countoffs, which would be using addition in this particular part.

Possible bugs
  • None




None.

Aug 17 2010, 10:02 pm Cinolt Post #16



This map has shared resources for one force regardless of player number using the absolute least amount of triggers possible (128). It's for both resources, independent of player availability, uses 3 DC's and has no resource limit. Copy and pastable to any map given the DC's aren't interfered with. The only bug I can think of is what Cecil mentioned with multiple players spending resources at the same time in a rare circumstance that enables them to spend more than they should.

Shared income would require less triggers, I'll make one on request.

Attachments:
res share.scx
Hits: 3 Size: 59.39kb
res share.protrg
Hits: 3 Size: 27.94kb

Post has been edited 2 time(s), last time on Aug 17 2010, 10:09 pm by yoonkwun.



None.

Mar 23 2015, 4:49 pm BumpelSnake Post #17



Quote from Cinolt
This map has shared resources for one force regardless of player number using the absolute least amount of triggers possible (128). It's for both resources, independent of player availability, uses 3 DC's and has no resource limit. Copy and pastable to any map given the DC's aren't interfered with. The only bug I can think of is what Cecil mentioned with multiple players spending resources at the same time in a rare circumstance that enables them to spend more than they should.

Shared income would require less triggers, I'll make one on request.
To clarify things: in the case that more than one player buys something, each player gets his re-calculation separately, so the team will only be able to spend more money than "they have", if the cost of the summed up bought things in that very trigger cycle is greater than the team's account has. Am I right in this assumption?



None.

Mar 27 2015, 12:15 am rockz Post #18

ᴄʜᴇᴇsᴇ ɪᴛ!

Correct. If you use hyper triggers, then players would have to buy everything within 2 frames. If you don't, you'd have much longer. Also, minerals won't go into the negative, so if 2 players buy the same thing, it will drop down to 0 if they can't fund it entirely. If they can fund it entirely, no issues.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

Mar 27 2015, 5:25 am NudeRaider Post #19

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

If they were so determined they could detect that situation and save the amount of debt and keep trying to subtract until the debt is paid. Interest-free loan! ^^




Mar 27 2015, 5:38 am Wormer Post #20



It's possible to partically fix the problem of simultanious purchase with actually having "negative" number of minerals stored in DC1. Just let it zero level for instance be 2^16. Everything less than 2^16 should be considered internally by the distribution subsystem as "negative" amount and will transfer to player's minerals as zero. This way, at least even if you managed to spend more than possible you have to make up for it.

P.S. Sorry, Nude, you're the first :P I didn't see your post.



Some.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[07:33 pm]
KrayZee -- RIVE
RIVE shouted: Also, what was the point of choosing between Mia or Zoe when there's no pay-off?
There is payoff since there are different endings.
[04:10 pm]
RIVE -- CV is stupid hard. (Those red hunters..) If that was remade, Capcom would water it down too much.
[04:08 pm]
RIVE -- Also, what was the point of choosing between Mia or Zoe when there's no pay-off?
[04:08 pm]
RIVE -- RE5 felt like a chore. 7's alright except the Eveline fight is a blander rehashed of Carla from 6 which is sad bc 6 was terrible.
[04:00 pm]
O)FaRTy1billion[MM] -- Zycorax
Zycorax shouted: Their names makes absolutely no sense.
1, 360, 1, 10. what's not to follow?
[02:22 pm]
Dem0n -- RE7 was actually fun AF tho. Pretty spooky too.
[12:48 pm]
Zycorax -- Their names makes absolutely no sense.
[10:50 am]
KrayZee -- Xbox Series X. Microsoft is just weird at naming things. They’re good at code names until they reveal the real names.
[10:46 am]
KrayZee -- The thing with RE6 is that they rushed it. Instead of typical delays, they released it sooner than the original date.
[09:35 am]
Wing Zero -- Yeah RE5 also wasn't as scary as the others but that's part of why I liked it. I'm horrible into jump scares.
Please log in to shout.


Members Online: Roy, irelka48266, UEDCommander, GGmano