adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] Character design


From: Kai Sterker
Subject: Re: [Adonthell-devel] Character design
Date: Fri, 7 Mar 2003 21:22:06 +0100

On Fri, 07 Mar 2003 20:56:22 +0100 Alexandre Courbot wrote:

> The way graphics would be handled by the engine is quite simple, I
> think. The engine itself would not handle graphics as it does in 0.3,
> but instead each character would have a string describing which
> graphic model to use and maybe also some parameters for the
> instanciation of this model (key color - which could be used for
> dialogs also, etc...). It'd then be up to the client/renderer part to
> display them properly, knowing that each model has a set of "states"
> which are set up by the engine (would be "walking", "running", ... for
> characters. Good thing about that is that some characters could have
> states others doesn't have)

That's good. What could actually be done is also seperating images and
animations. That way, even if several characters or creatures (think
about animals and such) have the same graphics, the actual images need
to be loaded only once. Same would work for other mapobjects too.

Of course, each object would need its own animation instance, as they
could be in different states. 
 

> As for the rest of your mail:
> As we decided, the C++ engine should handle non-game related stuff.
> Therefore, things like map handling and an interface to control
> characters have to belong to it. But I think that's all. All the rest
> (characters attribute and so on) could be done in Python. Don't forget
> that all the map stuff if only a small part of what a character is. A
> map_character class would just be a placeable object which can nove
> and gets controlled by a specific interface. The actual character
> class would create such an object when needed. I think it's important
> to get these two well separated, I mean no more inheritance or things
> like that(references would be necessary though). That way, a character
> could exist without necessarily having to be on a map. This could be
> useful.

Yeah, I thought so as well. I imagine that no lowlevel character data
would be available on client side. Just the graphics part. Then there'd
be the map related, non-graphical data on server side (written in C++
for performance).

The client would just display what it gets, so I don't think it needs to
know which character data is associated with a certain graphics.
Obviously, the less it knows the better.

However, on server side, the map character part needs to know which
lowlevel data belongs to it. No more than that is required, methinks.
So a pointer would be enough, and much easier to handle than actual
inheritance.

Kai




reply via email to

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