Tree's with transparency or not?

Page: 1 2 3
ID:151762
 
May 9 2009, 9:42 am
I currently added tree's to my project and had a thought; Should the tree's be transparent so you can see your character and other objects through it or should the tree be opaque so that players and objects can hide behind the tree?

All suggestions are useful.
May 9 2009, 5:32 pm
Of course, I don't really see this applying specifically to trees; this is relevant for any object a player could be allowed to occupy the same space as and appear underneath it, like, say, a top of a building, obstructing a player visually behind it.
The question here is whether you want enhanced visibility of movables, making them visible at all times, even when obstructed, or do you not care about that and want the potential for movables to also be hidden behind obstructions, like the other poster said. Many (f.ex. RTS) games employ a technique of making an object become transparent when something is behind it (and when nothing is behind it, it becomes opaque again) in order to achieve the former. This could be pretty easily implemented in BYOND, just that you'll inevitably have a larger resource size for the game, because all such turfs will need to have transparent versions of their icon state(s) (this can and should be automatically pre-computed). Some new built-in feature like an atom.transparency var to eliminate this would be nice, but that would require Dream Seeker to have client-side processing of the transparency and I dunno whether that's possible/feasible.
May 10 2009, 2:26 am
In response to Kaioken
Kaioken wrote:
Of course, I don't really see this applying specifically to trees; this is relevant for any object a player could be allowed to occupy the same space as and appear underneath it, like, say, a top of a building, obstructing a player visually behind it.
The question here is whether you want enhanced visibility of movables, making them visible at all times, even when obstructed, or do you not care about that and want the potential for movables to also be hidden behind obstructions, like the other poster said. Many (f.ex. RTS) games employ a technique of making an object become transparent when something is behind it (and when nothing is behind it, it becomes opaque again) in order to achieve the former. This could be pretty easily implemented in BYOND, just that you'll inevitably have a larger resource size for the game, because all such turfs will need to have transparent versions of their icon state(s) (this can and should be automatically pre-computed). Some new built-in feature like an atom.transparency var to eliminate this would be nice, but that would require Dream Seeker to have client-side processing of the transparency and I dunno whether that's possible/feasible.

I like the idea but the same question still applies, which one would be better to have? A more aesthetic look to the game with transparent trees or a more strategic experience with the trees being opaque?
May 10 2009, 2:38 am
In response to Forerunnerz
I don't see what's wrong with having both. Of course, it really depends on what kind of game you're making, but a variety of different trees is something not seen in many games. People just don't spend the time drawing any more than one, maybe two.
May 10 2009, 3:35 am
In response to Kaiochao
Kaiochao wrote:
I don't see what's wrong with having both. Of course, it really depends on what kind of game you're making, but a variety of different trees is something not seen in many games. People just don't spend the time drawing any more than one, maybe two.

Actually, an idea just hit me. I can have the tree's opaque so you can hide behind them but when your behind them, the tree is only transparent to you and/or anyone else hidden inside the tree.
May 10 2009, 2:17 pm
I think stuff like this all boils down to what kind of game you're making and how you want it played. If you want people hiding behind trees, then allow them to hide behind trees. If you don't, then don't. You're the designer, you decide how you want your game to be played.
May 10 2009, 6:54 pm
Why not both?
To other players, the tree is opaque.
But to the player behind the tree, the tree appears transparent.
May 10 2009, 8:33 pm
In response to The Kawaii Fuhrer Adolf Hitler
The Kawaii Fuhrer Adolf Hitler wrote:
Why not both?
To other players, the tree is opaque.
But to the player behind the tree, the tree appears transparent.

But what is the point.
It takes time to program something like this, for a very slight result. I'm pretty sure that if you go hide behind a tree, you know you're behind the tree. You don't need the tree to be transparent to see that. Seems a bit unnecessary to me.
May 11 2009, 2:06 pm
Forerunnerz wrote:
I currently added tree's to my project and had a thought; Should the tree's be transparent so you can see your character and other objects through it or should the tree be opaque so that players and objects can hide behind the tree?

All suggestions are useful.

I would say that if you had a theif or ninja or assassin class or something of the sort (or in essence a skill that allows vanishing into the shadows) then I would go with the transparency and then the higher level the skill is the more transparent the character becomes behind or under the said tree/building-top/statue/etc/etc catch my drift?
May 14 2009, 11:29 am (Edited on May 15 2009, 8:30 am)
In response to AJX
AJX wrote:
But what is the point.
It takes time to program something like this, for a very slight result. I'm pretty sure that if you go hide behind a tree, you know you're behind the tree. You don't need the tree to be transparent to see that. Seems a bit unnecessary to me.

It adds polish to your game and makes it different than others. Just because something takes time to program is a horrible reason not to do it.

[edit] Ha, thanks! I didn't notice that.
May 15 2009, 4:58 am
In response to Slime Lord
Slime Lord wrote:
just because something takes time to program is a horrible reason not to do it.

I agree with your post, though I had to fix your last sentence. Don't forget the actual negation word, hehe. =P
May 15 2009, 9:58 am
In response to Slime Lord
Slime Lord wrote:
Just because something takes time to program is a horrible reason not to do it.

Perhaps, but when something takes time and game resources for a very small result then you need to weigh if the effect is worth the effort. :)
May 16 2009, 2:43 pm (Edited on May 16 2009, 2:58 pm)
In response to AJX
It really doesn't take that much time.

area/tree
   layer=WHATEVER_LAYER+1
   invisibility=1
   icon='opaque_tree.png'
   Enter(mob/M)
      ..();M.see_invisible=1
   Exit(mob/M)
      ..();M.see_invisible=0

turf/tree
   layer=WHATEVER_LAYER
   top   icon='transparent_tree.png'
   trunk
      layer=TURF_LAYER
      density=1
      icon='treetrunk.png'


And just put the area over the turf... easy as that.

As for the question, it depends is sniping/ambush is an aspect of your game. If not and it's not turn-based, I'd go with just transparent trees. (kinda like I did in this screenshot) They actually don't look half bad that way.
May 16 2009, 8:17 pm
In response to The Naked Ninja
The Naked Ninja wrote:
It really doesn't take that much time.
Using see_invisible isn't an appropriate way to do it... Considering that would mean if you stood behind one tree that would let you see behind every other tree in the area. That eliminates the point of hiding behind a tree, and you'd be better off with going with opacity at that point.

You would have to use images to create this effect without ruining the concept. At with that what I would probably do is keep the default icon for the tree solid, then when a player enters switch the icon to a transparent and add an opaque image on top which is displayed to everyone who is in or enters the area. I would do it that way because it would be much more resource efficient than having images for every single tree on the planet.

Anyway, doing it sloppily would be fast and easy, but doing it right wouldn't. And even though the programming would take anywhere from 15 minutes to a few hours (depending on how many bugs you encountered) it would still cost resources (depending on what way you implemented it)

Like I said. You have to weigh the costs.
May 16 2009, 8:54 pm (Edited on May 16 2009, 9:15 pm)
In response to AJX
The resources aren't that big and it shouldn't take anywhere near 2 hours. Hell, I'd bet it would take less than 15 minutes to make. There's two types of programmers: those that put forth the effort to create something good, and the lazy ones. Sadly with your posts in this thread it seems you fall in the latter category.

Even if it did take longer to program it, it's still something that adds polish. Let's say it would take an hour, why not take an hour out of your time for some aesthetic appeal to your players?

Again, this would not be that big of a resource hog. I doubt it would even be noticable.

[edit] Here, I even whipped up a quick example. http://www.byond.com/members/SlimeLord/files/tree_src.zip

No guarantee that everything (or anything) in there is good programming practice. That's the effect I believe you were looking for.

May 16 2009, 9:21 pm
In response to Slime Lord
Slime Lord wrote:
(...)Hell, I'd bet it would take less than 15 minutes to make.(...) Here, I even whipped up a quick example. http://www.byond.com/members/SlimeLord/files/tree_src.zip

How long did it take you and could you just provide the relevant code snippet here, saving everyone the download and virus scanning to check what the code's worth? ;)
May 16 2009, 9:29 pm
In response to Schnitzelnagler
 
atom/icon='icon.dmi'
turf/icon_state="g"
var/tree_images[0]
atom/movable/var/on_objs[0]
obj
    proc/OnStep(atom/movable/a)
        a.on_objs+=src
        ..()
    proc/OnLeave(atom/movable/a)
        a.on_objs-=src
        ..()
    tree
        trunk
            density=1
            icon_state="t"
        top
            layer=MOB_LAYER+1
            icon_state="lt"
            New()
                ..()
                var/tree_image=image(icon,loc,"l")
                tree_images+=tree_image
            OnStep(atom/movable/a)
                ..()
                if(!ismob(a))return
                var/mob/m=a
                if(!m.client)return
                for(var/b in tree_images)m.client.images-=b
            OnLeave(atom/movable/a)
                ..()
                if(!ismob(a))return
                var/mob/m=a
                if(!m.client)return
                for(var/b in tree_images)m.client<<b
mob
    Login()
        ..()
        for(var/a in tree_images)client<<a
    icon_state="m"
    Move(new_loc,new_dir)
        .=..()
        if(.)
            for(var/obj/o in on_objs)o.OnLeave(src)
            for(var/obj/a in loc)a.OnStep(src)


icon_state guide (contents of icon.dmi):
m=player
t=trunk
l=leaves
lt=leaves (transparent)
g=grass/ground

I've already noticed a small bug where Move() should be under atom/movable, but that doesn't affect the demo at all.
May 16 2009, 9:44 pm
In response to Slime Lord
You are creating a list containing one image per treetop upon initialisation.
Such a list should easily contain more than several thousand entries (on a decent sized map). This is indeed a resource drain and should be avoided, as there are better ways of handling this.
May 16 2009, 9:54 pm
In response to Schnitzelnagler
Hmmm, would it be best off only generating the images for trees on the player's screen and then removing them?

[edit]
world
    maxx=100
    maxy=100
    New()
        ..()
        for(var/turf/t in world)
            new /obj/tree/top (t)


That seems to run fine on an Intel Atom processor with integrated graphics. I guess there may be a problem if you have over 10000 trees, I'll whip together the other one and see how it works.
May 16 2009, 10:01 pm
In response to Slime Lord
In an event based programming environment, one normally tries to use the hook that is called the least, in order to avoid wasting resources.
In a game, normally, I'd expect this to be "hiding in the tree", so that is when you should cause changes and only then (well, both hiding and revealing ;)).
Page: 1 2 3