Spawning

by pushplay on 06/28/2003 06:21, 33 messages, last message: 07/11/2003 00:32, 6610 views, last view: 05/17/2024 19:39

I was wondering if anybody has played with Cube's system for chosing a spawn point? The existing system is ok, and certainly quite flexible and reasonably fast, but the pattern is easy to spot.

Has anyone coded up a quality, less deterministic system? If not, does anyone wanna get together and think on this one?

   Board Index   

#1: ..

by Pathegreat on 06/29/2003 21:31

hmmmmmmmmmmmmm.......... it is a bit easy to catch the spawing points, but how do you fix it? like the only way i can think of is put like 1000 diffrent spawn points in every map! and thats about it

reply to this message

#2: things

by spentron-peanutbutter on 06/29/2003 22:14

Lots of spawn points is obvious... every game has this issue, right, or do you mean something else? Also can put spawns (I've done teleports) in the middle of a column to make the actual destination location more unpredictable, or put the spawns in seperated locations where other players can't see them immediately (hopefully also without convenient rocket targets nearby).

There is at least one map in normal server rotation with only a couple spawns I think, that isn't too good.

reply to this message

#3: Re: things

by pushplay on 06/30/2003 00:43, refers to #2

I'm talking about this from a coding perspective. In most maps the spawn points are defined in a sequence that follows a path around the map. The game currently spawns people around the map in that exact path. I'm wondering if there is some efficient way to be more random about it.

Thalion, I'm looking in your direction. ;)

reply to this message

#4: alternative implementation?

by D.plomat on 06/30/2003 09:08

Well, i think implementing a path in the engine itself would be contrary to minimalistic design, but i don't know if there's a limit on spawn points on a map. If not, maybe we could add a script in edit mode to draw lines or path of spawn points. then the harder part would be... to have most mappers really use it, maybe easier if this script makes it into Cube official distribution. Now... looks like i've got to learn a bit more the Cube script language, and mapping ;)

reply to this message

#5: Re: things

by Thalion on 06/30/2003 23:35, refers to #3

Yes, I remember this discussion.

To summarize what we have now (it seems that not everyone understands the issue), Cube chooses spawn points not randomly, but by a known - and very simple - algorithm (for details, see findentity() in world.cpp). This was especially easy to notice in duel matches, but now that everyone has the code, there's even no need to experiment. Thus, on open maps where most playerstarts are visible (e.g. tartech), if you've killed someone on respawn, you can tell exactly where he will spawn again, and aim there. Repeat as necessary. How bad this can be depends on the skill, as the trick requires rapid aiming... but knowing where the enemy is gives some quite serious advantage anyway.

CubeCTF suffers from the same problem currently, although the algorithm there is a bit different because of teamstarts. But it's nonethless easy to predict. This will change for sure, if you want to hear that. =)

reply to this message

#6: well

by pushplay on 07/01/2003 03:00

..

reply to this message

#7: oops

by pushplay on 07/01/2003 03:04, refers to #6

One thing I thought of was instead of having it start looking from where it left off last time, is to have it start looking from ents[rnd(ents.length())]. I'm thinking there must be some disadvantage to that, but I can't see it at the moment.

reply to this message

#8: Re: oops

by D.plomat on 07/01/2003 12:03, refers to #7

I think the problem with that would be, say you have this as the ents array:
*.type=PLAYERSTART; -.type!=PLAYERSTART (other entities)

--*---*--*-----*----------------*-
in this case, the last would be chosen ~50% times

or

--*---*--*-----*---*--------------
in this case it would be the first one

To avoid this, we could either sort the ents array to have the playerstart entities between two well-known position and chose rnd between them (not very good solution), or (more likely): in clientgame.cpp: spawnplayer(), use findentity to extract a temporary array of the spawnpoints, and rnd-chose in it.
If i've some time i may give it a try.

Other options include:
-There is already a random factor to spawn (somewere near the chosen spawnpoint) and avoid collision with other entity, when spawnplayer() calls entinmap(). we could increase the random factor and have it used at every spawn. This way the spawnpoints would not be exact points, but strategic areas on the map where you can safely respawn. would avoid direct-hit on respawn with rifle/CG, but if not combined with the random-chosing on plspawn you can still use spreading-dmg weapon, and still pre-aim with other. Worse problem would be if a spawn-point inside a small-room you could spawn outside of it, that would be strategically very different even if physically very close ;)
it's possible to adress this problem by checking the effective spawnpoint is in the LOS of the reference sp.pt, that would be more complex (i don't know yet this part of the code ;)

Chose -either rnd or deterministic- two adjacent spawn point, rnd an interpolation factor and spawn this factor between them. The problem would be that the map should be designed with this in mind, and it would suck on certain maps (with amount of triggers and/or sniping places, you'd easily respawn in the wrong place)

Random-location of the map, but it'd obviously suck.

In fact the algorythms themselves are nearly trivial, but it's finding the perfect blend of random-vs-mapper_control that would fit every kind of map/intensity of game that's not easy

beside of that, a very cool thing would be chosing the sp.point according to other players: respawning not too far nor too close of intense action -would require much fine-tuning-.

reply to this message

#9: ..

by pushplay on 07/01/2003 12:14

Right, density! I knew there was something wrong there. I don't want to move people far off from where the mapper intended them to spawn, or else they could end up stuck in a void that should have been closed off (or something similar).

I suppose I could build another vector of all playerspawns, and use a flag that would be set to indicate that the vector needs to be rebuilt. It lags the simplicity of the current spawning code, but the end result looks more attractive. As it currently stands everything I've done borders upon dirty hack. Any mode more complex than Aard's modes either has code all over the place, or requires a system far more elegant than I am capable of.

reply to this message

#10: Re: ..

by D.plomat on 07/01/2003 13:41, refers to #9

Well, for randow sp.pt selection, this could be done elegant, it would be ~5-6 lines of code more in spawnplayer() -in my TODO list for the weekend ;)-. For density, depending on what factors we take into account with which priorities, ideal game intensity, min dist of another ppl, max dist, not being right in LOS of a close player etc, this could be 20 to 50 lines, so would take more time to make a clean implementation, but still can be contained in spawnplayer(), or a unique function called by it.

reply to this message

#11: Re: .. the indelicately-named 'spawn-rape' problem

by Bascule on 07/01/2003 15:26, refers to #9

Forgive my complete igorance, here, but it seems that you are trying, between you, to spawn the player at random positions in the map, rather than choosing a pre-existing spawn point *at random*?

If a DM map has sufficent, well-placed playerstarts, I would have thought just choosing one at random would be sufficent.

I recall that this was a problem with the first quake release (that's Quake 1 for all you youngsters) that was fixed by random respawning.

Please go ahead and flame me if you feel it's justified or I've got the wrong end of the stick...

:)

reply to this message

#12: Re: .. the indelicately-named 'spawn-rape' problem

by D.plomat on 07/01/2003 16:25, refers to #11

Well, if you remember in my long post, the option of complete random start is totally excluded...
In fact we are trying to make spawning less predictable, so the point is finding the 'perfect blend' between deterministic and random, so to sum up we have many alternatives on 2 essential points:
-how much spawning must depend on spawn points, IMO spawning exactly on a spawnpoint is OK, cause there are enough well-placed sp.pt on maps (and that's less work to code ;)
-how do we choose the spawn points:
actual=sequence
other options=pure random, or function of other players.
So we may strictly respect spawnpoints, or eventually add a very little bit of random to them, but we won't ignore them cause they exist for a reason ;)

reply to this message

#13: so...

by D.plomat on 07/01/2003 16:30

we're talking on which existing spawnpoint to choose rather than where to spawn the player.

reply to this message

#14: Re: so...

by pushplay on 07/02/2003 04:23, refers to #13

Right. I'm not looking to create a grand scheme minimizing spawn-raping, it's my opinion that spawning right in front of someone is a fact of life and you need to learn how to deal with it. I just want to remove the obvious pattern.

reply to this message

#15: Re: so...

by D.plomat on 07/02/2003 10:55, refers to #14

the option of simplistic rnd-chose of an existing spawn point is what we want... that's cool cause that won't take too much time ;)

reply to this message

#16: Re: so...

by Aardappel on 07/02/2003 16:27, refers to #15

quickest way :)

loopi(rnd(5)) spawnplayer()

or something similar. Yes this is wasteful in cpu time but it is pretty much impossible to notice.

reply to this message

#17: Re: so...

by Thalion on 07/02/2003 16:44, refers to #16

It would be very possible to notice when playing an instagib duel against Insight on tartech =)

reply to this message

#18: Re: so...

by D.plomat on 07/02/2003 18:01, refers to #17

LOL ;D yes he is damn fast :)

...didn't think it was possible in 1 line without very-cryptic style... I'll have to practice more on small'n'clean C code ;)

reply to this message

#19: Re: so...

by pushplay on 07/03/2003 00:41, refers to #18

Not only is it kinda wasteful, but there's still something of a pattern left to it. Here's what I did (look at the html source for the tabbing intact version):

void buildplayerspawns() {
if (playerspawnsuptodate)
return;
playerspawns.clear();
for (int i=0; i<ents.length(); i++)
if(ents[i].type == PLAYERSTART)
playerspawns.push_back(i);
playerspawnsuptodate = true;
}

int getplayerspawn() {
buildplayerspawns();
if (playerspawns.size() == 0)
return -1;
return playerspawns[rnd(playerspawns.size())];
}

playerspawnsuptodate only needs to be set to false in a couple of places

reply to this message

#20: ..

by Pathegreat on 07/03/2003 02:31

i like the system its on, you choose where the people go, so the harder it is to find out where the people are spawing form just makes it that much better of a map, plus some maps there are places you dont want the player to start at

reply to this message

   Board Index