There is still a place to get stuck, however it is possible to move with friezes.
It’s nice that it was not in vain, but it was not easy.
Ah, I see! But in this case, combat takes place in an entirely separate “space” from exploration, and has only the player and the enemy: there’s nowhere for the player to go if they’re not locked onto the enemy. If they weren’t locked on immediately, they’d just be at a disadvantage in the fight, I feel.
Very odd–there should very much be a sound on impact! I’ll check my builds, I think–perhaps I somehow omitted them, or perhaps the volume of the sound-clips is just too low…
Interesting. I’ll look into this, I do think–but I do want to make sure that the enemy has time to block, too.
(Note that attacks genuinely will be inhibited if your stamina drops too low.)
Okay, duly noted–it might take a few tries for me to find the right spot, then (so that I can adjust the stone blocks appropriately).
I’ll look into that one too, I intend–thank you for reporting it! 
Heh, yeah, that’s the first piece of “serious” traversal in the game. I might be tempted to broaden the collision geometry for the dead tree between the two structures, which might make it a little easier.
I’m glad that you did get up there! And thank you for all the reports!
Thanks for the updated version 
!
Here is more feedback:
-
When the demo starts, the window is centered vertically, but it has its origin at the left edge of the screen. Would it be possible to center the window horizontally as well? It does seem a bit strange the way it is now (although it’s not really a problem).
-
When I Alt-Tab to another application and then return the focus to the game, the mouse cursor is no longer confined to the window (I don’t have a high DPI screen, so it’s probably not related to this issue).
-
Most buttons are highlighted only once when mousing over them, until the mouse is over another button. Some exceptions are the “Get in touch!” button on the main menu screen and the “Leave” button on the Collected Lore screen (but only when accessing the latter from the main menu, not from the in-game tabbed interface, strangely enough).
-
Trying to delete a previously saved game, whether from the Load or Save screen, results in a crash:
wglGraphicsPipe (all display modules loaded.) :Actor(warning): Cannot control joint head :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body already attached :bullet(warning): rigid body not attached :bullet(warning): ghost not attached :bullet(warning): ghost not attached :bullet(warning): ghost not attached :bullet(warning): ghost not attached :bullet(warning): rigid body not attached :bullet(warning): rigid body not attached :bullet(warning): ghost not attached :task(error): Exception occurred in PythonTask eventManager :GameMessages(warning): Traceback (most recent call last): File "GameCore.py", line 1262, in <module> File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/ShowBase.py", line 3124, in run File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/task/Task.py", line 531, in run File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/task/Task.py", line 485, in step File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/EventManager.py", line 49, in eventLoopTask File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/EventManager.py", line 43, in doEvents File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/EventManager.py", line 99, in processEvent File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/Messenger.py", line 333, in send File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/showbase/Messenger.py", line 418, in __dispatch File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.4.1+opt-cp36-cp36m-win_amd64.whl/direct/gui/DirectButton.py", line 103, in commandFunc File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/Adventuring/SaveLoadMenu.py", line 326, in delete NameError: name 'os' is not defined -
Clicking the “Create New Save” slot on the Save screen should probably disable the “Delete” button.
-
While clicking a slot on the Load screen changes the image to the right to the corresponding thumbnail, this does not seem to happen on the Save screen: the image remains unchanged there, regardless of which slot is clicked. This image is the current view at that point, so it makes sense to see it when clicking on “Create New Save”, but not really when trying to overwrite an older save IMHO.
-
This is probably nitpicking, but being able to use the mouse wheel for scrolling would be a nice touch I think.
-
A small suggestion for the game itself: when travelling long distances, the ability to run (e.g. by holding down the Shift key) would likely be a nice addition.
-
Finally (really
!) it might be worthwhile to make the location of the log file user-configurable, i.e. whether it should be created in the “app-data” directory as it is now, or in the directory where the game is installed.
Keep up the good work 
!
That’s very much something that I can look into, I believe!
Honestly, I think that I just hastily selected a value, not long before initial launch; the window-placement had previously had a hard-coded value for horizontal placement, one that worked for me with my dual-monitor setup, but which was unlikely to be a good choice for most… ^^;
Yeah, I think that I’ve seen that too. I think that this may be a Panda bug, and something for me to file on GitHub! :/ (Presuming that a quick check doesn’t reveal that it has already been reported, either on GitHub or this forum, at least.)
Hmm… I’ll look into that, I intend!
(The main-menu lore-screen is separate from the in-game one, so it’s quite possible that I set up the two buttons differently in some way.)
Oh dear–that’s not good. o_o;
Hmm… It looks like I somehow managed to not import the “os” module in the “Save-load Menu” module, of all things. ^^;
Well, it should be quick and easy to fix, at least!
Noted, thank you!
Ah, interesting. My own logic was to the contrary, as I recall; I think that it makes more sense to me that when saving, the view show what is to be saved, not what’s in the slot that’s to be overwritten.
However, if I get significant disagreement with my perspective on this, I’m open to changing it!
That does make sense, I do think. I don’t know how easy it is with DirectGUI, but it might be worth looking into!
I’ve thought about that, but I’m a little hesitant to add yet another key to a game that already feels to me like it has quite a few. Adding a “sprint”-speed also has implications for traversal challenges, and which jumps are and aren’t feasible…
Hmm… That’s an interesting idea. I’ll want to think about it, and perhaps look into whether it’s good practice, however. At the least I’ve noted it down for consideration–but it’ll probably won’t be implemented for the demo, I’m afraid!
Thank you for all the feedback! It’s really appreciated!
I noticed that the cache under a small stone near the pyramid is inaccessible with repeated passage. Is it so conceived?
The sound of damage is. True, it is atypical and expressionless.
Do I take it correctly that you mean the stone under which you find the knife collectible? If so: First of all, well done for finding that–I was worried that people wouldn’t! Second, I’m not sure of what you mean by “repeated passage”. You can only push it once, yes; the idea being that there’s no reason to push it a second time. I could put in a character-response to this effect, perhaps.
Could you clarify, please? Are you saying that you do now hear damage-sounds, but that they’re unusual in some way, and dull?
If so, what sort of sounds were you expecting?
And what happened to cause the sounds to start being audible? Or were they previously audible, but you didn’t identify them as signifying damage?
With a new game, the stone is not even highlighted. Maybe it works inconsistently, I did not find out the reasons.
It’s hard to say, for example, like a character’s. Be that as it may, this is a robot, most likely a loud and metallic sound.
Thank you for clarifying, on both counts!
Hmm… If it’s behaving inconsistently, then that may be a bug.
However! The stone is intentionally not highlighted before you first examine it. It’s the first in a set of objects that are like this; “hidden” objects. This basically relies on the player noticing something about the object and trying to examine it even though it’s not highlighted. Once examined, it’s revealed.
Ah, I see.
… But while it is a robot of sorts, it’s a wooden robot–hence the “chunk!” sounds made when hitting it. (It also doesn’t speak, I think, so no vocalisations.)
Perhaps I should just increase the volume of those “chunk!” sounds, so that they’re a bit more satisfying…
As for the stone with a collection knife, I understood the principle. First you need to press the right button.
That’s good, at least; I’m glad.
So, you’re saying then that it doesn’t work that way any more when one starts a new game?
The problem is that I did not pay attention to how I could find for the first time. Maybe I was just not paying attention.
Aah, fair enough! In all fairness, it is perhaps a bit early to use a “hidden” object of that sort for a collectible, before the concept has been more-properly introduced. Perhaps I’ll make that stone non-hidden in a future version.
However, there is still a problem with stamina, it ends very quickly and does not accumulate.
This actually causes two problems.
The first one shows the cache.
The second saves the player to check everything in its path, but this is rather a plus.
It should recover, as long as you don’t do anything other than block… (Moving and attacking will drain it.) Is it not recovering at all?
A guard will kill you faster than stamina starts accumulating. I mostly die like that.
If you’re careful with your stamina, fighting methodically, you should have plenty. (Again, I think that I’m not tutorialising well enough here–not conveying that overextending your stamina can be deadly, and that methodical pacing is called for. :/ )
I had problems with the mechanics of the game. I can’t understand two things.
-
How to understand that I collected all the elements? Impression is currently being created that the center of the image is missing.
-
How to understand the correct position of the elements, position and rotation? Or is there a margin of error.
The character gives a thought to that effect on collecting the third (and final) piece, if I recall correctly, and I think that the description given when examining the collection gives a similar indication.
(If I’m mis-remembering on either point, please let me know! I want both of those indications to be present!)
There should indeed be a margin of error, yes.
As to figuring out the correct positions (and orientations), look at how the lines flow, and think about where the pieces might be to make the lines flow neatly into each other. There are also a few hints on damaged portion of the largest piece, as I recall. (Those hints are beneath the two smaller pieces in the picture above, I believe.)
It doesn’t quite make a fully-complete image–but it does become complete enough for it to be reasonable for the full image to be inferred.
(You’re really close!)
And by the way, if you want it, there’s an accessibility option that adds guide-points to the puzzle, showing how the pieces might connect. It does drastically reduce the difficulty, but it’s there if you want it (such as if the puzzle becomes frustrating).
Wanted to ask a question, is this character a copy of Mike Tyson? It’s just unbearable to fight him.
At such times, the cursor position is critical. It is better to keep the cursor in the center, sometimes you need to make a block, and the cursor is on the other end of the screen and this creates a big problem.
I think it’s better to use certain movements up left and right. Than the exact cursor position.
Hahah, that enemy is tricky!
Part of the challenge is figuring out how to defeat each new foe. 
And as with the puzzle that you mentioned above, note that the options menu includes a set of combat-specific difficulty modes. (Including a “have the computer do the fighting” mode, primarily for those who prefer to explore and not fight.)
That should actually be improved in the next version, I think: someone on TIGSource suggested confining the cursor to the central area of the screen, and I’ve implemented it. This means that even if you move the mouse broadly, the cursor is never far from moving to a new defensive/offensive region.
I forget why I didn’t do that. In all fairness it may just be a hold-over from an earlier iteration of the mechanic, which involved much more direct control over the character’s sword-arm.
I’ll give your suggestion some thought, I think.