Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Thank you for the honest feedback - it's good to know what didn't work, as well as what did.

The honest answer about the UI is that I was a software engineer first, and when I first started making these games, I was far more interested in writing the engine that actually making the game. Playing submissions for this Jam, I've seen how much better things are in actual game engines, so that's definitely something I'll be looking into.

Obviously it's hard to say anything without giving spoilers for others, but was there any particular clue that pushed you in the wrong direction? Brute forcing these sorts of games is always disappointing, so I obviously want to improve it to help avoid that!

I've added placeholder text to the input box, to hopefully make it a little more obvious. It does look slightly too much like a button at the moment.

Yeah, I had a sense that you were an engineer first :)

I think I was just overwhelmed by the clue possibilities and so my brain picked the one it liked the best ("a lady's generational revenge" - I wanted to be less overt to describe it but when I went back in to see what the code for that was it was a bit buggy - it started a new game but with residuals of my previous game still in the sidebar, and the skip codes weren't working at all, and then the text box stopped working... so you also need to flush whatever data is being saved long term).

As I was saying, I think the clues are a combination of too many possibilities plus little details that can get lost in a sea of other information (for example, I went back to confirm that the name of the pills was in the toxicology report because I hadn't noted the information when I read it but then it occurred to me afterwards that it was probably there, and it was). There were a lot of plausible theories, most/all of which you then detail in the narration, and the right one didn't stand out to me so I guess what I'm trying to say (apologies - I'm typing this while in a bit of a rush) is that you need to make the important clues more obvious and the red herrings more recessive, if that makes sense.

Also, bear in mind that I was fighting with a very difficult user interface so that pulled my attention away from the narrative aspects of the game. I got used to it and got better at playing the game using it but it took a while and I subconsciously missed a lot of the narrative in the beginning of the game because I was struggling to play and that's where my focus was - "How do I do [x]?" instead of "Hmm... that's a suspicious clue."

The important thing, though, is also that you made a full game and as a player I got to the end (and had a good narrative experience in doing so, even if I had a usability struggle) so it's fully functional and that's a great start. Hopefully you've learnt some things and will apply those lessons to your next game. That's what game dev is. (Along with: don't make your own engine when you are starting out; use the standard engines that are out there. They are refined and they result in gaming interfaces that players know and understand.)

(+1)

Thank you, this was really helpful feedback. 

I think you're right, and I may have done a little too good a job hiding the evidence! Of course, to me the obvious clues seem really obvious, because I know what they are. Emphasising them a little more for the players, and minimising the red herrings, is probably a good idea.

Definitely some really good things to think about for the  next one. Thank you for taking the time to play it, and to give detailed feedback!

Yeah, there's a lot going on in your game and different people think in different ways. For example, I noticed immediately that the jewels were in the wrong order but although that was odd and I knew it meant something it didn't make me think of forgery because to me a good forgery is something far more subtle and hard to discern. So my advice is use a standard game engine, while you're still starting out, which solves lots of usability and UI problems, and test with as many people as you can to observe how they approach problems and interpret the information they discover.