Archived from groups: rec.games.roguelike.development (
More info?)
Jim Strathmeyer wrote:
> Krice <paulkp@mbnet.fi> wrote:
> > What is a consistant timing?
>
> I just meant to express that time also passes on the maps/levels that
> you aren't on. The maps are actually on a priority queue, the same
way
> that creatures on a map are in a priority queue. So when a player
goes
> to another level, time still passes on the previous level, and
monsters
> can even go up and down stairs to go after or escape from the player.
It
> works well for me right now because my game is small, and will
probably
> stay small. As the game gets bigger than a simple dungeon, I will
have
> to find some way to deal with the computational complexity involved.
> (Threading, or just faking things away from the player, ie what's the
> result when the group of 20 orcs ambushes 30 travelers, but then 4
royal
> knights happen to pass by, instead of doing it turn for turn.)
>
> Also, some people mentioned using old machines to test the efficiency
of
> their games. Doesn't anybody use profiling? I implemented profiling
when
> I took a Computer Gaming class and don't remember it being very hard,
> and also remember it being very helpful/cool. Profiling is definitely
> done in all modern games, and seems like a much better alternative to
> just trying your game on an old CPU, though I've never seen an
roguelike
> 'article' about it anywhere.
I did quite a bit of profiling for Guild (using the inbuilt tool in
Visual Studio), it beats the hell out of just guessing which part of
your program is slow. There is a bit of an initial learning curve which
can be offputting, but it's worth it (if your game runs slowly).
For me the big time costs were AI (especially some parts of the AI: for
example the code for scared monsters running away turned out to be much
more time-consuming than that for aggressive monsters attacking),
pathfinding, LOS (although this got better when I stopped recalculating
the LOS of every group of monsters in every turn), and certain lookups
that I did very frequently. This was very helpful in directing my
optimising efforts (otherwise I might have wasted time rewriting code
which looked inefficient but didn't actually waste much run time).
It also led me to simplifying some parts of the functionality - for
instance, measuring the loudness of a sound in terms of the crow-flies
distance from noise to hearer, rather than the shortest clear path
through the corridors.
I never figured out, though, how to subtract the time spent waiting for
keyboard input from the profile. There must be some way of doing it.
A.