next »

[io3 creations]

Yes, I only have 2 eyes   o .  I'm guessing you have:    

Three eyes? o_0    

                              
                                      
 WhY DO you SeLl mE so ShooOrT?    
                        
                                          

Sorry, my bad!  I meant:

I'm guessing you have at least:    

*ahem*
I mean, uh three eyes, yes, just like any human! :D

;P

Yes, we all have a mysterious 3rd eye, right between the other 2!  o*o

Based on the length of your blog posts ... I had a "feeling" you'd say that.

I might also add that I have it in mind to include with downloads a (PDF or other e-book) short story written in the setting--albeit that the plot is unconnected.

(The short story actually came first, funnily enough.)

The downloadable PDF is a good idea if it adds to the same game-world.  If I like the main source, I tend to look for "more".  Since you mentioned that the short story came first, did that influence the game design?

In a game it's somewhat different, since people who like to explore are probably more open to reading  i.e. exploring the game further.  Of course, it's good to communicate that in the trailer and game description so people are not "surprised".  Some tend to prefer listening, but it your budged doesn't allow it, there's not much you can do about it.  Unless you have willing "friends" who could do that.

Also, if there is something important, it's good to make sure that the player "can't miss it".

Good points, all, I think! I should make a point of showing some of the text, of at least both the document and "character thought" types, I think. (Not as opening moments--I currently have it in mind to have a jump for the first shot of the first trailer, I think.)

(As to voicing, I want to do a crowdfunding campaign for overall funding--but even if that does raise some money for voices, it's likely that I'd stick to just adding voice-work to cutscenes and those rare conversations that occur. Documents and "character thoughts" would likely remain unvoiced, simply because there are a lot of them.)

Oh, I see.  If you have all text recorded, then you'd probably end up with a bonus *Audio Book*.

[Thaumaturge]

Sorry, my bad!  I meant:

I'm guessing you have at least:     

Much better! Now, was that so hard?

The downloadable PDF is a good idea if it adds to the same game-world.  If I like the main source, I tend to look for "more".  Since you mentioned that the short story came first, did that influence the game design?

Hmm... The game design itself? I don't think so. It's set in the world of that short story, so it inherits much from that--the animal signs, certain undead, the mist-world that is the focus of the plot, etc.

Come to think of it, there is that commonality between them: they take place in very different places, with very different people, but the mist-world is prominent in both, as are the limitations in accessing it.

Oh, I see.  If you have all text recorded, then you'd probably end up with a bonus *Audio Book*.

Heh, that would be nice!

Hmm... Alas, while much of the plot is contained in cutscenes or conversations, I suspect that at least some is found in the "character thoughts"--moments in which the protagonist collects an important item, or discovers a significant clue, etc. I suppose that I could consider voicing those, but having only occasional "thoughts" be voiced might feel odd. ^^;

[io3 creations]

Sorry, my bad!  I meant:

I'm guessing you have at least:     

Much better! Now, was that so hard?

It's not easy to focus when you're Sleeping With Third Eye Open 

Hmm... Alas, while much of the plot is contained in cutscenes or conversations, I suspect that at least some is found in the "character thoughts"--moments in which the protagonist collects an important item, or discovers a significant clue, etc. I suppose that I could consider voicing those, but having only occasional "thoughts" be voiced might feel odd. ^^;

Yeah, voicing only some of the "character thoughts" would probably not a good idea.  Unless, if those could be combined into some kind of summary or closing monologue at the end. 

[Thaumaturge]

It's not easy to focus when you're Sleeping With Third Eye Open 

Heh, I saw that, and thought of linking it myself! :D

Yeah, voicing only some of the "character thoughts" would probably not a good idea.  Unless, if those could be combined into some kind of summary or closing monologue at the end.

Perhaps, but it's additional work--and a change to the flow of the cutscenes into which it would presumably introduced--all in aid of a speculative bonus item. ^^;

[io3 creations]

It's not easy to focus when you're Sleeping With Third Eye Open   

Heh, I saw that, and thought of linking it myself! :D

Yeah, voicing only some of the "character thoughts" would probably not a good idea.  Unless, if those could be combined into some kind of summary or closing monologue at the end.

Perhaps, but it's additional work--and a change to the flow of the cutscenes into which it would presumably introduced--all in aid of a speculative bonus item. ^^;

Yeah, I agree that the extra work would be only worth it if it was adding something "more/special" to the game.  I was thinking something along the lines of the ending revelation of the Saw movies.  You've seen the bits and pieces before, but now that they are put together, you get the "answer" as to what happened.  If your game's case, it wouldn't have to be the same kind of revelation, but more like a summary that puts certain events together in a way that perhaps other than the more observant people others might miss.  You probably have an idea for the ending, but I just wanted to throw it out there.  Or perhaps you could do something similar for your next game.

[Thaumaturge]

Ah, "once more with clarity", as TV Tropes puts it, I believe. ^_^

It's an interesting idea (and thank you for it!)--although I don't think that it really fits into A Door to the Mists, indeed. It's less a story of mystery than of discovery, I suppose; there is a resolution at the end. In this case a summary would, I imagine, less explicate than, well, summarise. ^^;

[Thaumaturge]

Blog post (15th of January, 2018)
Level Complete!

Summary: In which a level is (pretty much) finished; the fading of forest-sounds is discussed; combat animations are reworked; combat logic is polished; climbing through walls is forbidden; and experiments are made with graphical effects.

Greetings and salutations!

For this week's screenshots, the first level once again:




The week just past was a somewhat varied one! There was work on the first level, on combat, on graphical elements, and more besides!

First of all, perhaps the most salient news this week is that the first level is, I believe, pretty much done! I have a few tweaks that I'll likely want to make, and I should perhaps do a complete run-through to check for issues that might have appeared during work on the level. But those aside, I believe that I have the level--in geometry, level-editing, and logic, all finalised! :D

Doing so in the week just past involved work on a few elements. I removed a troublesome shelf that was blocking a low gap; tweaked the tree-bark colour-texture; removed a planned collectible for which I never found a concept that I liked; and more besides!

One of these changes was that I added in "forest" sounds--the rustle of trees, sounds of twigs snapping, etc.; this was pretty much copied from the prologue.

One minor complication was the question of making it stop when moving into the tomb--let alone when exploring subterranean regions that happened to be near the edge of the surrounding woods!

In the prologue, I achieved this via a simple trigger--but in that case, I had the advantage that the entrance in question was a vertical shaft. With the gentler slope of the barrow-entrance, I wasn't happy with this.

I considered implementing a "sliding trigger" that would set the volume according to how far into it the player stood. I even started implementing this, as I recall--but in the end decided that it didn't seem worth it. (For one thing, I'm not sure that I should be adding new features like that at this point!)

In the end, I did something simpler: since the barrow is underground, I simply reduce the volume of the "forest" sounds as the player-character moves down below "ground-level". In addition to solving the issue for the barrow, this has the advantage of naturally doing the same for a small, sunken side-room to one side of the outdoor area.

With the first level (more or less) complete, I've moved on to work on the end-of-demo "cutscene". This is still a work-in-progress at the moment!

Another section of the game that saw salient work was the combat. I had received some (much appreciated!) feedback on the combat animations shown in one of my YouTube videos, and set out to improve upon said animations. (Well, and to look into why certain animations seemed to not play at all in some cases. I haven't managed to reproduce this, however!)

To that end, I've reworked a number of the player-character's animations to greater or lesser degrees. In addition, I've added a new "stunned" animation that plays when the character has been dealt a staggering blow and finished reeling backwards, but has not yet recovered.

On top of that, I made some tweaks to the combat logic. For one, I found that I could defeat one of the mummies by simply spamming attacks--which is not something that I want! Between limiting the player's ability to spam attacks and some changes to the mummy's AI, I think that I have this largely resolved.

I also made a few miscellaneous changes, including, if I'm not much mistaken, other tweaks to said AI, and a heavier stamina-penalty when stunned.

At some point during the week just past I discovered that it was possible in the prologue level to climb through a certain wall. As you may imagine, this was not a welcome discovery!

In the end, I tracked down the problem to an unexpected normal being reported by the physics engine--in short, I expected said normal to point down, and it was reported as pointing up. I've brought this up on the Panda3D forum.

However, I also decided to implement a minor change that somewhat prevents it from being an issue--in this case, at least: I've added a new ray-cast to the logic of climbing that--roughly speaking--checks whether there's an obstacle between the player and the point to which they would otherwise climb. Such as, say, the wall that was being climbed through. If there is, the climb is cancelled.

I was a little hesitant to do so, as I recall--I'm worried that there will be cases in which this will prevent a valid climb from happening--but thus far it seems to work reliably.

On the graphical side, I experimented with a few visual changes, one of which was ambient occlusion. Panda3D offers this out-of-the box, but trying it I found that it didn't seem to work well for me--possibly because of my custom shaders. I also attempted my own experimental approach using only five samples. This seemed promising, but I didn't manage to get it working properly, and I'm not sure of where I was going wrong. It's possible that it might be made to work with further development, but as things stand I've abandoned it. In any case, in both cases I wasn't happy with the performance impact.

Finally, there were a number of changes, bug-fixes, and experiments undertaken during the week just past that don't seem worth going into in detail here!

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

[Thaumaturge]

Blog post (22nd of January, 2018)
Shadowy Problems

Summary: In which performance is improved; tree-shadows are re-worked sans transparency; performance is slightly decreased, but for aesthetic improvement; and an animation bug is fixed.

Greetings and salutations!

For this week's screenshots, some improvements (I think) to the look of the grass in the first level:




The week just past was somewhat of a miscellany, including performance-related changes, bug-fixes, and aesthetic changes:

One thing that's been bothering me has been the performance of the game in the first level--in particular in the outdoors section, and especially in the first view of the level. My overall aim at the moment is to keep most views at or above about seventy frames per second on my own computer--and that first view was running about about sixty-two.

So in the week just past I put some time into attempting to figure out just where the problem lay, and into improving it.

I looked into a few elements of the scene, but one thing that I discovered (somewhat stumbled upon) to have a notable effect was the shadow-cameras: in short, it seems that rendering the shadow-map for the "sun-light" is noticeably more expensive than for the "player-light"!

This does make some sense: The "sun-light" renders a much larger area, the view of the "player-light" being somewhat more limited, and the "sun-light" renders to a rather larger texture. Indeed, just reducing that texture-size to match that of the "player-light" helped somewhat, I believe--but at the cost of significantly reducing the already-not-great quality of the shadows cast by the "sun-light".

In an effort to improve matters, I simplified the shaders used by the shadow-casting cameras--and doing so does seem to have helped performance.

As part of this, I gave up on rendering transparency in my shadow-maps. For the most part this should be fine--I have few objects in mind at the moment that are likely to call for it. One set of objects that was relying on it, however, was the tree-foliage.

With transparency disabled, the semi-transparently-textured geometry used to represent the shadows of trees was instead rendered as great, angular chunks. So, I set about creating a geometric representation of the tree-leaves. This didn't call for the full depth of visible foliage; instead, I made flat "outlines", essentially. Still, it proved somewhat tricky to make a halfway-decent shadow without using too huge a number of vertices.

I mentioned the grass earlier in the post, I believe. I also put in some work on improving the performance of this. In short, I removed uses of the "discard" command in the grass-shaders (which I've read can be problematic, along with the "if-statements" that supported their use here). Instead, inspired by a comment that I saw online, I now flatten down distant grass into degenerate geometry, and hide it beneath the ground.

(I also removed a few other uses of the "discard" command, to no real effect--but it's perhaps better to not have them.)

Overall, the gains made by these various efforts were fairly minor, improving things a few frames-per-second at a time. Still, I managed to pull up the frame-rate from about sixty-two frames per second to about sixty-seven, which is an improvement, at the least!

(Between the new geometric shaders and other changes and fixes, I ended up re-exporting the first level several more times. So it seems that the export reported in last week's blog-post wasn't quite the last!)

Moving to aesthetics, I spent some time toying with various changes to the game's look. Some of these didn't work out (like fading out both shadows and shading in the distance). A few, however, did, such as making the outdoors ambient colour a little more blue, and adjusting the distance-haze in the first level.

One that might be worth noting was the introduction of a "detail texture". The basic idea is of a texture applied broadly to geometry in order to apply some variation to the scene, to make things a little less uniform. Specifically, I had it affect both the saturation and the brightness of the surface to which it was applied.

However, I found that due to my expanding it over the surface, there were visible discontinuities at seams, which I found rather unsightly. Thus I removed it from most surfaces.

The one place in which it did remain, however, was in the grass (and the surfaces beneath the grass). Here, with some changes, I found that it provides some welcome variation to an otherwise rather uniform effect, and since the ground doesn't curve back on itself much, there are few issues with seams, I believe.

There is a bit of a cost, however: I seem to have lost a few frames-per-second to this, bringing performance in that first view down to about sixty-five frames per second.

On the technical side, I discovered a bug in the logic behind certain combat animations; in short, a particular animation ended up looping after it was intended to finish.

The problem itself was fairly easy to fix--but doing so brought me back to a previous issue that I had thought solved: After being stunned, the player-character would seem to "snap" back into the "en garde" pose, rather than transitioning smoothly.

In the end, I tracked this down to a particular sequence of animations being run in rapid succession. I had some custom code that automatically faded one animation into another (via Panda-provided mechanisms)--but this expected to have only two animations to fade between at a time. When a third was run, the previous fades were simply halted, and the fading begun anew between the third and second animations, as I recall.

So I set about expanding this code, allowing it to fade an arbitrary number of animations. It was a little tricky, and I wouldn't be surprised if there were lurking bugs, or cases in which it doesn't work well, but it seems to function well enough for the moment! At the least, the animations that prompted this seem to now transition better than they did.

And finally, there were a few other changes and fixes that don't seem worth further expanding this blog-post.

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

[Thaumaturge]

Blog post (29th of January, 2018)
A Start to Music

Summary: In which a multifarious miscellany is mentioned; music is tackled; performance gains are chased; a possible improvement to shadow-casting is in progress; the sky and sun are improved; and animated mist backs the end-of-demo "cutscene"

Greetings and salutations!

For this week's image, a partial look at the end-of-demo "cutscene":



The week just past was filled with numerous changes to various elements--bug-fixes, art touch-ups, experiments, technical matters, etc. As a result, instead of attempting to touch on nearly everything, I intend to pick out just a few items to discuss:

First of all, in the week just past I made a start towards adding music to the game.

A few of you reading may know this, but my brother (who is a musician) had previously offered to help me with music. To that end, I met up with him again in the week just past, and we further discussed and experimented with sounds.

It was difficult, I'll admit: I found it tricky to communicate what I wanted, what I thought might work, and he has little experience with game-music, specifically. On top of that, since he's doing this for free, I don't want to ask too much. In the end, it looks as though we may only produce a title theme from this collaboration--but that alone is exciting.

Right now I don't have the money to hire a composer, I fear. As a result, I've started looking through royalty-free music. I've pretty much only begun this process, however, so I don't yet have anything selected!

(As a side-note, I've decided that I want to avoid using Kevin MacLeod's music: my impression is that it's the royalty-free music most often used by indies, and I don't want my game's soundtrack to sound too familiar!)

(If I run a crowdfunding campaign, and if that goes well, I may add the hiring of a composer as a stretch goal.)

On the technical side, in my continued efforts to improve performance, I decided to remove the detail texture being applied to the first level's grass.

I had realised, you see, that the entire texture wasn't really called for: the nature of the grass geometry meant that I could easily just use the colours at the model's vertices. To that end, I used Blender to read the detail texture and store values derived from its colours in the vertex-colours of the grass, allowing me to have much the same effect without an additional texture-read!

(Alas, this doesn't seem to have helped much, which seems odd. I'm honestly a little mystified at some of the performance issues in the outdoors section of the first level! :/)

Another attempt at improving performance involved a change to my method of handling "sunlight"-shadows.

From what I've seen, (and as I've mentioned before, I think) part of the cost of those shadows is that they render into a texture much bigger than the one used for the "player-light". But simply reducing the size of that texture results in the shadows being of much lower quality. However, note that this effect is far more visible at close range than far: in the distance, perspective reduces the size of the "shadow-pixels", and thus the impact of their quality, I believe.

Thus, I'm attempting a two-layered system: Two shadow-cameras, both rendering to smaller textures. One handles nearby shadows; since it covers only a limited area, the lower texture-size shouldn't result in much reduction in quality. The second camera handles more-distant geometry, doing so at lower quality, but hopefully without that being too noticeable.

It's still a work-in-progress, however, so I don't yet know whether it will work!

Dealing with this, however, led to my discovering bugs in my handling of the "sun"-light and the sky-box, as I recall. For one, the "sun"-camera wasn't properly following the player; for another, the sun rendered in the sky-box and the "sun"-camera weren't properly aligned.

On top of this, I decided to change the way that I was handling the "placement" of the sun: instead of specifying a direction-vector, I felt that specifying an angle and elevation would be more intuitive. (And indeed, having implemented it, I think that it is.)

Getting all of this to work was a tricky business, as I recall, but I think that I have all of this working now!

And finally, as shown above, I decided that I wanted the end-of-demo "cutscene" to use my animated mist in its backdrop, instead of the static image that I had previously used. I was a little concerned that it would be too distracting, but with the appropriate speeds kept low, I think that it's fine, and that it looks rather better than the static backdrop!

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

[Pixel Noise]

Funny you mention having difficulty conveying what you want for the music - we've noticed this trend among devs, and are actually in the process of drafting a talk/presentation for PAX South next year, as well as to give in other local dev communities, university programs, etc.

The main point is that - everyone has common words to describe the music they want! You just have to find them and not be afraid to be "wrong"; for example, start with the overall emotion. Whether very general, like "happy, sad" or more specific "with poignant longing", etc. Just that can go a long way.

Good luck with the music, I hope you find something you are happy with!

[Thaumaturge]

Funny you mention having difficulty conveying what you want for the music - we've noticed this trend among devs, and are actually in the process of drafting a talk/presentation for PAX South next year, as well as to give in other local dev communities, university programs, etc.

The main point is that - everyone has common words to describe the music they want! You just have to find them and not be afraid to be "wrong"; for example, start with the overall emotion. Whether very general, like "happy, sad" or more specific "with poignant longing", etc. Just that can go a long way.

I think that a lot of the trouble that I had was with the specifics: What do I like or not like about this idea? Given an exemplar song, what is it about that song that I want to highlight? I have an idea in my head--of drums being used thus, or an emotion being expressed so--how do I convey that in words, especially given limited musical knowledge?

There was also the question of what should be dominant, and what feeling should be conveyed in the melody, as opposed to background elements.

I'm interested to hear your talk! Will it be available for those not going to PAX?

Good luck with the music, I hope you find something you are happy with!

Thank you very much! ^_^ (I hope so too! :D; )

[Pixel Noise]

Yes, we will record it and put it up on Soundcloud I'm sure - I'm going to follow up with you on twitter because you've shed light on a big part of what the talk needs to be about - what problems you as a dev face/feel when discussing music.

[Thaumaturge]

Yes, we will record it and put it up on Soundcloud I'm sure ...

Excellent--I'm glad to read it! ^_^

... I'm going to follow up with you on twitter because you've shed light on a big part of what the talk needs to be about - what problems you as a dev face/feel when discussing music.

I'm glad if I can be of help; message/tweet at me on Twitter whenever you're ready. ^_^

[Thaumaturge]

Blog post (5th of February, 2018)
Rise of the Bugs

Summary: In which shadows are experimented upon; bugs rise up in numbers; combat sees tweaks and changes; and a trailer is under way.

Greetings and salutations!

For this week's screenshot, a few excerpts from a trailer that I'm working on:



The week just past saw a lot of work, I feel--including a lot of work on a lot of bugs!

First of all, another episode in my continued efforts to improve performance in the first level:

I mentioned last week, I believe, that I was experimenting with rendering two shadow-maps instead of one for the "sun"-light, one handling nearby geometry and one handling distant. This allowed me to render them to smaller textures, as I had noted that reducing the size of the texture in the single-shadow-map version improved performance, at the cost of quality.

In the week just past I completed this, and it worked as expected: I retained acceptable quality up close, with little loss of quality in the distance. However, it didn't actually improve performance--perhaps because I was now rendering parts of the scene twice, and performing two shadow-map lookups in the shaders of "sunlit" objects.

Moving on from that, I decided to try something else, an idea that I'd toyed with every so often for some time now. In short, I intended to warp the projection of the scene such that nearby objects mapped to a larger centre portion of the shadow-map than distant ones, allowing for higher visual quality.

It took a little while and some effort to get it working, but work it did in the end! And indeed, it showed a noticeable improvement in performance! I was quite pleased with the result, as I recall.

I went on to record some gameplay footage (more on which below)... and noticed in the prologue level that certain shadows slid over geometry in manners that I didn't expect, especially around the surrounding walls.

Alas, it seems that large polygons--like those of a simple wall--aren't warped as one would want, simply due to a lack of vertices. As a result, certain elements of geometry end up moving relative to others, causing the shadows to move in unexpected ways. :/

So, for now, at least, I've returned to my basic shadow-mapping arrangement.

The above aside, it feels like a significant portion of the week just past was dedicated to bugs. A fair few were uncovered during the week, some during the above-mentioned gameplay recording, some otherwise. Few seem worth describing in detail, but one salient nest of bugs was the combat mechanic.

To start with, I noticed that blood particles weren't originating from the expected points.

After some searching, I discovered that attacks were landing rather too early. A big part of this, I believe, was simply that the combatants had been given "sizes" that were rather too large. But the course of fixing this involved a number of other changes, including calculated angles, the ranges of attacks, and more besides.

I also ended up changing the manner in which combatants handled their attack-lunges.

Due to one change or another, I believe, I was finding that the mummy enemy would respond to being attacked by attacking in turn--but without advancing, resulting in an ineffectual swipe as the player automatically recovered back from their lunge. Presumably the AI, responding to an attack in kind, found the player very nearby and calculated its lunge for that distance. But since the player recovered back after the lunge, the mummy's advance wasn't nearly enough.

On the other hand, allowing the combatants to lunge as far as they liked wasn't ideal either; doing so had caused problems in the past, as I recall.

What I did, then, was allow them to attempt a lunge to a specific maximum distance--but had them detect the nearness of their opponent, and stop if advancing further would take them "though" said opponent. They can, however, advance again--up to that maximum distance--if their opponent falls back, covering such instances as the lunge-recovery mentioned above, I believe.

And during all of this, I tweaked and worked on the AI for the mummy enemies, making them, I think, a little better than they were.

And those weren't the only changes made in the combat mechanic; as with the more general list of bugs, there were other things fixed and tweaked that don't seem worth mentioning, I believe!

On the artistic side, I continued searching for royalty-free music for the game. I didn't find much that worked for me--but I did discover a piece that gave me inspiration for and music to an "early trailer" that I wanted to work on. (Appropriately, the piece in question is called "Inspire"!)

I already knew more or less what I wanted for this trailer, but that piece led me to the text and structure for it. Accordingly, I began work on that--it was for this trailer that the above-mentioned gameplay recording was done, as I recall.

One challenge of putting together the trailer came from the length of the musical piece. As is fairly common, I think, it's a few minutes long--but that seems a little over-long to me for a trailer like this.

I liked the introduction of the piece, but also very much wanted its ending and some of the main of it. So I tried cutting it up and blending the pieces together--but didn't manage to get that to sound right. In the end, I settled for simply starting later in the piece, with a quick fade-in from zero volume.

That said, even a shortened version felt a bit long as a trailer. I could shorten it, but that would mean losing some of the changes in the music, resulting in less variety and subtlety. What's more, this further-shortened version would show less of the game.

So I've decided to make both versions. The shorter of the two is more compressed--perhaps more to-the-point for people first encountering the project?--but both reach the same ending.

I have the shorter version done, and am close to completing the longer one, I think--although I don't intend at the moment to release them until I've done some cleaning up and preparation in other places, such as the website.

And finally, a number of other things were done in the week just past, but none, I think, worth mentioning here.

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

[Thaumaturge]

Blog post (12th of February, 2018)
Press Start?

Summary: In which a trailer is revealed; the website is updated; a press-kit is added; music is sought out; and a bunch of bugs are fixed.

Greetings and salutations!

To start with, in place of a screenshot this week, I present to you a trailer! This is still an early trailer, but it's nevertheless intended to be my first "real" one--something that might be used for promotional purposes.





The trailer above is the short version; an extended version--which makes use of a bit more of the trailer-music and shows a bit more gameplay--should be linked-to in both its description and end-of-video annotations, I believe.

The week just past saw a start to marketing proper, I suppose--as well as a continued search for music, and a fair bit of bug-fixing. Let me elaborate:

Perhaps the biggest news of the week is as shown above: I've released a new trailer for A Door to the Mists! (As mentioned last week--and above--I believe, I've in fact released two--the trailer shown in this post, and an extended version, linked-to from that trailer.)

Along with that, I've made some touch-ups to the website: a new site-banner, some updated screenshots, and touched-up text, for example.

Perhaps the biggest of these is that I've integrated Rami Ismail's "presskit()" into the site, and have set up both the general press-page and one for A Door to the Mists specifically. This press-kit should be accessible via a button on my website's navigation bar, or via this direct link.

Overall, I found "presskit()" to be very good indeed: it's quite easy to use (with a few quirks, perhaps), and walks you through the process of setting up press pages. There are even a few example-pages linked-to from the "presskit()" website. And once you're done, it outputs a clean, navigable set of press-pages, complete with screenshots, description, trailers, etc. (as far as you've provided those, of course).

(I was somewhat hindered by an odd issue that I've been experiencing with the website, in which changes made aren't immediately reflected, only showing up a short while later. It looks as though the server may be doing some sort of caching. :/)

Marketing matters aside, I also continued to search for royalty-free music in the week just past. Alas, I haven't yet found much that I'm terribly enthused about. This doesn't reflect a lack of quality in the royalty-free sites that I visited--I think that there's some really good music on them. The trick is in finding music that I feel fits my game.

Otherwise, I also fixed a large number of bugs in the game itself, as well as doing some miscellaneous cleaning-up. (To my frustration, the custom code that handles animation-blending, which I mentioned in a previous post, I believe, continued to be a major source of said bugs. :/) However, none of these seem worth mentioning in detail, so let me end here!

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

[Thaumaturge]

One more thing: I've just updated the first post a little, as well as the "percent completed" value! (The "percent completed" is somewhat of a guestimate, I will confess. But hopefully much of the technical stuff is behind me, with level-work, modelling, enemy-design, writing, music-seeking, etc. making up the majority of what lies ahead...)

[Pixel Noise]

I think the music fits the trailer/style pretty well - I think the trailer pacing is good, and seems to show a bit of everything. I think the best shot is the player in front of the stained glass window - that might be a nice way to end the trailer, as it's a very nice shot and might leave the most lasting impression.

[Thaumaturge]

I think the music fits the trailer/style pretty well - I think the trailer pacing is good, and seems to show a bit of everything.

Thank you very much! That's really encouraging to read! ^_^

I think the best shot is the player in front of the stained glass window - that might be a nice way to end the trailer, as it's a very nice shot and might leave the most lasting impression.

Hmm... That's a good idea, I think. I wasn't quite sure of what to put in that last shot (where I currently have the curtain), and while I do like the current placement of the stained-glass window shot, I think that it might indeed be better as the last shot...

Thank you! I may well do that in the next version! ^_^

[edit] The next trailer will likely be a gameplay trailer--but perhaps it wouldn't be a bad idea to release a modified version of this early trailer at more or less the same time...

[Thaumaturge]

Blog post (19th of February, 2018)
Quest for Music (and a Font)

Summary: In which music and fonts are sought; only one of the former succeeds; music-logic is updated; "stuns" gain some "impact"; sound-effects are improved; and a visual effect isn't done yet.

Greetings and salutations!

For this week's screenshot, a gif showing some new effects that accompany attacks that "stun" the player in combat:



(Don't worry, the rapid "zoom-pulse" can be disabled in the options menu.)

The week just past was a bit of a slow one, I feel, but a few things did get done:

As the title may suggest, a major task during the week just past was the search for both music and a font.

The font was intended to be a replacement for my current "general text" font--the one used for the majority of the text in the game. While I like the one that I'm using at the moment, I do fear that it's not a legible as I'd like at the size that I'm using.

So I went searching on a handful of free-font sites for a replacement--but alas, I didn't find anything that fitted my desires. While I did find a few that I liked, issues with their licences prompted me to leave them. (In particular, it seems that a large number of fonts use the "SIL" licence, and while this licence may be safe for me to use, I'm not confident of that.)

As to music, I had a little more success there, I think. I fear that music is a bit of a weak point for me, and that I didn't always know at first what might work. As a result, I ended up trawling through various collections of royalty-free music more than once. But in time I think that I learned better what types of music seemed to work, and thus what I was looking for.

And between the collections that I already knew and freesound.org (to which I was directed by someone on Twitter, I believe), I may have found pieces to cover all gameplay sections, and possibly the alternate-ending cutscene and the end-of-demo "cutscene", too. I might like a little more variety, perhaps, or other changes, but at the least I may have stand-in music!

(I haven't yet downloaded and tried out the ambient sounds that I currently intend to back level-exploration, so we have yet to learn whether that works!)

I also ended up making some changes to the music-related logic of the game:

In cutscenes, music-tracks can now have an offset applied to their starting-times, which can in turn be specified in the editor. This allows me a little more control over the "scoring" of my cutscenes, I feel.

Elsewhere, I separated out the music-related logic of the "World" class (which is the base-class for levels and the "combat-world"), creating a new "MusicListPlayer" base-class. This allowed me to have the minigames derive from this base-class, too, thus taking advantage of its logic. I further added a volume-scalar to the base-class, allowing me to have different sections of the game play their music at different volumes relative to each other--levels are quieter than minigames, for example.

Stepping away from music, I've added two new visual effects to the combat mechanic, as shown above. Now, when the player receives an attack that "stuns" them, white "spikes" drive in from the sides, and the camera performs a quick, pulsing zoom -in and -out. Both may see changes going forward, but I think that they add somewhat to the impact of such attacks.

(As noted above, the "pulse-zoom" can be disabled in the options menu, I believe, for those who may dislike or be adversely affected by it.)

Various sound effects saw some work, too. To start with, I added a few new sounds: a handful to be played when the player is "stunned" in combat, and one for attempting to open a chest that's tied shut. I also reworked the various player-character "pain" sounds--the previous set were... not good, I fear. The new ones seem better, at least--although whether they're good (and actually sound like they come from someone female ^^; ) I don't know!

On the graphical side, I may have slightly improved the highlights produced by the player-light--but I want to try another change, and so I'm not yet ready to show the results.

And finally, I worked on a number of bug-fixes, changes, and minor additions that don't seem worth mentioning here.

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

[Thaumaturge]

Blog post (26th of February, 2018)
A Cutscene Scored

Summary: In which music is found; a cutscene is scored; sounds are added; conversations support voicing; the font-search ends; climbing is polished; inventory items may be lost (intentionally); an object is moved; and most bugs are small.

Greetings and salutations!

For this week's "screenshot", another video--this time of the intro. cutscene, now with (possibly stand-in) music:





The week just past was full of a variety of tasks. The main ones were perhaps those related to music, but there were a few others that are perhaps worth mentioning, too:

First of all, on music: I returned to various royalty-free sites and searched again their collections in the week just past. And between what I had previously found and what I turned up in these new searches, I think that I have at the least stand-in music for all gameplay elements, as well as for the intro- and first-level- cutscenes. (The prologue cutscene I've decided to leave music-less for the moment--it's short enough and has enough ambient sound that I think that it can stand without music.)

None of the music is quite right, I fear. And further, the scoring of the cutscenes is somewhat clumsy, as it involves my cobbling together various pieces of music to convey the various feelings that I'm looking for, to the timings of the scenes. But for the moment, and for demo purposes, I think that what I have works well enough.

The game's sound effects also saw some work in the week just past. There are two changes that might be worth mentioning here:

First and simplest, I've added a gong-like sound that is played when the player selects a collectible or lore-entry in their collection. I'm hoping that this adds a little bit of additional sense of saliency and mystery to these items, I suppose.

Second, I've implemented support for voicing of conversations. Now, I don't know that I will ever manage to get them voiced, but it's something that I want implemented ahead of time, in case I do. Further, I don't want them to be entirely silent either way, so I've added a "default sound" that's played when no voice-line exists for a given piece of text. Right now, that default is a simple drum-like beat, which I'm hoping is sufficiently dramatic. (And might add to the startlement of a few of the more-unexpected conversations. )

I don't know whether either of the above-mentioned sounds are final; we'll see as we go forward!

Remaining with aesthetics, I believe that I mentioned previously that I was unhappy with my "general-purpose" font. In the week just past I once again undertook some font-searching, attempting to remedy this. I did settle on one--Bitstream Vera Sans, I believe--but it was very plain, and I was unhappy with it. In the end, what I've done is simply to increase in various places the size of the font that I was using. It's perhaps less elegant than it was, but I do think that the change improves the text's legibility, which seems more important to me.

There are some situations in which I haven't changed the font-size, however; whether that will prove a problem remains to be seen.

On the mechanical side, I spent some time polishing the "climbing" mechanic:

First of all, I've fixed a minor but unpleasant "skip" in the view that happened when starting a climb from above.

Aside from that, I worked on making the process feel a little smoother, taking into account the player-character's speed at the start of the climb. I was perhaps a little anxious about doing so: I feared making so central a mechanic feel worse. Still, I think that it was worth making the attempt.

And I think that I have improved it a little. In the end, while I did succeed in making it much smoother than it was, I pulled back from doing so to a great degree: In the case of catching a surface as the player dropped down, the smooth transition from falling to climbing slowed the action down a bit much. And in the case of catching a surface while jumping up, the increased vertical speed made the process feel perhaps too smooth and effortless. I hope that what I have now retains the feeling of the climb calling for some effort, without bogging it down too much.

Moving over to the game's levels, I've added support for automatic removal of specified inventory items on exiting a level. This provides a convenient means of having certain items that are no longer relevant be "dropped" between levels.

This feature is currently implemented in the "exit" game-object, which does mean that it's theoretically possible for a level to be exited without this code being run. Furthermore, if an exit were to be used to "exit" to a cutscene with the intention of returning to the same level, the code might be run when it likely shouldn't be. However, I think that both of these are fairly unlikely scenarios, for this game, at least.

Turning to the first level, specifically, I decided to move one of the items therein: One of the upper tombs contains an important scrap of paper. I had hidden this in a corner of the tomb, perhaps wanting it to not be obvious. But I had also long been a little uncomfortable with this placement, fearing that it was too unobvious: it's a small scrap, of a colour similar to the floor, in a corner. In the week just past I decided at last to move it, placing it on the tomb-slab, near the corpse that rests thereon.

And once again, a number of things were done that don't seem worth reporting here! Bugs were fixed, polish worked on, details of implementation changed, and so on.

One thing that I've noticed over the past few weeks is that while there have been plenty of bugs, it's seemed that most have been fairly quickly fixed. Seldom have I encountered something that called for major changes. I find this quite encouraging. ^_^

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