Ploxmons DevLog #5
- The Ability System
Hello guys, as in the previous weeks I want to share with you the progress that was made during the last days.
Last week I was finally able to finish implementing all current boss, monster and ploxpower abilities. This has been in my head for a very long time and after finishing them there was alot of relief for sure. This task took a lot of time and basically the mayor part of the week.
From left to right: Boss monster, Ploxpower, Monstercard. Each of these units can have abilities.
Expecially complex was the task of implementing the ploxpower abilities since the ploxpowers differ alot from the monster and boss abilities. Reminder: Ploxpowers are powers that enchant your whole deck. For example "Stone Body" gives your monsters Armor.
In the past the ability system was divided into three separate systems: The monster abilities, the boss abilities and the ploxpwer abilities. Separating was the first idea that came into my mind back then since each ability type has different attributes. Expecially ploxpowers are really different since their abilities usually affect other monsters or even the boss on the field and not only theirself unlike monster abilities that were orginially only able to affect the monster that is triggering the ability. Separating sounds like a good idea right. Well the problem with that is that there are abilities that might occur as a monster ability, a boss ability and even as a ploxpower ability like the simple boosting ability (Boost your mon, Boost the boss, Boost your team, etc..). This results in duplicated code since I was forced to implement the same ability three times - for monsters, for bosses and for ploxpowers - which is of course really bad.
After fusing the monster and boss abilities together a few weeks ago I finally decided in the last week to also fuse the ploxpower abilities into one big ability system. This is a very flexible solution since we are now able to assign every ability that is implemented either to monsters, to bosses or even to ploxpowers. However flexibility has its price: complexity. Since I don't want to implement an own ability for each monster (80!) or boss/ploxpower there are some parameters to configure the ability that was assigned.
To allow maximal flexibility there must be alot of parameters for configuration.
Example: The stat boosting ability-> Which targets should be hit, which amount should be boosted (power+1? speed + 1?), should the boost be temporary or permanent, under which conditions should the boost happen, etc...
The more flexibility we want the more parameters are required. By fusing the ploxpowers into this ability system the complexity and amount of parameters reached another level for sure. Internally there is a big evil excel table that defines the abilities for each monster/boss/ploxpower. The abilities are definied by a sequence of numbers and symbols that define which ability ID is assigned with which parameters. In the past this sequences were kind of readable and clear.
Example 1: The monster "Levitron" has the ability Armor 2 that blocks 2 damage on hit. This ability is defined by the sequence: 6,19,2. 6 is the ID of the armor ability. 19 is the ID of the trigger when the ability should trigger in this case: when the mon takes damage. 2 is the parameter that defines the amount of damage that is blocked - in this case 2. Easy right? Fair enough this one is an easy one since there are no further conditions or targets except the monster that triggered the ability. However after fusing all ability systems together a lot of new parameters has been introduced. Many of them optional but still a ton of configuration material.
Example 2: The ploxpower "Green Thumb" increases the value of your healing and regeneration abilities by 2 (sweeet). This ability is defined by the good readable and clear sequence: 16,16,5_0_26_0&9_0_2_1_26:27:2:1:2:26#16,16,5_0_26_0&9_0_20_1_26:27:20:1:2:26. I will skip explaining every parameter in detail right now .. for reasons.
Three points to notice:
1) This sequences are written by hand. One does really easily lose track of which parameter means what. Basically instant brain damage .
2) The readability is kind of bad like really bad. Expecially when abilities should be adjusted one has to think through the whole ability and its parameters again to be able to adjust the parameter one is looking for (This is not the parameter you are looking for). Again: brain damage.
3) This sequences are parsed in the code and translated into the correct abilities, trigger, conditions and parameters. Code is complex as hell as you can imagin to support all of those different parameters. Also basically instant brain damage!
Overall even though this sequences are complex as hell they offer a really flexible way of defining abilities for monsters without the need for me to adjust something in code. A ton of parameters and conditions and triggers allow for a wide variety of abilities. If we had a bigger team or more time I would create an web-tool to visually configure the abilities. However since this takes a lot of time that I don't have we have to live with defining abilities by hand.
After implementing all missing abilities we are now in the testing phase of the ability system. There are already a ton of bugs that I need to fix. One can imagin that the more flexible the abilities get the more potential for bugs is created since there are a lot of interactions that can be weird or wrong configured parameters or just bugs in the code .. However a lot of bugs were already fixed and the amount of problems are getting less and less
UI for Invites
Yesterday I started implementing most of the missing parts of the UI: The window that allows you to invite friends to a game, a list of all game invites you received and an option to send new friend requests. Progress has been good so far. However still a lot to do since UI is always time expensive to implement.
Most of the day however was spent implementing the friend-game-invite-system on the server. This was also a really complex task since there are a lot of special cases that should be handled. Also client-server interaction is always really annoying since for each command that is sent from client to server the server has to response if this command was valid. Meanwhile the client has to wait for response of the server and react depending on the response. This means that there are alot of exchanges of commands and signals that has to be implemented. For a simple game invite there are for example 6 client-server-exchanges required each with an own command and code that handles each command. Stuff is getting complex really fast. However I was able to finish this implementation and need to finish the UI now to be able to test it(Bearbeitet)
By finishing the ability system a huge step in the direction of early access has been made. There are many bugs left to detect for sure however small bugs are pretty usual for early access versions so I am not very worried that we won't be able to find all bugs in time. After the UI I am working on is finished there are really less UI tasks left until we can release the game. Almost all important menus have been implemented already. Still pending: Configuration of the server droprates, ..., small tweaks of the UI and animations. Also there are a good amount of shaders left to create. However this has really little priority and won't prevent us from releasing the version. Overall a lot of progress has been made. There is actually not thaat mutch left to do until we can release the early access version. It will still take like 1-2 weeks approximately until we reach a point where we can release it in good conscience. However its getting closer and closer Thanks for your motivating support in the last weeks. We are glad to have you with us Thats it from me for this week.
EARLY PLAYTESTING available soon!
Our Discord members have the chance to PLAYTEST an early game version soon!
So join us on our Discord now! :)
We also have fun mini games there with our very own "PloxBot"!