For this week's screenshot, someone who objects to your taking from their tomb:
Perhaps the biggest news this week is that the first level's "critical path" has been completed, I believe!
A part of this that I'm particularly happy about is the inclusion of a minor branching of the way:
In one of the long tombs there are three doors. One leads into a room with no further passages onwards. Another leads into a tomb with a second door--but which second door is locked, and the lock blocked from the other side. The third door is similarly locked--but here the key on the other side is aligned with the lock, and might be pushed out--if one were to find something both small enough to fit the lock and strong enough to push the key.
On the other hand, beneath one of the tables in the room lies a section of loose floor-stones. If an appropriate tool were to be found, these stones might be lifted--exposing a low tunnel underneath, perhaps the work of some burrowing animal.
Both of these paths lead to the same place: the large traversal area that I believe that I showed in a previous blog post. (And indeed, it's possible to then go around to the path not chosen and approach it from the other side.)
Another part of finishing the "critical path" is that I found a new lockpicking minigame to replace the old. I'm not yet sure of quite how good it is, and am considering expanding it a little bit, but overall I think that I quite like it.
In short, it involves using the mouse to "feel" at the shape of the lock's interior. This unseen surface rises and dips, forming circular "tiers" or "mesas". The player is looking for the narrowest dip or slot: pressing the pick in here should spring the lock.
I actually started implementing basic line-line collision detection for the above, until I realised, I believe, that as with pushable objects it seemed a little silly to make my own when I already had physics engines on hand. After an abortive start with Panda's built-in physics engine (it turns out that it only provides continuous collision detection for certain types of collider), I switched over to Bullet. The result thus far has at least one (relatively harmless) bug, but overall I'm finding it to work quite well!
The shaders saw a fair bit of changing and tweaking in the week just past. Three changes are perhaps worth mentioning:
First, where the "sunlight" shaders were previously dark they have been somewhat lightened. Specifically, light now extends into back-facing polygons, modified by the colour of the surface's texture, and shadows have been made less deep. While this reduces a certain starkness that I liked in the old look, it also allows darker areas to show a little more variation, and thus feel a little less flat.
Second, the "player-light" has been changed in how it grades colour from the light's source into the distance: it now starts out less saturated, and lighter--thus hopefully showing colours a little more truly--then saturates towards its edges before fading into a slightly bluer distance than I previously had.
Third, the shader applied to inventory items has been updated to use logic from the main player-light shader, in particular the new approach to shininess. Inventory items--and perhaps especially collectible items, which can be viewed at larger scale--now look a little less dull to my eye, and better match what's shown in the level, I feel.
I also added a "default animation" to doors: a code-driven animation of a key entering, turning in, and leaving the lock, using for the key a model provided to the method. It's nothing special, but I feel that it adds a bit of player-feedback without requiring specific code for each door.
Finally, and as previously, there were quite a few other changes, and quite a few bug-fixes.
That's all for this week--stay well, and thank you for reading! ^_^