I'm making daily back-ups of the source files, which is something I've never done before... it's making me a little bit braver about making massive alterations like changing tick_lag. I know the further I get in the project, the more things I'll have to change if I alter tick_lag later and the more likely there will be something I don't think of that "breaks" because of the change.
I'm trying things out with a tick_lag of 0.5 to try to get extra degrees of difference between movement rates, without having any characters moving as fast as 10 squares a second under their own power. If projectiles and effects can move twice as fast as that, it's an added bonus.
I know having a lower-than-default tick_lag can bog down the processor, but the fact that the game will never be populated by more monsters than are needed for the current battles makes me more confident in that area than I would have been in my older gMUD projects. I can drastically streamline the AI of the monsters, too, compared to when they might have spent 90% of their lives looking for someone to fight.
Unexpected pitfalls: I didn't realize that world.time counts in 10ths of a second regardless... I figured it was just counting ticks, though the documentation does clarify this. I added a tick_counter to the world to give me something to compare to for elapsed time. Conversely, animation frame durations seem to be in ticks, even though the interface labels them tenths of a second... fortunately there aren't many animations in the game. A lot of the ones there are are flash effects, and I don't mind them being over more quickly while still having the same recognizable effects.
Aug 16 2011, 6:01 am
|
|
AlexandraErin
 |
Sleep and spawn go by tenths of a second? That's good to know... not what I would have expected. *checks reference* Rounded to nearest whole number of ticks... so if I want something to have a more precise or shorter delay, I guess I'd need to sleep for 0.5.
|
Yeah, for most things I want to keep the delay the same in real time, but there will be a few cases where I want something to be moving with that extra speed.
| |
In Tanx I've got a tick_lag of 0.25, around 15-20 mobs all with some hefty AI, and they're all doing their own pathfinding. The game still runs fairly well (even on a single core cpu) )so I'm thinking 0.5 will be just fine for this one.
| |
Yes, also a handy calculation for getting the frames per second (FPS) is doing 10 / tick_lag. Inversely, you can set the frames per second by doing tick_lag = 10 / <frames per second>
Could be useful. You could also modify sleep, etc. to work off of ticks instead of tenths of a seconds. e.g. sleep(ticks * world.tick_lag) | |
I just have TICKS #defined as "* 0.5" (I already habitually do this with SECONDS and MINUTES and sometimes HOURS when I start a new game project) so I can sleep(x TICKS) if I need to.
| |
I hope you #define TICKS as "* tick_lag," since tick_lag can be changed during run-time.
Also, that is pretty handy. | |
I would always just do:
#define SECOND 10 #define MINUTE 60*SECOND #define HOUR 60*MINUTE that's just me though, I hate having to do math in my head. | |
Bravo1: The only reason I'm concerned is that this is meant to be multiplayer. Even three or four players involved in separate battles could easily have 15-20 enemies going at once, and I expect to have more traffic than the usual BYOND game... back in the day it wasn't unheard of for me to get scores of players logged on to my games at a time, and that was before I had an internet following. :P
But the AI can seriously be bare bones because of the way battles work. Like, I'm reworking target acquisition from being something that each enemy mob has to do to being something handled on the player side... like, if there's one player on the battlefield, there is no sense in having each enemy loop through their field of vision to see who they're going to go after, right? In group battles I can have enemies be distributed proportionally based on the "priority" of each character (e.g.,"tanks" drawing more) and then they only switch targets if something directly provokes them. | |
@Complex Robot:
Nope. While I do have tick_lag ratcheting "up" from 1 to 0.5 after the world start-up and housekeeping stuff is finished, I don't see the point in making the value vary. When I say "sleep (1 TICKS), what I really want is "sleep (1/20th of a second)". It shouldn't even come up during the start-up phase, but if it does the difference between the 0.5 that's being called for and the 1 that it actually executes on won't matter. | |
I see.
That makes sense. | |
Lowering the tick_lag increases the potential CPU usage, not the actual CPU usage. Going from 1 to 0.5 means you can have events happen 20 times per second, it doesn't mean they will happen that often. It sounds like you're keeping most events at the same rate (in terms of actions per second) and are just using the increased ticks for increased resolution. This should have no impact on CPU usage.
The only concern is on the client. I'm not sure why this is the case, but even with fairly simple 2D displays Dream Seeker can struggle to redraw the screen at the desired rate. When games run at the default 10 frames per second it's hard to notice because even slow computers with no graphics hardware can (usually) keep up with that, but at 20 fps some users may have problems. | |