On Thu, 15 Nov 2007 15:03:31 -0800
"G33K" <[EMAIL PROTECTED]> wrote:
> New thread: too many entangled definitions in the code. I fear it'll
> get hard to maintain these once someone tries to code a real game in
> ScummC.
>
> It really bugs me that you can't define a room view and an inventory
> view within a single object. I'm currently trying to eliminate
> redundant code, so I stripped the Icon verbs from all objects. For
> the time being that means you can't pick up non-inventory items. I
> think it will be possible to code a global solution based on your
> Pickable class though. Luckily, in real adventures the number of
> straightforward pickable objects is limited, as they don't make very
> interesting puzzles. ;-)
Icons must be separate objects. You wont be able to get around this one.
Scumm was designed to run on hw with extremly limited memory and
loading the whole game in memory was not pratical. Hence the engine
load the rooms as needed and release them from memory when you leave
them. But you can't practically open up to a dozen of rooms just for
some icons. In the extreme case of a floppy version they might be on
differents disk, and even on modern hw that would waste lot of
ressources. What you should do instead is use a few rooms to store the
objects (and scripts) you will need all the time and lock them in
memory.
Now I agree that having code related to the same objects split in
several places is not so nice. The link could be the other way around,
with the icon object reporting the real object it is linked to. But
then the whole room would still need to be locked. Or with a separate
script from the object's room. The script could then be locked without
locking the whole room. It would be better but it would still mean the
engine need to open many room at once when loading a game.
On the other hand, in most case different reaction from the actor will
be needed when the object is in the room and when it is in the
inventory. But if you really want to put the code together you can
still put everything in the inventory object and use it for the room
object.
> Much worse is that you seemingly need to wrap actors in objects to
> define verbs on them, and to have objects point to actors in order to
> get an animation, or even just a transparent background and
> z-ordering!
I think I don't get what you mean exactly. I used objects to hold the
actor code because it allowed to handle actors much like the
normal objects. You can defintly look at some other way to do this.
Now for the animations I really don't get what you mean. Just add some
custom animations to your costume if you need the actor to do other
things than walking or standing there.
z-ordering is not very intuitive. Here is how it work: each box belong
to a layer, when an actor is in a box the mask from the corresponding
layer (and only this layer) is used when drawing.
So if you have a scene like this, where the actor should be able to
walk in front of the object, between or behind:
+--------------+
---------| |--------------------/
+------------+ | Box 3 /
| | | /
--| |--------+-----------------/
| | Box 2 /
--+------------+------------------------/
Box 1 /
--------------------------------------/
The mask for box 2 is obviously:
##############
##############
##############
##############
##############
but for box 3 you need both objects:
################
################
#######################
#######################
#######################
##############
##############
I hope this clear up things a bit :)
Albeu
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
