Automap (indoor & dungeon) implementation

[LypyL]

There will also need to be a utility method to return which section of model geometry the player is standing inside of. I'm not sure how Daggerfall handles this internally, but the implementation in Unity is likely to be different anyway. I can think of a few ways to accomplish this, the simplest being a hit-test, with more complex methods (spatial partitioning) yielding better results.

We'll also need serialization support for which dungeon fragments have been explored, which parts have been clicked to hide, and any notes the player has placed on the map.

It's possibly one of the most wired-up UIs in the whole game, touching a little bit of everything. Fun and exciting.

I've been messing around with this a bit today trying to figure out how it worked in daggerfall, and one thing I found interesting how it works in large rooms (like the one in castle daggerfall w/ the floating platform) - you can levitate through that room and nothing will show up on your map. I accidentally bumped a banner on the wall, and it showed up on my map, but nothing else did:



This is what it looked like when I touched the wall next to the banner:



Another thing I noticed is that daggerfall actually seems to be using the dungeon for the map? If you make something in the dungeon move that is shown on the map (like the floating platform in that room) and look at the map, you can actually see its position update in the map as you open and close the map.

[Nystul]

don't click that rotate button - it will mess with your orientation

regarding the discovery of map areas. Since this must be done very often (so the game doesn't miss a discovery) it is time-critical. So extensive ray-casting - which would of course be a solution - might be the wrong idea :/

I will give it a try tomorrow with a decent number of rays in the fixed update function - good that I wrote a DaggerfallAutomap class besides the DaggerfallAutomapWindow class... since DaggerfallAutomap is inheriting from MonoBehavior I can try to implement the discovery state in there. Feels like the right place to do it since it also mantains the geometry anyway

[Arl]

This looks amazing, great work so far!


Edit: I noticed that you are changing a bit the automap navigation, am I wrong to think that maybe some of the UI buttons will get obsolete?

Anyway, maybe you can use that space to place something else that fits better with your approach of handling the Automap. Here's a blank version of the automap graphic UI, just in case

[Interkarma]

Hit tests were just my first idea for trivial testing. Based on Lypyl's efforts above, this seems to be what the game itself is using (banner appearing after player bumps into it).

Personally, I would use a spatial partitioning setup. A basic oct tree could partition model bounds into an excellent hierarchy for testing where player is. Then just need to light up the current leaf based on player position in space. Would need a little tuning, but would yield much better results than collision testing or rays. Like Nystul pointed out, the geometry is not closed in well and even Daggerfall seems to have troubles with this approach.

[LypyL]

Hit tests were just my first idea for trivial testing. Based on Lypyl's efforts above, this seems to be what the game itself is using (banner appearing after player bumps into it).

It only works for some stuff like that though, I think the larger rooms (I need to check more, I've only tested the one). Like if you levitate through a hallway without touching anything, it will still appear on your map! It's like they're using different methods.

Another weird quirk I just noticed is that if you're colliding with a door when you open your map, it will show up in the map when you open it

[Interkarma]

I was only suggesting hit tests for trivial first-pass. My recommendation is still to use spatial partitioning like an oct tree for the real thing.

[LypyL]

Sorry, I was just pointing that out from an idle curiosity perspective, I wasn't suggesting it was how it should be done in Daggerfall Unity I just thought it was interesting they seemed to use different methods depending.

Anyways, I'll stop cluttering up the thread, I just got curious how it worked in Daggerfall

[Interkarma]

Sorry, I was just pointing that out from an idle curiosity perspective, I wasn't suggesting it was how it should be done in Daggerfall Unity I just thought it was interesting they seemed to use different methods depending.

Anyways, I'll stop cluttering up the thread, I just got curious how it worked in Daggerfall

Ah, gotcha. Sorry about that, brain elsewhere. You're right, it must be using a couple of different approaches to build the map visibility. Good observation on the levitate, I wouldn't have thought to try that!

[Nystul]

basic discovery working (some improvements need to be done though)

currently simple ray casting - seems sufficient (it is amazingly simple and working for most things except big halls - because it is enough to cast a ray down from player head position and when it hits the ground it will reveal the dungeon segments to which the face belongs - looks almost identical to how it looks in vanilla daggerfall when revealing geometry)

even managed to implement the idea with gray/color geometry when reentering already before discovered dungeons parts (currently only working for last visited dungeon)



update:
tried out casting a ray along view direction - turned out to be really nice - you can reveal objects targeted (within a predefined maxrange, e.g. 25 meters) - just look at it (make the crosshair point to it)

this is especially nice since smaller objects like chairs are not revealed until you look at it

feels like gameplay mechanic like "if I take a closer look at it I will mark it on the map as well"

[Interkarma]

I love how this is coming together. The idea of ray-testing based on where player is looking is a real twist of genius.