WE HAVE ARRIVED. At the end of the first production sprint, that is. A lot has changed, even though not everything is visible already. You will notice that there are bombs again, and that the enemies won’t straight up ignore the research camp anymore. Better even, if you leave them be, they will stop the research that gives you your upgrades. Oh, and you better get shooting, because waves will keep spawning now. You might get overrun if you sit still!
On top of that, some problems were solved that took quite a bit of time, although you can’t actually see them. Let’s dive straight into it!

Multi linetrace and delegates - uh, what?

In order to fix some issues and finalize our base, we needed to solve three problems: one was to send messages between multiple classes, even if these classes didn’t directly know about each other. The other was finding a way around having to call “GetActorsOfClass” too many times. This function, which is built into Unreal, would loop over all actors in a scene, which is not ideal. The last problem, which was smaller then the others but annoying nonetheless, was that due to some changes in the collision settings, our linetracing broke.

Messages between enemyManager and enemies

Because the number of enemies constantly changes with deaths and spawns, the enemyManager is mainly meant to handle the spawning and the stats of the enemies. It doesn’t keep all the enemies in an array. So how do you register when all enemies are dead?
If you are familiar with (game) programming patterns, you will have recognized the observer pattern as a possible solution in my earlier “this is the problem” explanation. In UE, you can use delegates for that purpose, but having delegates work over multiple classes turned out to be a pain. In the end, we figured that a single cast delegate worked well (many-to-one messaging), but multicast delegates (one-to-many)simply didn’t want to work in our usecase. Many hours later, the enemymanager now is a bit smarter than it was before - and we are, too.

Globals that aren’t actually global

Say there is this camp in your scene, and every enemy you spawn in needs to know the whereabouts of this camp. The planet knows the location, but not the camp itself. The enemies are freshly spawned in, they know nothing at all. The only thing that knows about the camp, is, well, the camp. Now, how do you make the enemies go to it?
At first we thought “no problem, the planet knows the location, we’ll just feed that to the enemies”. Well, that works, untill the camp changes position during the game. Then it breaks. The enemies are still on the old spot.
If you are familiar with c++, the next thing we tried was a double pointer (we had reason to use it in this case). That also failed. UE doesn’t like casting interfaces to actors when they’re double-pointered, apparently.
Now, there’s this other pattern that could fix some stuff, but lo and behold - UE doesn’t like it either. I’m talking about singletons. Becuase of the inheritance-based structure of the engine, singeltons are an aboslute pain. In the end, we have this thing that is a hybrid between a singleton and a normal actor. Not the best probably, but it works. When it starts, it searches certain things in the scene, once, and everything that needs access to these variables can ask them from this class. Easy use.

Broken tracing

After some fiddling with the physics and collision - and yeeting physics into space altogether - the linetrace that told us what tile we were on, broke. At first we wanted to use a multi linetrace, one that can get several hitrestuls. Guess what, it only got one, due to collision settings. In the end, we went back to a single linetrace and used that singleton-actor-hybrid, that was just finished at that point, to make sure we only linetraced certain stuff.

Purple horrors and lush forest

When opening the game, the first thing you will probably see is the forest biome. While the biomes aren’t doing anything yet, for us, who have been staring at boxes and triangles for too long, seeing two biomes come to life is an absolute delight. The third one is almost finished, and we are excited to put it in and show off our living planet next week.

Apart from the biomes, the characters also got some more attention.
Let’s start with the “purple horror” from the title. While it is certainly a monster, you will understand what we mean with “horror” when you see this picture: Yes, that is its yaw being pulled down that much. No, that’s not the goal here. What happened to the model, you ask? Well, Mixamo happened. Because rigging and animating takes a lot of time, we are planning on using Mixamo, a site that contains a lot of models and animations for humanoids. And the “humanoid” is a bit of a problem here. While the monster walks upright and all, its head is a nearly in front of his chest. That caused some skinning issues, and a lot of laughs while searching for animations that gave the least stretching.
Here is what we have, with the actual (non-animated) model in the foreground: For the time being, this is the only enemy we will have. Later on, extra skins and shapes will be added to have some variation and distinguish between the different biomes.

The work on the player character also started, with the modelling about done. With this, the only things left are the texturing of the player, and the riggin and animationg of both player and scientist. Then we will have at least a base for every single character that will appear in the game.

Work for the next week(s)

In the upcoming sprint, we want to get started on the quirks and skills of every biome and enemy, as well as get the player some new skills. Right now, the camp does give upgrades to the playe, but these are very basic ones like higher movement speed and more damage - things you can do purely with some numbers.
Some simple UI would also be welcome, as you still cannot see how much helath you have left.
As for the art, the ice biome should be finished very soon, and work on the player and scientist will continue. The enemy can start being integrated with the code aswell, and some basic animation can be set up. Then some models for the research camp and smaller things like bombs are also on the table.

All in all, this sprint enabled us to lay out a very decent, working base to build all other things on with relative ease.