I now added most of the animations now, using the new costume grammar.
Thanks a lot for implementing it so quickly, Alban! :-) The last commit
was actually for Zob, not Zif, copy-and-paste error, sorry.
It works, but it's not pretty. Here's a few questions about the
animations:
1. The definition of the animations is really cumbersome. You have to
define the pictures, then number them and then reference the numbers in
a third definition. The only way to know the right number is to put it
in the comments in the array definition, that's error-prone and verrrrry
inflexible in the case of a restructuring. I'd like to reference the
pictures directly in the anim definitions. Would that be possible? Like
this:
picture walk_E_ = {
glob = "../graphics/walk_E_??.bmp",
position = { 0, 0 }
};
...
anim walk = {
E = { [ walk_E_00, walk_E_01, walk_E_02 ] };
};
3. I think in the current costume grammar, the compiler accepts only
concurrent ranges of the limbs for animations. Can't you define random
arrays, like E={body([5,20,2,123,44])} ? Is this a Scumm limitation?
4. What's the limb definition actually good for? I've been an animator
in a former life, and I can't imagine anyone could animate a character's
limbs independently, they always move together and in context. Are there
any usage references from existing Scumm games? For example, I think
when the actors walk in DOTT, they can't talk at the same time, so that
means the entire body is just a single limb.
5. Defining and referencing the anims by offset is also error-prone and
not very readable. We could either use macros in header files for the
numbers, or even better, have the costumes export the anim names, as you
suggested earlier. Is this implemented? If not, how hard would that be?
6. Some animations need to be played at a different pace. I tried to
call setActorAnimSpeed(), but didn't notice significant changes, even
though I managed getting Zif to move a little faster than Zob in
general. Is there a maximum value for the speed?
Unfortunately, I might not have much time in December. I made a rough
TODO list, and I'd like to know which task might be most valuable to
you:
1. The only things that are still missing in terms of animation are the
UFO, and the grand finale. This should be a tedious but uncomplicated
task.
2. In terms of game logic, the dreadful triangle puzzle, the cube and
the gun handover are the only interactions crucial to complete the game
that are still missing. Does anyone know how to implement drag-and-drop?
I wasn't too keen about the puzzle, even in the original game.
3. For polishing the overall gameplay, we'll need to make the animation
smoother, change the default action results, add the red herring objects
to the office room, switch to the OpenQuest verb display, and of course
show the intro and end screens. Lots of fiddly work.
4. For polishing the code, we could increase readability by adding
macros for all numeral values like object states and the like, and also
add more comments.
5. I need to take a deeper look at the mouse scripts, and maybe
restructure them to make them easier understandable. A new feature that
I'd like to have for the grammar would be C-like function calls instead
of startScript(). This would simplify future refactorings. Would that be
possible, or should I try to use macros to achieve this?
6. We should also scan our implementations for good and bad practices,
and have a look at how things are implemented in existing Scumm games.
Where can I actually find that rd tool you're talking about?
If you would like to releasing a playable alpha binary of the game no
matter how buggy and messy the code is (like in a reeeal game company :)
the first two points might be most important. If you need more
developers for getting ScVM to work, it might attract some. In case
you'd rather publish the game in a major release anyway, after ScVM and
all those man pages are finished, we can do the code cleanup and
refactoring first.
My suggestion would be to script in the easy stuff, like the intro and
missing animations and dialogs, but to leave out the triangle puzzle,
OpenQuest verbs and default actions, as those might get buggy if done in
a rush. We could then release the game binaries, and wait for responses
while we concentrate on the game code in the next round.
Whaddaya say?
Regards,
Gerrit
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
