Brick Breaker Video Game

Study on Game Engagement

Mathias Bauer and I worked on a study to identify if Lootboxes increase Game Engagement in Video Games or not. First lets clear what a Lootbox is (you can skip this part if you are familiar with this Term).

A Lootbox is a common way of monetization in Video Games espacially in mobile gaming. Lootbox contains a set of Items where you get a random Item upon pruchase. The more valueable an Item is the lesser the chance it will have to be obtained. Now you think why should i buy a Lootbox if i can obtain the desired Item by directly buying it? Simply you cant. Most Games that use Lootboxes as their Monetization give you only this way to obtain certain Items. Some Games even bind their Player progression to Lootboxes, where you can only progress by opening Lootboxes (Clash Royal for example). This is extremly popular in mobile gaming. If you now think that this sounds a bit like gambling, it is and most of the research that compares Lootboxes to Gambling suggest that Lootboxes have the same psychological effects on our brains like Gambling.

But what most research does not compare is the Game Engagement between Lootboxes and other Progression / Monetization systems. This is what our Research aimed to find out. By comparing Lootboxes to a linear progression System like an old shop, where you can buy one upgrade after another. Since Lootboxes give Items in a random Order and the linear Shop not this could change the Player Experience drasticly. So in order to compare both System with little to none intereference the Lootbox would give the Items in the same Order as the Shop would. This would mean that the Player would have the same Experience in both Version.

Since there was no Game that offered these two Systems, Mathias and I developed a simple brick breaker Video Game. The Game genre was chosen because it is a simple game concept where the amount of variables is relativly small and can be played by anyone without much knowledge about the game. In this Blog i want to go more into details on how we developed the game rather than on the study. If you are more interested on the study follow this Link to the paper.

Physics

Ok i am honest. One would think there might be more than just one Calculation needed for this type of Game. But the reality is that all you need is a simple Reflection. Luckily Unity already has a implemented Reflection function in the Vector3 Library. Which means, this snippet here handles all reflection of any ball:


void OnCollisionEnter(Collision collision)
{
		// Ball Movement
		ballDirection = Vector3.Reflect(this.transform.forward, collision.contact.normal)
		
		// Other stuff
		...
}

The Player Object is controlled by reading the X-Axis input (left - right arrow, a - d key, etc.) and modifying the value with a speed value. Now this is sufficient and seemed to be “ok” enough from the Data that we collected from users.


// Update Player Movement
void FixedUpdate()
{
		Movement
		Vector3 move = new Vector3(Input.GetAxis("Horizontal"), 0, 0);
		rigidbody.MovePosition(transform.position + move * Time.deltaTime * movementSpeed);
		currentSpeed = move * Time.deltaTime * movementSpeed;

		...
}

It would be better to implement an acceleration and use physic-based motion, but we decided that this type of movement is good enough, considered we had only 3 months to develop the game. Sometimes having a simple solution is good enough until you are done tackling major features, that have higher priority in your Project.

Power Up System

Now this is most important part since it is a core Feature for this type of game. We decided to use the observer Pattern for our Power Up System since we wanted to create multiple type of Events which can trigger different types of Power Ups. Also we wanted to decouple the event and execution of the Power Up. Unity also has the option to develop this pattern in an interesting way.

The Unity Framework provides an class called ScriptableObjects, which are different from the standard Monobehaviour. In generall ScriptableOjects are data container that can store data over multiple scenes, which means they are persistent data containers. But how can these help building the observer pattern ? ScriptableObjects can be seen as an extra abstract layer between classes that can provide data. In this case we want to store the list of observers inside our ScriptableObject and provide a Script that subscribes observers once a Gameobject is enabled and unsubscribe once the object is disabled.

Now we implement an Raise Function in our ScriptableObject and simply raise the function once the condition is met for the event. Now every observer that is subscribed inside the ScriptableObject will be notified and execute their logic. And its not only this class. We can simply create multiple ScriptableObjects inside the Editor and have multiple instances, that can be seen as seperate channels, with only writing one Class. This approach allows us to manage our Class instances inside the Editor and not in our Code. This is a convenient way of implementing the Observer Pattern!

Conclusion

Brick Breaker Games are really simple and a great start project, where you can learn suprisingly a lot about the Unity Engine and how it works. It might not be the most interesting type of game (which is indicated by their none existing popularity) but you can still learn a lot by having a simple Project, where you can decide how much effort you want to put on your features. Our game might not be the best since there is still a lot to do, improving the Shader, creating more Level archtypes, creating more Power Ups and improving the existing Observer Pattern to allow more interesting Features and so on. But it turned out to be fine enough for us as a starting project for collecting data.

We also had a good lesson on good and bad programming practices like: “i will refactor it later” (famous last words) or “no one will ever see this code”, which is true but during development it can become quite hard to debug certain Features if everything is tied together and nothing works the moment one element is missing.

I hope you had a great time reading this little dev blog and wish everyone a great day/night/morning or afternoon.