Summary:
In which prefabs are done; prefabs aren't as easy as I'd hoped; Blender-scripts prove very useful; ladders may be placed in Blender; blob-light purviews are improved; stepping off of ledges is addressed; and the resolution drop-down is better populated.
Greetings and salutations!
For this week's screenshot, support for adding ladders in Blender--on the left, a view in Blender; on the right, a view of the same in the game:
The week just past was primarily dedicated to work on the second level, or work related to level-building, with a few excursions into other matters. Let me elaborate:
First of all, I believe that I've finished the prefabs that I recall that I previously showed. Alas, these aren't quite as convenient as I had hoped.
For one, I had hoped to keep the underlying geometry the same between collision and visual geometry. This might have allowed me to edit one and have the change be reflected in the other, and additionally allow me to work with relatively simple geometry.
To that end, I wanted to use Blender's "bevel modifier" to smooth the visual geometry on export. And indeed, this looked promising at first. However, it turns out that it produces some iffy geometry in some cases that were fairly common in my geometry, and there seemed to be no other modifier that might easily fix it.
It was a frustrating problem, I fear, and in the end I decided to abandon my attempt at using shared geometry in this way. It means that edits will likely call for duplication of effort, but so it goes at the moment, I fear.
More positively, I've created a few small Blender-scripts that seem to make my workflow significantly easier.
My favourite is a script that takes a collection of prefab objects, one of which is the active, "target" object, then finds the "base" objects of those prefabs. It then creates constraints that connect the two sets such that one ends up on top of the other--thus allowing me to construct building-storeys without the fiddliness of placing and aligning them by hand.
The other script that I'm finding useful is much simpler, but quite handy: it quickly links and then unlinks the object data for a set of objects, allowing me to essentially copy one mesh over a set of others. This allows me to quickly and easily re-use edited meshes in my prefabs.
At one point I discovered to my annoyance, I believe, that at least some of my prefabs had offset origin-points, which meant that when an upper storey was rotated, it went out of alignment with the storey below. However, simply resetting the origin of the prefab bases caused other elements of those prefabs to become misaligned.
So I wrote another (hopefully once-off) script. Roughly speaking, this one found the "base" objects of each prefab, reset their origin-points, and stored the resultant offset of this origin-point. This was then applied to the objects that depended on each base, offsetting both their origins and their positions.
The buildings of the second level seem to use ladders fairly often. But since I'm still prototyping the traversal elements of this level, and may change things as I go, I don't want to have to make edits in both Blender and my level-editor. It would be rather more convenient to be able to place my ladders in Blender.
To this end, I've added support for doing just that: I can now create an object in Blender that specifies the location, rotation, size, and model-file for a ladder; the game then automatically constructs the relevant ladder when the level is loaded. I suspect that this will prove quite handy!
I previously showed, I think, a "blob-light" being used the emulate light falling through a hole in the second level. There was a problem with this: it affected all nearby surfaces in that cell, meaning that it showed up in places that said light shouldn't much reach.
I tried simply reparenting the light to the roof-surface on which it should fall, but this resulted in the light not working properly at all.
As it turned out, my code was expecting the light to be parented to the cell, and its position was incorrect when it wasn't. I wasn't quite sure of why this restriction was in place, leaving me a little nervous about attempting to fix it. But attempt it I did, and fix it I did, I believe! The light in question now only affects the relevant rooftop.
For a while now, I've noticed a minor issue in my traversal mechanics: since the player moves quite fast, and accelerates rather quickly, it can be very difficult to simply drop down from a ledge. In the week just past I made an attempt to address this.
My current solution is, roughly-speaking, thus: If the player stops near an edge, then (without jumping) moves off of it and releases the movement keys within a short space of time, the character's horizontal velocity is zeroed, allowing them to simply fall.
This largely works, but it has some issues: First, I suspect that a certain distance-calculation will fail if the player steps off an edge at an angle. And second--and more serious, I feel--I've had occasional instances of the character hitting some obstacle on the way down, and being knocked off-course, potentially to die.
I have some thoughts regarding both, but I don't yet know whether they'll work...
A minor technical addition is that the game now requests a list of available resolutions from the system, and uses this to populate the resolution selection. When one or fewer resolutions are available, it adds in some fallback resolutions. In addition, the initial resolution of the game-window is added, and the list is sorted.
There was a complication with this: On my machine under Windows 8.1, I seem to get an awfully long list of resolutions. Panda3D's drop-down menu widget doesn't by default provide scrolling support--so I implemented a bit of hackery to provide it myself.
And finally, a number of changes were made that don't seem worth mentioning here!
That then is all for this week--stay well, and thank you for reading! ^_^