[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Pathfinding terrain costs, thoughts and changes

From: Kai Sterker
Subject: [Adonthell-devel] Pathfinding terrain costs, thoughts and changes
Date: Sat, 22 Aug 2009 12:41:59 +0200

Frederico, all,

I did a bit of a rewrite of the speed setting part, as I think it did
not actually alter the velocity as it should have. I.e. there were two
calls to speed() that ignored the return value. I also moved the
terrain detection into moving::calculate_ground_pos. Since we're
already figuring out the tile below the character there, getting the
terrain type in additon practically comes for free. That way, speed()
only needs to do the character-specific calculation as the terrain is
already known.

With that change in place, I'm finally seeing the debug message "Base
Speed is 3.100000. Actual Speed is 3.100000. We're walking over Wood"
regularly (so I commented it).

And finally, I made a change to keep the speed constant while the
character is jumping. I don't think terrain should have any effects
while the character is not actually touching it. However, terrain will
affect how far a character can jump.

So much for the changes, now on to the thoughts.

As I had avoided to come up with a link between rpg and world, you
really forced me to think it through :-). And I have arrived at a
different solution. However, I did not change anything just yet. I'd
rather present my thoughts for discussion first.

>From a technical perspective, relying on inlined code to avoid
circular dependencies between the rpg and world module is dangerous.
Ultimately, it's the compiler that decides to inline code or not, so
things might break in the future or with different optimization

So if we'd have to decide on a unidirectional dependency between rpg
and world, I would feel that world should have access to rpg but not
the other way round. If you think of it in terms of a model-view
relationship, then rpg is the model and world is the view that reads
and possibly alters the model. But the model should not have to care
about (or even try to directly influence) the view.

The only point where the model currently accesses the view is for the
base speed. And I guess, base speed should really be part of the model
(and not the view). It's meant to be character specific (so an old guy
would move slowly than a young guy, creatures faster than characters,
etc). As such it does belong to the model (and it's existance on view
side comes partly from not thinking about the issue. Sorry.). So in
reality, there should be no need to access the view from the model.
The model can make changes to itself (via schedule scripts or through
player interaction) and the view will pick these up from the model and
act accordingly.

One further interaction between view and model would be falling, which
should eventually cause damage to the character, based on some rules
that are outside of the views scope. The solution is for the view to
tell the model that it just dropped down a distance of <x> units. The
model can then handle this based on the rule implementation, update
the model state, etc.. And next time the view renders the character,
it might be lying dead on the ground. But again, it's the view that
needs access to the model, not the other way round.

So as a conclusion, rpg should be linked into world, the opposite of
what we have now.

Does that hold up? Or did I overlook something? Suggestions?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]