Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: oddity in the pup_land raffle #2



Seikoh Nishita wrote:
> 
> In order to make maps, we managed to understand object behaviors by a
> lot of explanation. (We couldn't ask them on this mailing list because
> of our poor english writing..) There were many suspecious behaviors
> that we thought it as bugs. But at the first time we made pupland, we
> weren't sure that our maps would be added in standard distribution.
> (We were sufficient that our maps were on Tenjin server in Japan.)
> So, we didn't mind to use them on our maps, if we had good ideas.
> 
> We could easily guess the behaviors would be changed and wouldn't work
> well.
> 
> BTW, I feel it is important for us to decide the object
> specification. It will make us happy, because we don't have to fix our
> maps a lot of times. H.Okuda and I could help it. But I also know it's
> very difficult. Sometimes, I want to use an object behavior to realize
> good effect in my map, but the behavior isn't reasonable in crossfire
> world. (For example, invisible objects in raffle2. we use it for
> pazzle, but of course we know invisible sword is quite strange.:)

 When writing the 0.96 code, I am also trying to give good documentation on the
objects an desired behaviour.

 For many things, the correct behaviour is pretty obvious.  However, the problem
is more in usage of objects that are quite unexpected.

 What happens when a multipart object falls on pits is such an example.  This is
a problem that until someone actually uses it one way or the other it might not
be thought about (floors on top of gates is another one).  So  I think even with
better documentation, there will still be cases where the behaviour is not
documented and an argument could be made in such a situation that it should work
in one of many ways.

 Some of the solution is to make more things setable on an object basis - show
invisible is such an example (have a flag that determines if show invisible
makes that object visible or not).  But do you really want a flag for the gate
and floor (ie, floor is moved, floor stays put).  So some things will have an
expected behaviour that can not be changed by the map maker.

 I think, poor english or whatever, if a map maker thinks they run accross
unusual behaviour in objects, a message to the list may be in order.  If nothing
else, we can document the unusual usage as proper, or say that is a
bug/unsupported use.   I think some of the problem is that if the object
behaviour is not clarified until after the map is made (or more importantly,
after the map has wide distribution), trying to change/correct the behaviour
means a lot more work and a lot more annoyed players as something no longer
works.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]