Hello! Nice to see you have found our little game - even though there isn’t much going on just yet. Don’t worry, in the next few weeks, this “I can walk around” project will gradually change into an actual game. Blood, sweat and tears included.

Who are we

We are second year students from Digital Arts and Entertainment, Belgium. With two programmers and three artists, we will make a game from start to finish in just 12 weeks.
The two programmers: Tom Kalders and Judith Verdonck.
The three artists: Lars Korden, María Martinez and Tatiana Devos.

The game - Idea

After brainstorming within the restriction of the genre “Arcade”, we came up with the following.
The player is dropped onto an alien planet together with a scientist. While the scientist researches this strange environment, the player will need to defend both themselves and the scientist from the planet’s inhabitants. As time goes on, the enemies will become stronger and more stubborn, but the player will get help from the scientist, giving them an upgrade whenever research has finished.
On top of that, the enemies might drop bombs, which will slowly break away the planet if not defused in time.

The game - Research (and troubleshooting)

After spending a week on brainstorming, we started doing tests in both Unreal Engine and Unity.
Or that was the plan. Due to trouble we have had with Perforce (which we use for source control) and Unreal crashing time and time again for groupmembers, we run a little behind at the time of writing this.
We did, however, manage to do the most important testing.

A planet… What about gravity?!

Engines have gravity implented as an acceleration that always points down. Well, we have a planet. One that almost fits on a screen (well, it’s a little bit bigger, but you get the point). Gravity can’t just point down: it needs to point to the planet’s center.
The first task was looking into any components or options that would allow us to change the way gravity works - after all, especially Unreal has a lot of components that can do quite nice things, so it was worth looking into. However, nothing like this seems to exist, so we went on to the next step: making our own gravity.

A planet… Manual gravity vs existing physics

As gravity is, in essence, nothing more then an acceleration towards a certain point, we only needed to do some relatively simple calculations to make our player fall “down” to the planet center.
In Unreal, this gave some problems with collision - there seemed (and still seems) to be no way to get collision working without breaking either the gravity (aka getting stuck at the planet center or getting yeeted into space) or the collision (decent gravity, but falling through the planet). Maybe we simply haven’t found the right combination of options yet, and we will certainly look into that further, but right now we managed to solve it with a simple linetrace.
In Unity, collision worked fine with gravity, yet there moving the player becomes a hassle, and the gravity causes jitter. There probably is a way around this, but we didn’t get to look into that yet.

A planet… Staying upright

When moving around, you of course want your player to stay with their feet on the ground. In both engines, this was done fairly easily with some vector math - and it works for both a perfect sphere and a tiled planet.

A planet… existing out of tiles

This is one of the things we didn’t quite get to test fully, due to the slow start we had with Perforce and Unreal. As we want our planet to be destructible, we wanted to use tiles for that. However, making a sphere out of flat shapes doesn’t give you that many options: either you make it fully out of triangles, or you go for mostly hexagons with some penta’s inbetween. Right now, we have one prototype with the hexagon tiles, and a triangle one is coming up very soon, but the main thing we still need to really look into is how easy we can place something on top of the tiles. Read: biomes like forest, sea, ice etc.
Tiled planet, made in Unity

Modular pieces of code in the engines

Mostly already known, but still tested out to be sure: how easy is it to have modular pieces of functionality in either engine? How does it work exactly?
In Unity, you just write a script that contains that functionality, adding it to prefabs.
Unreal uses the component system, where you write your custom component and add that to your c++ class.
The basic idea is the same in both engines, only the workflow changes a little, which was quickly figured out.

Hold on - C++ in Unreal?

The two programmers have never worked with c++ in Unreal before, so one of the things we certainly wanted to know, is how feasible it was for them to learn c++ in UE in just, say, two weeks time. After a lot of crashes and trouble with perforce (and figuring out not everything was automatically added and submitted to perforce, which caused part of the crashes), it turned out to be fine, as they do have experience with blueprinting, and a lot of the nodes in blueprinting have c++ counterparts. Knowing blueprints turned out to be really beneficial here, even if they aren’t allowed to use it for the greater part.

Conclusion

Our main goal with this research was to figure out how easily we would get a spherical playground to work. In the end, it seems to give the programmers some extra manual calculations to do, but nothing extreme or complex. We still want to go further into the “hexagon or triangle” question, and try to fix things like the jitter before actually choosing the engine we will use for the rest of the development.
Fixing the last rather large issues with Perforce and UE are also on the table, as our artists are unable to acces the project. At the moment, this hasn’t been a lot of trouble yet, as they have mostly spend their time on making an Art Bible, but this will of course become a source of trouble if not solved quickly.