adonthell-devel
[Top][All Lists]
Advanced

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

[Adonthell-devel] Re: Code improvements and next steps ...


From: Kai Sterker
Subject: [Adonthell-devel] Re: Code improvements and next steps ...
Date: Sun, 18 Jul 2010 11:32:51 +0200

On Thu, Jul 15, 2010 at 10:15 PM, Kai Sterker <address@hidden> wrote:

While thinking about some of the implementation details, I was struck
by a thought that had escaped me so far. Maybe we do not only want to
comment on objects when we interact with them, but we may also want to
open/close doors, push or pull levers, light or douse torches and much
more.

So far, I assumed we might need a different class of object to
implement those actions, but we don't! All we need is the already
proposed Python script that implements the desired action. So
commenting on an object is really just a very special case of object
interaction, handled by its own special script. A simple generic
implementation will work for displaying a predefined sentence, while
custom scripts could be used for dynamic comments, like displaying the
actual in-game time when looking at a clock.

And the interesting bit, that's the way the (map) action events worked
in v0.3. The difference is that those where tied to specific
locations, whereas now we can tie them to objects or locations.

All the rest below still holds mostly true, once you replace "comment"
with "action".

The interesting thing is that assigning an object action script looks
pretty much like assigning a character schedule, so there's even some
consistency across characters and scenery objects (and reusable code
in the map editor too!).


Anyway, enough talk, time to start coding ...

Kai

> After studying the code for a while, I've come to some conclusions on
> how to handle comments:
>
> 1. There are two places where we could store comments and my idea
> would be to use both. Per-Entity comments can be stored in
> world::entity. Each instance of such an entity on the map will have
> the same comment. It could be edited in mapedit by picking an entity
> from the entity list. The second place is world::chunk_info, which
> would allow unique comments by entity location. Again, those comments
> would be set in mapedit by editing an object already placed on the
> map.
>
> 2. Handling of comments must happen in schedules/char/action.py. In
> the case that no character or item was found to interact with, we'll
> search for scenery objects and get a list of chunk_info instances. And
> here's the clou: If we use a hypothetical method
> chunk_info::get_comment() we can either get the specific comment for
> that location or chunk_info can delegate the call to the entity it
> contains and we can get the global entity comment. Exactly what we
> would want.
>
> 3. The rest of the details are then encapsulated by the comment class.
> It will get the character triggering the comment (usually the player)
> and the object to comment on. In case we have a text-only comment, it
> can be popped up next to the character. If it's a dynamic comment
> produced by a python call, we pass in the character and object as
> arguments to that call. That will give us enough data to create
> comments depending on character or object state.
>
> 4. Some additional thoughts: chunk_info and entity data is all kept in
> the respective map file, so comments are all in one place (and
> editable in one place too). The caveat is that only scenery objects
> can have comments. But that should be okay, since we only have one
> action button and that will perform "talk" with characters, "pick up"
> with items and "look" at scenery objects. (True items can have a
> comprehensive description in the inventory view.)
>
> 5. In the map editor, "comments" would be an extra tab of the edit
> entity dialog. It would show the global entity comment and a list of
> location specific comments. So all data for one entity is accessible
> in one location again, but to create a new location specific comment
> you would have to select that location on the map first.
>
>
> That should give us anything we had in v0.3 and much more :-). So if
> nobody has suggestions for a better design, I'll start with the
> implementation on the weekend.
>
> Kai
>



reply via email to

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