a multiplayer game of parenting and civilization building
You are not logged in.
Pages: 1
It looks like items hidden behind scenery are often invisible. If you dropped
the item, it appears when you mouse over its position, and you can interact
with it. But this seems not to apply to items which were on the map when you
were born. I also noticed that the remains of a burnt-down fire hidden behind
a wall couldn't be interacted with - I guess any result of a transition
becomes hidden?
Offline
Right, currently, if you can't see it, you can't touch it....
UNLESS you put it there. Then you know it's there, and if you mouse over it, you can see its highlight glowing through.
So, the problem here is that you generally don't want "behind" stuff "coming through" when you're mousing over stuff, because most of the time, the behind stuff sticks out enough, and so you want "what you click on" to be "what you get". Like, if the kiln is sticking up in front of a shaft, and you click on the kiln, you don't want to click on the shaft through the kiln.
It's only if the item is totally covered up. But there's not a good way to detect this case, that I know if.
So, the current hack is that the client remembers what you dropped or created, and only shows you those things as click-through-able. Unfortunately, this means it also applies to a shaft put behind a kiln.
But it doesn't apply to a tree behind a tree, which would make the front tree hard to click on.
I think the current code also checks for "short" objects and only applies to them. So, even if you change a tree, like by picking a branch, it doesn't become click-through-able, because it's too tall. But if you click on building stakes that someone else placed, and make them rotate so they become hidden, you can now see them through stuff.
The other really hacky thing about the current implementation is that the "memory" is attached to the current map cache. If you walk too far away and come back, the memory of hidden objects that you placed is lost.
Maybe all short objects should be able to be clicked on through stuff, all the time? After all, the example with the shaft behind the kiln is already happening once you place the shaft there.
The code can't tell the difference between the kiln (not really covering stuff up, except maybe very small stuff) and walls (cover up lots of stuff). I'm not doing per-pixel analysis or ray-casting. Just treating sprites as sprites.
Offline
I'd say not only that hidden (parts of) objects should always be shown, even
when they're not moused over. This could be done for example by always drawing
the stencil highlighting on the foreground object.
Hiding the world state from the player for the sake of aesthetics seems like a
bad idea to me.
Offline
Sorry, can you rephrase that?
You mean that EVERYTHING should be visible through stuff all the time?
Like, essentially, everything is semi-transparent?
Offline
Sorry, badly edited post there. Delete the "not only".
So I meant that obscured objects and obscured parts of objects should always
be marked. Effectively making objects transparent where they would otherwise
obscure something.
Offline
Well, I'm afraid that this would cause a lot of visual "jumble."
Here's a sample tree with transparency that you can import into the GIMP to play around with:
Can you make a little mock-up of how you think it should look? You can build a forest out of one tree.... You can grab a ground image out of the ground folder too, if you want.
Offline
Sorry, I can't figure out how to do it in GIMP. But what I'd draw if I had the
chops is a pair of trees, one above and behind the other, with something like
the current stencil highlighting being drawn as if you were mouse-overing the
back tree, but drawn only on the overlap of the two trees.
Maybe it would look too noisy. I didn't have this case of two large objects in
mind, and really it would be better if it only applied to a small object
behind a large object. Can you detect that? Does the engine know that the tree
is drawn on two tiles?
Offline
Yeah, I can somewhat reliably detect "tall" objects. I'm already doing that with the mouse-over highlights. Highlights only "show through" if the rear object is not tall.
However, I don't think there's an efficient way to draw the highlight JUST on the part that's obscured by a foreground object. Obviously, you wouldn't want to highlight all small objects all the time. Currently, it looks okay to highlight whatever you're mousing over, and highlight the whole thing, not just the part that is covered up. I'm doing that with the stencil buffer, and this involves drawing the highlighted object multiple times, which is inefficient (dramatically increases the pixel fill requirements), but there's only one object at a time that this applies to.
In order to "cut out" the highlight so that only the obscured part is highlighted, I'd have to further trim the stencil by drawing all the objects in the next two rows down into the stencil buffer. Which involves loads of extra pixel fill....
And repeat this process for every small object on the screen...
I'm all right with you having to mouse over to see hidden objects. I think I'll probably make it so that all short objects "show through" when moused over, not just the ones that you placed yourself.
Offline
I just tried this, where hidden short objects are always mouse-able, with the highlighting showing through, whether or not you or anyone else put them there.
And it just feels weird. The part of the map that I'm testing is known to me, and all these hidden objects are there. A rabbit here, milkweed there, a sapling. Pretty much half the trees have something hidden behind. And some of the things are "rare" items, like milkweed, that I ran out of when I played that part of the map.
So, this sounds like a good thing! Finding all this stuff that wasn't available before. However.... it encourages a tedious "mouse over everything" style of gameplay. Like, if you don't mouse over every tree, you might be missing something. So you mouse over every tree, one by one.... And it's a pain!
Obviously, your suggestion of always highlighting short object that are behind stuff would fix this.... But even if I had a good way to trim these highlights, I don't think I could stomach the visual noise that would result. I'm going to make a mock up in a second here...
Offline
Okay, here's a mock-up using the actual highlighting that the engine produces. I moused over each thing and then patched it together into one image:
I find this really mars the artwork.... It's also not terribly readable. Can you guess what the second thing from the right is, behind the yew tree?
Without the highlights, those things simply do no exist in the world to you. Chopping down a tree would reveal them, but beyond that, there's really not there.
Offline
> I find this really mars the artwork.... It's also not terribly readable.
This is pretty much what I had in mind, and I agree it isn't beautiful or
perfectly readable.
> Can you guess what the second thing from the right is, behind the yew tree?
No.
Maybe in place of the highlight, you could have the foreground object be
transparent in the highlighted region?
Or just make two-tile-tall objects actually take up two tiles, so there can't
be anything behind?
I don't know what's best. But being able to hide objects from other players
seems strange and surprising, and if there's going to be any sort of conflict
in the game, I guess it would be heavily (ab)used. The neighbouring tribe is
coming to raid our village - quick, hide the pies behind the walls!
Offline
It's a rabbit.
I agree that the possibility of hiding stuff is a problem.
Preventing stuff from being placed behind things is tough, because some taller things are kinda "see-through", and this means that you can see the ground back there but you can't click on it....
Maybe what I'm after is just showing any non-naturally objects that are behind things. Drop the memory of placing it there yourself, and just check if it's a short object and if it's a non-natural object, and then you can mouse there to find it.
Essentially, if any human caused it to be there, ever, then you can mouse to find it.
People will still hide stuff behind their walls, but a little mousing will reveal it.
Offline
That sounds ok.
But not allowing mouse-over discovery of naturally placed objects would be
annoying in the case that they are just barely visible - then you know they're
there, but it's very fiddly to actually select them. It would also be
confusing for natural objects which are totally hidden, because it would mean
you mysteriously can't put down objects in that tile.
Maybe the world generation could just avoid placing one-tile objects above
two-tile objects?
Offline
Well, the server doesn't load the sprites for things (it doesn't need them), so it just has a very rough estimate of object height based on sprite positions. I could code up something else that saved accurate records of each object height.
I think that some objects are 3 tiles tall, and taller ones may be coming.
Also, it's only short natural objects that shouldn't be placed back there.
Offline
Okay.... I've done this, and it seems to work well. True object pixel heights are now computed and cached at object edit time, and then these are used to detect short objects and avoid placing them behind tall objects in the naturally-occurring map.
Objects that players move or create can still be put behind tall objects, but they are mouse-through-able back there.
Offline
Good, I think this is an improvement.
I think I'd still prefer there to be some static indication that there is a
hidden (non-natural) object, even if you still have to mouse-over to identify
the object. It's too easy to accidentally leave an important tool behind a
tree or wall, and then having to carefully mouse over every possible hiding
place to find it again doesn't sound like fun (though definitely better than
having to right-click on empty space in every possible hiding place, as was
the case before the mouseover highlights).
Offline
Well, there could be a key that you press to turn on "xray vision." That's somewhat tedious, but less tedious than mousing everywhere.
Though I think that "I lost my ax" is a rare enough event that having to "look for it" isn't so bad. If I cared about it, as soon as I dropped it behind a tree by accident, I would grab it right away back out of there. That's the main case, and one where "mousing around" is not a problem (I just saw it drop back there, so I know where to mouse).
The other case is where you suspect that someone has intentionally hidden something. Then you would be mousing over every tree looking for it. This is tedious, and if the potential for hiding stuff is there, then people may end up "spam mousing" everything as a reflex, just in case something is hidden. This is no good, obviously.
But even if I gave you an x-ray-vision key, people would end up spamming that key as a reflex too, which I don't like.
Oh, and the x-ray vision key would have the same pixel fill issues that I already mentioned for always-highlighting hidden stuff. So I think that's out anyway. (Though it could do something stupider and uglier like temporarily reverse the draw order... still, people would spam that...)
The other option is to prevent people from dropping stuff behind tall objects. But I think that would simply be too counter-intuitive. You see empty space behind the kiln chimney, but clicking there does nothing. And yes, even though the chimney is skinny, it can hide small stuff, like berries and leaves and stones.
Anyway, I've got to be careful here that I don't create a lot of other casualties in attempting to fix this corner-case. Dropping stuff and not being able to get it back sucks, and that's fixed now.
Offline
OK. I'm happy to consider the bug fixed if you are!
Offline
Pages: 1