next »

[io3 creations]

Ah, of course! Indeed, I do think that I've seen this done elsewhere. Thank you for elaborating! (And for taking the time to create those GIFs.) ^_^

You're welcome! It was easy to do them with Flash.

Your current technique for creating the speech bubbles makes them look good.  The only thing I would change is to move them a bit farther and higher than the character's head if space allows.  Also, depending if it fits, but maybe different characters could have different speech bubble style or color.

[TonyManfredonia]

I love your cutscene idea. Having the 2D stop-motion will work well for you, I think. It's a great style and I wholeheartedly approve

[Thaumaturge]

Your current technique for creating the speech bubbles makes them look good.

Thank you! ^_^

The only thing I would change is to move them a bit farther and higher than the character's head if space allows.

Ah, that's interesting--I'll try to remember that, and thank you. ^_^

Also, depending if it fits, but maybe different characters could have different speech bubble style or color.

It's possible--but I honestly don't think that there are going to be enough speaking characters in any given scene to make it worthwhile. (Indeed, I have one cutscene in mind that might have more than two speaking characters in a single scene, but I believe that most will have two or one.)

(I'm also not sure that such colouration would quite fit the style that I'm going for.)

I love your cutscene idea. Having the 2D stop-motion will work well for you, I think. It's a great style and I wholeheartedly approve

Ah, thank you very much! I appreciate that! ^_^

[Thaumaturge]

Greetings and salutations!

For this week's screenshot... well, technically it's not a screenshot. Instead, the following are excerpts from the (work-in-progress) backdrop for the first scene of the intro cutscene: a large stained-glass window portraying the two worlds of the game's setting.

Aside from a few minor bits of coding, this past week was almost entirely dedicated to work on cutscenes, primarily the introductory cutscene.

Let me describe my process:

My first step in making a cutscene (after conceptualisation) is to sketch it out. I do this in a paper notebook, thumbnails to the left of the page (with a few directorial annotations) and text on the right (for the most part). It's likely not a perfect approach, and may see refinement as I go on--for one thing, it leaves me with limited space for reworking anything that I've set down. I'm tempted to use loose pieces of paper for each scene--as I get the impression is standard in some industries--but fear that this might quickly result in a fair bit of mess...

I have a pretty-much-complete sketch for the intro cutscene--there are a few points that I'm uncertain of, but I think that I have it overall set. I also spent some time sketching out a few other cutscenes.

Next comes the main of the work: actually painting each image in GIMP.

Most of the week was spent painting the backdrop from which the above excerpts come; it's not quite done, but I hope to have it complete by the end of tomorrow.

I suspect that not all backdrops will take quite so long, however. For one thing, I think that I'm starting to learn more effective (and perhaps more efficient) methods for achieving the style that I'm going for. For another, I believe that certain parts of this backdrop--the stars and mist in particular--went more slowly than others.

Last of all (presumably) is implementation of the cutscene: bringing the images into the editor, specifying the various timings, movements, etc., and doing any other work that might be called for--for example, I intend to use a custom shader to make the glass panels glitter in the backdrop above.

On another note, I'm still considering how to go about including animated mist in my cutscenes. I'm leaning towards implementing cutscene objects that hold a particle system instead of an image, but I'm also tempted to try some sort of texture-based animation, employing layered textures and texture -offsets, -rotations, etc.

Finally, I have it in mind to use some of the cutscene-backdrops as wallpapers if they turn out sufficiently well, whether released with the game, provided as crowdfunding incentives (should I seek crowdfunding), or made available at some other point.

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

[Pixel Noise]

I've dropped in on this a number of times, but I guess never commented? Sorry about that 

Progress is looking good 

[Thaumaturge]

I've dropped in on this a number of times, but I guess never commented? Sorry about that 

Progress is looking good 

Thank you!

Whether sooner or later, the comment is appreciated. ^_^

[Thaumaturge]

Greetings and salutations!

First of all, this week's "screenshot": a recording of the first scene of the intro cutscene, albeit sans sound or music:




This week past was a somewhat slow one, I'm afraid. Nevertheless, a few things did get done:

Perhaps most salient, and as shown above, the first scene of the intro is complete, save for sound and music. I may yet go back to add a little polish, or address any feedback that I get, but for now it's on to the second scene.

(And indeed, I've already made a start on the backdrop to that second scene.)

The creation of the first scene resulted in my adding a new (minor) feature to my cutscene editor:

The stained-glass window shown above moves sigificantly, starting with its origin well below the bottom of the screen, and ending with it above the top. But when I came to build this in the editor, I discovered that I had no easy means of working significantly beyond the edges of the screen, and thus no easy means of placing those start- and end- points as I intended.

(I could have had the scene itself move--a feature that was already present--but felt that doing so would make the parallax between window and silhouette more awkward to implement, I believe.)

To enable such editing, I added the ability to pan the editor's view, operated via the arrow-keys, and to recentre it via the "5" key. This has proven to be a pretty intuitive way to work, and rather handy.

Further into production of the scene, I discovered another problem: Both the backdrop and the silhouette images are larger than shown above, and it seems that scaling them down resulted in some jagged pixel-edges, which I felt to look a little unsightly. To deal with this, I had my cutscene class activate Panda3D's multisample antialiasing, a solution that I feel has worked quite well. The frame-rate has dropped as a result, but thus far it remains well above the frame-rate at which the game proper runs, and so I'm not yet inclined to worry.

(I did try enabling mipmapping, but was less happy with the results of doing so.)

Perhaps more serious was a lurking resolution-independence bug.

As I may have mentioned previously, the images used in my cutscene system are placed on the screen by applying them as textures to simple rectangular pieces of geometry. However, these pieces of geometry are by default generated as squares of uniform size, and this seldom matches the images being applied to them. I discovered fairly early on that it was awkward and inconvenient to manually resize each object after importing it, so I added a bit of code that, when an object's image was loaded, automatically scaled the geometry so that the image appeared on-screen at more or less its pixel-size. This worked, and proved rather useful.

But what happens when a cutscene is loaded in a window of a size other than that in which it was designed? Since the code results in the image being displayed at more or less its pixel-size, it will take up more space in a window of lower resolution--which has fewer pixels--and less space in a window of higher resolution--which has more. In addition, object-positions are, I believe, resolution-independent: the lack of resolution-independence in image-sizes can thus also result in objects becoming misaligned relative to each other.

The solution was fairly simple: store a "reference resolution" for each cutscene, being simply the resolution at which it was designed. When an object's image is loaded, the automatic rescaling code is run--with the addition of applying a scalar based on the comparison between the reference resolution and the window's resolution.

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

[Thaumaturge]

Greetings and salutations!

For this week's screenshot/GIF, a look at the (possibly still work-in-progress) mist effect that I intend for cutscenes:

(Sorry about the "skip" that happens when the GIF repeats--the mist effect is designed such that looping should be rare.)

This past week feels as though it was both productive and a little slow. Let me elaborate:

The first part of the week went fairly quickly: I began and completed the backdrop for the second scene of the introductory cutscene.

Excerpts from the backdrop to scene two

However, this scene calls for animated mist, and so, in the second part of the week, I set out to implement that. This was the "slow" part of the week, with a few days given over almost entirely to producing the effect.

As I believe that I've mentioned before, I had been of two minds as to how to go about implementing mist.

Particles seemed like an attractive possibility--they should be fairly straightforward, and their use is a venerable technique for representing smoke and mist. However, I recall that I wasn't convinced that they would readily produce the sort of billowing, evanescent mist that I wanted. For one thing, I think that I was worried that the individual particles would be a little too obvious. On top of this, there was the question of how to make a particle system fit nicely with the workings of the cutscene system.

My other salient idea was to use layered textures, blending them in such a way that they produced interesting billows. I believe that I've seen something like this done before, and think that I even recall having done something similar myself. I hesitated to approach this concept, however; I forget why--perhaps because the concept was too inchoate in my mind, or because I had an intuition that it wouldn't likely produce the effect that I was looking for.

I settled on particles.

One challenge to this approach was that I wanted the mist to be brighter where it billowed up, or was thicker. This could be done via additive blending--but I didn't want the mist to be additive with its environment, only within itself. To achieve this, I had my particle system render additively into an off-screen buffer, then applied the resultant texture to a piece of geometry (with a shader to generate the desired colour and transparency).

This produced promising results. I spent some time tinkering with it, trying to get it right--but it never quite worked as I wanted. In particular, the particles spawned randomly along the length of the emitter, resulting in frequent gaps. This could be reduced by increasing the number of particles--but doing so made the result over-bright, and too homogenous.

I did have my own particle implementation available, which would likely have given me more control over the particle-spawning, but I've found it to be a little heavy on performance.

I turned to my other idea, layered textures, but the results were not promising. One issue that I recall in particular was that the layers were far too visible--the result looked more like multiple textures flowing over each other than a single effect.

3D perlin noise was given brief consideration, but I wasn't sure of how to make such a thing look "painted".

Then a new idea came to me. In a sense, it was a combination of both the "particle" and
"texture" ideas: As in the latter, the central element is a texture, in this case representing a looping "line" of mist, which would be layered multiple times. However, the layers would be treated as something like particles: each would expand outwards, with their starting times staggered, and with random positional offsets. When a layer completed its expansion, it would be reset, expanding again from the start with new offsets. Thus each layer would be essentially a single, huge particle, repeating along the length of the effect.

The layers are multiplied together, but the degree to which a given layer contributes to this is greatest halfway through its expansion, fading to having no effect at its start and end.

After much experimentation and refinement, I found that this worked fairly well.

The next question was that of how to present this new effect on the screen; initial experiementation applied it to a simple rectangle, as I recall, but that wouldn't likely give me the flow that I wanted.

I tried to use a class provided by Panda3D that's generally well-suited to such tasks (and indeed, I've successfully used this class before, I believe), but for some reason the resultant geometry didn't seem to quite match the points that I was using--a frustrating issue that I never did find the cause of. In the end I gave up and switched to generating the geometry myself using lower-level Panda3D classes, a process that seems to have worked.

In the end, the result was the mist-effect shown above. It has a few bugs remaining, and it's not exactly what I had in mind, but I'm overall pretty happy with it.

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

[Thaumaturge]

Greetings and salutations!

This week's "screenshot" is a recording of the second scene of the introductory cutscene. As with the previously-posted first scene, there's no music or sound yet.

This past week was fairly productive, I feel: I perhaps didn't get quite as much done as I might have liked, but I think that I nevertheless got a fair bit done:

First and foremost, as shown above, the second scene of the introductory cutscene is done!

While the backdrop for it was completed fairly early last week, as I recall, arranging the mist in the scene took some time. I had a layout in mind when I began, but only in the form of a small thumbnail sketch. While it worked well enough in that small, somewhat-inchoate format, I found that it didn't look as good when laid out at full -size and -detail. So I tinkered and experimented, looking for an arrangement that I felt both looked good and conveyed what I intended for the scene. I'm not entirely happy with the final result, but I think that it's decent.

On a similar note, I went back and adjusted the timings of the narration in the first scene: While I think that the text was on-screen for long enough to be read, it was perhaps too brief to be spoken (against the possibility of voice-acting being added in the future); on top of that, having the screen visible for longer may benefit those who read a little more slowly. This does mean that the scene lingers a little more than it did, but I hope that it's not obnoxiously so.

With scene two completed, I've moved on to the third scene. This scene doesn't rely on a single, monolithic backdrop, being instead composed of multiple layers and components. Nevertheless, I've been painting most of these as though they <em>were</em> a single backdrop. The main exception is an image of the protagonist, which has been painted at a larger size to facilitate zooming in on her. (I may similarly make a larger version of the chunk of scenery around her, depending perhaps on how the main image looks at that scale.) I believe that I have this nearly, but not quite, finished.

Excerpts from the third scene

The above-mentioned mist-effect saw a bit more tinkering this past week, largely in fixing (or attempting to fix) a few minor issues. Perhaps more interestingly, I created a radial version of the effect:

There's a bit more work to be done there, primarily in enabling a means of animating its state (making it fade in and out, expand from a point, or dissipate outwards). Nevertheless, I'm happy with what I have there thus far.

Finally, I made a few minor changes to my cutscene editor, largely intended to make it a little easier or more intuitive to work with. Of these, perhaps the most useful thus far has been the ability to insert points into an object's "track", where before one could only add onto the end; this proved very handy while experimenting with the mist-layout in the second scene, I believe!

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

[Thaumaturge]

Greetings and salutations!

For this week's screenshots, the final two scenes of the introductory cutscene:

(The final scene above has been cropped in order to reduce the size of the gif. However, no real content has been removed; the scene simply lasts a little longer, and fades -in and -out, as I recall.)

This past week was somewhat productive, I feel! ^_^

As shown above, perhaps one of the most salient items of progress is that the introductory cutscene is complete, aside from sound and music! It's one of the longest cutscenes that I have planned: a little over a minute in length, I believe.  (And indeed, of the cutscenes that I have in mind, only the intended first-level cutscene--which begins the main plot--compares with it in length.)

That done--and after a brief change of pace with some coding-side work, including the changes described below--I've moved on to start work on the cutscene for the prologue level.

A "hands-on" approach?

I mentioned above that music and sound are still lacking from the intro. For some while I had been unsure of how to approach the question of music/ambience in cutscenes--should I use background music, or just sound effects and ambient noise? If the former, what music should I use?

Ambient noise is an attractive option--it obviates the worry of finding music--but I'm not convinced that it's a good idea, especially in the somewhat-abstract scenes of the intro cutscene. Additionally, creating appropriate ambient effects is not a path without its own challenges.

I spent some time hunting around for royalty-free music to play in the intro cutscene, but while I found a number of rather good pieces, I struggled to find something that quite fitted my intentions. And this makes sense, I feel: how likely is it that one of those collections, which span a number of styles and moods, has a piece that conveys quite the feelings that I have in mind?

Additionally, using a single piece for each scene could quickly result in quite a few pieces being called for. Conversely, having one piece cover each cutscene entirely would likely either result in music that fits a cutscene generally but poorly matches the individual scenes, or call for a custom piece for each cutscene.

But another idea came to me: instead of having one piece per scene, one could have a variety of simple, sparse "mood pieces", then layer these to produce the overall feel of a given scene. In addition to allowing reuse of these pieces, this might allow for scenes to be tied together, sharing "mood pieces" where they share themes or feelings, while remaining somewhat distinct.

However, the cutscene system was not designed to layer music in this way; it inherited the relatively-simple approach to music that the base "world" class employs, intended to play single pieces during levels and the like.

Hence another salient change of this past week: the implementation of a new music system for my cutscenes, and alongside that, an editor with which to specify a given cutscene's musical layers.

The system is fairly simple: a cutscene has three "tracks", each of which holds a number of music-entries specifying a starting time, ending time, and the name of the piece to be played. There is no overlap within these tracks, but they run simultaneously, allowing up to three pieces of music to be layered at a time. As the music-system's time is updated, it starts and stops pieces according to the timings given in the entries. In addition, the system fades pieces in and out, (hopefully) producing soft transitions between "moods".

The editor for this system is likewise simple: it presents the three tracks one above the other, with a timeline and scene-markers for reference, and allows entries to be added, deleted, and altered.

I don't yet have "mood pieces", so I tested the system with oridinary music. The result was... interesting, somewhat overpowering, and <em>slightly</em> less cacophonic than expected.

A few other features were added to the cutscene system and its editor this past week:

• Black bars now cover superfluous parts of the screen when a cutscene is played at an aspect ratio other than the one in which it was created
  
  
• The editor can now zoom in and out, allowing fine placement or a broader overview
  
  
• The duration and delay of an object's track-points can now be entered numerically, allowing for more precise values.
  
  

In implementing the above-mentioned black bars, I discovered a rather nasty bug: as it turns out, the code that I had in place to handle variations in resolution wasn't working properly. Objects ended up in the wrong places, misaligned, and the mist effect was incorrectly generated. This should (hopefully) be fixed now!

Finally, a few other minor bug-fixes and changes were implemented.

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

[Thaumaturge]

Greetings and salutations!

For this week's screenshot, the first scene of the cutscene to the prologue level:

This week just past was another of mixed progress:

During the first portion of the week I worked primarily on the first scene of the cutscene that plays before the prologue level; this went fairly swiftly, as I recall. Shading the hands that are the focus of the scene went surprisingly quickly, in fact! Ironically, the simpler backdrop--and the sitting figures in particular--was a little more challenging, perhaps simply because I'm less used to working on elements that are "out of focus" in that way. As shown above, this is complete (again, aside from sound and music)--although I might still make some minor changes.

The second scene (which is also the last) takes place in the forest that surrounds the prologue level, showing the approach to that level's gate. This was, I fear, where things went rather more slowly.

Most of this slowness came from two sources: the leaf-litter that covers the ground, and the shading of the trunks of the trees themselves. While it took me a few attempts to find an approach to the former that I was happy with, in both cases I think that it was primarily the repetition, and thus tediousness, that slowed me down: both involved quite a bit of painting more or less the same thing over and over again. This resulted, I fear, in frequent pauses and thus slow progress.

On top of that, the scene is intended to include a degree of parallax, with distant elements approaching more slowly than nearby ones in order to give a sense of three-dimensionality. To this end the layers of the forest overlap, resulting in my painting certain regions more than once (indeed, perhaps more than was entirely called for).

The scene isn't quite done, but is, I think, almost there; I'm hopeful of completing it either today or tomorrow.

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

[Thaumaturge]

Suddenly, Coding

Greetings and salutations!

For this week's screenshot, a look at a new gameplay element: some objects can now be picked up and placed elsewhere:


This week just past was a bit of an odd one, and quite productive, I feel.

During the start of the week I finished off the prologue cutscene, completing the second scene and tweaking the movements in the first. Here is the result (once again, without sound or music):




(As part of this, I made a minor change to the glimmer-shader: the rate at which it glimmers is now controlled by a variable. This allows the same shader to handle both slow effects such as light shafts and fast ones like twinkling lights.)

That done, I moved on to a little bit of coding. I had it in mind to try a new mechanic: objects that could be pushed and that would slide physically. Such objects might be moved to reveal secrets, or rearranged to create new paths for traversal.

The game already uses the Bullet physics engine for other purposes, so little physics implementation was called for--and indeed, the basic implementation was fairly quick, as I recall.

Unforunately, the results were also a little less stable than I'd like; in particular, the objects in question had a tendency to jitter in a manner that I was not happy with. I managed to greatly reduce this jitter, but it still showed up when such an object came to a halt with the player standing nearby, not settling until they moved away. Preventing rotation pretty much solved the problem--but objects no longer tipped at edges or aligned themselves to slopes, which I wasn't happy with. In addition, physical objects seemed to interact poorly with certain static objects.

(At least part of this instability may have come from my somewhat-hybridised approach to the game's physics.)

So, in the end, I decided to scrap the feature.

I had previously considered allowing the player to pick up objects and move them about--a venerable mechanic that has been used quite effectively in other games, I feel. Indeed, I recall that one of my inspirations, the Thief series, made rather good use of such objects for traversal purposes.

However, I was hesitant. In particular, I think that I feared that it might interfere with the extant mechanics--point-and-click interaction and climbing especially. I also wanted to avoid filling my levels with the ubiquitous crate!

As it turns out, the implementation was actually fairly simple! Most of the issues with the extant code were solved via simple checks, and the mechanic itself turned out to be pretty straightforward. A few bugs turned up later, but I believe that I have them fixed.

As to crates, the answer, I think, is simply to use other objects--chairs, chests, drawers, etc.

Still working with code, I took some time to rework the logic behind "falling" objects (such as the stone that can be dropped into the dark entrance of the prologue's pyramid): it should be somewhat more stable now than it had been, I believe.

I also ended up tinkering further with the player-light, and think that I've improved it a little.

A number of bugs were discovered during the week (mainly during the coding-side work described above); I believe that I have them all fixed! Additionally, one of the changes that I made called for some minor adjustments to certain objects in the prologue level.

Finally (on the code-and-writing-side, at least), the prologue level now has a few extra comments from the protagonist, along with the logic behind them; these cover looking at the "darkness" of the pyramid's entrance under various conditions (such as doing so after having lowered the interior "lift").

With the above-mentioned coding done, I've returned to cutscene-work. At time of writing, I'm partway through painting the backdrop to the first (non-prologue) level's cutscene, I believe.

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

[Pixel Noise]

Loving how the cutscenes are shaping up!

I think the choice to use movable objects, both for puzzles, climbing, etc, is the right one. In terms of the pros/cons, I think it just adds too many potential gameplay elements to be left out - unless you specifically want to streamline and focus the game mechanics.

[Thaumaturge]

Loving how the cutscenes are shaping up!

Thank you very much! ^_^

I think the choice to use movable objects, both for puzzles, climbing, etc, is the right one. In terms of the pros/cons, I think it just adds too many potential gameplay elements to be left out - unless you specifically want to streamline and focus the game mechanics.

I do think that you're right. It's a fairly small change that has a number of potential uses in gameplay, primarily in traversal, but perhaps also in puzzle-solving.

If it had been more troublesome--in particular, if it had interfered with the extant mechanics as I'd feared--then I feel that it likely would have been better omitted: the extant mechanics provide a fair set of possibilities, I think, and I really don't want to destabilise them.

It does perhaps call for more care in level-design, of course: the ability to move and stack objects means that it's more difficult to reliably prevent players from reaching the edges of a level.

(There is one issue that I still haven't dealt with, come to think of it: moveable objects don't yet detect the loss of the object beneath them--removing an object beneath a moveable one leaves the latter just sitting in empty air, as I recall. Not only does this look odd, but it means that two moveable objects could theoretically be stacked higher and higher indefinitely... ^^; )

I still like the idea of pushable objects as a replacement for moveable ones--it's something a little different, would involve a different set of objects, and provides a slightly different experience, I think. However, I don't think that it's worth the more-difficult implementation, especially when a similarly-effective and much easier option is available.

[Thaumaturge]

Greetings and salutations!

Before I get started, a quick notice: I intend to take a day off before and after Christmas; since the day after Christmas is a Monday this year, I believe, next week's blog post will likely be posted on Tuesday instead. (I'll also likely be away from social media over those three days.)

That said, this week's screenshot: an excerpt from the first scene (which may end up as the second scene) of the cutscene to the first level:


This week just past was... in some ways both slow and productive. Let me elaborate:

Most of the week was spent on the painting of the backdrop to the first scene of the first-level cutscene. It's a somewhat-complex image (for me, at least): there are a number of features--bar, tables, patrons, etc.--(some which I found a little repetitive to paint), and multiple light-sources. I found it to be fairly slow going (and I perhaps didn't approach it in an optimal manner). Nevertheless, given the complexity of the scene, I'm not entirely unhappy with the time spent, and I'm reasonably happy with the final image. (Indeed, I'm actually a little happier with the "out of focus" figures of the patrons than I was with the similar figures in the prologue cutscene, I believe.)

While the image is complete (barring a few minor changes), the scene itself isn't yet done: aside from building it in the cutscene editor, I still have two images of the protagonist to paint.

I did take a break at one point to start work on the backdrop to the second scene, a rather simpler image; the main challenge there will likely be the base pose for the protagonist, I think.

Not all of the week was spent in painting; part was spent creating the fire that can be seen glimmering in the hanging lamps above.

As I recall, my first approach to implementing this used particles; and indeed, I added support for particle effects to the cutscene system and its editor. However, I realised that the curved lamps--and thus curved pools of flame--in the scene made particle effects awkward to work with--not impossible by any means, but not ideal.

Next I believe that I tried a simple shader-driven animation: three frames of painted fire rising and falling, fading in and out, layered over each other. This more or less worked, but I wasn't happy with it, as I recall.

Finally, I tried the approach shown above. In essence, it's a shader similar to that used to produce the mist-effect, but much simpler. In broad strokes:

A single "flame" texture is used to produce two "layers", each drifting up and to one side or the other. These are multiplied together, producing shifting patches of light and dark. A second texture controls the range of values produced: it allows only high (i.e. opaque) values where the texture's pixels are black, only low values where they are white, and degrees of the full range in-between. (It would likely have been wiser to have mapped white pixels to high values and vice versa for black, but it's not likely a serious issue.) The control texture is simply an image, allowing curves to be represented simply by painting them in.

The result isn't perfect, but I'm overall fairly happy with it!

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

[Thaumaturge]

Greetings and salutations!

First of all, whatever you celebrate or observe during this time, whether yet to happen, happening now, or just passed, I hope that this year's is or was a happy one for you! If you neither celebrate nor observe anything at around this time, then I hope that you find the period to nevertheless be a happy one. ^_^

This week's screenshot shows some progress on carriable objects: they should now fall when their support is removed:


As I mentioned last week, I took a few days off over the Christmas weekend, making the week just past a little shorter than usual. Nevertheless, a few things were done:

Work continued on the first scene of the cutscene to the first level, primarily in painting two close-up images of the protagonist, sitting at the bar that fronts the scene. This isn't quite done, but is close, I believe.

On the code-side, I added three new features, two in the game itself, and one in the level-editor:

To the game, as shown above, I added support for objects falling automatically when their support is removed (and when the appropriate flags have been set); this was primarily intended for carriable objects, but may see use elsewhere. I haven't yet tested all cases (for example, I haven't yet tested how it works with doors), but thus far it seems to work fairly well.

Doing this involved reworking elements of certain base "game-object" classes in the game, a prospect that I recall being a little nervous about. I think that I feared introducing serious bugs by altering the workings of so fundamental a set of classes at so late a stage, with so much code already in place. However, I'm glad to say that it actually went fairly smoothly!

There is an issue with the implementation that I have right now: it uses only a simple ray-cast from the centre of the object to determine the point to which the object should fall. This means that if one object falls from above another, with its centre not over the lower object but its edges overlapping, it can end up falling through the lower object, intersecting it.

The obvious thought is to instead use the physics system, with significant constraints to prevent jitter, allowing collision and stopping to happen more or less naturally.

As I recall, I moved away from this when I recently reworked "falling objects" because I found that the small rock that the player can drop in the prologue level seemed to have a tendency to fall through the floor, landing rather too far below; the ray-cast method seemed rather more stable.

I think, however, that this should only be a significant issue for smallish objects--like that rock; larger objects should be fine. For such smaller objects, I see two potential solutions at the moment: I could have them continue to use the current ray-cast method (since overlaps should be less problematic with small objects), or have them use "continuous collision detection", which should be more reliable, but a little more costly in terms of performance.

I'm still considering whether to switch to using the physics system as I've just described; right now, I'm leaning towards doing so.

The other feature added to the game was support for "display-names". Thus far, I've been using an object's internal, unique name to determine what label should be shown on-screen, drawn from a string-file. However, when there are a number of objects that should all show the same name (chairs, for example), this can lead to a slightly-tedious business of creating the association of each internal name with the relevant string. To alleviate this, I've given each object an optional "display-name": if present, this name is used to find the relevant string to show on-screen; if not, the internal name is used, as before. Display-names needn't be unique, so they allow me to create just one string association for a number of objects.

This was implemented, as I recall, because of the new editor-feature: object templates. In short, these are saved objects that can be spawned in with all of their attributes intact--quite useful for creating a number of similar objects, such as chairs, tables, and so on. The implementation is fairly rudimentary--there's no easy way to edit a template, and deleting one is achieved by just deleting the relevant file in the template directory--but I think that it's likely to prove quite useful in future.

Finally, I discovered two bugs in the code that assigns internal object-names; one was fixed, and the other deemed not worth fixing, I believe.

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

[Thaumaturge]

Greetings and salutations!

For this week's screenshot, the first three scenes of the cutscene to the first level:


As with last week, the week just past was made a little shorter by the holiday that I took over Christmas. In addition, during my holiday I played through the "Kingmaker" module for Neverwinter Nights (which I picked up for free during the GOG.com Winter Sale (I think that it was))--but didn't quite complete it. And while the final dungeon itself wasn't that difficult, the final boss gave me quite a bit of trouble. As I recall, in my attempts to defeat him I ended up staying up quite late on two nights this past week. And defeat him I at last did, I'm glad to report!

Nevertheless, I feel that a decent chunk of progress was made:

I completed the scene from which an excerpt was shown two weeks ago (I believe that it was)--a tavern in which we find our protagonist sitting at the bar, perking up when her ear catches a scrap of story from nearby, a scrap of story of particular interest to her.

The next scene sees her arrive swiftly at the story-teller's table, demanding information.

It's a fairly simple scene, but I'll confess that some of the poses gave me a little trouble--in particular the two in which our protagonist leans forward on the table.

The scene was originally intended to be black-on-white. This proved a problem, however, when it came time to add speech-bubbles: the white bubbles were lost against a white backdrop. For a while I considered adding a black outline or secondary backdrop to the bubbles. In the end, however, I instead reworked the scene's backdrop, painting it in browns similar to those of the tavern walls in the preceding scene. Aside from rendering the speech-bubbles visible, I feel that this has the advantage of being rather less stark, and of connecting this scene to the setting of the previous.

As with the previous, this scene is now done, I believe.

The first of the two scenes described above--the protagonist in a tavern--was originally to be the first scene of this cutscene--as shown above, it no longer is: a new scene has been inserted before it, tying off the events of the prologue.

The brief text used in this scene is somewhat of a violation of the "show, don't tell" principle, I'll confess. And indeed, I had previously intended to close out the prologue with a short, dedicated cutscene that might better have shown what this tells. However, I feel that these opening cutscenes are already getting a little long (indeed, this cutscene has three scenes yet to be shown--albeit that one is a brief establishing shot). I don't want to add too much more passive viewing to the start of the game.

(I'm also perhaps a little anxious to get to work on the first level itself!)

Implementing this new first scene presented a minor challenge: While appending a new scene is easy, neither the cutscene system nor its editor were designed with insertion in mind--a bit of an oversight, perhaps. Support for scene-insertion might be a useful feature to add, but I'm not convinced that it's worth the development time at this point.

So, how then to add a scene to the start of a cutscene? In the end, it was fairly simple: I didn't. The first scene remains, technically, the first scene--I just extended it, offset the starting times of all objects belonging to the original first scene, and added a black overlay to simulate the usual inter-scene fade.

This, too, is now complete, I believe.

All of this done, I've made a start on the next scene of the cutscene: an establishing shot of the Archive at Teli. It makes for a nice change of pace, being fairly broad and simple--and having no human figures. It does, however, include the return of grass; once again I am engaged with my old enemy, although I think that I may have the upper hand for the moment. But grass is a tricky foe, so I hesitate to call a victory just yet...

As a side-note, none of the cutscenes yet have sound or music--something that I have in mind to go back and add later.

Finally, I toyed a little with the texture used for the in-game sky, using an approach taken from my cutscene painting. While I've reverted these experiments (they were just quick proofs-of-concept), the approach that I was testing may provide an improvement to the sky's appearance, should I get around to repainting the texture in earnest.

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

[Pixel Noise]

I think the pose with the MC leaning on the table is very natural and looks good - the only thing I'd say is that I think "she" looks a bit too masculine; not in the pose, but in her features. I think it's in the nose-mouth proportions. I'd make the nose a bit smaller (top to bottom), and the mouth a bit wider and fuller? If I hadn't read your description, I would have thought "she" was a man.

[Thaumaturge]

I think the pose with the MC leaning on the table is very natural and looks good ...

Thank you! ^_^

(Getting it to the point shown above took a few attempts, and a few instances of leaning on a desk myself (sometimes rushing to it first) and observing my own pose, as I recall.)

... the only thing I'd say is that I think "she" looks a bit too masculine; not in the pose, but in her features. I think it's in the nose-mouth proportions. I'd make the nose a bit smaller (top to bottom), and the mouth a bit wider and fuller? If I hadn't read your description, I would have thought "she" was a man.

Hmm... Looking again, I think that you're right--her nose is a little tall (and her face thus similarly), and her lips could be a little wider. I'll make some changes there, I think!

Thank you for the critique! ^_^

(In all fairness, her gender isn't a particularly important part of the story, so it's probably not a major issue if some people mistake it.)

[Thaumaturge]

All right, I've made some edits, and would like your feedback before I integrate them into the cutscene, if you don't mind:





[Edit] Oh, and did the same critique apply to the silhouettes in the third scene, or was it just the close-ups?