Follow-up Comment #1, patch #2719 (project freeciv):
Thinking about this, there are natural extensions to just orientation. For
instance, different sprites when a unit is doing a certain activity (sentried,
fortified, irrigating etc). Clearly, in the core code, we could define sprite
names for all activities and display them at the appropriate times.
However, there are also desirable things that it won't be practical to build
into the core game engine. For instance, when certain kinds of sea unit fight,
it might be desirable for them to rotate 90° to look like a broadside attack.
This sort of knowledge clearly can't be built into the game engine; it would
have to be handled by Lua scripting, I think.
Here's a sketch of a design that would be script-friendly:
* Allow tilesets to define a set of sprites for each unit with arbitrary
string tags (not just n, ne, etc), and load them all when loading the tileset.
(Requires associative lookup whenever the sprites are accessed...)
* Normally the sprite used for a unit will be determined by the core game
engine in the manner that's being implemented by these patches. This probably
handles movement, and could extend to fights/activities or not, as we choose.
* A script function allows the script to override the sprite for a specific
unit with the string of its choosing. This override stays in effect until the
script removes it.
** Hooks/signals are added so that the script can get in on unit attack,
activity change, etc.
** A function is added to get the current orientation of a unit (which is
tracked even if the sprite is overridden), so that the "broadside" case can be
* Scripting runs on the server, but the tileset defining the sprites is on
the client (and potentially different for different clients). This can be made
to work, but the sprite string has to go over the network, and the loaded
ruleset/script would have to agree with the tileset on the set and naming
convention of sprites. Probably too much faff to be worth it.
** Client-side scripting to the rescue? (I haven't looked into whether the
client scripting hinted at in patch #2515 is remotely the right shape.) In
this case, only orientation would have to go over the network.
* Performance -- I don't have a feel for this. Is having scripts involved in
any of unit movement/activity/fights going to be too slow?
** If the scripting is on the client, then perhaps it's less of an issue?
** We can trade off frequency against adaptability (having ordinary movement
handled by the core engine seems like a reasonable trade-off).
(I'm not remotely suggesting we should aim to get all of this in 2.4, just
that we should consider a design that extends to it in future.)
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list