| 06-15-2004, 02:16 AM | #1 |
For a tower defence, you have 2 options for spawning really. What we call "Lag Free" and the normal method. Lag free is where we place all the spawnable units on the map during initialization and hide them. Then when the spawning occurs you just have to MOVE the units, not create them, which doesn't cause any lag. The downside to this is long loading time at the beginning. And the normal method as I'm sure any one of you who has played any TD, is you create the units at once, and order them. Creating units causes lag because you have to create a seperate variable for each one (yes each unit is a variable) and the upside is less load time during init. Please vote, as neither really matters to me, I can deal with a little lag, and I can also deal with longer load times. Please, no immature responses like "TD's suck" or "Not another tower defence" just vote, that's all I'm asking. |
| 06-15-2004, 02:23 AM | #2 |
1. Why does every unit need it's own variable? Just use an array. And setting up that array doesn't take very long. 2. It won't be as laggy if you put a small sleep inbetween each unit spawning. Do a normal (not polled) wait of 0 seconds. It still causes a delay but will prevent all the units from spawning en masse at once. And if you're worried about that being too slow -- use this method to spawn 1 level ahead of time, just hide the units until they're needed. |
| 06-15-2004, 02:31 AM | #3 |
I'm just saying, when you create a unit using unit -create it has to set a variable and a pointer to that unit when you create it. When you create them at at init (or having them on the map when you save) it doesnt need to create them, it will just reference them and move them. Still a small sleep messes up the group a little, and it just extends the lag over a longer amount of time. |
| 06-15-2004, 04:20 AM | #4 |
I say lag-free as you could have more players playing at once w/o worrying about lag. |
| 06-15-2004, 04:24 AM | #5 |
Maybe a it of both? Hhalf of the creeps are pre-placed and half created. Then yould probably not get lag ot excessive loading times. |
| 06-15-2004, 04:39 AM | #6 |
Too much work. If for each level you are moving half and spawning half you have to go through the trouble of coordinating them. If the first half of the levels are moved then the 2nd half will lag. Go all the way. |
| 06-15-2004, 04:39 AM | #7 |
Right now it's not lag free, it's the extended lag, meaning there is a 0.15 second wait before spawning the next 2 units (7 times) --only 1 player-- and it isnt noticable, but then again, im playing alone and I dont have eleventy billion towers. I'm still thinking 1 way or another. EDIT: Right now the loading time on my 1.8ghz 512 ram system takes about 30 seconds. |
| 06-15-2004, 04:40 AM | #8 |
Normal. I have never had that much lag, so no one really cares. The other could get messy. |
| 06-15-2004, 04:53 AM | #9 |
The thing is though, I want this to be as lag free as possible, I'm going through great extents to stop every memory leak I have, making sure to destroy unused triggers to free up memory and stuff. If a simple spawn trigger makes it lag.... kind of annoying |
| 06-15-2004, 04:54 AM | #10 |
Easy way not to have lag during spawn: Divide up spawns so that spawns are asynchronous (by .01 seconds) and divide up each spawning area so that only 6 units are spawned by .01 second delay. In my incomplete TD I have it set up so that each spawn (for the 4 sections of my map) is offset by .05 seconds, and then within each section I have groups of units created 3 at a time by .01 seconds. Result: I can spawn 296 units in less than a tenth of a second with no lag. So the lag-free method isn't the only lag free method, its just the easiest to think of method. Be smart with your GUI, and you will have FAR better results. Some other tips... Create an array of groups for spawns, and then use groups over and over rather than creating/destroying every round. Use region arrays for pathing with an integer array. I use 8 integer variables "AlphaCwp" "AlphaCWwp" "BetaCwp" for Clockwise/Counter-clockWise. Then, I set each to 0 at the beginning of the round, I have triggers set so: Unit enters region [First Waypoint region] Unit enters region [Second waypoint region] etc Then, I search my 104 region array combined with 4 regions which define Alpha/Beta/Delta/Gamma sectors. If its in Alpha, I check the unit group of the unit. If its 0 or 1, then it is Counter-clockwise, if it is 2 or 3, it is Clockwise. Then I parse my point array based on 13 * (Unit Group / 2) to find the correct starting index. That allows me to find the region the unit entered by doing a custom For Loop which ends when the region matches the Entered Region. Then, I can check if the unit group has visited the waypoint already by checking the variable integer for that unit group set (Clockwise/Counter-clockwise). If they haven't, then I set the next waypoint. Then I send them to the waypoint that is next. I have 13 waypoints per set of two monster spawns, I have 16 monster spawns. That makes 8 unique paths. And I have 8 "Army" spawns, which go the opposite direction (and in fact fight the monsters, its very cool) which have their own integer variables. I've succesfully tested multiple levels of my TD, as well. The reason I did my system this way is I wanted it to be difficult. And hoo-ee, this is difficult. For example, if your defense is weak and you let a unit through, and that unit gets to Waypoint 4, then all the units behind him who reach Waypoint 1 through 3 are going to go to Waypoint 5. Regardless of whether or not they've reached Waypoint 4. The monsters act as small groups of 3-7 which may all suddenly change direction towards the current waypoint. It all results in a sort of chain reaction where if one unit gets past your defenses, then its very likely that any mazes you make may be circumvented by the monsters. Smart buggers, they are. |
| 06-15-2004, 05:06 AM | #11 |
That isnt lag free, it will STILL have to create 296 variables in a 1/10th of a second still. It's just a normal method with it prolonged a little. Trust me, this is one thing I know 100%. |
| 06-15-2004, 05:14 AM | #12 | |
What are you talking about? I ran this for 6 rounds, the units were all properly destroyed and there was no lag at spawn creation at any time. The lag comes from not properly destroying the units, the groups, and from forcing the game to spawn a huge number of units within a very short amount of time. If I forced the game to spawn 296 units simultaneously, it would have to cache ALL of that before it allowed any more events to occur. That results in a huge lag which would doubtless pause the game for a small amount of time. Additionally, I made the units spawn invisibly, and then appear through special effects. Likewise, upon reaching the goal, I had them disappear and then be removed. It made the TD altogether cleaner and better looking, with far less latency on my computer. Whether you choose to believe me or not is irrelevant, what I have said is true. Edit: A quote from the main post. Quote:
|
| 06-15-2004, 04:55 PM | #13 |
Another thing I'm thinking of doing is "buffering" the spawns. After you kill the last levels units, over the 10 seconds you have, it will spawn all the units in a set location and hide them, then it will move them to the spawn location when it's time to start the level, then unhide. |
| 06-15-2004, 06:50 PM | #14 |
Also you cant test fully test lag by yourself. When you play on bnet there are other people who may not have powerful processors. |
| 06-15-2004, 11:58 PM | #15 | |
Quote:
How does this differ from quietly spawning them at tiny intervals, and issuing a group order? Whether you use .5 second delays or .05 second delays, the game doesn't care. As long as you do not overly tax the game by spawning many units very quickly, the game will continue giving visual output, and accepting user input. |
