A challenge was to get our difficulty progression to be somewhat okay. Since if the shapes would spawn too fast after each other it would be impossible to predict the next shape. This gives the player a feeling of impotence. So I created a system that clamps this to a certain value so that the objects stay far enough from each other. The speed slowly increases towards a maximum either. Don’t worry, it’s very challenging when you get to higher numbers. I’ve implemented the rotation of shapes coming towards you. There also now is some sort of combo system. You’ll get points each time you fail to complete an obstacle in a perfect angle. If you get a perfect angle the multiplier gets increased by one and this will be applied on the score you receive. I also added some small screenshake and fov change when going through an object.
Overtime we started noticing some new bugs with the way we checked if the player has a perfect fit. This caused a very big disconnection with the player. I spent this week researching this issue and fixing it. I also started commenting multiple methods and classes so we both know what method does what. I also a way to add an action to perform every update frame for the shape. So you can now make a shape rotate while coming to you, etc.
This week we’ve had our game been played by a group of people. This really gave us some insights about what features and mechanics were frustrating the players. First off we discovered that our special shapes felt more like we just had some ideas and tried to use all of them. We now took a step back and removed the special shapes to focus more on the simplicity of the game. The main thing that stood out was that we didn’t really have any system in place yet to make the game progress. It wasn’t getting harder after a while. This week I implemented a basic manager that changes the firespeed , acceleration, rotation speed and wait time of the obstacles. There won’t be a gif this week since it’s not really easy to show. I also started fixing some bugs. Since new shapes were added I discovered a small bug where we turned on the mesh collider. We don’t need a mesh collider so I went ahead and fixed that. I also refactored some variables into a class, TuningVariables, so it’s easier to pass and update those variables. The variables are things like Firespeed, acceleration, etc… Basically all the variables needed to keep our level progressing. I then pass this to my LevelDifficulty manager and update these variables. I have a struct TweakingVariables that contains information about how fast the TuningVariables should change over time. Currently this is all linear and boring. I’m still searching for a way to make this differ. I’m thinking about exponential and logarithmic functions for this.
Monday we had a weekly meeting to discuss certain aspects. Lots of feedback was giving to each other and we brainstormed choosing a new name, deciding on art style, etc…
This week I’ve mainly worked on rapidly getting a working version of our final idea out. I implemented a new collision checking system. Instead of colliders I’m now using some calculations to compare angles with the player. So the obstacles compare the angle with the player. When the angle is between a certain value you “completed” an objective.
I changed the way we handle obstacles too. I’ve created a base class from which we inherit. The base class itself inherits from monobehaviour.Each inherited object must implement a “GetState()” method. This will either return “FINISHED,FAILED,GOING”.
I’ve also implemented a very basic bezier spline curve which we can use to sample to position so the Obstacles fly in at a certain curve.
I’ve also implemented a new system of switching shapes. The buttons now remember what shape was your current shape and store it. So when you press the button you will switch your currently used shape with your center shape.
Added a whole new prototype idea (one that we discussed during the meeting.)
The player now consists of a base mesh with several sockets, on these sockets shapes can be attached. The shapes rotate together with the base shape. Every shape can be swiped to a different socket and the base mesh will change. Meshes adapt their rotation to what socket they are on. Designed the user interface for this, on the lefthand side you have a sprite of the player mesh (not rotated) with its four sockets. On the righthandside you have your building blocks. These can be dragged (or with a swipe) to the sockets of the player. If you swipe a mesh on a socket back to one of the three placeholder sockets on the right, the socketmesh detaches from the player again and you can add other parts etc.
Also added the 3 (placeholder ofc) models, made 3 sprites for the UI and programmed an efficient drag and drop system for the UI.
Also added five small iterations on the original idea:
Iteration one: Disables the accelerometer of the phone, we had the feedback that it would be almost impossible to tweak the accelerometer for different phones etc. Rotation is now being handled by taping either the right side of your screen (clockwise) or left side (counter clockwise).
Iteration two: Enables the accelerometer for rotation. Which I smoothed out and tweaked for my own mobile phone. It is a very enjoyable gamemode.
Iteration three: Introduces a small new feature I implemented. You can drag the shape around with your finger. The holes are now being spawned on different heights. Tricky gamemode, hard because of perspective.
Iteration four: Same drag mechanic except for the fact that the x axis is locked. This eliminates the problem of iteration three, the perspective problem is gone. Fun and intuitive to play. Maybe not the hardest gamemode though.
Iteration five: Drag and drop, no locked axisses and rotation (without accelerometer). Very hard on mobile. But also very fun on pc (but that’s not the target platform.)
During our feedback we got the feedback that we should have iterated more on our idea. Changing certain aspects of the idea. Iterating with how to use shapes, and so on.
I’ve prototyped some of the ideas this week. In order to proceed to prototyping we first had to find a good solution to a very relevant problem. We needed a good way to detect what shape the player draws on the screen.
So we needed something to easily handles gestures and touch input. I’m not planning to write my own gesture recognition system so I used a unity package called TouchScript. This allows me to quickly add new custom gestures when I need it.
Then for the shape recognition I first stumbled on this library that used point cloud recognition. I searched the asset store and found PDollar Point-Cloud Recognizer
This has helped us a lot for implementing an easy way to add shapes and recognize it.
Below you can find some gifs of different prototypes.
Stacker(most left): Here you have to draw the shape you see as fast as possible to decrease the stack. If you complete 1 stack another one pops up. Keep doing this until you get a couple of shapes wrong
Draw them out(top right): Draw out the parts of a shape you won’t need and keep the ones you want
Pattern drawing(bottom right): The idea is that you have a certain pattern on the panels. you have to draw this pattern so that the door opens and you can proceed to the next door.
This idea is not implemented yet.
Programmed basic interface and gameplay
We’ve got three weeks to quickly produce a prototype so I decided to already try out our current idea and get a basic prototype up and running. I’ve already created the basic layout in Unity. Deciding if the idea we have is still interesting enough to use as a concept. Here is a list of things that I did.
- Rotating the shape can be done with the accelerometer of your device or with the left and right arrow key
- Changing the current shape can be done by pressing the buttons on the screen
- Colliding with an object pauses the whole object queue
- Pressing R will reset the game
Creating this first iteration has already made some problems clear to me.
Currently the player has no idea what the next obstacle will be. The player should be able to anticipate or already think about how to move the phone to get to the next position as fast as possible. This is currently impossible.
The collisions now are super sensitive. If you collide with the collider of an obstacle, even with a very small part it will trigger the stop and you will have to restart. I’m not sure if we want to keep a system like this or make something that will also allow an approximation of the position with a small error margin.