After checking shops in Daggerfall city and Gothway Garden, I think I have the weightings worked out. Daggerfall weights the quality text a bit more in the mid-range that the extreme low or high ends. I’ve long assumed it was just qualityValue/4 to get the popup, but testing proved otherwise. Each shop has a quality value between 1 and 20 with a total of 5 different quality popups.
When the player enters a shop in Daggerfall, the overall quality level is presented to player as a popup. While I was working on this, I decided to add shop quality text. With all of that in place, player can finally make info clicks on buildings in scene. The net result has practically no performance impact and still fits nicely hand in glove with Unity’s physics setup. The end result is zero new collider objects in the scene and only a small amount of overhead for storing building data and testing hits, which happens only when the player clicks on a city block. If a hit point intersects with a known building trigger in world space, then everything we need to know about that building from scene layout time is returned to PlayerActivate. The world-space point of impact for hit ray is tested against known buildings in that block (and only those buildings). When the player clicks on a block in scene level, a single box trigger is instantiated and tested for each of the buildings in that block, usually no more than 5-14 buildings. This is just a small amount of raw data stored on each block. I store the box information for every building on the block GameObject itself using component DaggerfallStaticBuildings. To work around this, I used the same solution I came up with for doors. Not ideal from an optimisation point of view. If a few large cities are in the world at once, then it’s very possible that 2000-3000 colliders would be added to scene, the majority of which will never be used. A large city like Daggerfall will add around 800+ new collider GameObjects. While this is great to visualise the bounds, I’m not happy with adding so many GameObjects to scene. The end result looks like this.Įvery building now has a nice crisp bounding box trigger collider. Then I just had to pass that information to scene builders.
I now have what I need to construct a tight bounding box around any model effectively for free. Because the models are being constructed procedurally, and I have to process that information anyway, this step adds almost no overhead to the job of loading models at runtime. During the vertex conversion process, I added some tracking for minimum and maximum vertex positions from origin to get the overall size of models in X, Y, Z space. There are ways of handling this of course, but I decided to go with box colliders instead that will tightly wrap Daggerfall’s little box houses.īefore I can implement boxes, I had to go right back to the procedural mesh builders that extract data from ARCH3D.BSA (Daggerfall’s 3D model archive). Depending on where player is standing and where they clicked on the building, it’s possible for that target point to be inside two or three different building spheres. The sphere colliders would do the job, but they unfortunately suffer from a lot of overlap. So I don’t know which building player has clicked on – I just know they’ve clicked a combined block model and I need to resolve that back to a specific building. This is more efficient for rendering and results in fewer draw calls to the graphics card. Keep in mind that I’m not storing individual building models at scene level, the entire block of buildings above is combined into one large model. This seemed like a good place to start, so I overlay the radius as a sphere collider on test buildings. Each Daggerfall model contains a radius value stating the overall size from its centre point. I go to work looking for an efficient way to manage this. I already track player clicks in PlayerActivate class, and can detect clicks on static scenery and doors, but not on the building model itself. Next, I needed a way of detecting when player clicks on a building. After several minutes it was possible to flip between the 4 interaction modes.
WATCH ES DAGGERFALL CODE
Key-kinds were already in place inside the InputManager class, all I needed were a few more lines of code to track which mode player was in and a new HUD label to present switch to user. What I’m most interested in here is the ability to perform an info click directly on a building to discover its name.įirst step was to quickly implement the mode switch itself. Steal, Grab, Info, Talk which are by default bound to keys F1-F4. I decided to tackle this along with a start on Daggerfall’s interaction modes, i.e. The next step from here is to propagate this information to scene-level where the player ultimately lives. In my last post, I talked about the “Place” quest resource and merging map-level data down to block-level.