Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

The game was rushed since I started it all on AI and then build the models all alone. In the end I had to build the puzzles and maybe balance the gameplay difficulty.

It endeup ok but for someone who never saw the game it got really “complex”. I only saw how hard it was when a guy from twitch played the game.

The flow of the game isn’t clear at first so I really needed to add a sample level before actually putting the player in the heat (the level I hate so much in games: Tutorial).

For me, I don’t really care about tutorials since I always played random when kid, but people have standards and mostly they must understand your game. The fork, the puzzles and the light switches aren’t clear and that’s something I didn’t put a lot of effort into explaining to the players and the whole “flow” of the game is flawed because of that.

Conclusion is that the game is good and the gameplay is fun, but new players just can’t undestand in less than 5min and that’s a big flow in the design. Taking into account I tried to make all that alone I think is a win but as a game you deliver for people, it lacks tutorials.

About the door handle puzzle, all you need to do is move your mouse quickly sideways (left-right or vice-versa). The concept idea for that takes into account switching lights off to gain a few time + you’re thriving to escape the hotel. Since you found a fork then you might try to open that door in any way possible; Since your input to the door is your mouse, the motion on the mouse(sideway movement) is the equivalent “desperate” you would have in that situation… So on trying to explain the little details, the idea is that your input on the mouse reflects the “rush” the character has to open the door.

Next time just try to move is sideways and that would be easier (the same with the storage room which is somewhat hidden into players view but it’s there).

(+1)

I think my issue with the fork is that in fullscreen I did not move the mouse far enough. If you are basing the input on how far the horizontal movement is proportional to the total width, then the same amount of mouse movement in the smaller window translated to a bigger input. In fullscreen I was simply not moving the mouse far enough. I pulled it back up and moved the mouse from end to end in fullscreen and was able to get the handle to start moving. The default viewport size felt a bit small, so I did not really like playing it without fullscreen.

(1 edit)

The code for the input was just “InputMouseMotion.relative * weigh”.

I took viewport into account too but overall it works the same on both “modes”.

In my tests the fullscreen were easier but I didn’t tested the web version, I just “deployed” to match the jam requirements (I mostly took optimization into account rather than tweak the gameplay settings).

Anyway, the game wasn’t meant to be played out of fullscreen so in a way it’s totally a bug (I tried using both axis on InputMouseMotion cause the player could get confused if the motion were supposed to be up-down or left-right; I just used both so any input like randomly moving the mouse very fast would have the same effect and not just left-right which was harder even while I was developing).

Also, the viewport is small cause I couldn’t get the godot 3.x “downscale” effect on 3D so in a way it was meant to improve performance but also to “look” like PS1 artstyle. I took “256 * 5 / 4” x “224 * 5 / 4” as a rule for the resolution but since 512x480 was “too laggy” because it lacked optimizations I just kept that lower (on 512x480 the fork is visible but that was a cheap way of picking performance x quality – I wanted a PS1 look so PS2 resolution was “too good” for the design I had in mind, I’ll probably use 800x600 in the future since it’s more standard but still as pixelated as 512x480).