Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 09:30:07 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsA Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat
Pages: 1 ... 9 10 [11] 12 13 ... 32
Print
Author Topic: A Door to the Mists--[DEMO updated!]--traversal, exploration, puzzles and combat  (Read 63462 times)
Ian_A
Level 2
**


Indie Artist & Designer


View Profile WWW
« Reply #200 on: February 28, 2018, 01:40:10 PM »

Intro looks pretty good! I feel like you timed it well for giving the viewer enough time to read it. A lot of people mess that up.
Logged

CRIMSON KEEP - First Person Action Roguelite
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #201 on: February 28, 2018, 04:34:14 PM »

Thank you very much! ^_^

As to the timing, if I recall correctly I actually timed according to how long I expected it to take to speak the text, against the possibility of gaining voice-acting at some stage. I've actually worried that it was tiresomely slow when read (it can feel so to me, I think), and I'm relieved if that's not the case! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #202 on: March 05, 2018, 08:26:20 AM »

Blog post (5th of March, 2018)
Towards a Demo


Summary: In which work on the demo continues; contact -info and -buttons are added; the credits/legal screen is updated; new (stand-in) menu-music is selected; a short-story e-book is made; crowdfunding is investigated--and found (perhaps) problematic; and seeking a publisher is contemplated.

Greetings and salutations!

For this week's screenshot, a look not at something from the game, but at something adjacent to the game: the cover to a PDF e-book containing a short story that takes place in the same setting.



The week just past was a bit of a slow one again. But nevertheless, a few things did get done:

The first major part to the work of the week just past was in moving towards building a playable demo.

To that end, I've been working on the process of creating a distributable build with Panda3D. In previous versions of the engine, this involved running certain commands, using a special "rtdist" (which I think is short for "runtime distributable") build of the engine. This has changed for the version that I'm using at the moment; the new version seems, thus far, somewhat more streamlined.

However, it has also come with some issues.

First of all, this deployment method isn't yet part of the main branch of the engine, and certain fixes in the main branch hadn't been merged into its branch. I requested on the Panda3D forum that this be done, and it quickly was.

However, that introduced a new issue: at some point during development of the main branch, a new bug had been introduced that prevented the first level from loading. I sought out the commit that seemed to have caused it, and reported it on Panda3D's bug-tracking page. They requested an example that reproduced the issue, and I isolated it enough to create a short and simple case that did that. And thereafter the developers fixed the problem, and, at my request, merged the fix into the branch that I'm using. All of this was done in rather quick order, I'm glad to say!

But with that working, the build system itself continued to be problematic. Thus far, with help from the Panda3D forum, I've managed to deal with or circumvent a few issues, but a successful build is still a work-in-progress as I write this.

Aside from the build itself, I did a few bits of demo-related cleanup and polish-work during the week just past:

To start with, there is now a simple "splash screen" that appears before the main menu, stating that the version in which it appears is a demo, and giving some contact information. In addition, I've placed a "get in contact" button on the main menu. This brings up a dialogue with buttons that direct the player to various means of getting in contact with me, hopefully making it a little easier and more convenient to provide feedback.

The credits/legal screen saw some cleanup, with the text reflecting the new fonts and music-pieces in use, general cleanup, and some updates and additions to my own portion of the text. That last is rather brief and simple, and I'll confess that I worry a little that it isn't good enough--after all, I'm no lawyer. :/

And finally, I selected a new piece of stand-in music for the main menu, and cleaned up some issues with the logic thereof.

Moving away from the demo entirely, in the week just past I put together a little side-item: A PDF e-book version of a short-story set in the world of A Door to the Mists. It's a little extra that I currently intend to include with the full version of the game, and perhaps use as part of the promotion thereof.

This short-story actually pre-dates A Door to the Mists; it was written for a small forum-based writing competition a few years ago, as I recall. Its protagonist is a warrior of the nomadic Khayeht tribes. He embarks on a fateful raid on a neighbouring tribe--and discovers a situation much graver than he had expected. Much like A Door to the Mists, the mist-world has a significant place in the narrative.

The process of turning the original file into an e-book was fairly straightforward, hindered primarily by my unfamiliarity with the process and with the quirks of LibreOffice. And indeed, I think that I have the document done and ready!

I may have mentioned previously that I've been considering a crowdfunding campaign for A Door to the Mists. If not, then... well, I have. I started to look into this in earnest in the week just past. It's possible to run a campaign from this country, I do believe--others have done it, as far as I'm aware. However, it looks as though there may be some complications when crowdfunding from South Africa.

As I'm no lawyer, and not terribly well-versed in business, I fear, this makes me rather nervous. As a result, I'm considering looking for interest from one of the smaller indie publishers. (I'll only attempt this once the demo is out, and some feedback on it gathered, I intend--I imagine that it will help to have something to show.) And aside from allowing me to dodge my uncertainties regarding crowdfunding from this country, having a publisher might be a boon when it comes to marketing.

And finally, there were a number of other tasks done in the week just past that don't seem worth mentioning here!

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #203 on: March 12, 2018, 07:35:01 AM »

Blog post (12th of March, 2018)
The Question of Funding


Summary: In which progress in demo-building is made; the performance of a specific interaction is improved; and the question of funding is considered.

Greetings and salutations!

For once, this week I have no screenshot, I'm afraid: the week just past was a very slow one, I fear, and while some things did get done, they tended towards non-visual changes.

As to what was done:

The largest task of the week just past was perhaps the continuation of work towards building a demo. I believe that as of last week's blog-post I hadn't yet managed to complete a build. Well, with the help of the Panda3D forum, I passed that hurdle in the week just past!

However, the first resultant build crashed pretty much immediately after startup. Some of the issues in effect were fairly simple: including an additional "import" statement to tell the build system that I wanted particles, or fixing a library name that I had entered incorrectly, for two examples.

The first more-serious issue, perhaps, was with the language-scripts (which hold the various lines of player-readable text). Panda's new build-system automatically finds modules that are imported into a project in the normal way. However, it doesn't detect dynamic importation--such as I use for the language-scripts, as well as other elements, like level-scripts. As a result, the game was failing to find the language files, and keeling over.

Still, as it turns out, the build-system does allow the developer to direct it to any modules that might be dynamically imported. But this in turn prompted me to realise that I didn't want the language-scripts, at least, to be "frozen" into the build. I wanted them separate, to allow for the possibility of simply "dropping in" translations at a later date, should the game ever be translated. (Level-scripts and the like I'm happy to have "frozen" into the build, I've decided.)

I gave the matter some thought, and at the time found no terribly neat solution. As things stand now, the build-system produces a simple archive, so it's easy enough to just include the language-scripts in manually. For now, that works. For the future, I'm told that allowing the storage of nominated Python files by the build-system has been added to the "to-do list" by the developers.

The next--and current, at time of writing--blockage is related to the texture-references in models: for some reason the build system (or perhaps the tool that converts model-files, and which is used by the build-system) seems to be storing incorrect file-paths to model-textures, causing the game to once again break. I've reported this issue, and am waiting for a response!

Aside from work on the build, I made only a few changes. Most were minor, or were not kept.

The only one that seems worth mentioning here is that I improved the performance of a particular action in the first level: I had noticed that this action (breaking some loose tiles) incurred a pause that was brief, but palpable. Guessing that the problem was that I was loading certain assets when the action took place, I instead loaded them when the level-script started--and indeed, that brief pause seems to be gone now!

(While that action was the only one that exhibited a pause that I noticed, I went through the script and moved other instances of asset-loading to script start-up as well--it seems like better practice, to me.)

Moving away from the game itself, the other issue that I gave time to in the week just past was the question of funding.

Up until now I'd had a thought to perhaps crowdfund the game once a demo was out. Having researched that, it looks as though it's possible to do so from this country--but also that there might be some problems with it. As I'm working alone, and as I'm no lawyer, and not enormously confident with business-stuff, I'm now somewhat hesitant to pursue that path.

So I started looking into the possibility of finding a publisher. I've started research into this (and have a short preliminary list), but I still have some questions and concerns; I may well start one or more forum-threads, seeking advice.

On the other hand, a respondent to a query of mine on Twitter suggested one more possible path: finding an investor, of the sort that takes a specified financial return after release, rather than the sort that takes equity. As things stand, I'm not sure of how to find such a person. ^^;

And if anyone reading this has any advice or suggestions, please do share them!

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #204 on: March 19, 2018, 07:19:44 AM »

Blog post (19th of March, 2018)
First Steps Into a New Level


Summary: In which demo-work advances; UI support for language-selection is added; and work on the second level has begun.

Greetings and salutations!

For this week's screenshot, an addition to the options menu that provides UI support for language-selection:



(As I believe that I've mentioned before, I don't know that A Door to the Mists will be translated. However, I want the functionality to be available should translation become feasible.)

The week just past was rather more productive than the one before, I do think!

First of all, work continued towards building a demo. As before, this was largely a matter of discovering and fixing various problems, slowly working towards a fully-functional build. At time of writing, it's not quite there--but I've at least reached the point at which I can produce a build that runs all the way into gameplay under Windows!

One pitfall that I discovered was in my checking for the existence of files. Technically, this works fine, and seems in concept to be a good idea. The trick is that not all files are present in the final build, or are altered in some way. Specifically, Python modules are "frozen" into the build, and model-files are converted into another format.

The latter I had foreseen, and I was looking for files with the appropriate extension--what I hadn't foreseen was that said extension would be added on top of the previous extension. That is, the files start off as "<file-name>.egg", and I was looking for "<file-name>.bam"--however, the files were in fact being renamed as "<file-name>.egg.bam".

Thankfully, once discovered all such issues proved fairly easy to fix.

One of the problems that I think that I mentioned previously regarding creating a build was the inclusion of language-files. I had a work-around for this in manually adding the language-files after the build was completed--functional, but not ideal. I'm glad to report that in the week just past the Panda3D developers added support for nominating Python files to be copied into a build! This allows me to more-cleanly and reliably include my language-files, while retaining the possibility of dropping new ones in at a later date, I do believe!

Speaking of language-files, as shown above, I added UI support for language-selection. This was fairly straight-forward--the only really tricky bit was figuring out where to put it.

None of the extant tabs seemed to quite fit; it felt shoe-horned in all of them. I could have made space for another tab--but it would have had only one item under it.

However, there was that empty spot at the bottom-right, and after some deliberation, I decided to indeed place it there. For one thing, it means that someone looking to change the language doesn't have to hunt through tabs that may be in an unfamiliar tongue in order to do so.

I did realise that one thing still outstanding in language-handling is that per-language fonts don't yet fully work: while the font-variables are replaced, the fonts referenced in the actual GUI-objects aren't. Right now I'm hoping that an easy means of "reloading" fonts will be added to Panda3D, to save my replacing the font on each object individually!

The matters described above didn't occupy all of the week just past. And during the periods between, I started work on writing out the "canonical" version of the second level.

I may have described this process before, but just in case (and for any new readers), here is how I approach the start of level-design in this game: I sit down and write out the events of the level as a very rough short story. I follow the protagonist through the experience, noting the events and surroundings as we go. This I do on the computer, typing it up in LibreOffice--and while I do that, I also note down level-design and lore ideas in the paper notebook by my side.

As things stand, I've finished a first pass on the "short story", and begun a second. Meanwhile, the level-design notes are slowly filling out with ideas for traversal challenges, modifications to the levels for gameplay purposes, thoughts on lore, and so on.

It's not done, but it's a good start, I feel!

And, as is so often the case, there were a few things done in the week just past that don't seem worth mentioning here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #205 on: March 26, 2018, 08:45:04 AM »

Blog post (26th of March, 2018)
Step Less Quietly


Summary: In which performance gains are made; file-paths are a nuisance; climbing is slightly improved; and crouched footsteps are played.

Greetings and salutations!

Once again, this week has no screenshot, I'm afraid--while a number of things were done, they generally didn't produce changes that would be well-served by a screenshot, I feel.

One thing that I'm excited about is that in the week just past I finally made gains in improving the performance of the first level!

I remembered a very neat tool that Panda3D provides, "DirectTools", which provides amongst other things a tree-visualisation of the scene graph. In addition, it turns out, it allows the user to delete nodes at run-time. Thus I could experimentally delete various nodes, and observe their effect on the game's frame-rate.

And one object in particular turned out to be problematic: the ring of trees at the edge of the level, being the highest-resolution parts of the surrounding woods. I had this ring as a single object--and as it turns out, it was a massive one.

I asked for advice on the Panda3D forum, and one suggestion was to chop it up into several objects, thus allowing the engine to cull away some of it. I tried this, and it worked!

On top of that, I made a minor gain by enforcing simplicity on the rendering of the light-cameras: they don't require things like materials, textures, transparency, or multiple culling-bins, I believe, and so I've set flags on them to ensure that the engine acts accordingly.

Overall, the performance gain isn't huge--from about 62-63fps to about 67fps, I believe--but it's one that I'm happy to have. ^_^

As to the demo, work continues on that--and indeed, I think that there are only a few outstanding issues before it's ready!

As before, working towards the demo involved dealing with a few problems. One in particular proved to be a bit of a nuisance: file-paths.

In testing under Windows, I discovered that while the game was successfully writing save-files, it wasn't writing out the associated screenshots. Once again I sought help on the Panda3D forum, and one thing that it was suggested that I check was the file-paths.

Doing so, I found that I had an awkward mishmash in place: some elements used Unix-style paths (which I gather is what Panda's file-handling likes to work with), while others used OS-specific paths--which would be Windows-style under Windows. In some cases they could even be mixed in a single path!

Finding a good solution was a little tricky, but I believe that I have this fixed now. As I recall, the general idea now is to use Unix-style paths for the most part, only converting to OS-specific paths when called for (such as when passing a file-name to my save-game system).

On the gameplay side of things, I made some tweaks to the detection of surfaces to climb onto. Specifically, I found that narrow ledges could be a problem, especially when very near to the player. To solve this, I've simply had the ray-testing start closer to the player, and reduced the distance between testing-rays. It does slightly reduce the distance at which surfaces may be detected--but this distance was fairly large anyway, I feel.

I also made a few changes to sound-related matters. One that might be worth mentioning is the re-introduction of footstep-sounds when crouched. I had previously removed (or rather muted) these--but I felt that this left such movement a little too quiet. However, I didn't want crouching to be accompanied by the normal footstep sounds--I don't think that those really match crouched movement.

So what I've done is re-instate those sounds, but played more slowly (at about half-speed, I think it was). This produces something a little different to the usual noises, but still recognisably similar. I'm not sure that it's quite right, but at the least it does for now--and is better than near-silence--I feel.

And a number of other things were done--fixes to bugs and oversights, changes, work on the second-level draft and notes, etc.--that don't seem worth detailing here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #206 on: April 02, 2018, 10:43:08 AM »

Blog post (2nd of April, 2018)
Level-Building Uncertainties


Summary: In which the demo makes incremental progress; work on building level two is begun; there are uncertainties as to how to go about this; a shader is experimented with; and climbing bugs are fixed.

Greetings and salutations!

This week's screenshots show some early steps in building level two:




The week just past was a moderate one, I feel, with a number of things being done:

First of all, a little progress was made towards getting the demo ready to release.

Specifically, I had an issue under Windows in which the cursor seemed to be vertically offset, making its use awkward. The solution was fairly simple: just use a ".cur" file (which includes hot-spot data), rather than a ".ico" file (which doesn't). It was slightly complicated by "icotool"--the tool that I use under Ubuntu to convert files to ".cur" format--perhaps not recording the data as expected. I ended up getting a hex-editor and, referencing a Wikipedia page on the file-format, setting the appropriate bytes as called for!

(Right now, I think that the only thing yet to be done for the demo--aside from some basic cleanup of which files are included--is to read through two third-party licences, checking that all is well there, and editing my "credits/legal" file if called for.)

But perhaps the main work of the week just past went into a start on roughing out level two; some of the level's current state is shown above.

(The in-game level-file is currently named "level2_future", as the demo already has a file named "level2". I'll presumably rename the new level once the demo is done!)

I've been somewhat uncertain of the best way to approach building this level.

For one thing, this level is larger than the previous, so my written draft doesn't include every building. This leaves me feeling somewhat afloat when it comes to the specific layout of the place.

Further, I learned in building the last level that while prototyping, it can be a nuisance to have to copy-paste objects between Blender-layers in order to keep the visual- and collision- geometries matching.

And finally, with a number of buildings to construct, I want a reasonably easy method--perhaps something involving prefabricated elements--rather than hand-constructing each.

For the copy-paste issue I think that I've found at the least an improvement on my previous approach: Blender allows me to give two objects the same underlying data, meaning that a change to one is reflected in the other--while nevertheless allowing them to have different tags (such as indicating collision geometry).

I'm still a little uncertain about how to improve my construction efforts; I may do some research into what other developers have done.

As to the layout, what I currently have in mind is to sketch a layout on paper, based on my written description. We'll see how that goes, I suppose!

(I'll confess that I have gone slightly beyond bare "grey-boxing"--I've added a trigger for the "player-light", and a "blob-light" to emulate light falling through the hole that you see above. This is simply a part of the way that I work, I feel--I seldom stick purely to one thing or another.)

On the visual side, I discovered in testing a build of this new level that the player-light didn't extend quite as far as I wanted it to. I've thus increased its range a bit. (This may even improve visibility in the prologue level, where the dark colour of the stone makes things murkier than with the lighter stone of the first level.)

I also experimented with a "painterly" post-process shader. The technique showed some promise, I feel--and didn't seem as heavy on performance as I'd feared. However, it also wasn't to my satisfaction, so for now I've shelved it.

On the technical side, experimenting with climbing in the second level led to the discovery of a new bug in the climbing mechanic, which could occasionally result in the player-character being stuck in a wall! Worse, it led me to discover further problems in the system. I think that I have all of it fixed now, but--as with the previous such bug-fix, I believe--it was a process that incurred some anxiety.

And finally, there were once again some changes that don't seem worth mentioning here.

So that then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #207 on: April 09, 2018, 08:53:59 AM »

Blog post (9th of April, 2018)
Architectural Work


Summary: In which I try to figure out how to design and build level two; level -prefabs and -props are made; the sky sees some updates; and a feature from one shader is copied into another.

Greetings and salutations!

This week, I have two things to show by screenshot or gif. First, some changes to the sky-shader; and second, various prefabs and props that I've been working on for use in building level two:





The main work of the week just past was focussed on level two--but a few other things saw progress, too.

I mentioned last week, I believe, that I intended to sketch a level-layout on paper, and I indeed tried that in the week just past. This did help to some degree, I do think: while I didn't come up with a full level-layout, I think that it helped me to solidify the basic progression that I have in mind for this section, as well as some of the gameplay challenges that I want to present.

But I wanted a means of more directly experimenting.

I could build simple grey boxes quickly enough in Blender--but these wouldn't model the interiors of buildings, which I do intend to play a part.

Conversely, modelling each and every building individually would likely take a fair bit of time, and perhaps be a bit slow for experimentation. And indeed, I don't want to build each final building from scratch, either!

Instead, I came to the idea of building "prefabs": various sections of building that can be mixed and matched to create a variety of (simple) architectures. These can then be individually edited as called for--breaking this one's walls, filling another with rubble, adding a hidey-hole here, and so on.

To start with, I sketched out various elements of the architecture of this region: building floor-plans, illustrations of various individual pieces, etc. From these sketches I could then start to build 3D models.

But there's another problem: The game calls for both visual and collision geometry, and these don't share a common "parent" node. But keeping them entirely separate means that it's easy for them to go out of sync., either in position or in geometry. Conversely, in some cases they should differ, with the visual geometry generally being more complex than the collision geometry.

What I've settled on for this is a slightly-complex setup: Where appropriate, visual and collision geometry share underlying meshes, allowing changes in one to be reflected in the other. Further, shared meshes between different prefabs allow quicker editing while the prefabs are being constructed.

Further, Blender allows me to use constraints to match positions and rotations. Where that becomes problematic (due to offsets in position, thus far), I've found workarounds, such as parenting one visual element to another, and then constraining the associated collision geometry to the visual.

I've also created a number of miscellaneous items that might affect traversal--stairs, water cisterns, toilets, and so on.

All of these currently use stand-in textures taken from previous levels; since the materials are shared, it should be easy enough to simply replace the texture-files being referenced once I make the textures relevant to this level.

With these pieces, I hope to relatively-quickly build up the section of city in which this part of the level takes place. Once again, we'll see how it goes!

Moving away from level two, I also made some changes to my sky-shader. I had been a little unhappy with the way that it handled the sky near the sun: the mapping resulted in a radial pattern that I found unsightly.

So, I worked on a new mapping, applying a radially-patterned texture with its centre at the position of the sun. It took some time to figure out, but in the end I did get it working, as I recall. However, I also discovered that this pattern doesn't tile nicely, meaning that the texture ended up somewhat stretched.

In the end, I returned to my previous mapping--but faded out the pattern near the sun, hiding the radial artefact.

In addition, I found that the sky was no longer flaring when the player looked to the sun. I fixed this, and then went further, intensifying the flare and having the "painted" texture apply more strongly to it.

Finally, I made the sun less diffuse, more a bright, solid circle.

Overall, I think that I rather prefer the way that the sky now looks!

And last, a minor change: I copied the saturation control from my "sunlight"-shader into my "player-light"-shader, allowing me to apply the same effect there.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #208 on: April 16, 2018, 10:24:53 AM »

Blog post (16th of April, 2018)
Adventures in Blender


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! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #209 on: April 23, 2018, 09:31:31 AM »

Blog post (23rd of April, 2018)
Construction Work


Summary: In which prefabs see changes and fixes; level-building is started in earnest; a new window may aid workflow; window- and door- frames are being added; and ladder-generation code is tweaked.

Greetings and salutations!

For this week's screenshots, some work towards level two, in both prefabs and level-building:




The week just past was a bit of a slow one, perhaps, but nevertheless not without its progress, I feel:

First of all, as shown above, work went into the second level, and the prefabs being used for it.

Regarding the prefabs, the most salient change is the composing of a set of new pre-constructed buildings, using the simpler prefabs already made. I'm hoping that these will enable me to more-quickly populate the level with buildings.

Aside from that, a number of lesser tweaks and changes were made, either improving the appearance of the prefabs or fixing various issues.

One nuisance that I discovered was that the constraints used to link building-storeys together didn't work quite as I had expected. Specifically, while they did indeed match position and rotation, they did so separately, and the offset in position was unaffected by rotation. Thus, rotating a base storey resulted in the storey above turning in place about its own axis, potentially separating from the base until the latter's rotation brought it back underneath the upper storey again.

Thankfully, I discovered that Blender also offers a "child of" constraint--separate from an actual "parent-child" connection--that doesn't seem to produce this issue. I've now updated the storey-making script, as well as the compound prefabs, to use this new constraint in place of the old ones.

As to the level itself, I've begun in earnest the work of laying it out.

Thus far I have a small initial section, and the start of the first significant traversal elements of the level (as well as the end of the last). Here the player may find that the direct route to their goal is blocked--but exploring in the other direction reveals a path onto the rooftops, and from there around and over the blockage.

In working with my prefabs, I started to feel that moving back and forth between the region that contains the level itself and the region in which the prefabs are stored became a little tedious.

Seeking to make this easier, I tried opening a new Blender window, hoping that it would allow me to work on the same file from two windows. And it did! Furthermore, if I save the file with both windows open, it restores both on reloading! This has allowed me to create a smaller "palette" window focussed on the prefabs, in which I can select and duplicate them before moving them into place in the level.

I haven't yet really tried out this new workflow, but it seems like a good idea, at the least. (And is a neat feature on Blender's part, I feel.)

Up until now, I had planned on leaving such details as window- and door- frames out of my prefabs, only adding them later. This was born, I think, from a thought that adding them early on went against the idea of rapid prototyping.

However, I realised in the week just past that by leaving them out entirely, I was somewhat setting myself up for adding an awful lot of window-frames one-by-one at the end of construction. To avoid this, I've begun work on modelling them, with the intent of now including them in the prefabs.

I do have one uncertainty: should I join the window-frames of a given prefab into a single model (or more likely, one per prefab-side), or leave them separate? The former might be better for performance, while the latter might allow me to keep them internally connected, enabling edits later on.

My thought at the moment it to keep them separate, perhaps to be merged at a later stage, once their model is completed.

I also made some tweaks to my ladder-generation code: it now automatically adds a number to each ladder's name, rather than relying on the game's name-conflict code, and provides a display-name, so that a separate name-entry isn't called for with each ladder.

And finally, I made a few other tweaks and fixes that don't seem worth mentioning here!

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #210 on: April 30, 2018, 08:39:54 AM »

Blog post (30th of April, 2018)
Slowly, The Level Grows


Summary: In which level two continues to grow; window- and door- frames are added; placeable planks and ladders are considered; movement speed is increased; and ladders see some tweaks.

Greetings and salutations!

For this week's screenshots, an overview of level two as it currently stands--still incomplete, and work-in-progress, but slowly building up, I feel:




The week just past was a little slow, I feel. Still, a few things did get done:

To start with, work continued on level two. Indeed, this week I started using my "palette" window in earnest, and while it's not perfect, I think that it does help.

My approach thus far has been to simply lay out buildings somewhat arbitrarily, then work and rework both the layout and the buildings therein as I figure out a main traversal path. So far I think that it's been working, but it remains to be seen whether this is indeed true, and whether it continues to work.

I'm honestly still not confident of this approach; I feel as though there might be some better way, but I'm not seeing it right now.

Still, I feel that I've made a reasonable amount of progress here.

One thing that I've noted is that alternate routes are already springing up, just by virtue of the traversal mechanics. Some of these I've removed, especially when they would make things too easy. Others I welcome, however, especially when they provide different opportunities for exploration.

I also did some work on the prefabs themselves. One significant part of this was in adding window- and door- frames to the various buildings. And I'm glad that I did: It was tedious enough to add them to what I had (including the small amount of level already in place at the time). How much more it might have been had I waited until the level was complete to add them!

I was quite amazed by the effect of adding these frames: where before the buildings had felt somewhat fake, I think, the simple addition of window- and door- frames left the them feeling much more convincing!

Speaking of traversal, I gave some thought to the ideas of placeable planks and ladders. The former I think that I won't implement, while the latter I may well.

The planks would have been carriable objects that could be set down across gaps, allowing the player to make their own paths to an extent.

In concept, this is fairly simple. With more examination, however, it appears somewhat more complex, as obstacles and corners become involved. In the end, I decided that it was better to leave it: I shouldn't be adding major features at this point, I feel, and this seems as though it would call for a fair bit of development.

The ladders would similarly be carriable objects, and similarly allow the player to place paths of a sort.

However, I think that it might be possible to create a version of these that would be fairly straightforward. Perhaps not perfect as I current envision them, but conversely not too far out of scope. We'll see going forward how this works out...

On the technical side, I decided to make the player-character move a little faster, and produce footstep sounds a little more rapidly.

The latter is, as you might expect, connected the the former. However, I did find that increasing the pace of the footstep sounds resulted in the scene feeling more urgent to me. As a result, I've tried to strike a balance, playing the footstep sounds at a pace that reasonably matched the movement speed, but that didn't sound too urgent--I hope!

As to the movement speed, I found during testing that on the larger, more open spaces of this level the previous movement speed felt a little too slow, a little too "stodgy", perhaps. When I approached a ledge to jump forward, I didn't feel that I was running at it, as I found that I wanted.

On the other hand, I don't want movement to be too quick, as that may interfere with exploration.

I could add a "run" button, but that adds to the already-long list of controls, and may encourage players to speed past opportunities for exploration.

So, as with the footstep sounds, I've attempted to strike a balance--to find a pace that feels fast enough for traversal, but that's slow enough for exploration. So far I'm fairly happy with the new speed that I've set--but I have yet to go back to previous levels to see how it works there.

Finally, I did some work on the ladders in the game.

On the minor side, I fixed a bug in the ladder-generation code. I also experimented with making them "solid", but found that this complicated matters.

Perhaps more interesting, I implemented support for moving the player to the centre of the ladder, and to the correct side of it, when taking hold of one. Previously, the player simply stuck to the ladder in place (aside from moving up and down, of course). This meant that they could climb the edge of a ladder, and so--aside from this feeling odd--could end up colliding with the ceiling or floor, preventing their reaching the end of the ladder.

So, I implemented a means of moving the player to the centre of the ladder. This isn't simply a linear motion, however: when the player takes hold from the side or back, they now swing around the ladder, before transitioning to a more linear motion.

It isn't perfect--the player can sometimes seem to "wobble" a little when gripping from certain positions--but I think that it's much better than the previous state!

I considered having the player's view automatically rotate to face the ladder. However, I realised that this conflicted with the player's ability to freely rotate on ladders, which I feel is useful in traversing from them. So, while it might be odd to approach a ladder from behind, swing onto it, and find oneself facing away from the ladder, I feel that it's better than the alternative.

That's all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #211 on: May 07, 2018, 11:40:53 AM »

Blog post (7th of May, 2018)
Ladder Carriage


Summary: In which ladders may be carried; carriable objects are (hopefully) a little more intuitive; level two continues to see work; and the level's culling problems may have a solution.

Greetings and salutations!

For this week's screenshot, a look at the newly-placeable ladders:



The week just past was another slow one, I feel, but once again some things did get done:

First of all, I mentioned last week, I believe, that I was thinking of implementing carriable ladders. I attempted this in the week just past--and indeed, it ended up taking a fair chunk of the week to complete!

One reason for this, I think, is that the two systems in question--ladders and carriable objects--somewhat fought each other. For example, carriable objects have their origin-point at their centres, while ladders expect their origins to be at either their top or bottom. Thus the calculations of one or the other might be unintentionally offset.

But in the end, I believe that I have everything working! Some of the sounds may be replaced at some stage, but everything seems functional, and I think that it's a neat new traversal tool. ^_^

There was a brief period in which it was possible to place a ladder, climb it, and then--while still holding on--pick it up again and place it elsewhere, resulting in the player sliding over to its new position. This was actually kinda fun and amusing for a short while, but nevertheless I made a point to remove this little bug.

While working on this, I made two salient changes to my handling of carriable objects:

First, carriable objects are now placed down facing the player, where before they had retained their original orientations. This feels a little more natural and intuitive to me, I think.

Second, the action-icon for placing a carriable object now changes to reflect whether or not an object can be placed. This, I hope, is a little more convenient than relying on perception, intuition, and simply trying to place the things.

With these features done, I returned to work on level two. Overall, I think that I'm making progress, with the traversal for the level slowly building up.

There was one problem, however, and that was with portal culling:

As the level has grown, I began to feel that it was time to start separating it into sections for portal culling. However, as it's in a fairly open space, that becomes awkward; portal culling, I think, works best with narrow passages between sections. In some places that's easy enough, but in others I don't really want to narrow the layout down into choke-points. Furthermore, with the multiple, broad portals that I was using, performance seemed to actually decrease.

Now, it's entirely possible that I was doing something wrong. Nevertheless, I was alarmed, and started thinking about a different approach.

What occurred to me was that the player-light really only extends so far; beyond that, all is black. So I could simply hide sections of the level that are too far away. (It isn't as easy as this under the "sun"-light, but I have an idea or so for that, when I get to the later level that may call for it.)

Thus I experimented with splitting the level (which thus far lies on a more-or-less narrow, straight line) into a series of roughly-equal chunks. At any given time, only the current chunk and those to either side are shown; all others are hidden. Then on each update I check the player's position with some simple maths, and if a new chunk has been entered, I adjust the visibility of the chunks accordingly.

There are some challenges with this, but the experiments suggest that it may indeed perform better in this scenario than portal-culling!

And finally, I made a number of minor changes and fixes that don't seem worth mentioning here!

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #212 on: May 14, 2018, 10:48:23 AM »

Blog post (14th of May, 2018)
In the Grid


Summary: In which a grid provides culling; said grid may support simplified "distant geometry"; level two's traversal is nearly laid out; and work has been done on a distantly-seen light in level two.

Greetings and salutations!

For this week's screenshot, an overview of level two as it currently stands (once again work-in-progress, with stand-in textures, and seen under the sun-light for the sake of broader visibility).



The week just past was perhaps a little bit slow, but also perhaps less so than the one before:

Perhaps the biggest change was the implementation of grid-based culling.

You may recall that I mentioned in last week's blog-post that I had experimented with splitting level two into chunks, and showing only the current chunk and those to either side. The new grid-based culling system is a generalisation of that (and properly implemented, as opposed to the experiment mentioned last week).

An initial uncertainty, as I recall, was that of where to implement it. Should it be included into the manager-class used for portal-culling, or made a thing of its own?

In the end I went with the former: It simplified matters, especially in allowing me to treat the grid as just another set of cells, with specialised handling kept internal to the manager class. In addition, that manager class seemed like an intuitive place to keep this. Furthermore, to external classes nothing much has changed: they still query their current cell, get placed into cells, and so on--it's just that now those cells are sometimes grid-cells.

Another question was that of what to do when geometry suddenly vanished. Under the sun-light, or in player-lit areas that have distantly-visible blob-lights, this could result in chunks of the level visibly disappearing.

Now, in the case of level two, there are few lights that aren't the player's, and so the geometry should be effectively blacked out when distant enough to disappear. But even so, when the geometry vanishes it can reveal the sky behind, which shouldn't be visible down there in the dark.

My answer right now is to have each grid-cell optionally store "distant geometry".

In the case of level two, that amounts for now to large black boxes, designed to block the sky behind.

In other levels however (or if I find it called for in level two), this might instead hold simplified (perhaps slightly stylised) depictions of the standard geometry. The hope is that this would allow distant areas to remain visible, but still provide a boost to performance.

One caveat is that the change between standard and distant geometry is somewhat sudden. As a result, it might be worth taking care that the level-layout obstructs anything more than one cell away when the player stands at the edge of a cell, allowing the switch to be made out of sight. (Again, this shouldn't be a problem in the darkness of level two.)

(And there might be some changes called for in order to get the blob-lights working quite correctly--but I think that this should be fairly straightforward.)

Overall, however, the system seems to be working quite well thus far, and I'm fairly happy with it! ^_^

Of course, level two is still more or less a long "cavern" (or enormous corridor), narrow and straight, walled-in on either side. In this case, the "grid" effectively becomes a linear sequence, there being no point in splitting it up along the narrower horizontal axis. As a result, the behaviour of a full grid has yet to be tested; I think, however, that the next level should provide an opportunity for that.

The level itself also saw continued work in the week just past--and indeed, I think that I have the traversal near-completely laid out! (Or a first draft thereof, at least.)

In addition, I've started work on the logic to handle a particular distant light, intended to give the player some direction in this level. In short, and roughly-speaking, the idea is to fire a set of rays from the light's source to the player. If at least one of these hits the player (as opposed to hitting level-geometry instead), a light-flare would be made visible; if not, the flare would be hidden.

This feature of the level is only in its early stages, however. (For one thing, I have some hole-making to do in the level in order to provide an unbroken line-of-sight when crouched (the ceiling is low there) at the first place from which the light is intended to be seen.)

And as is often the case, there were a number of minor fixes and changes that don't seem worth detailing here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #213 on: May 21, 2018, 09:25:22 AM »

Blog post (21st of May, 2018)
A Distant Light


Summary: In which a distant light suggests direction in the level; the level gains a ceiling; the level continues to be otherwise built; movement on ladders and ropes is a little more responsive; and falls produce pain only from a greater height than before.

Greetings and salutations!

In this week's screenshot, a distant light gives some direction in the darkness of level two:



The week just past was rather slow, I'm afraid: a number of things compounded to either pre-empt work, or (I think) slow me down when I was working, I believe. (Not all of these things were untoward, however!)

Still, some work did get done:

As shown above, there's now a little direction given to the player in level two: a distant light, growing larger as one draws near. It's not always visible--indeed, it's seldom visible, as intervening structures obscure it. But I've made a point of having it be visible from that first rooftop (although from some positions the roof itself hides it), and it shows up in one or two other places along the way.

Now, you may wonder why it's visible at all. After all, I remove distant geometry, and at current I replace that geometry with huge slabs of pitch-black geometry. The answer is simple: that light isn't really where it appears to be. It is, in fact, attached to the player's camera. It simply rotates and scales itself so that it appears to be located as intended, and uses ray-casts to determine when to be shown or hidden (fading -in and -out as it does).

Aside from that, I put in further work on the level itself.

One part of this that might be worth noting is that I've put in a first-draft of the stepped "ceiling" of this level; no more the open sky above!

For the sake of the distant light mentioned above, I've been careful that the steps of this ceiling never pass significantly into a narrow cylinder of space lying between the source of that light and the entry to the underground part of the level. Furthermore, I've applied some damage to some of the buildings in the level in order to allow this cylinder through.

I've also continued work on the traversal of the level--it's not quite done, but it's drawing closer, I think.

On the technical side, I've made two changes that seem worth mentioning:

First, I've increased the player's acceleration when climbing ladders and ropes: I had found that when the player dropped down and caught a ladder, the previous level of acceleration could result in the character feeling somewhat unresponsive when attempting to climb up. Simply put, the slower acceleration meant that it took a little too long (I felt) to overcome the character's downward speed and start moving upwards instead. With the change made, the character feels much more responsive on ladders, I feel!

Second, I've increased the height from which the character expresses pain on landing. You may recall that while the character doesn't take damage from falling, a sufficiently high fall can result in death. Between the "death height" and another, lesser height, the character is simply "pained", serving as a warning that death is a possibility.

However, I'd started to feel that the "pain height" was a little too low--that is, that too small a drop produced such a reaction. For one, it felt to me that the character was being hurt a little too easily. For another, I worried that it might discourage jumping and dropping down.

So, as noted above, I've increased this "pain height", and I think that it feels better this way.

And finally, once again there were changes made that don't seem worth describing here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #214 on: May 28, 2018, 08:49:13 AM »

Blog post (28th of May, 2018)
Hidden Interactions


Summary: In which level two's traversal draws nearer to completion; non-traversal elements and interactions are introduced to the level; some interactions are hidden; a conversation is added; the "Conversation Editor" causes confusion (and is renamed); and a glass shader is begun.

Greetings and salutations!

For this week's screenshots, a few images from around level two:

(All of course work-in-progress, and using stand-in textures. The bookshelf is a stand-in too, borrowed from the previous level.)






The week just past was a more productive one than the previous, I do feel! Let me elaborate:

I think that I have much of level two's traversal done now--or a first draft, at least. Indeed, I think that it's possible to traverse almost entirely from start to finish, with only the final step incomplete and untraversable. I do still want to look into some possibilities for alternate paths, find places for a few additional interactions, and block off at least one overly-convenient shortcut, but I think that it's largely done.

I also worked a little on the line-of-sight involved in seeing the distant light; there are now three places along the level from which the player might reasonably spot it, if I recall correctly.

With the traversal shaping up, I've moved on to work on some of the non-traversal elements of the level.

For one, note in the above images that lone bookshelf, standing at the end of a long room. From this section of the level, there should be no clear way forward, no apparent means of progression.

But what's not shown (because I haven't added the visual part of it, yet) is that a set of scrape-marks lie to one side of the shelves. There is no indication that these are interactive--until the player attempts to examine them. After examining them, if the player then examines the bookshelf, the player-character speculates that it might be moved, and the player is given the option to push the shelves. Doing so reveals a hole behind, which in turn opens onto the end-most section of the level!

Another (not shown above) sets up this "hidden interaction" mechanic. (Well, reinforces it, as it appears briefly in level one as well.) Here the player is confronted with a similar situation, but a little more obvious: a large pile of debris (not yet modelled) blocks a large but visible hole. The debris isn't initially interactive--until the player examines it, and the character remarks that it might be moved. This opens up an interaction prompt, allowing it to be cleared away and thus giving access to the hole and progression.

A third example is shown above: A wall with a single stone plate that looks a little different to its surroundings. (Although it will hopefully fit in a little bit better once I replace the textures being used for this level.) Examining the plate allows it to be removed, revealing a small cache of books hidden behind, from which a collectible may be taken.

Moving away from hidden interactions, I've placed the pieces (if not the models or logic) for a little scene that may be found partway through the level. It's still rather nascent, however.

When the player reaches the most-distant part of the level, they find there the adventurer who they've been seeking, hoping for information on the mysterious city of "Catol". I've begun implementing the conversation for this (and indeed, it's largely in).

A minor part of this was the addition of a "done script" to conversations: simply put, the game can now run a script-method when a conversation concludes, allowing changes to be made. In the case of level two, it allows me to update the player's goal after talking with the above-mentioned adventurer.

Now, when I set out to build the conversation in question, it's perhaps unsurprising that I went to my "Conversation Editor" to do so.

When I ran it, it crashed immediately--but that was quickly exposed as being the result of changes made since the last time that I used it, and was quickly fixed, I believe.

However, as I attempted to make a new conversation in it, I continued to hit crashes. I was a little mystified, as I recall--surely I had used it to create the conversations in level one, after all! Nevertheless, I set to work on fixing them, and made some progress in doing so.

And then I remembered that, no, I no longer use this editor for conversations!

Since I reworked the way that conversations function, they're simply sequences of lines to be said and speakers for those lines, specified in text- and Python- files. The "conversation" part of the "Conversation Editor" was a relic of an earlier, more-complex approach to conversation in the game.

I created the relevant files for the new conversation, and indeed it worked as expected!

Since that editor is, I think, still used for books, I've now removed most references to "conversations" in it, and have renamed it to "Book Editor". Hopefully this will forestall some confusion later on!

That said, the fixes that I embarked on did turn up a lurking--if very minor--bug in the conversation system. In short, at some point the error produced by Panda when failing to read a file was changed, meaning that I was catching the wrong error in my code. It's a quick thing to fix, I do believe!

The last thing to mention is that I've begun work on a (very) simple "glass shader"--just a transparent shader that becomes opaque at the edges, to suggest the properties of glass. This is still a work-in-progress, however.

And once again, changes were made and bugs fixed that don't seem worth mentioning here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #215 on: June 04, 2018, 10:46:23 AM »

Blog post (4th of June, 2018)
A Tale of Two Particle Panels


Summary: In which player-light- and glass- shaders see work; blob lights can be softer or harder; conversations can be extended; Panda's particle panel gives trouble; a new particle panel is embarked upon; and a vertex-shadow shader is begun.

Greetings and salutations!

For this week's screenshot, a new (work-in-progress) particle editor:
(The particle effect shown isn't anything intended for the game--it was made simply for demonstration purposes.)



The week just past was a bit of an odd one, as I was diverted from my usual work into a bit of tool-creation--specifically, the creation of the particle-editor shown above. Let me explain:

To start with, work continued as usual.

I made some minor adjustments to the player-light shader--specifically, I forced it to produce absolute darkness beyond a certain threshold. This, as I recall, was done to reduce the likelihood of odd monitor/graphics-card settings showing areas that should be entirely in darkness.

I also continued with my glass shader, which I believe that I mentioned last week. As it stands, this isn't perfect (and I have some ideas that I might try), but it's working. I actually ended up taking an idea regarding the edging of the glass from a shader that I made for a game-jam.

Blob-lights also saw some work--they can now be "softer" or "harder", making them a bit more flexible. For one, this has been employed in the light that shines through the entrance to the level proper from the room outside it: Where before the light was somewhat concentrated at its centre (which I wasn't quite happy with), now the light is spread out more over the area covered by the "blob". This makes, I feel, for a better representation of dim light falling through a hole onto a nearby surface.

One change that I'm particularly happy with is that it's now possible to load additional lines into a conversation--meaning that I can now tack on lines in response to player actions. In the case of level two, this can happen if the player finds a certain hidden cache of books; if they do, then the character mentions it to the adventurer that she's there to meet. Further, if they take a book, that too gets a mention.

(The actual lines haven't yet been written; I currently just have place-holder lines being loaded at the moment. The logic for adding them in response to the relevant actions seems to be working, however!)

Now, you may recall the "distant light" that gives direction in level two. That light comes from an adventurer's lantern, and, as one might expect, there's fire in that lantern. I gave some thought to how I wanted to represent that fire, and after considering a few options, I settled on the classic approach of particles.

You may further recall that particle effects are already supported in the game, and indeed in the editor too.

So, I made a new particle effect in Panda's particle panel, and attempted to load it. There were a few stumbles--it seems that since last I added a particle effect in the editor, some changes had been made that affected their use. But those were pretty simple to fix, as I recall.

I loaded the effect into the level and... nothing happened. The editor's 3D "icon" for a particle effect was present and worked as expected, but there were no particles in evidence. I thought that perhaps there was a problem with particles in "player-lit" cells, so I moved it to a "sun-lit" cell, but there were still no particles.

Conversely, a previously-made effect (the "falling leaves" from the prologue) did work.

I ended up checking the file produced by the particle panel--and it seems that a large chunk of it had for some reason not been written! I tried re-creating the effect in the panel, but it produced the same result.

This was rather frustrating, as I recall. On top of this, I don't overmuch like Panda's particle panel: it's clunky, prone to throwing up errors (often seemingly-harmless but distracting), and can be unreliable, in my experience.

I started to consider making my own particle panel. But particle effects in Panda3D are quite feature-rich, meaning that there's quite a lot to support. I checked the forum for an alternative particle editor--but while I did find one, for some reason I wasn't comfortable with using it.

So I decided to indeed make my own--and that project took up much of the rest of the week.

My new panel isn't yet done: I don't yet have support for particle-forces, and haven't yet implemented my own saving and loading (in place of Panda3D's "ptf" files).

Nevertheless, as shown above it's making progress, and already in some ways feels rather better to me than Panda's particle panel. (Not that it's a marvel of ergonomics--it has a little clunkiness of its own, in all fairness.)

Towards the end of the week I set aside the panel--I was feeling somewhat fatigued with it, as I recall--and instead worked on a new shader. This one is intended to produce some simple, animated, vertex-based shadows, ostensibly "thrown" by one of the blob-lights. This is very much a work-in-progress. Indeed, I'm not yet sure that what I have in mind will work, although I think that I'm making progress.

And along the way I made a variety of minor changes and fixes, which don't seem worth detailing here.

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Mochnant
Level 0
***



View Profile
« Reply #216 on: June 04, 2018, 11:42:00 AM »

Looks like the game is making great progress.  I'll be following along.
Logged
Thaumaturge
Level 10
*****



View Profile WWW
« Reply #217 on: June 04, 2018, 03:13:04 PM »

Thank you, on both counts--it's much appreciated! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #218 on: June 11, 2018, 08:54:29 AM »

Blog post (11th of June, 2018)
An Un-Cast Shadow


Summary: In which a shadow has no caster; I describe how this was achieved; the particle editor is (pretty much) done; a particle effect is placed; windows are made--and send the vertex-count soaring; the placement of windows prompts some scripting; and wooden things are given colours and normals.

Greetings and salutations!

For this week's screenshot, a shadow being cast by nothing--if perhaps not in the way that you might think:



The week just past feels like a fairly productive one, to me. Let me elaborate:

First of all, as shown above, I completed (I believe) the shadow-shader that I recall mentioning last week. The technique has its limitations, but for the purpose that I have in mind for it, I feel that it works.

I said above that the shadow is cast by nothing, and looking at the gif above you might indeed note that the shadow appears to rise alone. But I didn't mean that there is no in-universe shadow-caster--I just haven't gotten around to modelling that character yet. Instead, I meant that on a technical level the shadow is cast by nothing--or rather, is not cast at all.

The fundamental idea is fairly simple: the ground and wall on which the shadow "falls" have two shadows painted into their vertex-colours, and a special shader shifts between the two.

However, a simple fade wouldn't produce the effect of the shadow moving over the surface, I imagine.

Instead, the manner in which the shadows are painted describe their "influence": The shading of the painted shadow describes the movement of the shadow, sliding from areas of full intensity to cover those of near-zero intensity. Since vertex-colours are interpolated, this shading is (in part) produced automatically.

A single value controls the "state" of the shadow at a given point in time: when the value is at "zero", one shadow appears; when it is at "one", the other is visible; and the shadow slides from one to the other as the value changes.

In the shader, this is achieved by comparing the shadow-colour value of a given pixel with the control value. For one shadow, the higher the control value, the more of its pixels are shown; for the other shadow, the opposite is true.

(This is all somewhat roughly speaking. For example, I actually painted my shadows as "darkness", so "full intensity" means a colour of "zero", which is intuitive to paint, but a little counter-intuitive in the shader-logic.)

In last week's blog post, I recall that I described a particle editor that I was working on. This, too, was finished in the week just past. (Well, there are a few features that it lacks--there are no controls for removing forces or particle-systems from an effect, for example--but nothing that I'm terribly worried about right now.)

And with that working, I went on to create the particle effect that sparked the endeavour in the first place: a small, pale fire, which has been placed in the lantern associated with the "distant light" that provides direction in level two.

Returning to the level itself, I gave some time to the wooden elements of the level.

For one, I created windows to fill in the window-frames.

The modelling itself wasn't terribly difficult, but I did run into an issue with the vertex-count.

Taken individually, the window-model didn't have a terribly high vertex-count, I don't think. The problem was that there were over eight hundred windows in the level, and the vertex count very much added up--at one point the windows took the scene's vertex-count from around seven hundred thousand (I think that it was) to over two million!

With some effort--including replacing some geometry with a normal map--I managed to reduce this count; I believe that I now have the vertex count at a little below one-and-a-half million.

The other issue was in placing all those windows. As I said, there are over eight hundred, and while some might be skipped (such as those in the prefabs), that still made for an awful lot of fiddly, tedious placement.

On top of that, I have static, non-traversable windows boarded up to indicate that they're non-traversable. But I didn't want the boards placed in exactly the same location on each window--that would make for obvious repetition, I fear.

So I wrote a script to automatically place the windows, then adjust the location and rotation of the boards. This involved some fighting with Blender (placements, especially when objects were parented below others, didn't work as I expected), but in the end it worked, and I have my windows placed, I believe!

(I will likely want to join the various windows together before I next export the scene, as they make for a rather high number of scene elements, and superfluously so, to my mind.)

I said that I gave time to the wooden elements of the level. Aside from modelling the windows, I also created colour-textures and normal maps for those wooden elements, whether windows, floors, ceilings, or planks. This called for some adjustments to various UV-maps, but went fairly smoothly (if at times somewhat tediously), as I recall.

And once again, a number of smaller changes and fixes were made that don't seem worth mentioning here!

That then is all for this week--stay well, and thank you for reading! ^_^
Logged

Thaumaturge
Level 10
*****



View Profile WWW
« Reply #219 on: June 18, 2018, 09:35:31 AM »

Blog post (18th of June, 2018)
Walls of Stone


Summary: In which the sandstone of level two makes its appearance; scripting once again obviates some tedium; a stone plate is adjusted; and the exit to level two sees some work.

Greetings and salutations!

For this week's screenshot, two looks at some of the aesthetic work of the past few weeks, via an excerpt from level two:




That aesthetic work took up most of the week just past, I believe, alongside some minor level-design work:

First of all, as shown above, with the wooden elements of the level re-textured, I've moved on to the stone. The walls of this buried city are now composed of great sandstone blocks; the roofs of its buildings are covered in a cladding made from the same; and the ceiling above is once again stone blocks, seated upon great slabs of sandstone. Slowly, I feel, the place is starting to better resemble itself.

As I think that I mentioned some time ago, I've found Blender's UV-projection modifier quite useful for tiling textures across flat walls, and the same is true of this level. There is a catch, however: if I use the same set of "projectors" for all buildings, then the blocks will be tiled in such a way that they are all in alignment, even between buildings, and even when the buildings themselves are not aligned.

It would make more sense, and look better too, I feel, for the blocks to be aligned to their specific building. This is simple enough to achieve: just give each building its own set of projectors.

However, as with the windows, there are a fair few buildings. Manually adding projectors to each, then referencing those projectors in the projection modifiers of the building's parts, would likely be rather tedious.

So, as with the windows, I wrote a script to automate the work. In short, my script looked at each object in the scene, and attempted to find the bottom-most base-object of each building. It then copied the original set of "projectors", and placed them at the location of that bottom-most base (which aligns them to the base). With that done, it went through the UV-projection modifiers used by the parts of the building, and updated them to reference the new "projectors".

As to the ceiling, that was mostly fairly simple, if perhaps a little finicky at times. I did end up making some minor changes, including adding a few more columns to the level to add support where it seemed lacking.

In one part of the level, a stone plate hides a small cache of books. Up until the week just past, I didn't have the level's stone blocks to provide a reference for the size and position of this plate. Thus, with the blocks in place, I went back and adjusted both the plate and the gap that it hides, to hopefully better match the layout of the stones.

As to the level itself, I did a little work on the final exit to the level. There is now a carriable object that provides a step up at one point, allowing a jump for an open window, and a hole in a ceiling/floor that provides a way up. This exit isn't yet quite done, but it's getting there, I think.

And that's all for this week! Stay well, and thank you for reading. ^_^
Logged

Pages: 1 ... 9 10 [11] 12 13 ... 32
Print
Jump to:  

Theme orange-lt created by panic