My goal was to create a game that would challenge my technical abilities, this resulted in three systems, the core system being spherical gravity. The core game loop consisting of destroying objects in order to grow bigger and destroy greater objects. Eventually becoming a destroyer of planets.  The three required systems were;

* Custom gravity

* Size comparisson

* Scaling of player size

Most importantly, these systems needed to collaborate.


*Made in Unreal Engine 4.21

*Created in 6 weeks halftime

*Singleplayer casual game

*Assets created in Maya

*Music made in Studio One


I took inspiration from two existing games, Super Mario Galaxy and Katamari Damacy. The inspiration from Mario was their custom gravity on smaller planets and asteroids. As of Katamari I took their core loop where the player rolls up objects onto their ball to grow bigger and bigger. This because these games alone have their own sophisticade systems. Creating a mix of them seemed like it could result in interesting challenges, but most important a fun game to play and debug.

Mission Statement:

I wanted to create a casual undemanding game to play, where the games movement could allow support for several different platforms such as console, PC and mobile/tablet. The core loop needed to be as satisfying as possible and what is more satisfying than destroying things.

Custom Gravity:

The gravity in itself was solved with a simple trace from the player to the center of the planet then adding a constant force in that direction aswell as rotating the character to the hit face normal. This seemed like the most straight forward solution. The functionality of scaling gravity depending on the planets size was also implemented since without that the world seemed illogical.



The next challenge was the functionality of traveling between planets. This resulted in every planet having it's own "Atmosphere" to change the previous planet reference to the current one. To make sure that the player did not just fly past the planets I had the atmosphere trigger a short lerp to decrease the current speed to a more resonable one. Around this point in was when I realized that every object needs to know which planet it belong to, to make sure all are destroyed with its planet.

Im already Tracer

Rotation gone wrong.

Size Comparison:

Comparing the size of the objects and the player was less of a challenge then I thought. My approach was to get the bounds of colliding actors, condense each of their respective vectors to a single float and in turn compare those.


Some variables had to be taken into account since if a mesh were to have protruding element this would skew its bounds and lead to an inaccurate representation of the world and confusion for the player.

Playing a dangerous game.

Scaling Player Size:

Scaling the player was also somewhat straight forward. The thing I had to keep in mind was that everything regarding the player had to scale with it.

This was done through a datadriven float that kept all the components relative to each other.

The growing itself had to be communicative and satisfying as possible. I tried different feedback methods, such as a snappy zoom out and different curves in the linear interpolation. In the end I settled that the scaling should be relativly smooth.

Feed me!

A sense of scale and proportion:

I was pleasently surprised by how these systems really complimented each other. The approach of having sphereical gravity really put an emphasis on size. The feeling of growing bigger never stopped to feel rewarding, since every time you grew you were one step closer to match the size of the planet itself. I would like to think that the simple aspect of having the player character also a sphere contributed alot due to their matching geometry.

Simon Carlsson - Technical Game Designer