The logics of sight

ID:265645
 
Oct 9 2006, 12:35 am (Edited on Oct 9 2006, 4:54 am)
Many times I find it that procedures such as view() are used in places where they don't make sense. For example, take this verb:

mob/verb/cast(mob/m as mob in oview(1))
    oview() << "You see [usr] casting a spell on [m]!"


Now, picking a mob in oview() makes sense, as you need to see him in order to cast the spell, but would everyone that you can see be able to see you? No.

Procedures such as oviewers() or ohearers() are often missed, while they're a much more logic answer for this. oviewers() should be used in that attack verb, as it refers to everyone that can, well, 'view' you(=P).

Now, it doesn't really end here, what if you're blind, but can still hear the slash?

mob/verb/attack(mob/m as mob in orange(1))
    // orange() would be used here, since you could still slash randomly around you. =P
    ohearers() << "You hear a slash!"
    oviewers() << "You see [usr] attacking [m]!"


Now this makes much more sense, everyone that can hear you gets a message saying they heard the slash(yet they still don't know who caused it), and everyone that views can see who caused the slash.

But it doesn't end here. In the previous example, we had the user pick a mob in his range, but if he is blind, he shouldn't be able to pick the mob he wants to attack.

mob/verb/attack()
    var/target
    
    if(usr.sight & BLIND)
        target = pick(orange(1)) // you can target anything, even the air!
    
    else
        target = input("Attack who?") as anything in oview(1)


I think the logic in sight is often underestimated, and should be used more often.

Thoughties?

Oct 9 2006, 1:19 am
I think the main reason that more people don't implement those sorts of things is that they don't expect their players to be in those situations...

Generally, in most BYOND games, if another player is in your view(), then you are in their view() (and some for the converse, of course) And so using the simple oview() is sufficient to cover virtually any event...

So to get to the point where you should be using oviewers() and ohearers() for output, your underlying systems will need to be more sophisticated overall (and by that point, I'd assume this developer is experienced enough to know the usage of these two procs)

Of course, having more sophisticated systems in general will make for better games, so this would definitely be a welcome change...
Oct 9 2006, 7:46 pm
Roguelike games like to go this route -- they envision every possible status effect which can have an effect on the user's output and adjust it accordingly.

This is why Nethack's source code is spaghetti, for instance. =P

If you plan for something like this from the very beginning and set up a powerful "output event" system which allows objects to receive sights and sounds in an object-oriented fashion, your game will be able to handle it gracefully. Otherwise, however, it's not worth the hassle. =)
Oct 10 2006, 4:57 am
DivineO'peanut wrote:
Many times I find it that procedures such as <code>view()</code> are used in places where they don't make sense. For example, take this verb:

> mob/verb/cast(mob/m as mob in oview(1))
>     oview() << "You see [usr] casting a spell on [m]!"
>

Now, picking a mob in <code>oview()</code> makes sense, as you need to see him in order to cast the spell, but would everyone that you can see be able to see you? No.

Procedures such as <code>oviewers()</code> or <code>ohearers()</code> are often missed, while they're a much more logic answer for this. <code>oviewers()</code> should be used in that attack verb, as it refers to everyone that can, well, 'view' you(=P).

Now, IMHO, why would someone neccesarily need to see who is casting the spell at them, in order for the spell to work? So long as the caster can see the target, it should work. (At least, in all my gaming experiences that is how it goes.)


> mob/verb/attack()
>     var/target
>     
>     if(usr.sight & BLIND)
>         target = pick(orange(1)) // you can target anything, even the air!
>     
>     else
>         target = input("Attack who?") as anything in oview(1)
>


and shouldn't that be

    if(usr.sight && BLIND)


:P

_>

<_<

§atans§pawn
Oct 10 2006, 5:06 am (Edited on Oct 10 2006, 5:17 am)
In response to Satans Spawn
Nope, it should be & not && because it's trying to see if the bit flag value BLIND is enabled or not >_>


- GhostAnime

http://bwicki.byond.com/ByondBwicki.dmb?BitFlags <-- Too bad BYONDscape is down or I would've linked to a great article that Unknown Person made for it, which I learned from
Oct 10 2006, 5:14 am
In response to GhostAnime
OK. I wasn't sure. I checked the reference, and it seemed (in my mind) that && would be more appropriate.

§atans§pawn
Oct 10 2006, 5:17 am
In response to Satans Spawn
Well, I just edited my pervious post with the link if you are interested as to know why & is used >_>

- GhostAnime
Oct 10 2006, 5:26 am
In response to GhostAnime
yeah, that makes more sense. I was/am still kind of tired. I saw usr.sight and it didn't clue in that it was a predefined variable that would work like that...

The only semi-problem I have found with this is the fact that you called the parenthesis --> () brackets --> [] I would have simply fixed it, but it says you are editing the page already.

§atans§pawn
Oct 10 2006, 5:35 am
In response to Satans Spawn
Oh, I keep forgetting their names >_>; along with the other bracket-family members such as { <_<'

- GhostAnime
Oct 10 2006, 5:36 am
In response to GhostAnime
I pretty much only know... Bracket, Paranthesis, Angle Bracket (cause I just read that one), and... that's it.

<_<

_>

§atans§pawn
Oct 10 2006, 5:36 am (Edited on Oct 10 2006, 5:58 am)
In response to Satans Spawn
Satans Spawn wrote:
DivineO'peanut wrote:
Many times I find it that procedures such as <code>view()</code> are used in places where they don't make sense. For example, take this verb:

> > mob/verb/cast(mob/m as mob in oview(1))
> >     oview() << "You see [usr] casting a spell on [m]!"
> >

Now, picking a mob in <code>oview()</code> makes sense, as you need to see him in order to cast the spell, but would everyone that you can see be able to see you? No.

Procedures such as <code>oviewers()</code> or <code>ohearers()</code> are often missed, while they're a much more logic answer for this. <code>oviewers()</code> should be used in that attack verb, as it refers to everyone that can, well, 'view' you(=P).

Now, IMHO, why would someone neccesarily need to see who is casting the spell at them, in order for the spell to work? So long as the caster can see the target, it should work. (At least, in all my gaming experiences that is how it goes.)


Huh? I'm afraid you misread. 'but would everyone that you can see be able to see you? No.' was meant for the message part, as only people who are able to see you will see you casting the spell, but not everyone you see.
Oct 10 2006, 5:39 am
In response to DivineO'peanut
Oh, sorry. I'm going to chalk that up to me being tired once again. Thus, making both my points in this thread, invalid... :(

§atans§pawn
Oct 10 2006, 5:59 am
In response to GhostAnime
Ghostkindacan'tremembername fellow wrote:
along with the other bracket-family members such as { <_<'

Braces, me thinks. =o
Oct 10 2006, 10:12 am
In response to Satans Spawn
Satans Spawn wrote:
I pretty much only know... Bracket, Paranthesis, Angle Bracket (cause I just read that one), and... that's it.

Braces: { }