[Blog post (6th of June, 2022)Lighting and Looks]

Blog post (6th of June, 2022)
Lighting and Looks

Summary: In which an editor is made for the purpose of lighting; a shader is updated; another shader gains some variation; the appearances of two levels see work, as does their moon-exterior; the interaction icon is changed in look and placement; an NPC is being modelled; and certain enemies may seek mana.

Greetings and salutations!

This week's screenshot shows a few changes in the tutorial level: some decor, some lighting, and some variation in the tiled floor:



The week just past was perhaps one largely given to matters of appearance, with a few other things done besides:

Perhaps the biggest part of this, both in salience and time spent in the week just past, was the creation of a new tool: an editor for the lighting of levels.

You see, up until the week just past, I had included lighting in my general level-building workflow within Blender. However, this presented a difficulty: as I didn't have my shaders in Blender, I couldn't see what I was doing. I could use a visualisation to see the range of my lights, but not their levels of softness, or their intensities, or how they merged together--or, overall, how they affected the appearance of the level.

So, after some deliberation, I decided to make a simple editor for the purpose.

This editor, now implemented, allows me to load a level; set the level's ambient lighting; and via the mouse and keyboard place, edit, and delete my lights. And, combined with some supporting changes to the handling of lights within rooms and ambient lighting within levels, this new approach seems to work nicely!



Here below you should see a gif showing the overall workflow within the editor. It's from an earlier iteration than the current--note the different UI and light-markers--but it should nevertheless give you and idea of how editing with this tool works:



And concomitantly, I also added support for lighting to a shader that lacked it.

Speaking of shaders, the standard location-shader was updated a little in the week just past.

You see, I had been wrestling on-and-off with the fact that simple tiles, viewed top-down, can feel a little over-uniform, and thus not very interesting.

Decor helped somewhat--but much of that was placed around the edges of the various rooms. I did experiment with adding hand-made cracks and chips to the floors, but this looked to me to be overly painstaking.

But the inspiration came to me to implement some variation in the underlying shader--to add some data to my tiles, and to have the shader interpret this data in a way that would produce a more-varied appearance.

In short, the tile-image now has an additional layer of values packed into its "alpha" (i.e. transparency/opacity) channel. These values are then compared to a noise-value that was already being read by the shader. As the noise-value changes, essentially, so too does the value at which a tile is changed, and the manner in which it changes.

And I do think that it rather helps!

All of the things mentioned thus far contributed towards work on the overall appearance of the tutorial level. You can see much of this in the first screenshot above, but let me post one more screenshot, showing all of lighting, decor, and tile-variation:



Likewise, work was done on the exterior appearance of the moon, both its in-space texture and, more so, the look of its "surface" level.



Remaining with visuals but moving away from the moon itself, in the week just past I also touched up the game's "interaction" icon. Specifically, I updated its appearance, and switched it from appearing over the subject of interaction to appearing over the player:



And last of the visual matters that I intend to report in this blog-post, I made a start on the appearance of an NPC who is encountered in the tutorial level.

But not all work of the week just past was visual in nature: I also made a change to the behaviour and abilities of the "Deceived Acolyte" and "Deceived Cultist" enemies: They can now draw power from the mana crystals that the player can create, becoming more dangerous for the brief lifespan of a crystal. (Just as was already true of the player.)



And of course there were various other tweaks, fixes, and changes that don't seem worth detailing here!

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

There may also be an element of nostalgia: The games (and works in other media, for that matter) that we encounter early in our experience tend to be especially impactful to us, and thus may at times appear to be superior to those that we encounter later.

And as you say, there may also be an element of the opening of game-dev to greater numbers of devs may at times result in a bit of a discoverability issue.

But I do think that personal, heartfelt games are still very much being made by indies.

Well, what is your game about? That might suggest some directions for inspiration.

I would add a picture, but I'm not completely sure yet how I would do that. Help would be greatly appreciated.

I believe that at least one method is to upload the image to an image-/file- hosting service (e.g. DropBox), and to then use tags within your post to display that image. The tags in question (with spaces added to prevent the forum from interpreting them) are "[ img ]" and "[ /img ]". (Let me note too that said tags have an optional "width" parameter, should your image be larger than the post.)

Those tags are used something like this:

Code:

[img]<your image-URL here>[/img]

Or, applying a width:

Code:

[img width=800]<your image-URL here>[/img]

When writing a post, you can either type in the tags yourself, or press the "image" button that should be available amongst the various buttons above the text-entry in which you enter your post; said button looks like a tiny frame painting, I believe.

[Blog post (30th of May, 2022)Touching the Aethereal]

Blog post (30th of May, 2022)
Touching the Aethereal

Summary: In which a new metroidvania-ability is implemented.

Greetings and salutations!

This week's screenshot shows the effect of a new metroidvania ability:



And indeed, that new ability was, I think, the main work of the week just past, albeit with some other things done besides:

The new ability in question is--for the moment at least--called "The Eye of the Aether". In short, it allows the player-character to dip into the aethereal at their current location--and thus to reveal some things and vanish others. In some cases this only reveals an impression of a past event; in other cases, it changes the world around, and the paths available through it.

And I have at least one use in mind towards the full game that would take the latter even further...

The presence of such unseen elements is currently sign-posted by a localised mist.

Actually creating this feature did prove a little challenging, as I recall, and involved a bit of iteration:

Originally, I envisaged the ability as operating by area of effect: when activated, it would make relevant objects appear or disappear within a certain radius of the player. And indeed, I implemented this and had it largely working, I think.

But I realised that it presented a problem: if the player revealed only part of an aethereal structure, they could potentially find themselves dealing with a broken room--and indeed, one that might then allow them to escape the confines of the level.

So, after some thought, I changed my approach: Now aether-related structures are handled as indivisible units, meaning that when acted upon the entire structure is affected.

Further, such objects are now detected via trigger rather than distance: aether-related objects each have a trigger that alerts the ability to their presence, and on the ability's activation, all present objects are then affected.



And once again, a variety of things were done that don't seem worth detailing here--collision for dragged objects; some level-building; a few more bits of tutorialisation; bug-fixes; and so on!

But before I conclude this blog-post, let me share one more gif--this one showing a test of a post-process effect that I implemented in the week just past. The effect was subsequently removed, but I like the gif well enough to want to share it anyway:



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

[Blog post (23rd of May, 2022)Shedding Some Light]

Blog post (23rd of May, 2022)
Shedding Some Light

Summary: In which level-building continues; tutorial-messages are added; "blockages" are made; room-hiding is reworked; a door is thickened; lighting is implemented; and performance optimisations are sought and enacted.

Greetings and salutations!

This week's screenshot shows another addition to the aesthetics of the game: lighting! (As well as some tutorial-text.)



The work of the week just past was perhaps given primarily to issues raised by level-building, with some actual level-building and other matters done besides:

To start with, I did enact some level-building in the week just past--indeed, I think that I have the functionality and layout of the Vertical Slice Tutorial Moon complete!

This itself involved the implementation of two new features: Tutorials, and "blockages".

The tutorials in question are simple things: popups that appear when the player is within certain rooms, each sized to its text.

Speaking of which, I think that I have said text more or less complete--although I might add one more entry in the final room of the tutorial.



"Blockages" are likewise fairly simple: they're essentially "doors" of a sort (although not descended from the actual "Door" class), being objects that may control whether two rooms are linked. However, unlike actual doors, or breakable walls, these are not "rooted", and so can be moved via the player's "grab" metroidvania-upgrade.



As to the aforementioned issues raised in level-building, one of those was the matter of hiding rooms when they're separated from the player.

Until the week just past, this was done by fading the room itself to black--a simple expedient that had seemed to work.

However, in building a proper level in which this effect was visible, I found that it didn't work as well as I'd hoped: the cut-off between hidden and visible rooms was too sharp. (And there may have been some other unsightly artefacts; I forget.)

So, in the week just past I replaced that system with a variation of a previous one: now each room (optionally) has "cover" geometry, which can be faded -in and -out to hide said room. And since these covers are separate geometry, they can be made to overlap adjacent rooms and given semi-transparent borders, allowing for a softer transition between a hidden room and an adjacent visible one.

But this approach did incur a problem of its own: the doors of the Ossuary Moon were too thin. With the soft transition placed over them they would be all too greatly covered.

Thus I reworked the Ossuary's doors to be wider--and, I think, a little cooler:



Another issue that I discovered in level-building was that levels could end up looking a little flat; a little uninteresting. Even, I suspected, once additional decoration was put in place.

After some thought, I settled on the idea of adding lighting to my levels, in the hopes of adding a bit of depth and variation in their appearances.

These lights are fairly simple things: up to sixteen circles of illumination, each with a size, an intensity, and a "softness". (Although I may yet add colour.)

What's more--and with the aid of someone on GameDev.net--these lights do not accumulate independently. Instead, they merge together into blobby "masses" of light, creating an effect that's a little more stylised, and with a little more "form", than might be had with independent lights.

The result, then, should be visible in the first screenshot above!

On the technical side, one more issue that I had discovered was that performance dropped quite significantly around a cluster of enemies in the Vertical Slice Tutorial Moon.

So, in the week just past I set out to improve matters. Offhand, I recall that I implemented shader-based skinning, and that I adjusted the handling of effects by projectiles.

And indeed, these things helped! The frame-rate does still drop more than I'd like--but noticeably less than it did, I do believe.

And of course, there were various tweaks, fixes, and changes that don't seem worth detailing here!

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

[Blog post (16th of May, 2022)A Tutorial Moon]

Blog post (16th of May, 2022)
A Tutorial Moon

Summary: In which a UI bug is fixed; weapon-icons are reversed; a UI is reorganised; enemies may respawn--but generally not as they once were; an autosave is put in place; some writing is done; a start is made to level-building; an old enemy returns; and some new issues are discovered.

Greetings and salutations!

This week's screenshot shows the return of an old foe, now with a new coat of paint!



The week just past was another bit of a miscellany--but perhaps most notably included a push into content-creation:

On the UI side, for some time I've had a bug that prevented players from typing into text-boxes (such as when naming a save-game) while using non-mouse menu-navigation. In the week just past I believe that I fixed this issue!

Perhaps more saliently, however, in the week just past I re-ordered some of my UI elements!

For one, the weapon-icons in the main game-view are now ordered in the opposite direction (top-to-bottom instead of bottom-to-top). This results in their matching the ordering used in the status screen, and thus makes for a more-consistent presentation.

But larger than this is the change to the save-load menu: it's been completely overhauled, with wider save-buttons and repositioning of both the screenshot-view and the control-buttons. All of this with the intention of allowing more space on the save-buttons for long file-names.



And that in turn prompted by the fact that I've implemented a more-useful approach to generating default names for saves:



Moving to the gameplay side, I have at last implemented enemy respawning!

Now, in some metroidvanias enemies simply respawn as they were first encountered: if on first entry to a room you encounter an enemy, with subsequent respawns you'll again encounter that same enemy in that same spot. (Barring changes to world-state.)

But I don't want that in Moons in Crystal: I want, I think, for the player to have a greater sense of having an impact on the world, and of making it at least a little safer.

So, I've thus instead implemented a system under which respawns draw from an optional secondary set of spawners, and select randomly from those. The idea is that these will offer lighter and more-varying opposition to the player--and indeed, will more-often include harmless "wildlife".

(And the system that I have in place should also allow me to change which secondary set a given room draws from, allowing for changes to the state of the world.)

All of this did, however, call for some changes and fixes to my handling of spawning, and of saving-and-loading.

Remaining with gameplay matters, in the week just past I also instated an autosave on exiting a major location (such as a moon).

As to content creation, in the week just past I did a bit of writing, adding for example drafts of codex-entries for various moons, if I recall correctly.

And with all of the above done, and my to-do list thus looking rather lighter, I took a step at last into the level-building phase proper. Specifically, I've begun work on a small "Vertical Slice Tutorial Moon"--a location in which to provide a tutorial for players just starting out in the vertical slice.

(I want this to be separate from the previously-shown "Vertical Slice Moon" because I don't want new players to have access to the things contained there from the very start.)




And it's for this location that I've brought back the worm shown in the first screenshot of this post: an old enemy left fallow since the Treasure Hoard Moon was cut, now finding new use as a starter enemy. With, admittedly, some changes to both behaviour and appearance.

That said, creating this location has--not entirely unexpectedly, I think--uncovered some lurking issues, things that I feel want for fixing before I move forward. For some of these I think that I may have answers (or indeed, one answer that--somewhat literally--covers multiple issues), while for others more investigation may be called for.

And of course, in the week just past I enacted various tweaks, fixes, and changes that don't seem worth detailing here!

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

Which one looks better?

To my mind, it depends on the feel that you're going for: both might look good if they're of a piece with the rest of the aesthetics.

The "straight" laser, to my eye, looks more precise, more "technical", more technologically polished.

Conversely, the "wibbly" laser, to my eye, looks less precise, more "organic", more chaotic, and less technologically polished.

By the way, have you considered adding a bit of glow around the laser? That too might improve the look of the thing, I feel. (Again, if it fits with your aesthetics.)

[Blog post (9th of May, 2022)Optional Changes]

Blog post (9th of May, 2022)
Optional Changes

Summary: In which writing is done for the codex; the number of codex-entries is reduced; the liche gains a new effect on death; the effects and camera-work for teleportation are reworked or polished; new accessibility options are added; and some video options are implemented.

Greetings and salutations!

This week's screenshot shows some new accessibility options:



The week just past was one of those "miscellany" weeks: A week in which a number of different aspects of the game saw work:

I mentioned in last week's blog-post, I believe, that I had begun filling out the codex. Well, in the week just past I both did more of that--and actually reduced the codex!

Regarding the former, in the week just past I sat down and wrote or edited a number of entries for the codex. I have a few yet to be written--those for the moons, specifically, I believe--but I think that I have at least a draft of the majority!

However, I also realised that I had some problems, if I recall correctly:

For one, I wanted codex-entries for NPCs to be found within the world--but this made less sense for artefacts and upgrades, producing an inconsistency in the gaining of entries. For another, I wanted to have an effect and title be displayed on gaining a codex-entry--but in the case of artefacts and upgrades, these clashed with the effects and titles already associated with those. And finally (that I recall), there didn't seem to be much to say in a codex-entry about the upgrades, specifically.

So, in the end, I took the decision to cut the codex-entries for artefacts and upgrades. (With some of the writing already done for them being transferred to one degree or another to relevant NPC-entries.)

And with that done, I implemented the display of an effect and a title on gaining a codex-entry.

Speaking of effects, in the week just past I added two new ones:

First is a simple effect added to the "death" sequence of the liche: the undead sorcerer's soul can now be seen passing on after their death, a black shade that reaches out to grasp at the living world--but in vain.

And second is a reworking of the effects used for teleportation: Now a "tear" appears at both the source position and the destination, rapidly shrinking as the fabric of the world mends. Furthermore, the "rings of light" effect already in place has been polished.

In addition, in teleportation the camera now translates from the source position to the destination, providing a smoother segue than the immediate skip that was previously used.



As the first screenshot above shows, I also did some work on the game's options in the week just past.

Previously, I had only two gameplay options: sliders for each of "game speed" and a controller "dead-zone".

Now there are two more: accessibility options that allow the player to halve the health of one or both of general NPCs and bosses.

(Also visible in that screenshot is a revision to the appearance of the "reset" buttons used by sliders, as well as some changes in the spacing of the options.)

Not visible in that screenshot is that a new page has been added, this one for video options.

Specifically, this page currently holds two options: one by which the player can select a window-size, and one that allows the player to toggle to and from full-screen. (Both of these were taken largely from their implementations in A Door to the Mists.)



And finally, a number of things were done in the week just past that don't seem worth detailing here: a reduction to the in-game size of artefacts; some reworked map-icons; and more besides!

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

I am intrigued, I will say--and the art is lovely! ^_^

Still working on this font, and tests/thoughts about how I might want to design the logo. The blue flame is magic fire created by the game's antagonist, fires which burn continuously in Larkstead, around the bones of those who wronged the antagonist.

Ooh, that looks really cool! (Literally, in the case of the colouring. ;P)

I will confess that Schrompf's concerns are a worry--but I don't feel that I know well enough to comment on the matter, myself.

[Blog post (2nd of May, 2022)Codex Entry]

Blog post (2nd of May, 2022)
Codex Entry

Summary: In which an item gains proper art; the UI for item-enumeration is set in place; enumerated items are given upper limits; the codex fills out; and some further effects-polish is enacted.

Greetings and salutations!

This week's screenshot shows a revision to the appearance of the Rune of Power item:



The week just past was, for the most part, a visual one, albeit with a few other things being done besides:

As shown above, the Rune of Power finally has a proper in-game image! And indeed, I'm rather happier with it than I was with my previous draft. ^_^

Further, I've likewise made a proper utility-icon for it, to be shown in the UI:



That said, I will confess to an anxiety: sometimes--and indeed in this case--when designing a rune or suchlike I worry that I've stumbled upon an extant symbol--and worse, an untoward one.

So let me appeal: if I have done so here, please let me know so that I might change it! ^^;

(I have tried some searching for similar images, but have thus far found none.)

Now, you may note in the preceding screenshot a little bit of UI poking through at the bottom--a small curve that wasn't previously present. This is the top of a new UI element, a place in which to display the number of items held in the case of enumerated items (those currently being the runes of power and health gems).

Previously, this number was simply displayed over the main icon, which wasn't ideal for readability. So, in the week just past I set about finally displaying it properly.

And... This proved to be a bit of a challenge, as I recall! I went through a number of iterations, none of which I was happy with.

In the end, I went with something fairly simple and fairly small: a little circle that appears when an enumerated item is selected, below and to the left of the main icon. And with this I believe that I am happy. ^_^



This particular UI choice was in part supported by another change made in the week just past: Enumerated items may now have a maximum count applied to them, and indeed, such a maximum has been instated for both the runes of power and health gems.

Aside from allowing for a smaller UI footprint, this, I hope, will encourage players to use their items, and discourage them from grinding for items.

Moving from the UI to content, in the week just past I set about filling in the codex.

At the start of this, I somewhat alternated between painting icons and writing entries, but eventually I settled into completing the icon set.

And indeed, I believe that I have all but one of the current set done!

I don't want to show all of these icons right now--but here below is a redacted view, showing at least some of them:



And in working on the codex, I found that a number of elements didn't yet provide entries (enemies in particular, if I recall correctly). Further, a number of elements of logic turned out to want for reworking or filling in. These things, then, I think that I have now largely done!

(As I also tweaked which things do in fact provide codex entries.)

That said, looking at how extensive the codex already is, I am now thinking that I might want to break it up into sections! ^^;

Moving to matters of gameplay, in the week just past I did some further effect-polish: The binding ability gained a set of simple effects that appear on a failed attempt, as well as some polish to its extant effects. In addition, I may have a start to a new element for the effects used by the teleportation ability.

And as per usual, there were tweaks, changes, and fixes enacted in the week just past that don't seem worth detailing here!

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

Ha, yeah. I agree that it is indeed easier to implement, though.

And even at that it's not exactly "easy", I have found! ^^;

Map/tileset/rooms looking nice, looks smoother! I kinda agree for paid or community content DLC a menu like that is effective, and it seems smart to keep each adventure environment/version separate.

Thank you very much, on all counts! ^_^

(Especially on the art: I do worry at times about whether it's turning out well enough.)

I intend to have it feel as natural as possible. Imagine the cursor being a hand and you grad the object. I have some objects where the cursor is actually pinned and does not move away from the point you have touched at all, which is the optimal case. When rotating things, this is almost impossible to do.
This is the reason why making the cursor exit on the left and reenter on the right would feel totally wrong. The same can be said if the object moves further than the cursor/mouse.
A lot of puzzles are based on the correct and natural movement of things. Making it act in an unnatural way like Blender or something would take away too much from it and would make them feel like a click puzzle in the end.

For myself, I'm not convinced that it would feel all that unnatural. However! It comes down not to what I find natural, but what you find natural, and if you don't find that behaviour natural, then fair enough!

However, there may be a third option: Instead of either the current behaviour or cursor-wrapping, allow the in-game cursor to move beyond the view, moving with the object. That way there's still a sense of the player's "hand" being "connected" to the object, and of that "natural" movement--but without one of the restrictions of the current system.

After all, it's not exactly natural that one's hand gets stuck at the edge of one's vision... ;P

(Come to think of it, this might help with things like doors, too, as it would mean that the player wouldn't have to reposition in order to keep moving the cursor "towards" themselves...)

Thanks for the reports, everyone!

It's my pleasure for my part! ^_^

- there was a bug when restarting the game and selecting "continue" that would prevent you from interacting until you opened and closed the menu once again. This was caused by a recent hotfix, so that version didn't exist for long enough for it to get noticed. Thanks Thaumaturge!

Ah, I'm glad that you found and fixed the problem! Well done! ^_^
 

@Thaumaturge: I wasn't able to notice any problems when switching between windows. It's not using exclusive fullscreen mode, so there isn't happening much. I've seen that you are still using Win 8. Maybe that could be a problem, but I don't have such a system ready for testing.

Bear in mind that it's entirely possible that the tabbing was unrelated--it may just be that some other application happened to decide to steal focus at that point.

As to Windows 8, it is indeed possible that it's part of my problem; I haven't heard good things about it, confessedly! (Alas, I'm afraid that I'm unlikely to upgrade any time soon, I imagine: I primarily use Linux, only booting into Windows for things that refuse to work under Ubuntu.)

Would be great if the game straight up prevented you from walking too far while you're still interacting with something with your mouse so that doesn't happen, I think.

It would also contribute to the sense of physicality, come to think of it.

It would also be cool if maybe the mouse wrapped around the screen if you reach the edge, like in Blender, so you wouldn't have to move at all to keep pulling something all the way.

This is also a rather good idea, I do think! It feels really natural in Blender, and so it--or something like it--might perhaps work here!

It is not like moving a slider or something where you move a value up/down, but rather really attach the cursor to the thing and move it.

However, this is true of some interactions in Blender, too, I believe (at least in 2.78; I don't know about more-recent versions). For example, if I start drag-moving a 3D object to one side, and keep going when the cursor passes the side of the panel, the cursor wraps around and the object keeps moving. It works really well, overall, I find.

On a separate note, an idea occurred to me:

Have you tried having physical dragging produce an exaggerated effect? That is, having a movement of the mouse across half the screen be enough to fully open a door or pull out a drawer? I wonder whether that might not result in it feeling a little more natural, as there would be less call for the player to move while dragging...

It might not work, but it seems worth suggesting in case it does!

Okay, I've managed to reproduce the bugs that I encountered, I believe. Specifically:

I started a new game, and finished the tutorial. At this point--before the character wakes, I think it was--something, whether on my system or in the game, caused me to be tabbed out of the game to the desktop.

Tabbing back in, Windows informed me that the game wasn't responding. I closed the game, found what I think are the save-game and some logs, and stored them in a zip-file.

That done, I restarted the game, selected "continue"--and found myself back at the start of the tutorial. And indeed, I then found that the "no interaction" bug was in effect: when approaching things, the cursor remained unchanged, and clicking had no effect.

Finally, I returned to the game's save-folder and added one more log-file to the aforementioned archive.

I'll PM you a link to said archive presently, I intend.

[edit] And done, I believe!

In addition, let me note my system specs quickly:

Machine: Dell Inspiron 15 3000 Series
CPU: Core i7 2.4GHz (4-core)
Memory: 8GB
Graphics: GeForce 840M, 2GB (+Intel integrated)
OS: Windows 8

Yes, I guess we are - in some parts at least - different types of players. I think this came up back in the good old days when I feedbacked (this is now a word) your demo. ^_^

Indeed, we two do have different sensibilities and tastes in some things! Which is fair enough! ^_^

Hahah, another difference between us as players, it seems: I prefer it the other way around!

That is, I want to feel, when I get a game, that I have the whole game; that I'm not missing out on content in the current adventure if I don't get the DLC.

Plus, having separate adventures means that each can have separate abilities, weapons, and items, without my having to take DLC abilities, etc. into account when working on the main game.

Hi! Thanks a lot for playing and the detailed feedback!

It's my pleasure!

Operating stuff with a click is an absolute no go, unless it is a button. This is a part that brings lots of immersion and is important to me and gets lots of good feedback. When I play games where I open drawers with a click, I'm always disappointed. ^^

That's fair! My own experience is somewhat the opposite: I'm more likely to be disappointed that a game uses this sort of simulated physical operation, at least for things like opening doors, as I find the awkwardness of it counter-immersive, personally.

(I do like it for some purposes, admittedly, perhaps especially for movements that are more or less in the plane of the screen--think of sliding a bolt across a door.)

However, different people will feel differently, and if you're largely getting positive feedback on it then I may simply be an outlier for your game!

Some interactions might be a bit weird to operate from all positions, but in real life you would not pull a door open while standing right in front of it either.

Sure, but I also have rather greater and finer control of the movements of my physical body. For example, I can move my arm independent of my torso and legs, allowing things like easily stepping around a door even as I pull it open.

The thing with the rotation of closeups is that the closeup object is fully interactive and you can click and drag to operate some of them. To keep controls consistent and clear, right click is always examine (or cancel).

My thinking is that rotating such objects is a form of examining; I think that to my mind it's natural to connect the two.

And it needn't interfere (overmuch) with ordinary examining: that can be done when the player right-clicks without dragging, with rotation occurring when the player right-clicks and drags.

As to interaction, you still have left-click dragging for operation of elements of the close-up; right-click-dragging shouldn't interfere with that, I would imagine.

WASD or the CTRL modifier might not be the first thing the player attempts to do, but it is the very first thing that you learn in the tutorial and there is a hint for it.

Indeed, I saw that hint--but I still found that it didn't quite feel natural to me.

I'm unsure what you mean with "slippery" in the minigame. It needs some pretty precise timing at times, but it has all the magic like input buffer and such things (IIRC). Maybe it is caused by a low framerate?

I don't think that it was a matter of frame-rate. At least not in the sense of lag.

Simply put, it felt like there was too little friction, both on the ground and in the air. As a result, my character tended to move as responsively as I wanted, making attempts at precision quite frustrating.

There haven't been bug reports in the current version. Is there something that can be reproduced? If not, might you be able to send me the savegames and log files (in folder "%appdata%\..\LocalLow\ScaniX\MournwayMansion").

I can try, I intend! Give me a little time to get around to booting back into Windows in order to test!
 

Thanks again for the feedback!

It is again my pleasure! ^_^
 

PS: Sorry for the late reply, I've been away for two weeks.

Not at all, that's perfectly fair! ^_^

[Blog post (25th of April, 2022)Applying Some Polish]

Blog post (25th of April, 2022)
Applying Some Polish

Summary: In which the Ossuary Moon gains skirting; the appearance of the Vertical Slice Moon is further developed; multiple visual elements are polished; new map-icons are added; game-selection is implemented; the main menu gains some text; credits and legal notices are compiled and made available; and the race is tweaked.

Greetings and salutations!

This week's screenshot shows a tweak to the appearance of the Ossuary Moon: the bases of walls and pillars now end in a rather less rectilinear fashion!



The week just past was, in some ways, a "polish" week: A week primarily of the implementation of ancillary functionality, of tweaks to appearances, and of various improvements of one sort or another:

As shown above, the Ossuary Moon now has walls and pillars that don't end in simple straight lines. This is achieved simply by the addition of a strip of "skirting", using a new texture made in the week just past.

And indeed, I think that it improves the feel of the environment!

Likewise, I continued in the week just past with the look and feel of the Vertical Slice Moon. Specifically, the walls there too now have skirting, and the pillars have been reworked:



Furthermore, in the week just past I worked to polish various elements of the visuals: tweaking certain effects, improving the rendering of map- and inventory- icons, touching up the automatic outlining, and improving the handling of player-trails when crossing room-boundaries.

I also added a few map-icons that were yet missing--specifically, icons for health-upgrades, ship-skins, and the one remaining boss that I intend for the vertical slice.

On the UI side, perhaps the most salient change is the addition of a new menu:

When the player presses the "Start a New Game" button, in general this simply takes them into Moons in Crystal itself, naturally.

However, the game is designed (hopefully) to support DLC adventures--which prompts the question of how to allow the player to start one such, should they have it.

Hence this new menu: When only one adventure is present, the game starts as described above: clicking on the "Start a New Game" button just starts whatever is available (presumably the main game). However, when more than one is present, the new menu is shown first, giving the player the choice of which to begin.



Also shown in the screenshot above is a minor change made in the week just past: The addition of a byline, engine-credit, and version-number at the bottom of the main menu.

And one more new menu was added, this one rather simpler: There is now a "credits/legal" screen, which shows a basic scrollable text-view. That view holds a text compiled in the week just past, including my own copyright claims and disclaimers, as well as the various credits and license -texts/-references called for by the various third-party elements that I use (e.g. music).

(The button for this "credits/legal" screen can also be seen in the screenshot above, by the way.)

In compiling the text for the above, I discovered that a few of the pieces of music that I was using had licenses that were perhaps problematic. (Some may have been okay, but I preferred to play it safe.) So, in the week just past I spent some time replacing those few.

On the gameplay side, I mentioned in last week's blog post, I believe, that I had a few touch-ups in mind for the race. And in the week just past I did indeed implement some changes: in short, the race now ends only when all racers have crossed the finish-line, and the starting trigger has been moved and reduced (thus allowing the player to pass without starting the race).



And, well, there were quite a lot of tweaks, fixes, and changes enacted in the week just past that don't seem worth detailing here!

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