[CF-Devel] Ingame map 'building' / modification: full patch
crossfire-devel at archives.real-time.com
crossfire-devel at archives.real-time.com
Tue Nov 11 03:12:55 CST 2003
Hello.
>
Some general notes:
>
>
Consider using marked objects when determining what 'raw' item to use.
>
Otherwise, if the player has multiple raw items of a type (lets suppose
>
different styles), there is no way for the player to specify which to
>
use, other than to drop the other types. Using marked objects fix that
>
problem.
Hum, will work for floors & walls, but not doors, since it requires 2 materials.
But ok, can be done.
>
I'm thinking that specific images for the builder types should be used
>
- the images selected would seem a bit odd.
Yes, i didn't want to mess with image files to create new pics, so i used
current pics. I'll make something at the time i commit, if i ever commit :)
>
seems to be a bit of redundant code to check to see if the direction is
>
buildable - perhaps reduce that redundancy into one function like
>
'check_buildability(....)? That would seem to be useful if additional
>
buildable options is added.
Probably. But building functions don't always check the same thing, or keep some
variables for later use (item below floor, for instance, when building a floor).
>
Some notes more stylistically and not functional:
>
>
Remember that the error messages are things that players see, so instead
>
of saying things like "Invalid map or weird square?!?", just saying
>
something like 'you can't build there'.
Those messages are supposed to never happen. If this message ever comes, it
means there may be some issue with the map (or i forgot something in the tests,
quite possible). For instance if you build a floor in a direction, there should
_always_ be something there (wall, floor, anything). Because if nothing, it's an
undefined square, and the player is standing next to it...
>
In terms of block comments, please do:
>
>
/*
>
* this is
>
* a block comment
>
*/
>
>
instead of
>
/*
>
some block
>
comment
>
*/
Ok.
>
Also, in terms of comparisons in if statements, have the variable
>
first, and constant second if that is what the compare is against, eg,
>
instead of
>
>
if (4 == a)
>
>
do
>
>
if (a == 4)
>
>
This includes comparisons against constants, eg
>
>
if (op->type == WALL)
>
>
not not WALL == op->type
Ok, even though i do this to avoid mistaking for the evil 'if (op->type = WALL)'.
Nicolas 'Ryo'
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list