Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

ThatGame.exe

A cryptic puzzle game about being a bad coder. Also ducks. · By BobboDev

Overall feedback

A topic by Mithenson created Jun 09, 2022 Views: 553 Replies: 4
Viewing posts 1 to 3
(1 edit)

In short, I had a blast sparkled by frustrations. The concept is very promising & the aesthetic of the game ties well with it. You're a programmer & you interact with the game through that lens. You have an IDE, there's "meta" comic relief about the development of the in-universe game (Reminds me of There is no game a bit) and you have to think in terms of how the game was built. It seems to me like something that could easily be expanded upon aswell. We might meet other people working on the game: artists, managers, etc... We might see different stages of development. There's so much that can be done with this & it's awesome!

However, I feel the game suffers a lot from two things:

1. It has an identity crisis. Is it a physics game where dexterity is the main skill to have? I mean I know I spent a lot of time pushing a duck, doding ducks, following one, etc... Or is it more of a puzzle game? The premise of the game seems to push it more towards being a puzzle game where reflection is key (I think there's reason why Baba is you was one of the referenced game). If that's what the game should be, then the gameplay needs to be fully reliable. Actions should have clear outcomes, dying should put back the level at its starting state, etc... The player should be able to focus on coming up with the solution & not struggle with executing it.

2. The gameplay isn't systemic at all. It's only a series of unrelated gotchas, which don't misunderstand me, I love. They convey a "Ah-ah" moment which puts back into perspective the comments of the player-character & the context for the level. However, there is no one or two mechanics that guide you towards these. It could be the pause menu which would act as an actual way to view & interact with the entities in the scene (E.g-Level 7: You might be able to look at the duck properties & see that it's tied to the audio system). It could also be tinkering with the game files as it worked greatly once you figure it out in level 6. The player could learn an ultra boiled down scripting language to interact with the scene. Essentially, I consider that most levels are hard to solve because you have no tool you already know to use with which to start the solving process.

I really look forward to further work on this if some is planned.

(+1)

I completely agree with your first point, I didn't know how to put it into words but you did it perfectly!
As for the second point, I'm not sure if I understand it correctly;
Basically you're saying you want a help tool that points the player in the right direction? Not like a tutorial, but an active tool throughout the game so that you're never confused about what to do? I agree with that, and I think the game tries to do that with the displayed code feature, but it falls off a little in some places
a tutorial could solve this as well, but I think a tool that is with you the entire game is more immersive

Yeah that's it. So more like a mechanic than a tool. I agree that's more or less what the snippets of code try to do. However, you can't interact witht them & they're not always presented in the same way. It's true that a tutorial might help but yeah like you're saying having something through the entire game would bring a good cohesion. 

To try & phrase it in a better way, I was thinking of a gameplay mechanic that is yuour main if not only way to interact with the game. Of course, you can still move your chatacter freely & observe the level but if you want to get information needed to solve the puzzle or interact with objects then you would use that mechanic. 

I think there's tons of way that could be done & fit in what the game already uses. Like if the snippets of code were in the editor, you might be able to re-write only some parts. To give a really simple example for level 6:

The editor could have a DATA tab. In it you would see the different objects in the scene. So something like:
- PLAYER [Read-only]
- PLATFORM [Read & Write]
- BUG [Write-only]
- EXIT [Read-only]

Each of those would be folders which contain some files. So in the PLATFORM folder there would be the "Settings.txt" file with "moving = false" in it. You could only edit the "false" to "true" to solve the puzzle.

Now for the other folders, those marked with [Read-only], you woule only be able to look inside of them & not edit anything. So maybe there's some "Info.txt" in the PLAYER folder & some funny stuff like "lastTimeSinceSawTheSun = tooLongAgo". As for the [Write-only], you would only be able to put files in them. That way you could copy / paste the "Setting.txt" from the PLATFORM folder & put it inside the BUG folder to get it.

Developer (2 edits) (+1)

Hey Mithenson!

I really appreciate your feedback man! I'm really thrilled to hear your excitement about the potential of the game! I am also super excited about all the directions I could take this in - it's exciting because the gameplay is basically completely open-ended but still contained within a strict box of "game-dev" theming. Btw sorry I didn't reply before, I've been so busy trying to fix things in the game and replying to the people I can. As for my opinion of your feedback, I really think you are spot on with most things!

So because I just had a week, I created a bunch of difficult lateral thinking puzzles - the ideas that I was most excited about, and then didn't have time to think of any easy puzzles to ease the player in. I didn't want people to be immediately put-off by everything being too cryptic straight away, or for the game to be one massive headache after another.

Interestingly, super difficult puzzles with real "Ah ha!" moments seem to be easier to think of than easy puzzles - with most ideas it's either cryptic and therefore satisfying when you figure it out, or so obvious that it just leaves the player feeling like "well that was easy, was that supposed to be a challenge?". It's super difficult to come up with a level where you know "the player is going to spend about 30 seconds figuring this out, and it will be considered enough of a challenge, but no one will get it straight away".

That's where the dexterity levels came into it - it was literally just an attempt to create a level where you see a clear goal, it takes some time, and literally no one will get stuck so that the flow of the game doesn't stop. I don't personally mind the dexterity element of it but I think I could definitely come up with better levels given more than a week (Although I made them all in one day really, which should tell you a lot :D). I also think I could come up with those "think for 30 seconds, no one gets it immediately" ideas given more time. 

There are certain levels in this game which frustrate me as well (especially the collider level), but as I was giving myself a hard deadline and didn't want to end up with a lack of content I didn't take them out. So please don't think this is my idea of a balanced and optimised experience. It has a lot of problems - it was made in a week :D

As for your second point, I also agree, I had a lot of ideas about how I could extend the code editor - even add more programs in that could aid in the puzzles. But again, one week. I barely had time to get what I did into the game so I had to sacrifice some cool ideas just to get it done. But yeah, when I develop this further I'm going to do exactly the kind of thing you're talking about :)

Except for maybe exposing all of the info about the level in a data-viewer in every level. I don't want the player to have to check through a bunch of files and settings every single level just to be sure the answer isn't there.

But yeah, I think you're spot on really and I would definitely love for you to be a play tester for future versions if you're interested :)

(1 edit)

Hey!

I should've been more clear about that but most of my feedback was in the idea that you would be able to do more work on the game. Like you're saying it was only one week & for that amount of time it's awesome! 

I completely understand your worry about players not being satisfied with easy challenges where they might understand the solution too quickly. I'm curious though, did you make mostly hard levels because of the 1 day constraint or is it a stance you took on pushing the player in a mostly unknown environment & let him figure things out as opposed to taking him through a usual learning curve (Easy "dumb" levels to hard levels) ?

Also now that you frame it like that, the dexterity aspect does make sense. The argument that it keeps the flow rolling is really good. It makes me think of most platform puzzle games where you can always easily move with your character & try things out while coming up with the solution, you're not stuck somewhere with having to think about what to do.

However,  I still think that regular physics will introduce a lot of issues if the gameplay is kept tight as it is right now (E.g: you have to restart the level if you weren't touching the duck for more than 1 second). I didn't thought about it initially but games like Portal 2 or Viscera cleanup detail make the physics aspect work quite well. I guess it comes down to how punishing messing something up is & how precise you have to be with the physics (E.g: You can easily fit 3 cubes on the button plaform in Portal 2 I think). In any case, there should be ways to make it work out if you want physics to be an important part of the game!

The idea of having all of the level info in the data-viewer was just me spitballing & I think you're right that it might make the player a bit paranoid. I'm glad you have plans to extend that side of the game though! I look forward to see what you come with ^^