Greetings and salutations!
This week’s screenshot shows a decorated iron staircase–and the source (or notifier) of a problem…
The week just past was, I think, a reasonably productive one, the above-mentioned problem aside:
I mentioned last week, I believe, that I had updated the end-of-demo screen. In the week just past, then, I made some likely-final tweaks and polishings of it: I touched up some text; I worked on the logic, placement, and transparency of an animated element; and I finalised the music to be used (different now from that used in the previous demo, I believe).
Hopefully this screen is now ready for the next demo!
Similarly, I made some changes to the “contact” dialogue that can be opened from the main menu.
To start with, it now uses the button made for the end-of-demo screen.
Perhaps more notably, the button-texts have been shortened, each now showing only a one-word name for their destination; the full URLs are now parenthetical in labels beneath. The result is far more readable and appealing, I feel!
And finally, I added a link to the TIGSource devlog to the list of buttons there.
Here, then, is the result:
On the game-logic side, I made a tweak to the handling of the examination of objects within the game.
This was prompted by an issue that I’d discovered in the conclusion to the upper puzzle in level five: when it was completed, multiple “character-thoughts” were initiated, conveying the protagonist’s response to the discovery made there, and indicating what next to do. This worked well enough. However, these events occurred with the player looking at the bookshelves of that puzzle. As a result, clicking through those “character-thoughts” (without moving away) resulted in examination of the bookshelves, and thus multiple iterations of the response to that examination.
And indeed, it makes sense that while clicking through responses, the player may not intend to examine something new–let alone multiple times over.
That said, I do want players to be able to examine objects while a preceding “thought” is showing: requiring that they first click away the “thought” seems cumbersome, and may disincentivise examination.
So, after some thought on the matter, what I implemented then was this: examination occurs only if there are no “thoughts” in the queue, waiting to be shown; if there are no more queued–even if one is showing–then examination occurs as before. This means that when there are multiple “thoughts” to click through, the player won’t be flooded by unintended examinations.
It’s not perfect: when the last “thought” in the queue is removed and shown on-screen, the logic once again allows for an unintended examination–but at the least only one, and not several!
Sticking with game-logic, with the new minigame for the upper puzzle pretty much settled, I added an accessibility mode for it. This provides a much-simplified version of the puzzle, perhaps useful for those who either don’t like the experience or have trouble with it:
The geometry for level five also saw work in the week just past.
I polished the rough form of the mezzanine; worked on the collision geometry for the railings there; and added a material where it was missing.
But perhaps most saliently, I put in place the model for the staircases that would provide easy access to the mezzanine–if only they weren’t very much locked, and quite unpickable for our protagonist.
These are tall iron-cage stairwells, decorated with curving ironwork designs, and having an iron-barred gate at top and bottom.
Furthermore, I added logic-objects to the gates, and a sound for basic interaction: the player can attempt, in vain, to open them.
I’m fairly happy with the way that they turned out, I believe!
However, not long after setting these in place, I activated the frame-rate meter–and found it to be showing a value below sixty frames-per-second! (I forget quite what it showed; somewhere between forty and sixty, I think.)
Concerned, I set about investigating the issue. I used Panda3D’s performance-grapher and its scene-graph analyser to look for an obvious problem. I tried deleting various elements using one of Panda3D’s graphical tools. I experimented with exporting various sub-sets of the level’s geometry.
(I also tried merging various elements to reduce the node-count, but this seemed to actually backfire a bit. Conversely, reduction of the vertex-count in one set of elements may have helped a little.)
In the end, it looks like there were two elements that accounted for much of the problem, and two problems in effect.
The two elements were the iron staircases, and the books.
The two problems were the overhead of rendering everything to the shadow-buffer, and–I think, at least–overdraw.
The former of those problems was at least somewhat ameliorated by excluding certain elements, in particular the stairwell and the books, from shadow-casting. It’s a pity to not have shadows cast by the stairs, but so it perhaps goes.
The latter of those problems is trickier. I’m not employing deferred rendering–I’m simply not familiar with the technique–which means that full shading is applied to all non-culled surfaces, even if they’re hidden by a later-rendered object. This can be reduced by controlling render order (and I’ve done so here)–but that, I fear, only goes so far.
What changes I’ve made have at least brought the frame-rate up above sixty frames-per-second on my machine, I believe. More than that I don’t know; I want to explore some possibilities, but don’t yet know whether any of them will help.
And finally, I made some changes in the week just past that don’t seem worth detailing here.
That then is all for this week–stay well, and thank you for reading! ^_^