On Thu, 29 Nov 2007 04:29:18 -0800
"G33K" <[EMAIL PROTECTED]> wrote:
> 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 ] };
> };
That would be possible.
> 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?
Yes you can: E = { body(5,20,2,[5-10],3,7) }
> 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.
Yes they are used in dott. For example in some talk anims the
body is a limb with a single frame and a separate limb is used for the
face.
> 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?
I added the possibility to have the costume compiler generate a header
with a define for each anim. -header file.sch enable the header
generation and you can set a prefix for the defines with -prefix XXX
However atm using such header mess the dependency generation. It'll need
some modification to ignore missing headers.
> 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?
I'm not sure but I think you can't play anims faster than the game
frame rate (set by VAR_TIMER_NEXT). Also setActorAnimSpeed() probably
set the delay between the frame.
> 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.
You can use objects or a copy of some part of the screen as pointer.
iirc dott use the latter when you pick an object from the inventory.
> 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.
That's proabably a good idea.
> 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?
I don't see what you mean. Scripts can already can called directly.
There is definitly a few things that need to be improved with the
grammar. I recently added 2 niceties:
* You don't need to always have [0] when assigning string or array to a
variable. That is: foo = "bar" is now equivalent to foo[0] = "bar".
* Scripts can now return a value. However one have to be carefull.
Because of threaded nature of the engine internaly script don't have
anything like a return value. What the compiler do is basicaly:
return x => VAR_RETURN = x
return
y = func() => func()
y = VAR_RETURN
Another thing I'd like to get rid of are the infamous setCurrent*().
Or having the function call syntax for object script too. But for both
some stringer typing will be needed first.
> 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?
In scummc, make rd :) But beware this is a big bunch of investigation
code packed together, nothing really clean. It dump the blocks as-is
you then decompile the scripts with descumm (from the scummvm tools).
> 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.
scvm won't be finished in the near future I fear. And anyway scummc
have seen more than enouth improvements in the last years to justify a
major release.
> 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?
That sound like a good idea. In fact doing a pre release might be a
good idea. It would help getting a bit of attention on the project and
give us the chance to iron out a few more bugs before the "real"
release.
Albeu
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
