ID:1326301
 
The original Scream of the Stickster used opacity to its advantage, heightening tension by making the Stickster's exact whereabouts somewhat ambiguous and allowing for some surprises.

I'm leaning toward ditching opacity in the sequel. I'm starting to think it just isn't up to snuff, visually, and in spite of the fact that this might make scavenger hunts too easy (and CTF harder), I think it's probably worth it. Thoughts?

I'm also strongly considering moving away from a skin and toward an all-HUD interface. With maptext this just makes so much more sense now.
I have been all for ditching skins in favor of HUDs for years. I love a lot of things that skins can do in the background, but HUD based interfaces are just so much easier to work with, more customizable, and look nicer as a result.

As for the opacity issue, I've never minded it when playing Stickster in the past. But if you believe that it's not up to par, graphically, I'd come up with another method of obscure his position. There are other implementations you could use that look a lot better. Hell for such a small game, you could probably even use Darke's lighting system pretty well. There's no reason you should abandon the gameplay mechanic altogether.
Yeah, I thought using skin-based interfaces would be the future for the games. However, the only thing I use the skin for now is to store a map control.

While I haven't made much use yet still with maptext, I am planning to add more features related with maptext into my SByIo Library. The only time I really ever use skins anymore is for other types of projects.

And ah yes, going HUD completely should enable a full-screen version of Scream of the Stickster. :D
Opacity would be nice if BYOND could do more than make tiles solid black.
It's a lot of work to make a DMF interface look as good as what an HUD interface is capable of, and even then it doesn't feel anywhere as good when it comes to how interactive and dynamic an HUD interface can be. Makes sense to favor a HUD interface over a DMF interface.

For opacity... I just think that BYOND's opacity needs a makeover. I haven't used it in years as a result. Digging your own tunnels and exploring the Stickster maze kind of relies on opacity, though; without opacity, the game will be missing some suspense and excitement. I don't believe a superior alternative to BYOND's opacity will be difficult to design and implement, so I think that's the route to take here.
I'm not so sure you're right about an alternative to opacity being better. For instance, the only thing I can think of is to use custom shadowcasting, but angled shadow icons are pretty much going to be an impossibility, but that's still not going to get past the fact that tiles are either all black or all visible, unless I use something very similar to a lighting library where there's a light value assigned to each corner of an overlay icon and use that to make some tiles in the shadow zone only partially visible--that's kind of an ugly approach though and I don't think it can be done smoothly. (Most lighting libraries use areas for faster updates, because altering turf appearances triggers a map refresh; I'm not sure offhand if attaching images would do the same. But using areas is out of the question, because the game itself makes use of them.)

The thing is I'm not really sure how much suspense I'm getting out of opacity, and it's making map exploration way more difficult than I think it needs to be. It does have a bit of value in terms of cover for players in CTF and other such modes, but I'm not sure that's enough to justify keeping it.

I should also mention, any custom shadowcasting I might do would have to be done for the NPCs as well. They rely on view() to tell what's visible, so with built-in opacity out of play but custom-made opacity in, they'd need something to limit what they can see.
Could you not use the infared tools to make opacity still a feature, just players can still see everything.

That would at least mean you didn't have to shadowcast for NPCs
What about something like the marching squares algorithm for opacity shadows, if you dislike the thought of interpolating between light values on tile corners or making an icon state for every "angle"? I believe I've seen some other peoples' implementation of autojoining to smoothen out the jagged edges from the default opacity, and the approach was certainly an improvement.

I know that sd_DAL does make use of area clones, where he clones area objects for the use of showing shadows. This will screw up any references to the /area objects but it will not screw up the Enter() and Exit() events.

There's also Forum_Account's Regions library, which provides Enter() and Exit() functionality, essentially equivalent to /area, without screwing up references to the region object.
Marching squares is effectively what most of the advanced lighting libs I've seen have used, marking light levels at each corner and interpolating. (One demo I saw took this to an extreme with 9 light levels.) This would obviously be a much simpler case of visible/invisible, but the problem of how to display those icons remains--and the NPCs would still have to do the custom shadowcasting.

Using areas for the lighting is simply not an option in SotS II. The engine uses areas for other purposes, not Enter()/Exit().