Spawning

by pushplay on 06/28/2003 06:21, 33 messages, last message: 07/11/2003 00:32, 6598 views, last view: 05/04/2024 18:47

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   

#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

#21: Re: ..

by pushplay on 07/03/2003 05:15, refers to #20

Do you mean you like Cube's current system, or Quad's current system?

reply to this message

#22: Re: so...

by Aardappel on 07/03/2003 09:49, refers to #19

Duplicating state is one of the worst offenses in programming. if you fail to set playerspawnsuptodate after every bit of code that potentially changes the ents[] array, or you get weird results. You use a LOT of code for a very simple feature, and introduce unneeded global state. This is really the worst possible solution imaginable.

There is no pattern left to my solution if you make the 5 a bit bigger (10 or 15). It is not wasteful if it is not noticable. Experiment setting the random number to very high figures to see when you will start to notice a framerate hiccup at spawn... I bet its well over 10000 or so.

You have over a billion cycles of computation time per second... if you can use it to simplify code without anything slowing down, you should.

reply to this message

#23: Re: so...

by Thalion on 07/03/2003 10:52, refers to #22

Yes, I agree. Actually, I've came to the same scheme myself, although I am still worried about perfomance. But tests will show. Just one note though: I think that N should be the number of playerstarts on the map (so that each one gets an equal chance).

reply to this message

#24: Re: so...

by pushplay on 07/04/2003 00:57, refers to #22

It's not a lot of code but I never said it was pretty. I'm well aware of the dangers of duplicating state, but the sections that change the ents seem to be few and no one else has to deal with my code anyways. So I'd rather do just a little more work on my part to prevent that hiccup.

reply to this message

#25: Aw Heck

by pushplay on 07/04/2003 02:21

Here's what I can do...

I found out that I can build the vector every spawn and still not hiccup the game in dmsp. The idea of stepping through at random increments just seems ugly to me.

reply to this message

#26: ..

by Pathegreat on 07/04/2003 04:50

pushplay's right, i dont realy like it in perfect order(i know last post i was aganst it but i think i was thinking about it another way) it showuld be randomized threw the playerstarts not perfectly numbered threw them all in order thats dumb as a drone ant! it should be random not like it is now!

reply to this message

#27: temporary array with spawn points only

by D.plomat on 07/04/2003 15:48

...was my first though, it's the most CPU-efficient that can be done while still fully contained, 5-6 lines in spawnplayer() and 0 line outside, but depending on what weight you give to small code vs brute performance, you'll prefer this, or Aard's solution, the only downside is that it wastes some CPU-cycles, but it's negligible, and as long as there are no side effects in spawnplayer() it's not a problem. Plus it looks cool, and trying to reach functionnality with the least amount of code is fun.
... and performance is not a deal when respawning, we could have even a 1/4 sec before respawning, to avoid being still clicking when dead and respawn immediately, without having time to take a breathe nor reading the scores :(

So i'll make my modifiaction just for the fun of coding on my own customised Cube, and let Aard implement or not something in the next version, maybe there is some other best overall method that none of us thought of. So...don't miss out the next episode in next version of clientgame.cpp? ;)

reply to this message

#28: Re: temporary array with spawn points only

by pushplay on 07/05/2003 03:29, refers to #27

If vectors were time stamped on modification I could avoid the recalculation of the array and it would be uber clean. But I'm sure as hell not rewriting the vector!

reply to this message

#29: Re: temporary array with spawn points only

by D.plomat on 07/05/2003 18:17, refers to #28

Right, your method was the most CPU-efficient one, but as stated by Aard, it would make it very sensible to others modifications. Of course tracking modifications on the vector itself would combine the efficiency of your method with more contained location in source code. Still, it's more complicated. Also, my method of temporary array of spawn points is a bit overkill. Maybe this could be adressed by not using a temporary array of entities, but let's say an int array containing the indexes of all spawn points. Moreover, we could have a function GetEntsOfType() to return this kind of thing for every type of entity. Anyway, Aard is obviously the one who knows the best his code ;) so he'll probably find a very cool way of implementing this.

reply to this message

#30: Re: temporary array with spawn points only

by D.plomat on 07/05/2003 18:33, refers to #28

Well, looking back to your code, your buildplayerspawn / getplayerspawn is somewhat like what i was planning to do, it's just the 'uptodate' flag that adds extra-complexity, if you call getplayerspawn in spawnplayer, and always buildplayerspawn, it's still very efficient, perfect rnd on all points, and you can then contain it. moreover, the playerspawn array could be declared/built/destructed in spawnplayer, and then your code is 100% contained, and doesn't have the downside that made Aard not approve it.
It's still very efficient, could be more, but not wasteful. As this function doesn't need to be very fast, it's not a problem, so it can be used instead of Aard's method if you don't want it to be CPU-wasteful.

reply to this message

#31: respawn

by yarrgh on 07/10/2003 19:47

YOU MIGHT SPAWN INTO A WALL!

reply to this message

#32: hee

by yarrgh on 07/10/2003 19:50

or you could just place a whole bunch of
player starts. i don't know what im talking about. just play a bigger level that takes a long to to get around in.

reply to this message

#33: Re: hee

by D.plomat on 07/11/2003 00:32, refers to #32

The problem is that is that it must be usable on every map, and the mapper don't have to care about this, only defining places where it's good to spawn. so, just random choosing a spawnpoint already defined by the mapper is a solution, and won't overly bloat the code. A whole bunch of spawn points can still be learned, unless there's really too much... in which case it isn't very elegant, and... a bit annoying for the mapper ;)

reply to this message

   Board Index