Wellspring: Altar of Roots is a dark and plot-heavy tactical RPG that merges old-school, turn-based strategy with modern, fast-paced combat. Featuring gridless battles, roaming enemy encounters, complex character customization and a vast and open world map, Wellspring offers a fresh look at a time-honored genre.

Post news Report RSS Big Boy Demo (Part One)

A detailed list of the new features and bugs that we have corrected in preparation for our upcoming demo. Part two will itemize (pun slightly intended) the enemies, skills, locations, and items available in the demo.

Posted by on

As we move closer towards the release of our third Bevontule demo, I realized we hadn’t posted anything for about two months on the development front. The last blog post focused on the AI, but man, have we made some insane progress since all of that. I wanted to talk for a moment about all of the actual tasks that we have completed since then, so what follows is a list that touches on some of those things:

  • UI Overhauls
    1. Increased the size/font resolution of all buttons/panels/images/et cetera. Increased the quality and type of information presented by panels/buttons/skill tooltips. This is pretty important, but we could have realistically done without.

      Battle UI

    2. Added an entirely new UI element, tentatively called the main panel (compelling name, huh?) which is a blown-up version of the currently acting character’s mini panel. This main panel provides additional information, such as the number and duration or stacks of currently granted buffs and debuffs. This is a huge f’ing deal because it was a crucial piece of information that is now presented in a logical, size-efficient manner. The icons are pretty nice too, honestly (shout out to the inappropriately named game-icons.net)

      MainPanel

    3. This might be a little tricky to explain, but there are different ‘option’ panels, numbered from 0 – 3, going from left to right (options, confirm, actions, targets.) If you move the mouse to a lower number, all higher-numbered panels will collapse and disappear. This is basically like hitting Escape with the mouse (if that makes sense.) Unfortunately, clicking on say, an action, will show a higher-numbered panel. If you are a mouse-kinda person (death to ye), you might mistakenly move the mouse directly up when trying to select the next higher-numbered panel (say targets). Even though mousing over the currently-clicked button won’t do anything, mousing over another button accidentally will collapse the panel you just opened. Highly annoying. Now there is a ‘highlight’ period, but only in certain cases. You can still cancel your selection by moving the mouse over an option in the same panel but it now requires holding the pointer over a button for a short period. Only posted this because of the extreme effort in getting it to work. Also ranks like a 6 out of 10 on the BFD-o-meter (thanks joe biden)
    4. Cleaned up some panel animator states/code, added new transitions for the main panel / new effects on skill usage, et cetera. BFD says 2 out of 10.
    5. Significantly improved the battle completion panel to better show exp/AP/money gains. Also created a battle reward panel (more on that later) to show item drops, if applicable. Also shows the duration of a given battle (I imagine this’ll come into play when we get around to designing a battle-ranking system.)

      Victory Panel

    6. I guess this kinda goes under UI, but also added the ability to, in certain situations, actually click on targets directly in the battlefield instead of clicking their corresponding UI target button. This is pretty awesome, but not really necessary. Mainly added it because it popped up often as a requested feature. A blessing and a curse because it also highlights how terrible some of our capsule colliders are… but with good reason, which I’m not gonna get into. Basically, if someone tells you they made something shitty intentionally, you believe them!
    7. This is simply a cosmetic change, but we added new and improved highlighting on selectable or targeted characters. Previously, there was simply a colored (green or red tint) that surrounded the character. Now it’s a pulsating glow. It’s the little things, man!
    8. Camera tracking between acting/active targets is smoother in a lot of ways, but still needs some fine-tuning.
  • Battle Overhauls
    1. This is probably the largest change that has been implemented in the game (after a year of development), but it just makes too much sense to not do it this way. Previously, there was a move option… now there is not. What this means is that the active character can pretty much always move, or rather, it’s like the move option is always selected. This had some pretty profound implications. For starters, we couldn’t previously actually show other things while a character was moving; now battle options can be freely cycled through the entire time that the character is moving. Similarly, a character can still perform an attack/item use and move or move and use a skill, et cetera, just like before. However, since the character can now mouse over any arbitrary skill/item/action, it meant that we had to constantly compute the potential targets for every single skill, pretty much all the time (not really, but close enough.) Since we had to always compute the targets, it meant that we always had to show the area effect indicators for the currently selected skill. Since we had to do that, it meant we had to always show the highlights for ‘potentially’ selected targets. As a result of all of that, it meant we had to dynamically add/remove targets as they came into range, depending on the selected skill. Basically, it led to what I like to call a shit cascade, where you, as a developer, gets a really awesome idea, and in a rush to implement it, doesn’t fully appreciate how many things you’ll ultimately need to change to accommodate what you thought was a rather harmless change. Shit. Cascade. Overall, this is like a 37 / 10 on our scale of important stuff. It radically alters the way you play the game and makes a lot of things way, way easier, while only being slightly more complicated to the end user. It’s a good change and something that, I think, just increases that ‘wow’ factor of the battle system and all of the various innovations we’re bringing to the table. Still though, the code took a massive plunge in readability/complexity. I’m not going to lie and say that this was perfectly architected and planned out, oh hell no. Imagine that the codebase already resembled Sloth from the Goonies and that adding this change (just one change, mind you) was akin to smacking Sloth in the head with a shovel. Gonna need to definitely refactor soon…
    2. Changed the base damage formula, making it far easier to balance. We could literally talk one’s ass off (up to certain sizes of ass) about the damage formulas in this game and how we ultimately arrived at what we’re using, which unfortunately, is still not enough, but will work for now. The main problem with the previous formula is that it only really cranked up when the damage inputs were within certain ranges. IE, for starting characters with low stats, it was really difficult to cause legitimate changes with stat boosts of 1 or 2. This meant that most characters had armor that possessed similarly-valued defensive qualities, which obviously makes no sense when you think about a light tunic having as much armor as a cuirass. The new formula literally converts armor to RES, which is a base stat. Similarly, weapon damage is converted directly to STR and then added to the character’s base strength. At the end of the day, we can calculate damage using only those two stats, which is a lot more convenient. Enemies are a little trickier since they don’t have armor or weapons, but ultimately required only slight alterations. It’s not perfect and it’s by no means final, but it’s easier to work with and allowed us to, in lieu of this demo, create much more variety for battle strategies.
    3. This isn’t exactly the same as the previous point, but we were able to create an amazing battle simulation script (in Python, no less, which I’m told feels good to program in after such a long, harsh winter spent with C#.) This needed to happen, but was continuously de-prioritized as we beat the asses of some of the bigger features. Ultimately though, this means that we don’t have to twiddle our thumbs making changes in the actual game code and waiting to observe the results. Pretty big deal, I’d say. The cool thing is that this script is able to import skills/weapons/character attributes et cetera from the main game itself so that we don’t need to hard-code a bunch of junk and then worry about changing it in two places. Obviously, the damage formula code itself can’t be used directly interchangeably, but this definitely shortens the overall testing cycle and makes balancing allies, enemies and items a breeze. Would recommend.
    4. Added a bunch of new enemies, skills, AI setups, battle formations and battle drops. This will be discussed probably in the next blog post, which will focus on the actual demo content.
    5. Equipment-based attributes are properly applied to characters in battle. This is a huge deal as previously, this… uh… just didn’t happen. This basically means that equipment that provides attribute bonuses are correctly added and then removed from the character’s base attributes in battle once the battle has concluded. Likewise, attributes granted by equipment are properly displayed in the menu as well. There are still some lingering issues of multiplicative and additive attribute stacking, but again… super boring and unnecessary for the demo.

      EquipmentStats

    6. Status resistances are now properly granted by equipment (accessories) at the start of battle. This, too, is a huge deal because you can now equip an item that grants status immunities (or percentage-based resistances.), such as, say, an item that prevents a status effect like ‘Stop’ (hint, hint.)

      Capultra Stopped

    7. Fixed a very long-standing issue where the character could ‘cheat’ and continuously move along the borders of their movement radius, thus gaining a bit of extra range for attacks/skills/et cetera. Implemented much more robust clamping code to prevent this from happening.
    8. Fixed a pretty hilarious bug that resulted in the battle text progressively shrinking over the course of many, many battles. Thanks to some of our awesome testers, we were able to catch this. Essentially, text instances are reused (sort of like a circular buffer.) The default, or ‘normalized’ font size is determined by the first text object to exist in this array. There are certain effects in battle that actually shrink or grow the text (status effect text reduces the size of a particular instance, whereas combos increase the size.) Unfortunately, there is a random chance that one of these ‘grown’ or ‘shrunken’ texts could wind up as the first element of the array, thus, it would offset all other text by a small positive or negative value. The net effect of this is that randomly, (about a 50% chance), after battle, the font size would be slightly altered. Over the course of many battles, the font size was eventually reduced to a 0 (or lower) size. Ugh. Simple fix though, so that was nice.
    9. Literally fixed like a hundred (no exaggeration) or so other random issues that were not important enough to list. Seriously, the TODO section referring only to battle-related issues was over a hundred items long, assuming I even took the time to list them. Some of these tasks were very quick to fix. Others, however, like getting Apolith’s taunt to always force a particular target to attack him took almost a day to properly sort out. Others were just silly oversights, like Bodom being able to walk in the air far above the canyon.
  • General Overhauls:
    1. We finally have the beginnings of a very solid-looking minimap. We just need to generate the maps for the available areas (Atonian Canyon, Caves and Beach, along with Cephaline) within the demo and it’ll be ready for primetime.
    2. We have added many new items and ‘resource’ nodes that are scattered throughout the demo. While we haven’t fully rolled out our crafting system yet, these items are present and can be traded for various rewards, so they are not completely useless.
    3. Enemy chasing and returning behaviors are more natural, and we were able to significantly improve the robustness and customization of our waypoints system, which allows enemies (or NPCs) to perform arbitrary animations/actions during their circuits. This was kinda implemented before, but that was like 8 months ago and a lot of shit can get broken in 8 months… trust us.

      Gastornis Small

    4. Enemies can now be ‘hidden’ and will only appear on the game world once they are approached within a certain distance. Furthermore, enemies now have unique sounds associated with them when they begin to chase the player.
    5. We were able to procure some super kick-ass music from a few amazing and generous artists. Our Cephaline theme is provided by an artist known as Kalabi and the song is called “Cut Short.” Our Atonian Steppe theme was provided by a musician known as Alcyone, and is titled “Reflections.” I would highly recommend checking these guys out! And once again, I am forever grateful that they allowed us to use their jamz.

I won’t lie, there are still hundreds of things that I have omitted just because we want to actually put this demo out (of its misery) at some point. While we don’t have a solid release date yet, we imagine it will be out near the beginning of July. There are still a few important things left to do, such as providing some sort of rudimentary tutorial, and some last-minute tuning and optimizations. The best part is that most of this will literally come down to playing the game over and over… and over. Luckily, it’s pretty damn fun already so I don’t think this will be too problematic. Until next time!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: