next »

[Thaumaturge]

Yeah I can totally relate. If it's something that requires considerable dev effort then probably not worth it. In my case, this kind of stuff is usually just a matter of tuning some engine settings, but obviously not the case for everyone.

Unfortunately, in my case I'm using custom shaders, meaning that all the shadow-stuff is my own work. Improving it is still something that I have in mind, but it is a matter of actually implementing those improvements (possibly from this article, which I've had saved for ages), and not just tuning values. :/

That's fair but I can honestly say that my first impression was one of "fighting a cardboard robot with a wooden sword".

I have had feedback like that before--but I do wonder how much if it comes from the sound-effects, sound design being a weakness of mine. Some of those sounds do, I fear, sound a little cardboard-y.

(I may have another shot at reworking those...)

I also think there's risk in underestimating the importance of "game feel"; it's often one of the primary ways in which players connect with your game.

Side note: there's a great talk from one of the Vlambeer guys about this. While it won't entirely apply to your game, it really drove the point home for me.
...

I don't disagree on the matter of game-feel, and I'm very much aware of it--I just wonder if we don't prefer different feels in our games. I've seen a number of games that have quite turned me off with over-egged "juice".

I really don't want sword-trails, huge hit-flashes, etc.

Will cover all the climbing stuff in a subsequent post, possibly with video. I may wait until the next version as it sounds like the revisions may address some of my feedback.

Fair enough! I have been thinking of putting out an updated build in the near future with these changes to the traversal; this gives me another nudge to do so!

Hmm, could be, I'll keep an eye on this and let you know if it happens again. Does the enemy not attack when you're out of stamina, then?

They should attack when you're low on stamina--some of the later enemies are even intended to punish you for letting your stamina drain. However, this enemy, being very much a starter enemy, does take a fair bit of time between attacks when not responding to the player. Furthermore, if the enemy itself was low on stamina, that might have prevented it from attacking.

Not really, ...

Ah, that's a pity. :/

I would have liked to have introduced such books later, perhaps, but that proves tricky...

... but it might once I've gotten a bit further? For my benefit: is this what allows me to read the text above the doors?

Nope; the text above the doors in the upper tomb is legible from the start.

No, this book provides elements that are used in a minigame, one that revolves around translation.

Perhaps I should have a look at altering the initial set of elements such that the player can pick up the book later, after the first main-path translation minigame...

(I think that I recall that this proved problematic on previous attempts, but perhaps I'll find a way this time.)

Good to hear, and yeah, doesn't need to be anything crazy, just enough to avoid the traversal feeling tedious.

Even just testing these past few days, I feel like it's helped a bit in that respect. ^_^

I found one thing to climb and it doesn't seem to go anywhere? I'll keep looking

Did you see the tall stone structures at the "back" of the outdoors area? It might be worth your while finding a way up to their tops...

I hear that, but if the items are blended into the environment so much that they just look like props, it could lead to some frustrating moments. And there's a pretty strong precedent of having such "quality of life" thing in games these days--in fact, I can't think of any that don't?

I don't know--I feel like when half the point of the game is nosing around and finding things, highlighting them just undermines the experience.

As to precedent, SOMA doesn't seem to have that sort of highlighting (I had a video-link, but the forum tried to embed it, breaking the paragraph o_0). It does have that "wave of light" effect that highlights items when hovering over them (an effect that I'm not a huge fan of, myself)--but both games provide an on-screen icon when hovering over interactive items anyway, so that seems superfluous to me.

When's the last time you went outside? The lighting conditions in that scene, as well as my reference pic, are basically mid-day sun, which is quite harsh. And everything to the left of the mound is in direct sunlight, so it should be horrible neon.

Hahah! But I don't think that grass is always that neon; it'll vary somewhat by type of grass, for one thing. Grass out in nature actually looks quite pretty, I think.

Still, I've brightened the sunlight a little bit--not as much as you suggested, but somewhat!--and I do think that it helps.

[Cosmocat Games]

That's fair but I can honestly say that my first impression was one of "fighting a cardboard robot with a wooden sword".

I have had feedback like that before--but I do wonder how much if it comes from the sound-effects, sound design being a weakness of mine. Some of those sounds do, I fear, sound a little cardboard-y.

(I may have another shot at reworking those...)

That's definitely part of. A rework is probably worthwhile and I'm always happy to weigh in on this, I'm all about the sound design, as you know

I really don't want sword-trails, huge hit-flashes, etc.

Agreed, something like that totally wouldn't be a fit for this kind of game.

Did you see the tall stone structures at the "back" of the outdoors area? It might be worth your while finding a way up to their tops...

I did but nothing that seemed climbable. Will check again.

I don't know--I feel like when half the point of the game is nosing around and finding things, highlighting them just undermines the experience.

As to precedent, SOMA doesn't seem to have that sort of highlighting (I had a video-link, but the forum tried to embed it, breaking the paragraph o_0). It does have that "wave of light" effect that highlights items when hovering over them (an effect that I'm not a huge fan of, myself)--but both games provide an on-screen icon when hovering over interactive items anyway, so that seems superfluous to me.

I know where you're coming from, but there is a subtle difference: (as I recall) in SOMA the main quest items were quite obvious, and not "needle in a haystack" kind of things. I would make the argument that if the required items look like rubble, and are in a pile of rubble, some players may simply see the "Rubble" interact option and stop looking beyond that. (I can vouch for this first hand, heh.) But this is very much first impression stuff, and of course if that is the norm in the game then I may become more accustomed to it.

Still, I've brightened the sunlight a little bit--not as much as you suggested, but somewhat!--and I do think that it helps.

Good to hear!

[Thaumaturge]

That's definitely part of. A rework is probably worthwhile and I'm always happy to weigh in on this, I'm all about the sound design, as you know

Thank you; I appreciate that! ^_^

I did but nothing that seemed climbable. Will check again.

A spoiler, in case you still find yourself stuck after further exploration: Climb the tree next to those two large structures, cross to the first of the structures, then hop over to the next.

As noted, I've changed things on my end to have the protagonist explicitly draw attention to the first part of that as being climbable.

I know where you're coming from, but there is a subtle difference: (as I recall) in SOMA the main quest items were quite obvious, and not "needle in a haystack" kind of things. I would make the argument that if the required items look like rubble, and are in a pile of rubble, some players may simply see the "Rubble" interact option and stop looking beyond that. (I can vouch for this first hand, heh.) But this is very much first impression stuff, and of course if that is the norm in the game then I may become more accustomed to it.

That's fair. On the other hand, SOMA also had a ton of arbitrary items that could be picked up, but that didn't actually do anything.

Still, perhaps the rubble-pile specifically is a bit too much so early in the game; perhaps it's worth easing players into it a bit more.

One solution that remains in line with the current design philosophy might be to simply move the ceramic shard to lie a little distant from the main pile. That might make it more clearly a separate thing, and thus make for a more gentle introduction to the idea that players are expected to nose through everything.

Similarly, I could perhaps remove the "examinability" of the rubble-pile, thus perhaps leaving the key and the shard standing out by virtue of being examinable in a non-examinable setting. (The rubble-pile's description doesn't add much, in any case.)

Or I could do both, come to that.

No, this book provides elements that are used in a minigame, one that revolves around translation.

Perhaps I should have a look at altering the initial set of elements such that the player can pick up the book later, after the first main-path translation minigame...

(I think that I recall that this proved problematic on previous attempts, but perhaps I'll find a way this time.)

Minor update on my thinking regarding this: It is indeed problematic, but I might have a way forward.

The problem, in short, is that it's tricky to make all of the sentences that I might want in the translation puzzle with just a few word-parts to employ. But the first translation puzzle is optional, so I can't really rely on it as an introduction to the mechanic. Furthermore, I don't want to start players off with too many word-parts; I want to ease them into it a bit more.

What I'm thinking of doing, then, is this:

• Remove the translation-puzzle in the prologue.
  
  • (The art accompanying the lore-entry that it gives isn't the best, anyway.)
• Reshuffle the starting set of word-parts so that it includes only those used in the first puzzle in the barrow-level, plus one or two more.
• Place a lexicon-book deeper in the barrow-level, ideally somewhere obvious, and have the subsequent translation puzzles rely on gaining it.

There is a stumbling block in this, however: since only the first translation puzzle in the barrow-level is part of the main progression-path, I can't rely on players getting that lexicon-book. That means being careful about subsequent translation-puzzles, and perhaps providing redundant lexicon-books, I think.

[RealScaniX]

Just a little thought concerning the examine stuff problem.
I had a similar problem when large interactive or examinable objects had smaller items "in" them.
My current solution is to make the cursor blink when crossing over from one interactive element to another.
 
https://twitter.com/HiBeGame/status/990550912975429632

[Thaumaturge]

Just a little thought concerning the examine stuff problem.
I had a similar problem when large interactive or examinable objects had smaller items "in" them.
My current solution is to make the cursor blink when crossing over from one interactive element to another.

The thing is, it can be argued that the game already has two such indications! :/

First, the name of the object being viewed is shown beneath the cursor. Thus when moving the cursor from the rubble pile to the ceramic shard, that text should change.

And second, the rubble-pile is examinable, but not interactive, while the ceramic shard is both. This means that when the player moves the cursor from the rubble-pile to the ceramic shard, a "grasping hand" icon should appear beneath the cursor.

Well, I've now both removed the "examinability" of the rubble-pile and placed the shard a little more distant from it. Hopefully that should make it more distinct!

(The wooden key is still where it was--but it's quite distinctly shaped, I think, and should also benefit from the rubble pile being non-examinable.)

[RealScaniX]

Just a little thought concerning the examine stuff problem.
I had a similar problem when large interactive or examinable objects had smaller items "in" them.
My current solution is to make the cursor blink when crossing over from one interactive element to another.

The thing is, it can be argued that the game already has two such indications! :/

First, the name of the object being viewed is shown beneath the cursor. Thus when moving the cursor from the rubble pile to the ceramic shard, that text should change.

And second, the rubble-pile is examinable, but not interactive, while the ceramic shard is both. This means that when the player moves the cursor from the rubble-pile to the ceramic shard, a "grasping hand" icon should appear beneath the cursor.

Well, I've now both removed the "examinability" of the rubble-pile and placed the shard a little more distant from it. Hopefully that should make it more distinct!

(The wooden key is still where it was--but it's quite distinctly shaped, I think, and should also benefit from the rubble pile being non-examinable.)

I could not remember how it looked in the game. In fact, I think that you should have been fine with the old state. I was able to find the item. Making the pile not interactable will not help here IMHO as the player will then just ignore the whole pile.

[Cosmocat Games]

And second, the rubble-pile is examinable, but not interactive, while the ceramic shard is both. This means that when the player moves the cursor from the rubble-pile to the ceramic shard, a "grasping hand" icon should appear beneath the cursor.

Well, I've now both removed the "examinability" of the rubble-pile and placed the shard a little more distant from it. Hopefully that should make it more distinct!

(The wooden key is still where it was--but it's quite distinctly shaped, I think, and should also benefit from the rubble pile being non-examinable.)

I could not remember how it looked in the game. In fact, I think that you should have been fine with the old state. I was able to find the item. Making the pile not interactable will not help here IMHO as the player will then just ignore the whole pile.

Interesting... I was about to say that I think Thaumaturge's solution would solve the problem! But I was also going to say that this only one person's opinion/experience, so probably best to hear from a few other people on the matter.

[Thaumaturge]

Well, that's a frustrating contradiction! XD;;

In fact, I think that you should have been fine with the old state. I was able to find the item.

In all fairness, if I recall correctly from your video you reacted at first just as did snugsound: You looked at the rubble-pile, but didn't notice the two items with it until you came back and took a closer look later.

Making the pile not interactable will not help here IMHO as the player will then just ignore the whole pile.

Possibly; I can hope not. I do see the possibility that lacking a large named object in the room might leave the room seeming empty...

Hum. I wonder: perhaps re-instate the rubble-pile's description, but keep the new placement of the ceramic shard?

On the other hand, that might leave players not bothering to look behind the pile, and thus missing the key... :/

I could then move the shard deeper into the room--but players may still not look closely enough at the pile. :/

But I was also going to say that this only one person's opinion/experience, so probably best to hear from a few other people on the matter.

The thing is, as noted above, if I'm not much mistaken both of you reacted to the pile in similar manners: seeing the pile, finding it non-interactive, and moving on, returning to look more closely only when you found nothing else...

[Cosmocat Games]

I do see the possibility that lacking a large named object in the room might leave the room seeming empty...

Hum. I wonder: perhaps re-instate the rubble-pile's description, but keep the new placement of the ceramic shard?

On the other hand, that might leave players not bothering to look behind the pile, and thus missing the key... :/

You could always try to "cue" the player somehow? For example, the rubble pile description could allude to there being some useful items nearby, and/or you could add some additional "decoy" items that might prompt the player to look harder?

The thing is, as noted above, if I'm not much mistaken both of you reacted to the pile in similar manners: seeing the pile, finding it non-interactive, and moving on, returning to look more closely only when you found nothing else...

That's not necessarily a problem, assuming all players eventually come to the same conclusion. But of course that design philosophy also carries the risk of frustrating new players.

[RealScaniX]

The thing is, as noted above, if I'm not much mistaken both of you reacted to the pile in similar manners: seeing the pile, finding it non-interactive, and moving on, returning to look more closely only when you found nothing else...

That's not necessarily a problem, assuming all players eventually come to the same conclusion. But of course that design philosophy also carries the risk of frustrating new players.

I'd agree. Also without some sparkling like in hidden object games, I don't think you can make players recoginize things like those. In a way you ARE hiding the object in the pile. This part is a little like an easter egg hunt.
If the player learns that there are such things in the game, he/she/it will look more precisely in the future, I guess.
You might be right that I had to return to the pile later, but I cannot remember feeling bad for it. I was kinda happy to find something new there.

[Thaumaturge]

You could always try to "cue" the player somehow? For example, the rubble pile description could allude to there being some useful items nearby, and/or you could add some additional "decoy" items that might prompt the player to look harder?

That's... actually a really good idea, and I feel silly for not having thought of it. ^^;;

Thank you--I think that I'll do that! ^_^

That's not necessarily a problem, assuming all players eventually come to the same conclusion. But of course that design philosophy also carries the risk of frustrating new players.

That last bit is what I'm worried about, I think: this is, after all, only the first (non-prologue/tutorial) level.

If there were a similar arrangement in a later level, I would likely take the view that by that point I would expect players to be aware of how items are located in this game. But in so early a level players may not yet be used to it, and may find the experience frustrating. It's a matter of easing them into such challenges, I think...

I'd agree. Also without some sparkling like in hidden object games, I don't think you can make players recoginize things like those. In a way you ARE hiding the object in the pile. This part is a little like an easter egg hunt.
If the player learns that there are such things in the game, he/she/it will look more precisely in the future, I guess.
You might be right that I had to return to the pile later, but I cannot remember feeling bad for it. I was kinda happy to find something new there.

That's reassuring to read; thank you. ^_^

All right, I've re-instated and updated the debris-pile's description, and moved the ceramic shard back into its previous position. (The latter on the basis that having it be too separate in that situation might suggest that it's a singular thing to find, rather than just one of the things to be found.)

PS: I have been tempted to have the pile be something that the player can pick up in parts, making it a matter of searching by "excavating" the pile. I'm not sure that I want to do so, but having the pile be interactive, and in a way that suggests searching, might better suggest that there's something to be found there...

I think that it might be a bit over-complex for this level, but it might be worth keeping in mind for a later one...

[edit]

@snugsound: I know that you said that you were holding off on climbing feedback until the next version of the demo, but would you mind expanding on one point in particular please? It's something that I don't currently have a change addressing (as far as I'm aware), and I'm unclear on quite what you mean and thus quite what to approach.

The point in question is this:

The most obvious cause of confusion is that you're supposed to climb the sides of the stones, yet you can simply walk up the front faces of some early on, kind of giving the wrong impression.

Could you elaborate, please?

[Thaumaturge]

Blog post (20th of January, 2020)
Tutorial Polish

Summary: In which tutorialisation is improved; the introduction to translation is reworked; the translation UI is polished; combat effects are touched-up or reworked; the prologue sees more traversal changes; and level-models can now be loaded from multiple files.

Greetings and salutations!

This week's screenshot shows a new means of accessing the game's tutorial-texts:



Quite a bit was done in the week just past! As a result, let me try to somewhat breeze through the various changes made, lest this post run overly long:

To start with, I've been working on the tutorialisation of A Door to the Mists. In particular, I discovered via demo-feedback that it was quite easy to accidentally skip or prevent various tutorials, resulting in the player missing whatever such tutorials were teaching.

Broadly speaking, I've been addressing this in two ways:

First, I've been adding some nuance to the conditions that dismiss tutorial-text. For example, the "jumping and climbing" tutorial was previously dismissed simply by leaving its trigger. Instead, it is now only fully dismissed when the player has reached a given height and climbed at least once.

In this, the combat tutorials are still a work-in-progress: it's possible for the player to interfere with some of them by repeatedly attacking, and I haven't yet settled on how to deal with that.

And second, I've added what's shown in the screenshot above: a "book" accessible from the in-game menu, and which holds all of the tutorial-text (barring some prompts and the "combat tutorial over" text).

Sticking with player experience, I've reworked my approach to the first few translation puzzles.

Demo feedback showed that what I previously had was a little clunky: The first lexicon-book (which extends the player's word-root list) will likely be found before the first main-path translation puzzle (with only an easily-missed optional puzzle before). As a result, the purpose of the book can be a little opaque, and that first main-path puzzle, using then the extended lexicon, is perhaps a bit much for a first encounter with the mechanic.

So, after some deliberation, this is what I've done: I've reworked the starting set of word-roots to fit the first main-path translation. This new set doesn't work with the preceding optional puzzle, so I've removed that one. And finally, the lexicon-book has been moved to a location deeper in the level, well after the first main-path puzzle. Indeed, it appears late enough that players might encounter a translation that requires its word-roots before finding it, perhaps underscoring its purpose.

I've also touched-up the UI for translation a bit: First, I've caused the buttons that hold the current translation to be hidden when not in use, so that they don't appear to be targets for word-roots. And second, I've highlighted the words themselves to hopefully encourage seeing them as active parts of the puzzle.



Another element on which I had feedback was the combat mechanic; it was felt that it called for a bit more "juice", and that some of the sounds weren't working for it.

I've thus reworked some of those sounds, and furthermore switched them from using 3D positional audio--which can dull sounds with distance--to 2D audio--which should play more-closely to their intended volume. As audio-positioning isn't terribly important in the combat mechanic, I feel, I don't think that a great deal is lost in the switch to 2D audio.

I've also increased the size, and in one case the number, of "blood"-particles produced by the current enemies when hit.

You may recall that I previously made some changes to the prologue-level's traversal. Well, in the week just past I made further such changes, polishing that traversal to (hopefully) be easier and more-intuitive.



And in working on the prologue level, I was glad to discover that there are in fact now multiple routes up to the second part of the level's traversal-challenge. Not only might that render the traversal a little easier for new players by virtue of giving them more opportunities to find a way up, but it also fits nicely with the game's intended design. ^_^

On the technical side, I've added a feature that will likely be near-invisible to players, but that may hopefully be a great boon to me: the ability to load level-models in parts.

You see, the level-model files for A Door to the Mists can get... rather large. As a result, the process of exporting them from Blender and importing them into the game can... take a while. Hours, in fact, for the largest thus far.

Splitting the levels into parts, however, allows me to export-and-import only the relevant section or sections of a level, dramatically reducing the duration of the process. Furthermore, since the system doesn't have to deal with handling a single massive chunk of data all at once, even exporting-and-importing an entire level takes nowhere near as long! (And better yet, doesn't lock up the computer while in the process.)

I was a little nervous about the coding side of this--but I'm glad to say that it actually turned out to be much easier than I'd feared!

The Blender side proved tricker: Manually selecting level-elements for each export would be just asking for mistakes. Blender does provides layers with which to sort things--but only twenty, and the third level already uses all of those.

In the end, however, I discovered a neat add-on called "Super Grouper" that seems to solve the problem!

And indeed, I've already used this new feature to provide a simple escape from a previously-nigh-inescapable alley in the third level, and the process seems to work well. ^_^

Aside from all the above, a number of other changes were made that don't seem worth detailing: sounds for the player sliding down a slope; a bit of blue backlighting in combat; a new animation for a mummy-enemy; and various others beside.

One that might be worth briefly mentioning is that I've brightened the sunlight. Here's a comparison of old vs. new, with the older, dimmer lighting on the left:



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

[Thaumaturge]

A short video showing some of the recent changes in combat, in particular in its audio!

I'd like to request feedback, please: does this sound better than what was shown in the demo?

In addition, the "blood" particles used for enemies have been made a bit bigger, and in one case I think more numerous. An improvement, do you think?

[Cosmocat Games]

@snugsound: I know that you said that you were holding off on climbing feedback until the next version of the demo, but would you mind expanding on one point in particular please? It's something that I don't currently have a change addressing (as far as I'm aware), and I'm unclear on quite what you mean and thus quite what to approach.

The point in question is this:

The most obvious cause of confusion is that you're supposed to climb the sides of the stones, yet you can simply walk up the front faces of some early on, kind of giving the wrong impression.

Could you elaborate, please?

To elaborate on what I mean by "front" vs "side":



Most of the climbing seems to be based on climbing the sides of blocks, but it's also possible to walk up the front of some. I remember this causing some grief for me initially because I was expecting the same towards the top, but instead was knocked off the pyramid if I even went near front faces.

It's kind of hard to put this stuff into words sometimes so I'll try to record a video of my first attempt in the next version. (if possible, it would be good to get a first-time player to do this as well)

One that might be worth briefly mentioning is that I've brightened the sunlight. Here's a comparison of old vs. new, with the older, dimmer lighting on the left

Looking better. I'd still say it's far too dark given the lighting conditions, so if you're set on having such a dark look it might be worth tweaking the sun and clouds to match? (i.e. sun position and/or overcast clouds)

A short video showing some of the recent changes in combat, in particular in its audio!

I'd like to request feedback, please: does this sound better than what was shown in the demo?

In addition, the "blood" particles used for enemies have been made a bit bigger, and in one case I think more numerous. An improvement, do you think?

Definitely an improvement, though the SFX are still very "light" sounding, like hitting wood or cardboard. (if you wanted to send them to me I'd be happy to take a stab at beefing them up)

In other news, you'll be happy to know I made it a little bit further, though I'm once again stuck! I'm at a point where I can't fully decode something, and can't seem to find anything to interact with in any useful way. I'll give it another go, but honestly, there's been quite a bit that I'd have Googled by now so I'm hoping somebody makes a guide at some point, heh.

[Thaumaturge]

To elaborate on what I mean by "front" vs "side":
...

Ah, I see. Hmm. I'm not really sure of what to do about that: whether or not you can walk up a slope depends on the angle of that slope, more or less as in most games and (sort of) in real life. Shallow slopes can be walked up; steep slopes you simply slide down.

I will say that the new version (see the blog-post that I intend to post shortly after this reply! ) includes "sliding sounds", to perhaps better-convey that the player is sliding down a too-steep slope when that happens.

It's kind of hard to put this stuff into words sometimes so I'll try to record a video of my first attempt in the next version.

I'd appreciate that, thank you! :D It may well help to see where the confusion is coming from.

(if possible, it would be good to get a first-time player to do this as well)

Heh, I'd love to, but right now I fear that that depends primarily on whether or not I manage to attract new players, and if so, whether they're inclined to comment! ^^;

Looking better. I'd still say it's far too dark given the lighting conditions, so if you're set on having such a dark look it might be worth tweaking the sun and clouds to match? (i.e. sun position and/or overcast clouds)

That's interesting; I actually had it brighter, but felt that it looked rather too bright for the lighting conditions, myself. :/

Definitely an improvement, though the SFX are still very "light" sounding, like hitting wood or cardboard.

*sigh* That's frustrating. I'm really not sure of what more to do with them, given my current skills and resources. :/

... Although note that the player is hitting wood in this case. The guardian in the prologue level is a wooden construct. ^^;

(if you wanted to send them to me I'd be happy to take a stab at beefing them up)

I appreciate that, but I fear that doing so would complicate the matter of crediting and suchlike. For the moment, until perhaps I at some stage have a contracted audio-engineer, I'd be more comfortable with sticking with my own audio work, I think. :/

Still, thank you for the offer; as I said, I do appreciate it. ^_^

In other news, you'll be happy to know I made it a little bit further, though I'm once again stuck! I'm at a point where I can't fully decode something, and can't seem to find anything to interact with in any useful way.

I'm glad indeed to read it! ^_^

You say that you're stuck on a bit of decoding--I presume that you're referring to the translation minigame? If so, then as long as you picked up that mystery book that we discussed earlier, there should be no translation puzzles in the game that can't be decoded. (Indeed, the character should refuse to even make the attempt if you don't have all the required word-roots.)

That said, the new version of the demo makes the very first translation rather lighter, which might perhaps help with discovering the nuances of the puzzle!

(And there is one nuance that I'm not sure of how to better teach, right now, and which may well trip up players...)

I'll give it another go, but honestly, there's been quite a bit that I'd have Googled by now so I'm hoping somebody makes a guide at some point, heh.

That's fair! I see no harm in using a guide if called for; I know that I do so when I feel frustrated with a puzzle or decision in some games.

[edit]
Oh, but I'm being silly: A guide of sorts already exists! I posted a full (albeit non-100%) playthrough on YouTube, so if you're stuck, perhaps that will be of use to you!

[Thaumaturge]

Blog post (27th of January, 2020)
Redux Demo UPDATED!

Summary: In which the Redux Demo has a significant update; more polish is applied to combat audio; the combat tutorial becomes more reliable (and a bug is fixed in doing so); the top of a tree is felled; the model for the second level is split; and old data is automatically removed.

Greetings and salutations!

The big news this week is that a significant update to the Redux Demo has been posted!

As before, you can get it on Itch or IndieDB:
https://thaumaturge-art.itch.io/a-door-to-the-mists-demo
https://www.indiedb.com/games/a-door-to-the-mists/downloads

I hope that you enjoy it, and let me know what you think! :D

And with it, a short video depicting some of the update's more-salient changes:




As to the things done in the week just past--the release of the abovementioned demo and video aside:

To start with, I continued to tweak and polish the sounds used in combat, both in the audio-files themselves and to a degree in how I handle them internally. (I now have a means of setting the overall volume of various sounds, for example.) And indeed, I believe that I'm rather happier with the current audio than that of the previous demo!

Still on combat, I continued work on ensuring that the combat tutorial wouldn't be interrupted by the actions of the player. Specifically, you may recall that I mentioned in last week's blog post that certain parts of the combat tutorial could be interrupted by the player attacking. (As it turns out, only one part of the tutorial seems to have been so affected.)

Fixing this was fairly straightforward: the landing of the player's attack put the enemy into a state in which its AI method wasn't being run (by design)--but the combat tutorials were being controlled by that AI method. The solution, then, was to instead have the combat tutorials be handled by the enemy's general "update" method, which is run even in that "paused AI" state.



(And in dealing with this, I discovered and fixed a bug in which enemy attacks seemed to land without transition if the enemy was hit during the telegraphing of their attack.)

Moving over to level-design, I made a last-minute change to the second level: There's a tree in that level which the player is expected to climb. For the most part, I was happy with this--but did also at times find that the very top of the tree made for some slightly-awkward traversal.

So, given that this tree appears early in the game, and that anything appearing so early should generally be extremely easy from my perspective as the developer, I decided to cut off that troublesome top. And that's what I did: the top of the tree is now gone, leaving traversal up there much less difficult, I do feel!



Speaking of which, you may also recall that I mentioned in last week's blog post that the game now has the means to load level-models in parts, and that I'd split up the third level accordingly. In the week just past, then, I furthermore split up the second level--something that proved beneficial when I came to make the above-mentioned tree-cutting change, I believe!

And indeed, the difference when exporting from Blender and importing into Panda, and especially when generating a build, is quite amazing! Previously, builds took hours to complete, and eventually rendered the computer effectively unusable until done. Now, building for a single platform takes all of about fifteen minutes, with only a little impact on the responsiveness of the machine! (And building for two platforms--i.e. Windows 64-bit and Linux 64-bit both--takes less than half an hour.)

Speaking of builds, and thus of the demo-update, I realised something troubling ahead of the release of that demo: some of the changes meant that old saves or config-files could potentially be problematic. Loading an old save could potentially cause changes to not appear, or even result in a crash.

I wanted, thus, to clear out this old data from a user's system. But how to do so? Deleting files automatically might be seen as undesirable by players--but asking players to do it themselves could be easily missed, misapplied, or appear suspect, depending on execution.

I asked for advice, and what I was told was this: Do it automatically--don't require that players do it for me--and inform players that it's happening.

So that's what I did: the game now checks for a special file in the game's user-data folder. If the file isn't present, it assumes that the data in the folder is out-of-date, and erases it. It then shows a brief message to the player, informing them of this action.

Hopefully this will prove both effective and acceptable to players!



And along with all the above were a variety of other changes, fixes and tweaks that don't seem worth detailing here!

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

[Whales]

ADTTM looks really interesting and the menus + intro set a nice tone.  Unfortunately the linux version crashes (game instantly closes) whenever I try to pick up an item:

Code:

AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"   [whales: unrelated line]
Traceback (most recent call last):
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 49, in eventLoopTask
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 43, in doEvents
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 99, in processEvent
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/Messenger.py", line 336, in send
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/Messenger.py", line 421, in __dispatch
  File "GameCore.py", line 959, in actionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Level.py", line 2030, in handleActionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Player.py", line 2184, in handleActionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/GameObject.py", line 682, in use
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Inventory.py", line 96, in useInternal
AttributeError: 'NoneType' object has no attribute 'getPos'
Traceback (most recent call last):
  File "GameCore.py", line 1519, in <module>
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/ShowBase.py", line 3152, in run
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/task/Task.py", line 537, in run
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/task/Task.py", line 491, in step
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 49, in eventLoopTask
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 43, in doEvents
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/EventManager.py", line 99, in processEvent
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/Messenger.py", line 336, in send
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5+opt-cp36-cp36m-manylinux1_x86_64.whl/direct/showbase/Messenger.py", line 421, in __dispatch
  File "GameCore.py", line 959, in actionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Level.py", line 2030, in handleActionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Player.py", line 2184, in handleActionUp
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/GameObject.py", line 682, in use
  File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/Inventory.py", line 96, in useInternal
AttributeError: 'NoneType' object has no attribute 'getPos'

bf3be885fece4aa95ce5a6665583222c  A Door to the Mists-0.8.5_manylinux1_x86_64.tar.gz
Linux 5.4.13_2 #1 SMP PREEMPT Sun Jan 19 12:22:44 UTC 2020 x86_64 GNU/Linux
Radeon RX 470 with default (in-kernel) drivers

I managed to get item collection to work once by deleting ~/.local/share/ADoorToTheMists/, but I have not been able to repeat this.  The only other intermittent thing I can think of is having too high of a framerate?

Happy to perform deeper debugging upon request.  N.B. Windows version is very slow under Wine, I might see if DXVK fixes this.

[Thaumaturge]

ADTTM looks really interesting and the menus + intro set a nice tone.  Unfortunately the linux version crashes (game instantly closes) whenever I try to pick up an item:
...

Oh dear, that's alarming! :/

It's also rather odd, as I develop under Linux, and haven't had that error thus far! o_0

Thank you for including the log-file contents, by the way--that may prove very helpful in tracking down the issue!

As to the issue itself... Hmm... It looks like the item being picked up has somehow already been destroyed by the time that it reaches that line of code.

If I may ask, does this happen with one specific item, or any item at all? (If you've just started the game, and this is happening with the rock at the top of the pyramid, try ignoring the rock and progressing until you reach the goal-item of the level. That's also an inventory item, so it should allow us to test whether the problem is one specific object, or objects in general...)

[edit]
Another question, if I may: You say that you got item-collection to work once by removing your user-data directory. Does it work if you run the game, start a new game, and attempt to collect the rock at the top of the pyramid, without ever loading or saving?
[/edit]

[another edit]
What distribution of Linux is it that you're using, if I may ask? Looking at the output that you gave above, I'm guessing that it's not Ubuntu--could you tell me what it is, please?
[/another edit]

The only other intermittent thing I can think of is having too high of a framerate?

It's not impossible, but I doubt it: the game usually run at a pretty decent frame-rate on my machine. For example, I just picked up the above-mentioned rock while the game was running at a frame-rate of ~138fps.

N.B. Windows version is very slow under Wine, I might see if DXVK fixes this.

If I were to guess, I'd guess that the game is failing to load the OpenGL backend under WINE, and so falling back to software rendering--which is, naturally, horribly slow.

However, that's just a guess!

ADTTM looks really interesting and the menus + intro set a nice tone.

Thank you very much! I really appreciate that! ^_^

And I hope that we manage to get it working for you!

[Whales]

Chat: I am in UTC+11 (Sydney) and work 9-6, it looks like you are UTC+2 (Cape-Town).  I'll have free time on the weekend if you want to do this.    EDIT: I'm imagining things now.  Ignore me, I thought you asked for chat.

When I get home today I'll run some more tests, including running a copy of the game on my low-end Intel graphics laptop (same distro).

If I may ask, does this happen with one specific item, or any item at all?

Picking up either the rock atop the pyramid or the knife hidden under a rock triggers this problem.

You say that you got item-collection to work once by removing your user-data directory.

Yes, but only the once.  I ended up starting the game a good dozen times trying to solve this problem and I was not able to reproduce this, so it may have been a fluke.

Does it work if you run the game, start a new game, and attempt to collect the rock at the top of the pyramid, without ever loading or saving?

No this does not work.  Also loading a save doesn't make a difference

What distribution of Linux is it that you're using, if I may ask?

Void Linux.  It's a rolling release distro so I am very likely on different lib versions to you.

Do my python versions matter or is everything compiled into byte-code?  I noticed a distinct lack of .py files.

For example, I just picked up the above-mentioned rock while the game was running at a frame-rate of ~138fps.

I was running about double this speed.  I'll try thieving some cycles and see what happens.

[Whales]

• Almost always crashes when I try to pick up an item.  Very approximately: 4/5 times.
• Sometimes I can pick up my first item, but then the game crashes when I try to pickup a second.  Viewing the item in my inventory works fine.
• Problem is not affected by deleting any game files, resizing the game window or changing settings (as far as I can tell)
• Problem does not appear to be directly related to framerate.  If I run a GPU benchmark at the same time (thus limiting the game to around 50-60FPS) the same issue occurs.
• On my laptop: runs at a horrid 8-20FPS with lots of uneveness, but does not seem to crash!  Same distro, similar library versions (not exactly the same, updated on different days).  I'll try an update on both when I have free time.

It looks like this game is more GPU bound than CPU bound.  Could there be some weird logic ending up with 0-timedelta frames or input repeated across frames without proper context?

EDIT: two mouse clicks being registered in a single frame?  First click gets handled, second click tries to be handled but the referenced object is now gone or changed.  My mouse is being polled at a higher-than-standard rate IIRC.  I'll try again tomorrow with a different mouse.