The dangerous unknown is an experimental twist on hidden object games. I made this game concept in less than hour.
What people are saying:
“I think we just got pranked…”
Controls: tap/mouse click; PC only: r to reload, esc to quit
Genre: Hidden object with a twist. Experimental.
Nancy Newren: Original concept, sole developer
Tools used: Unity, C#, git, quick coding
Special Thanks: Jose Zagal for the theme.
Constraints: theme, less than an hour
Theme: Hidden Object with a Twist
I literally only had about an hour to make this game, but previously I had brainstormed some simple ideas. A common theme arose: what if the object you are locating bites back? It’s almost like the game doesn’t want the player to play: because the player gets punished for doing the only thing they can: find objects.
I knew the game would only play with player feedback, so I set out to implement the simplest of mechanics (tapping on an object to “find” it) and then implemented audio and visual feedback.
The entire game concept is a simple 2D orthographic camera, some UI elements, and I had the concept made: a flat map with the objects on top, which switch to a “found” texture, apply blood splatter to the screen momentarily, and plays one of two pain sounds.
Cool Things I Learned
“Code doesn’t always have to pretty, but it always has to get the job done.”
-Nancy Newren, Experimental Gameplay Engineer
The first thing I learned is that I have gotten a lot faster at prototyping. It’s certainly not my best work or my best concept, but knowing I had an hour I made deterministic engineering decisions to not architect a game that I could build on, but rather chose engineering design that would enable me to make the game work. I cut decisions like modularity and optimization, and opted for simplicity. I think it’s important in development to be cognizant of best practices and to know how optimize and make code modular, but to also be aware of deadlines and all important feature richness. Code doesn’t always have to pretty, but it always has to get the job done.
As I mention frequently I love designing games that can be played without explanation. So I had a friend in front of a class play my game. From the first “bite” the entire class jumped. I think that was the most enjoyable part to me. A feeling of being pranked prevailed. It was fun. And not just for me. It was also interesting to tap on these objects and see and listen to the feedback.
But even though the game was simple, I still learned some simple things. First: it didn’t read like the player was being hurt, it felt more like the pain sound was coming from the squished spiders. To resolve this I think a squish sound that is layered with the pain sound would help. Also, it would be good if the player didn’t necessarily get hurt each time. That way the player associates the squish sound with the spider, so the pain audio must be coming from a different source. Finally, I would also stagger the audio so they don’t play at the same time, though they could still overlap. This would increase the ability of the player to separate the meaning of the different audio.
To make it clearer that it is the player that is taking on pain is a border located blood splatter: instead of having the blood splatter cover the center of the screen, have red along the borders. The intensity and amount of red then can reflect the amount of pain the avatar is feeling. This plays well in other games this way and I think would translate well.
Also, I had to google blood splatter again as the stuff I had wasn’t a good fit for this game. If you don’t have a strong stomach, don’t google “blood splatter.” Just saying.
Ideas for Future Development
Found object games are typically played as static images and you located images within the image, but I think they would be more interesting if they were almost 3D: A “static” image with moving objects that you are searching for on the screen. This would add life to the game and make for more interesting gameplay as not all the objects may be visible all the time. This could potentially add to frustration as well. But adding things like timers, or find X when there are Y (where X is of course < Y), could dissipate expectations of finding all the objects.
I would really play on the jump scare, but keep it fun. I’m not personally a huge fan or horror, but I like a good scare and Half Life will forever be one of my all-time favorites. But I think the buildup of the scare and the buildup of a joke are similar. I spoke with Jose Zagal about wanting to keep the jump scare fun and he mentioned these similarities and how it’s a buildup: you build up to the punch-line or the scare. You do it again. And then sometimes you have a relief instead: in terms of horror this would be the audience thinking that a monster is about to attack but it turns out to be a cute cuddly kitten. The buildup of anticipation is what creates the pay-off of the scare/punch-line.
I particularly had the idea of a two level puzzle for this game: you are using your finger to squish spiders, but that can back fire, so if you find a different object to squish them with you might have some better luck. This is where the buildup comes from. There’s quite a bit of tension in the game design for a game like this: as a designer you need to keep the game predictable enough that the player can play the game, but not so predictable that there isn’t any challenge or surprise to it. There is also the biggest source of frustration for a puzzle gamer: knowing what you need to do and not being able to do it. It’s why I rage-quit The Turing Test. With this kind of puzzle game though, which would be building up jump-scare tension, it adds an additional layer of tension: that is player expectations of what should happen and whether what does occur fits within the boundaries of what the player would accept. It’s not always easy to tune all of these variables, but if you do it right it can be a very enjoyable experience for the player, even while they’re screaming.