I'm using both OBS and Blender, so the one that's missing is FFmpeg. Never heard of it. Thanks for telling me - I'll try it.

Fair enough! ^_^

What operating system do you use? If you use Linux and decide to go with FFmpeg, I have a script that might make conversions a little easier; if not, it might be feasible to convert it to whatever scripting language your operating system uses, if any.

Oh yes, my eastern-European English sucks . I too think the text here is somehow wrong - I just don't know why.

...

Fair enough!

One thing that might be worth watching out for is the tense in which you're writing--in the image that you've just posted, you seem to primarily be writing in the past tense, but occasionally use the present. Switching tense like this tends to read poorly, I believe (unless you have a particular reason for doing so, and do so well). For example, your first sentence starts off in the past tense ("At first I wasn't sure ..."), but ends in the present ("... what I see").

I imagine that the thing to do is to look for someone proficient in English, and who is willing to proofread for you. If a professional proofreader is infeasible, perhaps try looking for help in a writing forum, such as the TIGSource writing sub-forum, the TV Tropes "Writer's Block" sub-forum, or the "Absolute Write" forum.

I'm sorry to read that you've had so much trouble. :/

As to the new logo, I do think that it's much improved! ^_^ (It's actually legible now, for one. ;P)

I'm glad to read that we'll (hopefully) see a demo, and some gameplay footage, soon.

As to GIFs, the method that you use may depend somewhat on your platform, game-development tools, and perhaps other constraints. My own approach is perhaps a little over-complicated: I record using OBS, then use Blender as an editor, render out a video from that, and finally convert to GIF with FFmpeg, I believe.

The opening video is intriguing, and rather lovely, I think. If I may, it might be worth having a proof-reader look over your text--I think that I spotted a few grammatical issues.

I could very much see some interesting spells coming of that, I think--ideas spring to mind for the bishop and castle in particular. ^_^

@ompuco: Those are interesting effects! I particularly like the first (which looks as though it's continually effervescing away).

Objects can now (optionally) fall when their support is removed:

A belated "Merry Christmas" to you, too! I hope that you had a happy one. ^_^

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

That's good to read; I'm interested to see what you come up with. ^_^

Happy holidays and a happy new year to you, too! ^_^

I really like the "Stalwart Defenders" arcana (... should that not be "arcanum"? Admittedly, my knowledge of Latin is rather limited...) both in function and aesthetic. Those chess-pieces look rather cool to my eye, and are pleasantly unusual, I feel. ^_^

And I'll continue refining mouse control / fixing bugs with that.

Excellent, and thank you. ^_^

Although, re: skill hotbar, I do recommend IF you are playing with mouse to use left hand to trigger skills - that seems like a natural setup (left hand rests on 1-8, right hand on mouse)

Hmm... Actually, in a game like this, it seems natural to me to use only the mouse. After all, there's little call for quick reactions, and I see nothing thus far that couldn't be interacted with effectively via a mouse.

(Honestly, I think that I'd forgotten at the time that there were hotkeys for the skills. (Which is silly in retrospect, since as you've pointed out, the keyboard is intended to be the primary control mechanism.) While not ideal to my mind, at the least they should allow me to use my skills in the current build!)

Speaking of which, I a suggestion related to the mouse controls, if I may: I'd like to be able to use stairs via the mouse. Since moving up and down carries little penalty (as far as I see), the cost of a mis-click seems minor to me.

Specifically, what I suggest is this: When the player-character enters a tile on which some action may be taken, bring up one or more little buttons; instead of clicking on the player, clicking on these performs that action. For example, when entering a tile that contains loot, have an icon pop up that indicates "taking"; if the tile contains both stairs and loot, have two icons pop up.

Anyway, no build yet, but I'm working on a lot of stuff including testing getting rid of durability altogether. I've created a google doc which features everything I'm working on right now.

https://docs.google.com/document/d/1VIFBxOeX-ijjPTsrGuscJYKyGFre1WwHS_nfSlTT4kU/edit

Ah, interesting! Thank you for sharing that. ^_^

I like the idea of removing durability: thinking about it now, I think that it's been more of a nuisance than a mechanic that's enhanced the gameplay.

The new weapon-type properties are interesting; I don't care to speculate as to whether they're an improvement--we'll see once they're play-tested, I suppose. (Not likely by me--I'm sticking to my spellcaster classes, I intend. )

I see that we have a "town portal" coming up--excellent! ^_^

Echoing others above, the new art looks really lovely to me! I continue to very much enjoy the art-style. ^_^

As the poster just above suggests, gameplay GIFs may help to better convey the experience of playing your game--and thus perhaps generate more interest--than static images, however lovely.

Those low-health- and death- mechanics seem interesting; intuitively, I like the idea of having a moment to pull my character back from the brink if I act quickly.

I hope that you enjoy the holidays, and whatever you celebrate or observe during this time, if anything. ^_^

My pleasure! ^_^

Don't worry--while I doubt that the game is a fit for me as a player right now, I imagine that I'm not likely to simply ignore any changes that you make as you go.

I haven't played The Witness (although I have seen let's plays of at least part of it), but I have played Myst. I didn't like the "piano" puzzle that you described, although given what you've said, I don't know how much of that is because I'm simply not musically-trained, and how much because I'm generally not great at that sort of sound puzzle.

However, I seem to recall that I did like the sound puzzles in the region that it led to. In all fairness, it's been long enough since I first completed that section that I don't recall how I completed the maze that first time--perhaps I did brute-force it somehow. Still, the "tower" puzzles were fairly straightforward and enjoyable, I think, although they may have called for a bit of running around.

Ah, I see--interesting, and thank you for elaborating. ^_^

I like the changes that you describe for the tutorial to your "taste" puzzles; while--as you say--testing is still called for, the reasoning that you give makes sense to me. (... Pun not intended, but gladly taken. ) I'm a little concerned about the interior wall obscuring line-of sight to the results of a given selection, and about players ending up going back and forth between "mixture" and "ingredients", which I imagine as potentially a little tedious.

Hmm... I suspect that, for myself and speaking as a player, I might avoid this game due to the sound puzzles--they seem like the sort that I'd find unpleasant and frustrating. ^^;

That said, I still find this project rather interesting as a developer, so I intend to stick around in this thread! ^_^

An excerpt from the backdrop to the first scene of the first-level cutscene:

That does look really cool, I feel! I like the idea, and the art and animation work rather well, to my eye. ^_^

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

All right, I have a little initial feedback:

First of all, the reason that I'm doing this now, rather than after more play: I seem to have encountered a bug that makes the game difficult to play (by mouse, at least). Specifically, the skill-buttons don't seem to work--I can press them, and they respond visually, I believe, but it seems that nothing happens. :/

That said, the mouse-controls are otherwise rather improved thus far, I believe! In particular, I really like having mouse-selection work in menus. ^_^

I did find one bug with said selection: When selling, I found that selling an item resulted in the cursor jumping to the "exit" button, regardless of the mouse-cursor's location. It only resets when the mouse is moved--and further, it seems that it doesn't actually update the selected item until (I think) the mouse is moved to another item. :/

Otherwise, I do rather like having the shops available, both as a source of items and a place to dump unused loot, and get some resources in exchange for it. I do wonder whether going back and forth might become tiresome once the player has reached some of the lower levels--do you plan to implement a "town portal" of some sort?

The rivers seem like a nice idea. I haven't had much interaction with them yet, but I like the concept, at least. A suggestion, if I may: Have the rivers flow, pushing objects along their course. This might produce some interesting gameplay effects:
 - Objects being carried downstream
 - Easy travel in one direction and difficult going in the other
 - River hazards into which unwary creatures and players may be dragged
 - Places that can only be reached by river, whether by struggling upstream or riding downstream, with impassable tiles to either side

Having programmatic generation of those wires seems like a rather good idea; I imagine that it may save quite a bit of time, and be rather less tiresome, too!

I'm curious, if I may: how does the "hearing" puzzle work, and what do you have in mind for the new "taste" level?

Quite an update, I feel! I have the new build downloaded, I believe, and intend to try it soon. ^_^

Thanks, yeah not sure what the order will be with all the weapon tiers, I'm not posting any of these in order of what I think should be the most powerful.

Heh, I recall you saying as much--but it does nevertheless seem likely that the stick is the weakest of the wands.

Aah, a serpentine sword--I've long been fond of those, I believe. ^_^