Posted March 24, 2021 by Judith
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!
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.
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.
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.
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.