DEV – Tweaking and Difficulty adjustments

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.


DEV – Critical fixes

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.

DEV – implementing the feedback

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…

DEV – angle based collisions & inheritance

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”. ObstacleInheritance.jpg

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.

DEV – Testing out ideas

Prototyping phase

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.



After the first feedback session we headed back to the drawingboard. Literally.

We each thought of 5 new prototype idea around our main game. We each drew them out on a whiteboard and presented them to our teammates. Afterwards we selected the best ideas, those ideas are headed into prototyping.

Below are all the different prototypes we came up with, the ones with a red cross, are headed to the prototype fase.brainstorm