Unit progression is one of the biggest reasons players keep coming back to games. Although the progression has broadened more into aesthetics, weapons, and weapon upgrades as opposed to just the standard RPG elements, it's still a fundamental base for many, many games today. This blog post is about my implementation of my unit progression system in the game I'm developing called ROBA (An RTT Game). If you haven't been keeping up, here are some articles for you to catch up with.
When I initially set out to create ROBA, unit progression wasn't really in the scope. But what was in the scope was a cooperative survival mode. I guess what I didn't consider when I stored the coop survival aspect in my brain years ago, was that unit progression is intensely tied to cooperative survival games. ROBA will be no different.
I discussed the cooperative survival aspects I planned on implementing in the coop survival blog. This blog is essentially a follow-up on that and specifically how I'm constantly wrong with what I think is going to be difficult. I absolutely thought programming some sort of simple AI for units to attack and move around would be difficult. While that did give me some setbacks, the unit progression aspect of the game was far more difficult. Typically this is because of having to create dynamic modular systems for this to scale properly. Not just for one singular unit, but possibly for several other units.
Some of the issues I had during this development are replication, data tables, and the progression method such as a kiosk or per round.
Multiplayer Complexity: Replication
Replication is simply the multiplayer aspect of a game. You replicate where units are to clients, certain variables you want the client to know about (health for example). Every single thing has to be replicated properly to the clients. There's also the issue of if something is spawned. Is it controlled by the client or is it controlled by the server? What actions does the client have power to or authority over if any? If the client does have authority then obviously you'll have to apply checks via the server for every action. When it comes to the co-op survival aspect of this, I had pretty much laid all of the foundational work on the parental unit, but there was a considerable amount of work to be done in the UI section.
If you see the screenshot below, you'll see a very quickly made kiosk UI. We'll consider it the first draft, my UI skills have never been too great anyways. If you didn't catch up on the previous blog post, I had planned on implementing a kiosk you can purchase upgrades at. There's several issues going on with that. A lot of the unit skills are actually handled in the AI controller and clients never have access to the AI controller. Which means every action and every time you change this it has to be replicated to the client. So essentially, you're handling the data from the kiosk to the UI to the player controller to the actual unit being upgraded and then the AI controller of that unit. Once those changes have been made, that information has to be replicated back to the client. It makes things considerably more difficult and time consuming when trying to implement this unit progression. The information that's handled is discussed in the next section, Data Tables.
Unreal Engine 5 Data Tables: A Learning Curve
I have a background in database management and web application development. So when it comes to data tables it wasn't foreign to me. But I must say using data tables with unreal engine 5 was rather peculiar. I guess a popular method is actually creating your own csv's outside of Unreal engine and then importing them into the engine. That's fine and usually how excel sheets work, constantly copying and importing but what makes it strange is Data Tables have to use structures for their column and row placement. Finding the data(columns) was really the issue. For instance, it seems that you can only target the row name as opposed to finding rows with its columns. So from what I experienced, you can't particularly find a column with this one data set. You had to find the row associated with that name of the row and then pull the columns out from that. It took some getting used to. Also data tables seem to only be completely reliant on blueprint structures, now there's three different mediums that you have to deal with. Trying to implement all this was a new experience for me, and I'm not very fond of it but I did get through it. I managed to build the system with data for each upgrade associated with the unit. We'll see what it turns into in the future. The Data Tables only handle the costs of each upgrade or item but they don't manage actual progression stats of each unit, that's an entirely different structure. So after replication and the information now is time to handle the medium in which the unit upgrades.
How Players Earn and Spend Upgrades
The current setup I have is round-based economy progression utilizing a store. Essentially, for each unit you kill you get several credits or the amount of credits the unit is worth. At the end of a round a kiosk will appear somewhere on the map. If you make it to this kiosk then you have 30 seconds to purchase items or character upgrades. You're also awarded credits at the end of each round. There's plenty of other ways to do this, one being after each kill. You just receive experience which upgrades your unit. This didn't seem to fit the mold of ROBA so I shied away from it. At the end of each round, your credits can purchase different items such as grenades or RPGs and you can also purchase unit upgrades. These unit upgrades include shot cooldown, movement speed, special ability cool down (as well as others). More upgrades and items will be coming in the future. I also hope to expand to being able to purchase different weapons and maybe turn this into a class-based system where you can invest points into certain aspects that would consider you to be of a different class. So kind of like a tank or maybe someone who can hold more healing grenades or something like that. Time will tell and I'm a firm believer in relentless testing which is where most of my ideas come from. So if you're interested in play testing this game please go sign up!
Wrapping Up
In conclusion, these three features complicated the implementation of my cooperative survival progression system. Those being replication data tables and progression type. Easily the most difficult thing is creating the foundations for each of these knowing that these have to be modular. I also take into consideration the possibility of modding where people will have to look at this code and use it. It exacerbates the difficulty of the situation and features being implemented. Thanks for reading. If you're interested in receiving updates, please visit the follow section where I post videos and updates on social media platforms.