I like the concept and the three different "worlds" were nicely rendered with good choice of color palette. But I wondered why the entire game reset after eating the food in each world. I thought it would be better to bring the player directly back to the hospital to reinforce the connection that you talk about in the description. But I still enjoyed it—it prompted some meditation/reflection.
jafish
52
Posts
5
Followers
31
Following
A member registered Jul 12, 2014 · View creator page →
Creator of
An Interactive Video Game with Narrative Immersion to Educate First Year Students about Mindful Drinking
Educational
Play in browser
Recent community posts
Nicely done! I think the verb could have been more clearly developed as a "character". What I mean is that once the player figures out how to do one puzzle, the other two are trivial. How could you have made the "push" verb a bit more interesting? Maybe by pushing rocks in a group? or limiting the number of pushes, or some other restriction.
Great exploration of the mechanic by combining the verb with different combinations of obstacles in the four "scenes". I'd quibble with the verb (you're not exactly sneaking) and the unreliable jump/land on enemy makes for some frustrating encounters. But otherwise it's a good fit for the assignment!
Remarkable: If I'm not mistaken, you built the car physics system yourself. What I found most remarkable about it was that even if it drove slowly, the wheels against the road created a sort of "rumble" effect in the camera, so that it felt like you were actually in a moving vehicle.
Needs Improvement: Speed! More speed! Also, since you had audio (the "GPS" voice), it makes the absence of audio elsewhere really noticeable, so I'd add some audio.
Successful: It really does give the feeling of being stuck in traffic and desperately find a place to park. So much so that I started pushing cars out of the way (and also notice that some cars were dancing by themselves: https://d.pr/i/GYT0wR/9nWLDFpcrE)
Remarkable: The completeness of the game loop design - the fact that you've got a "waves" system.
Needs Improvement: Objects and environment felt a little random (i.e. not the most believable environment). Also, it felt like it needed more sound effects to help the player locate the covid spheres. Not that it was "too hard", more that since you added the gun sound effect, it raises the level of expectation that this game world makes sounds and so other things should be making sounds also.
Successful: Even if the world is somewhat random, the threatening feeling of the enemies/waves definitely works.
Remarkable: Great proof of concept - wasn't sure how you'd approach this but think this was neat. Sound adds a lot.
Needs Improvement: Speaking of sound, that ball sound make a bouncing sound! Feels like a missed opportunity (even though I think the sound you *did* add is a great choice because it adds enough to the "feel" of the space to make it authentic). Also the control scheme feels like a shortcut to something a bit more robust, like the strength of the shot being based on how long you hold the mouse button down (for example). These controls feel half-way complete (even if they do sort of work).
Successful: Creates a fun, simple hoop-shooting experience. Also a great foundation to build on. Also nice use of static variable to handle the ball picking up!
Remarkable: Terrific atmosphere created using combination of complete, enclosed environment, audio soundbed, and lighting and particle effects.
Needs Improvement: Lack of feedback (other than in the UI with the numbers going up) when I'm trying to pick up an object (some sort of visual and acoustic indication that items are pickuppable and have been picked up would be welcome. Especially in such an otherwise-polished experience, the lack of this feedback stands out (hopefully you take it as a compliment that this part is "worth criticizing").
Successful: Clever clues and environmental storytelling.
Remarkable: Good use of textures to indicate food items, and especially the facemask texture allows this to serve as a good time capsule for the times.
Needs Improvement: Project hierarchy and script organization could be improved, and since you used some on-screen UI it was a little confusing that the "you win" and "you died" messages were in the console rather than also in the on-screen UI.
Successful: I was motivated to collect all the coins. Even though it was simple, this works well as a "collect-a-thon" prototype.
Remarkable: Completeness as a prototype - I could see this foundation being developed into many challenges/levels, each with the goal of uniting the two characters.
Needs Improvement: I was thrown off/confused by a few things. First, the "button" hint wasn't actually helpful for me because the "buttons" looked more like sewer grates/coverings. "Switch" might be a better word, or making them more visible as interactible items. To be fair, they do stand out, and eventually I figured it out, but I think I maybe didn't step on one properly the first time, wrote them off for a while, and then finally decided to try again and it worked. Also, project and hierarchy were a bit messy - I'd encourage better organization there (folders and empty parent game objects).
Successful: Interesting puzzle-solving mechanics. Although the world doesn't really explain why one player can rotate camera vertical and the other can't, it results in an interesting challenge. It took me a while, but once I figured out that I needed to climb the ramp to shoot the bags I had a nice "ah-ha" moment, which is one thing you might be aiming for in puzzle design, so nicely done!
Remarkable: Not gonna lie - this caught me by surprise. At first, I was like ok, I'm going to be walking through some rooms with pre-build 3D models plopped in. But then you made it both personal and relatable and vulnerable and I was charmed.
Needs Improvement: The scale feels too big for the size and speed of the player. It also makes the world feel more sparse than it probably should be (like, that's the opposite of what a game like this should feel like!) Also, the assets and scripts aren't very well organized - I'd definitely use more folders and empty game objects to hold all that stuff.
Successful: Enjoyable to explore, personal, poetic.
Remarkable: Cool to see the car standard asset used in a project.
Needs Improvement: Car controls are not great - it feels like I'm not really sticking to the road (obviously not your fault exactly). Also, it felt weird that the game doesn't let you crash, stopping you before you fall instead of deciding when you've got yourself stuck/destroyed.
Successful: The premise - timed race to campus to park your car - works well, and it's cool to see some recognizable buildings :)
Remarkable: Charming and hilarious, especially when I try to take someone else's food.
Needs Improvement: Clicking on food to pickup feels finicky - I sometimes had to back away, and even then it wouldn't work It's inconsistent.
Successful: So many nice details, from the sound (ambient and sound effects) to the textures and lighting, to even the subtle "bopping/bobbing" animation of the food items.
Just goes to show you how player perception can often be "wrong". If you were going to push this further, I'd really dig into this question from the tester (me, but I'm trying to generalize). What made you feel like it wasn't your fault? This is also where it would be helpful to have players record themselves playing and to "play aloud" so that you have some insight into how they're feeling as they play.
On controls, I think I'd focus on collision actually, because the controls work fine, but it's the stickiness of the stairs (getting stuck to the side while trying to jump) and what feels like a pretty large collider when trying to avoid fireballs (I got hit sometimes when I felt like I had jumped early enough to clear the projectile) that make the controls feel not great. This is a great example of something that Ellie has talked about, where using the built-in Physics can often be "good enough" to prototype something, but that really you need to build your own player controller to handle this kind of thing using Raycasts/Boxcasts, or other solutions.
I love the blue puff/spikey characters, and the bats. Whimsical. The other artwork is just ok.
Apparently I didn't survive for over two minutes! What I'd work on more are the controls (it's been a while since I played Balloon Fight, but I think the left-right movement isn't as fast/responsive) - controlling the game almost felt too easy.
Even with that, the collision felt unfair sometimes. It felt like a lot of the times that I lost were not my fault, and that I didn't *actually* quite collide with the diamond shapes. If the diamonds use box colliders, that might explain why.
Remarkable: The scope and completeness of the experience. With a limited amount of time and resources, you really created something that felt like its own world.
Needs Improvement: Like others have mentioned, the scale was a little strange. A small thing I found strange was that the music was quiet during the "jail" scene because the audio source is so far away (in fact, when you return from the jail that becomes clear because the volume goes way back up again). Finally, there were some "plosives" in some of the voice recordings, so for future projects it would be worth it to practice better mic technique or record in a recording studio (which we would be able to do if it weren't for COVID, so totally understandable that the audio isn't professional quality).
Successful: The use of audio is really great, and the way you introduced the Easter eggs, and the challenge in finding them, was both novel AND accessible. In other words, it was well balanced, even though each Easter egg was found in a slightly different way (some were spacial, some were interactive, some required you to do things that, as a player, you might not think to do).
General: Even though this could be "polished" more, I think it's really successful as a prototype.
Remarkable: The combination of lights was pretty disorienting, which I think was part of the point?
Needs Improvement: This is just a personal nit, I think, but I'm just not interested in mazes if there aren't any clues or story bits or other things of interest to discover. It was very hard to get to the mask (I even cheated!)
Successful: The Purell sound effect was appropriately gross and effective ;) And the covid spheres stalking me felt ominous.
General: Doing more with sound might help the player navigate the maze. Not that the mask should make a sound, but maybe the covid spheres, and you could do more to make the maze "embody" the feeling/experience/sense that you're trying to create for the player. Could be through audio, color, text bits, etc.
Remarkable: Excellent use of sound - the ambient "summer nighttime" audio makes this feel leisurely and calm.
Needs Improvement: The language at the beginning is a little unclear (as some have mentioned). Even something as simple as communicating to the player that they are solving puzzles would help address some of the initial confusion I felt. For instance, I kept losing the first puzzle after just going straight and hitting the third tile and thinking to myself "But I'm doing what the instructions say!"
Successful: Puzzle design that progressively gets more difficult in ways that force the player to adjust their thinking (for the third puzzle, without giving away any spoilers, in particular).
General: Definite The Witness vibes from this one. From an architecture standpoint, it might be helpful to have a "Puzzle" or "PuzzleManager" class that stores information about any given Puzzle. Some of your code comments suggest that you think there might be a better way to store and manage everything, and something like this might help. One thing I noticed is that to check correctness, you're comparing GameObjects to Bools, and then need to go through `for` loops to check every individual element of the puzzle. What if, instead, a PuzzleManager script had two arrays of bools, the correct and the current, and each Tile could talk to the PuzzleManager to flip the proper bool. Then, checking the solution becomes as simple as checking two arrays for equality. Just a thought.
Remarkable: Good use of sound effects.
Needs Improvement: Feedback! First, hard to tell which box is which. Second, because the text reads "RedCube1", it took me a while to realize that the "1" is supposed to be a quantity (without a space, I thought it was talking about a specific box). Finally, it's hard to tell when you're allowed to pick something up. Since you're using a RayCast to indicate "pickuppability", I would add some kind of highlight to the box that is pickuppable at any time.
Successful: The feeling of monotony, which hopefully was the point! (but also the sound effects made it more satisfying than it probably deserves to be ;) )
General: I worry that it would take away from the sort of casual feel, but maybe you could have a timed mode. This game seems like a good fit for a competitive experience.
Remarkable: Great use of sound!
Needs Improvement: I agree with the other suggestions - some interactions beforehand might connect the player more to the experience.
Successful: As someone else mentioned, I think having items disappear while I'm not looking at them is actually spookier than it happening while I'm looking at them. Either way, it's a terrifying effect, especially coupled with the music.
General: Lots of great suggestions from others on where you could take this, but as a prototype I think it's very effective.
Remarkable: The small details that add up to make this feel like a movie theater (carpet texture, arcade machines, video textures, etc.)
Needs Improvement: The relative scale of the spaces still feels off (the spaces, except maybe for the individual theaters) feel way to big.
Successful: The interactions, including picking up the ticket, handing it to the attendant, getting concessions, etc., all contributed to the feeling of going to see a movie.
General: Idea for future game - stealth game where you try to see multiple movies with just one ticket.
Remarkable: SOUND! Nicely utilized, even if the bouncing sound effect *might* become a little annoying after a while.
Needs Improvement: I mostly agree with what has already been said. The ball bounces unpredictably sometimes, especially on the windmill level, for example, leading to situations where I felt like the game was screwing me over. I don't *think* that's how you intended it to feel. On other levels (04, for example), it feels like there isn't really a viable strategy that I can get better at (or maybe I just don't have the patience). Regardless, on that level especially I felt like I just had to get lucky with my bounces to finish it.
Successful: Nice variety of designs, with a couple interesting mechanics, some that you re-use (like the controlling of multiple paddles). You could combine those mechanics in a huge variety of ways to build more levels.
Remarkable: Super satisfying gameplay, excellent organization of scenes and code.
Needs Improvement: Initially I didn't see that I needed to hit enter to advance to the next level - the flow of messages in the console made that a little unclear (there was lots of other activity in the console). I also found it a bit frustrating how long I had to wait to fire the next cannonball, and there was no way to see how long it was going to take.
Successful: The detail of objects spawning in not *exactly* where they need to be so they sort of settle into place is really neat (whether or not it was intentional).
General: A perfect balance between simplicity and complexity. Like Angry Birds, Boom Box, and other games like this, you could build a ton of levels based on just the foundational "blocks".
Remarkable: I found myself wanting to return to the challenge multiple times, even though sometimes the distribution of balls made success impossible.
Needs Improvement: Movement was frustrating, although it did seem like I could translate horizontal momentum into vertical momentum, which helped. Since your code isn't doing anything directly with physics, you probably shouldn't use FixedUpdate (in the BallSpawn script) (more on that here: https://docs.unity3d.com/Manual/ExecutionOrder.html)
Successful: Finding a gap and speeding through it was satisfying.
General: Simple and well put together. Scripts are well organized and commented - good use of methods. Assets/Scene are well organized. Introduces some simple UI. Overally the game is very simple but it's fun. No complaints.
Remarkable: The fact that you created multiple scenes/levels for the game, each themed differently.
Needs Improvement: Organization, controls, and modularity. The control direction was rotated 45 degrees, which makes sense for an isometric perspective but not so much for a behind/third-person camera perspective. Makes the movement feel wrong and more difficult. The project hierarchy and folders were very hard to navigate and there seemed to be lots of scripts duplicating functionality.
Successful: Use of textures, materials, colors, and models to make each level feel really different thematically.
Like the other play testers, I found this way too difficult. HOWEVER, I have to give kudos for the well-tuned controls. This game is very difficult, but it is close to feeling like it's mostly my fault when I fall or miss a jump. That's a good sign! So why is it "too" hard and who decides? Well, you've got three people saying that. "Too hard" can either mean "this kind of game is not for me", "the game is fighting me and I feel like I can't win", or something else. It's very subjective! I think for this group it's a little bit of both. The reason I say that it's close to feeling right is that there's not that much of an indicator to follow, so you're largely going based on muscle memory and practice. Since that's the case, starting the game with a much easier level might be better. For example, just a few platforms. continue ramping up the difficulty as you go. Your current game is like the ultra hard last level.
I think you should also ask yourself what experience you want the player to have. You were focused on speed running, so do you know anyone who speed runs? What do they think of the game?
From reading the screenshot Saturday posts, I think you had hoped to get some AI working for the opponent, but didn't quite get there. When you're in this situation in a game like this, making it a 2-player game is a pretty simple compromise. We haven't talked about exactly how to do a split-screen kind of game, but that would be a good solution for your design.
I think your solution for getting the two pillars to rotate is *really* clever and remarkable. I would never have thought to attach them to a sphere and rotate it. I think the design of the course is pretty interesting and it left me really itching to try it out with two people. I can imagine using the moving platforms to hide out and to develop strategies to launch at my opponent from those platforms before they could see me coming (if I timed it just right). As for code, you did a good job combining the various parts together and the code organization in different files makes sense.
I largely agree with the other feedback, but I wanted to add that it feels unnecessary to require that the player collects all the coins to advance a level. Partly because it's not clear up front, but also partly because it feels overly difficult to go back through a level if you missed a coin. This is a really strong project overall and impressive for a first project! And there are a few really fun details, like the "funnel" in level 3 and the "glass" covering the falling portion of level 3. Really creative and versatile level designs! I also had some slow loading times - you may want to check out the Unity Profiler to see what's going on (especially in level 4).
But in the end I find it too frustrating. A simple thing you could do is instead of requiring all the coins to award a bonus for collecting them instead. Why else is it frustrating? Because it is *very* hard to see where you'll land. One way to address this would be to create a "fake" shadow directly underneath the player to aid in landing after longer jumps. I would also think about what kind of challenge you're trying to give the player. I think "punishingly difficult" is a genre, but when it is done well it usually is a quite "scaffolded" experience that only throws one new thing at the player at a time and gives lots of time to practice. Your levels do this sometimes, but other times it feels like a bunch of new things all at once without any ability to really practice them. The question I'd think about is "How do you want the player to experience challenge?"
Nicely done, and great to see the progress over time. One thing I noticed was that I could play and win the game without ever kicking! I didn't bother to look too closely, and ended up kind of just pushing the ball around. But the kicking is way more fun, so once I discovered that it was fun to play with. This game would fit right in with SportsFriends.
It's definitely a compelling initial setup, but I found the control of the ball frustrating only because I really felt helpless. *Maybe* you wanted the player to feel that way, or feel like the odds were stacked against them. But, if you didn't, then I'd suggest giving the player's movement a bit more "oomph" because the purple balls would knock me way out of the way and then it would take me a long time to get my ball back up to speed and then I'd get hit by another ball. The aspect that is super successful is just the feeling of chaos that you see as soon as you start the game. Mayhem indeed! It's also great to see that you added a timer and UI, even though we hadn't really covered those aspects yet.
One suggestion on the scripting - I noticed that you use `Find` in the `OnTriggerEnter` method in the `winbox` script. It's best to avoid using `Find` outside of the `Start` or `Awake` methods because it's a lot of work for Unity. Especially when the object you're finding, the "sphere", is always in the scene. A better approach would be to create a variable to store the GameObject and use `Find` like this:
public class winbox : MonoBehaviour
{
private GameObject playerSphere;
private void Start()
{
playerSphere = GameObject.Find("sphere").SendMessage("Finnish");
}
private void OnTriggerEnter(Collider other)
{
playerSphere.SendMessage("Finnish");
}
}
OR, avoid using `Find` entirely and just assign the `playerSphere` variable through the Unity inspector by making it public instead of private:
public class winbox : MonoBehaviour
{
public GameObject playerSphere;
private void OnTriggerEnter(Collider other)
{
playerSphere.SendMessage("Finnish");
}
}
Agree with the previous comments! As a prototype, this is very good! Clear instructions, eminently playable, even relaxing (which, if that's not what you're going for, maybe consider some of the other suggestions!) I finished with 5 seconds left, and I was meandering. And the timer is pretty high to begin with, so it left me wondering if that's the feeling you want to create. One possible way to frame this is to have an unlimited timer but have time goals (e.g. bronze, silver, gold), so that I don't just get reset when I'm about to finish (I'm assuming that happens, but I didn't actually check).
I definitely prefer the experimental version, even with the weird camera issues, because it addresses one complaint about the standard version, which is that it's very hard to understand where to go next, especially in more spacious areas (I'm thinking specifically of the area just after the maze). In the standard version, having an object attached to the camera that is always pointing towards the exit would be helpful.
Some feedback on project organization. Generally good in the project area, but I'd definitely suggest clearer naming of objects in the hierarchy, and maybe even some object grouping via empty game objects (you can really treat them as folders). Keep in mind when doing this that objects become positioned relative to the parent, but as long as you do that you'll be fine.
Finally, a question: In the experimental version, the horizontal movement of the camera is bonkers fast when the ball is not moving, or moving slowly. Why do you think that is?