Jump to content
  • Advertisement

Yyanthire Studio

  • Content Count

  • Joined

  • Last visited

Community Reputation

13 Neutral

About Yyanthire Studio

  • Rank

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yyanthire Studio


    Moonrise is an open-world real-time strategy game. Explore a vast land rich with demonic creatures. Establish a base, and venture forth to eliminate the powerful beings that have overtaken it. As you venture, you will come across great artifacts to bolster your warriors, and great resources to enhance your fortifications. In this land, the will of the leaders is absolute. One false step, and all of your creation will fall under. Intricate care is necessary for your warriors to survive to the next battle. The creatures of this world are powerful- are you able to stand up to them? Explore- Explore a world rich with conflict, where there’s always a new challenge to endure. And reap the rewards of such ventures. The lands are wide and vast, and the journey will be perilous. Do not get lost- always know your way back home. Gather Resources- All of this world has something to offer- whether it be the nature around, or from the souls of defeated enemies. Use those resources to build your base and your army, and wage war against the vast enemies of this land. As you explore more, you will find powerful foes- slay them, and grow your warriors even stronger with the mystical objects they have to offer. Build an Army- Build up your home base not only to act as a fortitude against the enemy onslaught, but also to enact key, pivotal research points. Whether you wish to give your warriors greater health and mana, or advance them down further into their class, building your base is the only true way to get the advancements necessary for engaging more powerful foes. Research- Whether you choose to spend your hard-earned, limited resources on empowering all warriors, or just a select few, researching various upgrades for your army will allow you to further craft and define the complexities of your army to a solid degree. And those who wish to venture even further will find themselves that much more fruitfully rewarded. Wage War- At the heart of Moonrise is waging war against the multitudes of foes of the land. Foes will wildly vary in volatility, and it is up to you to command your warriors in such a way to slay them without becoming slain yourself. Never stop moving- movement is key to avoiding attacks from enemies while still striking at them yourself. You can avoid enemy attacks by simply moving out of the way before the attack lands. By using clever tactics, you can survive many adversaries and come out unscathed and ready for the next fight. Invoke powerful spells to your advantage- there are many different beings at your disposal. Making use of their talents is the only way to come out successful, and to defeat even the strongest of enemies. In Moonrise, there are dozens of spells, each with wildly different uses, able to be enacted and used as how you see fit to command. State of the Game- This project is very deep into its development cycle now. There is a considerable amount of work that has been done to make the game playable, and as the game sits, it is currently in an Alpha state. There is still more work to be done- we have yet to finalize key features like a saving system, and have yet to get further into our desired open world elements. In addition, while we do have a lot of art done for the project, there is still some remaining, and we have a lot of animations we still need to create. Music and sound effects are the same story. But, as of right now, the game definitely plays like how we envisioned it- lots of tactical complexion backed up with a lot of intricate micro requiring you to not only think intelligently about what you are engaging, but also act swiftly before your units get overwhelmed and killed. Our current goal in regards to the project is to be able to release a playable game by 2020, or sooner if plausible. We may also consider releasing a Beta version of the game for many to play and test, given enough people are interested, but even with that there will be some time before we reach that point. Given the game’s current state, we believe that it would be beneficial to begin to show off the game to you all, the community. Let us know what you think of the project, just by simply typing a comment below. We’ll be happy to answer any questions regarding Moonrise. Thank you for viewing our page! Check us out on IndieDB: https://www.indiedb.com/games/moonrise
  2. Welcome to our twenty-sixth blog post! In this post, we’ll be discussing the Drake, a creature skilled in ambushing, whom requires one to focus greatly, in order to be adequately prepared for when it does strike. Hunting it is large part of the battle- it does not always simply charge, attack, escape. Its much more crafty. It waits for the moment to strike. Which can come at any time- during a fight, or simply standing at the ready. The mechanics based around this fight is that we desired a boss which would strike somewhat randomly, while one is exploring the land. It can either be relentless, attacking repeatedly and predictably, or escape for a while, not to strike again until it has been discovered. Discovery is not predictable- its long vision ensures it will come at random times, at a random angle. Sometimes, it can’t even be found at all, and you’ll have to search for it. As we begin to expand our Research system, we imagine this boss will be more on the optional side, yielding good rewards should you choose to chase after it. The Drake’s movement is quick and forceful, aiding its ability to escape. While out of view, it becomes invisible, and hard to detect easily. As such, utilizing the land around, and your array of warriors to surround this creature is the best and most fundamental strategy for defeating it. It relies on continuing its momentum to break through a wall of units, but a strong surround can end that. An even greater method of keeping it at bay is to freeze it in place. The Apprentices of Water plays a key role here: its Water Bolt spell roots a hit foe to their location for a few moments, stopping it completely. This can play a great role in surrounding, and keeping it from escaping. The Drake’s main method of escape is its teleport- a long cooldown spell, but with great range. This allows it to rapidly escape from any unfavorable engagement, to return again later for a more favorable one. It can even outright vanish with this, to somewhere far away outside of its normal aggro radius, forcing player to hunt it further. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  3. Welcome to our twenty-fifth blog post! In the earlier stages of development, we predominantly just utilized some open assets to handle our “dev-art”. But as of very recently, we’ve finally been able to get the last bit of it in replacement for much more official artwork. This is in regards to both our Icons, and our Spellbook. So, without much further ado, let’s just jump right into some new images. We hope you enjoy! If you’re brand new, consider checking out our trailer and overall description of the game here.
  4. Welcome to our twenty-fourth blog post! In the last blog post, we went over our latest boss fight, the Souls of the Lesser Dragons. This fight has proven to be a significantly more difficult challenge than prior- totaling multiple hours of attempts, this boss has greatly heightened our sense of understanding when it comes to the mechanics of this game. You may have noticed in the previous blog’s video- we didn’t actually slay the boss. Yes, the boss proved too much a challenge, even for us. However, we know the fight is plausible. You can slay these bosses with the tools given to you. And the video above proves it. The intricacies of this fight are quite spectacular, and harp back to one of our core design principles: the difficulty of a fight such as this should stay consistent throughout the fight. In this project, our goal is to have more bosses similar to this. That is, instead of fighting just one lone beast (which can be a good boss design, but not our core boss design), we want the player to essentially be clashing their army against the enemy’s. One critical element to that is, that, as the opponent’s army begins to fade away… does the challenge snowball in the Player’s favor? Or must the Player continue to fight and fight and fight all the way through? Our desire is the latter- you must be prepared for a challenge, a challenge that lasts until the last foe falls. Preferably, increasing with difficulty. In this particular fight, we’ve truly proven to at least ourselves that this is the case. Each stage of the fight is equally as intricate and dynamic as the last, an equivalent challenge all around. So let’s go into each phase, and what makes them so special. The Soul of the Lesser Dragon of Lightning is simple, but the timing is fairly precise. What you’re after is to Fear away the other two dragons at the same time so that you can quickly burst down the SotL Lightning Dragon. Timing is key- you cannot deal with more than just the SotL Lightning Dragon at a given moment, and you only have a short window, but with Mystic Energy, you’ll have enough time to kill it before the Fear status ailments end, and the SotL Flame and Frost are back upon you. The SotL Lightning Dragon’s health regeneration means you’ll need to not delay too long, else it will return to full HP. So you can’t have your focus averted- you’ll need all your warriors locked onto the SotL Lightning Dragon, not on dodging the spells of the other two assailants. Initially, the most devastating dragon is the SotL Lightning Dragon. This is primarily due to the fact that it invokes repeating damage, given how fast its spell can be cast, and the fact that it essentially can’t be dodged. It will quickly cut the health of our warriors, so that is why we must defeat it first. There are two spells crucial to this next part of the fight. The Soul of the Lesser Dragon of Flame has some timings that are fairly critical to hit, else it just becomes a boss that kills off all your warriors without you even able to do a thing. The first revolves around our core spell, Fear. Fearing the SotL Frost Dragon is inherently the best move- we don’t want to deal with its frost freezing us in place; the stun of the SotL Flame Dragon is bad enough already. With a quick Fear, the SotL Frost Dragon is out of the fight, and we can focus on step 2. In this next part, we need to ensure our Apprentice of Nature is primed. While keeping the SotL Flame Dragon from moving around too much, we need the Apprentice of Nature to invoke its primary status ailment: Spell Deprivation. This fully prevents the target from casting any spells for a short moment. Which is key for the fight: the SotL Flame Dragon has some devastating spells, but it is worthless while unable to attack. Controlling the SotL Flame Dragon from moving around too much is very important- we need to minimize our movement so that when the Apprentice of Nature’s spell is cast, it actually hits the target and invokes the ailment. Now, with all steps in place, we can begin our engagement. In this, we repeatedly cast our Mystic Energy upon the Dragon. When the Fear and Spell Deprivation wear off, we retreat, and when they are ready again, we re-cast, and repeat. Timing is critical here. Given that the SotL Flame Dragon has no health regeneration, and the fact that its only way of regenerating health is if we accidentally hit the SotL Frost Dragon, we must carefully take our time here and pick the best shots. In this stage, bursting the Dragon down like we did the SotL Lightning Dragon will have negative effects- this being that our mana is very, very important right now. We do not want to be missing our shots, so timing our spellcasts so that they hit the Dragon while its not moving is of critical importance. Else, we’ll run out of mana mid-fight with the SotL Frost Dragon and end up dying as a result. With the other two Dragons defeated, we have but one task remaining. But this will be no easy task. While you may think that, since the other Dragons are dead, that the fight is ours for the taking. But that is not the case- the SotL Frost Dragon will not go down without a fight. The primary concern with the SotL Frost Dragon is in regards to its health regeneration- its base regen is already excellent, but its healing spell is truly terrifying. We’ll need to be quick, to be able to strike it before it can cast it again. We only have less than a minute to pull this off. With this fight, we can re-use strategies of prior. That is mainly revolving around spreading out our warriors so that the damage spread is minimized, and keeping our spellcasts up. The SotL Frost Dragon likes to move around, way more than the SotL Flame Dragon due to the fact that the Frost’s spells are closer range (and thus it must move to get within range to cast its spell). So surrounding is the best strategy- our spells are not quick enough to catch up to the speed of the Frost. But if we surround it, it will not move nearly as much (since it will already be in range). We quite enjoyed this boss fight, and the numerous amount of attempts required just to defeat it. Its a fairly hard boss, but it taught us quite a bit about the game’s mechanics, and we hope to develop more, similar, harder bosses in the future! Hopefully bringing out even more of the “army versus army” feel that we currently have going on this one. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  5. Welcome to our twenty-third blog post! In our last post, we went over our Lesser Dragon of Frost, and with that done, we’ve completed our Lesser Dragons. The Lesser Dragons are intended as miniboss fights, preliminary to their greater forms. As a final test, we think conjoining our 3 Lesser Dragons, which we’ll be referring to as the Souls of the Lesser Dragons, would suffice for showing the Player how we wish to advance this game’s boss fights, alongside giving an even more interesting and difficult challenge. While we don’t know at this time exactly where the Souls of the Lesser Dragons fight will go, we imagine either before the greater Dragons, or before the Dragon’s Master, the Hydra. That’s their currently determined place in regards to ‘difficulty’ (Hydra being the highest level of difficulty for the game’s Beta stage). This is the fight that has come as a result. This is the Souls of the Lesser Dragons boss fight. --- First, we need to discuss some balance adjustments. Because they are definitely needed. Given that the Player has yet to acquire the resources necessary for advancing their Units into their final tier, they are stuck with Apprentices, a Tier 3 Unit. Apprentices are designed to have minimal spells to cast in order to give Player full opportunity to micro their Units, and are balanced around such a philosophy. This fight is almost no different, except it will demand a few extra spellcasts from player, given that it is intending to be a transitional boss. For balance, we first started by halving the health of all the Dragons, alongside halving their resistances. This is very important because mana is limited among Apprentices, alongside damage output. In the single fights, one’s mana pool can be fully expunged into the target. But here, it must be split among the three. On top of that, health regeneration on the Dragons have been severely limited. While some health regeneration is okay, we predominantly want to emphasize the role of the healer, especially in multi-boss fights such as this. As a result, the Souls of the Lesser Dragons of Lightning and Frost have had their health regeneration substantially cut, and the Soul of the Lesser Dragon of Flame has had its health regeneration redacted. Why? Well, we’ll need to go dragon by dragon. The Soul of the Lesser Dragon of Lightning is now incredibly frail and weak given its halved HP. However, its health regeneration is still too powerful, even in this current state. Dodging the spells of the other two Dragons is complicated enough, and having to do that while simultaneously bursting down the SotL Lightning Dragon can sometimes be outright unfair. Therefore, it deserves some health regeneration, to keep you on your toes, but not a lot, so its still reasonably defeat-able. The Soul of the Lesser Dragon of Flame is a different story. It references back to what we said previously- the role of the healer. All damage done to the SotL Flame Dragon, given its nonexistent health regeneration, can be considered ‘permanent’ for the duration of the fight. That is, of course, if the healer doesn’t step in. That’s where the Soul of the Lesser Dragon of Frost comes into play. In the previous blog post, you may have recalled the SotL Frost Dragon’s “Rain of Frost” spell. This heals itself, anything nearby, AND summons Frost Arkoyles for everything touched by the healing. In the original fight against the Lesser Dragon of Frost, the mechanic was oriented around dodging its healing spell to avoid it summoning too many Frost Arkoyles. Well, in this version, that mechanic has been postponed. Because the real part we care about is its ability to heal those nearby for quite a bit of health. And this mechanic is ONLY triggered if and only if the SotL Frost Dragon is damaged. Meaning, if said Dragon is hurt, it will attempt to cast its healing spell (the spell has a 60 second cooldown, which is very short given the complexity of this fight and how long it can go on, and works out to about 2.5 hp regen/s). Which in turn means that if you refrain from attacking the SotL Frost Dragon, you can keep it from healing both itself AND the Soul of the Lesser Dragon of Flame (+SotL Lightning Dragon, if its still alive), making it so ‘permanently’ damaging the SotL Flame Dragon is tied directly to damaging the SotL Frost Dragon. This, in turn, means that there is the role of a ‘dedicated’ healer into this fight alongside emphasizing that Player should enact a clever use of mechanics in order to reduce the difficulty of the fight. If Player recalls how the original Lesser Dragon of Frost’s heal works, they’ll know its something that should definitely be avoided in this fight, and that attacking either the SotL Flame or Frost Dragon solely is the better decision, but not both simultaneously. Finally, the Soul of the Lesser Dragon of Frost has minor health regeneration. Given that its the best candidate to slay last for both reasons mentioned above alongside reasons we’ll mention below, it needs some but not a lot of regeneration- its core health regen is in its healing spell itself. The mechanic for dodging its healing spell returns, so the final goal is to manage your mana pool correctly enough to still be able to kill it without it absorbing all the damage. All of these Dragons are lethal, and will kill you if you aren’t careful. But you must also ensure proper technique is in order to slay them as well. A final augmentation is to the Soul of the Lesser Dragon of Flame. Its non-Soul version contains an Aura, the Aura of Gust, which invokes powerful winds to push all your warriors back. During this state, your warriors are thrown back and also unable to attack; this made the fight fairly unforgiving, since most of the time your warriors could not even get a spell off. Given the abhorrent amount of stuns already listed between the SotL Flame and Frost Dragons, a third one (that you cannot dodge) is just outright imbalanced (especially since your Apprentices have no current way of dealing with this Aura). To make the fight feasible, we also had to change some things around in regards to enemy mechanics. Normal enemies are fully deactivated by the Fog, as discussed in the Lesser Dragon of Lightning blog post. So we utilized the code to keep the Unit from being disabled in order to make this fight function. We also boosted the Sight of the Dragons, to always keep them aggro’d accordingly. That ends the list of balance adjustments --- Now, we can get into the fight itself. The fight is almost broken into 3 stages, respective of the 3 Dragons. The initial stage begins with the elimination of the primary threat: the Soul of the Lesser Dragon of Lightning. The SotL Lightning Dragon is the first Dragon we must slay due to the fact that its spells cannot be easily dodged. Whereas the other two Dragons have attacks you can avoid, the speed and area effect of the Dragon’s Lightning is almost unavoidable. Therefore, the best strategy you can enact is to burst down the Dragon before it has the opportunity to deal too much damage to you. Next, we have the SotL Dragons of Flame and Frost. As we discussed previously, your best strategy is to defeat the Flame first. Its attacks are the most devastating, its stun has the widest area, but it lacks any form of healing itself. Taking advantage of the fact that the SotL Frost Dragon cannot use its healing spell without first being injured, we can defeat the SotL Flame Dragon without worry of regeneration, and this can be done at a slow enough pace in which we can successfully dodge the majority of incoming spells. For, if there is no health regeneration taking place, we can take our time and pick our shots carefully to avoid as much damage as possible, alongside stalling for a bit of extra mana regeneration before the last phase of the fight ensues. Its of critical importance that we carefully aim all our shots accordingly, as to minimize mana waste. Finally, the SotL Frost Dragon. Since its by itself, we can fight it like an easier version of the original beast. And, given that its resistances have been greatly reduced, we can burst it down with powerful mysticism. Two key spells are utilized throughout this fight- The first is Fear, a spell which forces the hit target to flee for a few moments. This is important for zoning, because while dealing with the initial threat, we want to try to avoid confrontation from the others. Its of critical importance to not lose your Apprentice of Sound, for zoning via Fear is one of the few tools you have to protect yourself from the onslaught of the collective Dragons. The second is Mystic Energy- our main damage dealer. These Dragons are very, very powerful, and can kill us almost instantly. A quick stun from the Frost or Flame can be followed up with all 3 Dragon’s powerful attacks combined, an attack none of our warriors can survive from. Bursting them down with Mystic Energy is the key to slaying them quickly, before too many attacks can come at once. Especially since Fear only lasts but a few moments before the Dragon is back in the fight. Given their halved resistances, they no longer have the high Mystic Resistance as their originals did. Therefore, Mystic Energy is the best tool for this particular fight. --- Now, we have yet to address the video. As, if you watched the whole thing through, you’d realize we didn’t quite defeat the boss. Not yet. After hours of attempts, the video shows our progress towards actually defeating the boss, and being able to label it completable. As of right now, we have yet to fully prove that. When we first started fighting this boss, we thought it was impossible to even slay the SotL Lightning Dragon, and that the boss as a whole was in need of some great adjustments. Now, we have a full understanding of how the complexities of this fight progress, and know its possible, even though we have yet to actually pull off a successful fight. We hope in the next blog post we can delve deeper into the progress and technical skill we needed to employ just to slay this brutal boss. And we hope you look forward to it. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  6. Yyanthire Studio

    Fragment’s Moonrise | #22 The Lesser Dragon of Frost

    Thank you! We definitely will
  7. Welcome to our twenty-second blog post! In this post, we’ll go over our final Lesser Dragon. If you missed the posts about the Lesser Dragon of Flame or Lesser Dragon of Lightning, feel free to check those out via clicking their respective links. As the development of this project progressed, the difficulty, and desire to make more complicated, interesting bosses has increased. As a result, the Lesser Dragon of Frost proves to be the most powerful of the Lesser Dragon trio, alongside the hardest challenge thus far. While the fight itself is over in almost a minute, its a minute of incredible focus, where each second ticking by feels like an eon lapsing. This is due to the array of spells the Lesser Dragon of Frost has in its arsenal, and the importance of steering clear of them. Ice Blast is its core, damage-dealing spell. It strikes in an area, emphasizing the Player should have their Units spread apart at all times. In addition to dealing damage, it also invokes Mana Drain. Dealing damage is desired, but disabling a Unit from even being able to cast spells will force the Player to retreat or die helplessly. Lunar Freeze is the Dragon’s core crowd-control. It deals absolutely no damage, however, it stops all hit Units from being able to move and attack for a few moments. In this amount of time, it can easily strike with its Ice Blast. Lunar Freeze strikes in an area, is quick to cast, and has a short cooldown. Given the rate at which Ice Blast can be cast and the speed at which it can kill a Unit, steering clear of Lunar Freeze is a must before one’s army can do nothing but be helpless against their decimation. Rain of Frost is its most intriguing spell- and the one that is the most important to dodge. Its a healing spell at its core, but also a summoning spell. It works quite simply- it casts it upon itself to heal itself. However, it strikes in an area, healing everything nearby. In doing so, given the game’s code, it invokes the spell’s summon. For every Unit healed by the spell, a Frost Arkoyle is also spawned at the Unit’s location. What this results in is shown above- dozens of Frost Arkoyles appear out of thin air, ready to defend their master. With that in mind, dodging this spell now becomes incredibly important. Moving just out of range allows it to properly cast Rain of Frost while simultaneously having none of its effects take place. This does mean that the Dragon heals itself, doesn’t heal us, and summons a single Frost Arkoyle, but that is negligible. The amount of foes that would have been summoned is far more difficult to deal with. Lastly, its final spell to worry about is not a spell but an aura- the Aura of the Bitter Cold. It slows all our Warriors near, and begins to damage them over time. This means that low-health Units need to be healed quickly before they are slain via the Aura. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  8. Welcome to our twenty-first blog post! We’ve been working on some new boss mechanics and features, one of which includes a boss who can spellcast at great distances. This gets a bit tricky given how our Fog of War system functions- since we have such huge Maps, we need a method of handling lots and lots of Units. In Fragment’s Moonrise, our Unit AI and all our various features necessary for the Unit to function are quite complicated. There are tons of lines of code that need to run per each Unit to handle all the various features on each Unit, and these need to run each frame. As such, as part of our Fog of War system, Units that are in Fog are not only hidden, but fully disabled. This is important because we definitely do not want to run so many Units at once, we only want to run them when Player engages with them. This is coupled with the fact that there are features we still want to run on Units while their disabled, like HP Regeneration, so we utilize Time to ensure that as they are disabled, when they are re-enabled, those features run for the X amount of Time they were disabled for. This gives them the ‘sense’ that they were never truly disabled, without having to utilize the CPU. Given that Units are only enabled if they are out of Fog, we need a way around this. Fortunately, the fix is incredibly simple: on desired Units (the Lesser Dragon of Lightning) have them completely ignore the fog. This means they are always enabled, which might sound bad on the CPU, but given that its only very specific and rare Units, its quite fine. Now, we can take advantage of all the various features we want, like an elongated sight and attack radius to make it so this Dragon can strike from very far distances. Onto the fight, Player must wade through a sea of enemies before they’ll be able to get to the boss. This means dodging is critical to surviving here, and bypassing some enemies just to get closer to the Dragon itself may be a good idea, even if you do procure a lot of damage in the process. Given this new addition, the best thing to do with it is add it around to other various minibosses. Introducing the Kolhunter Toad, another long-range attacker, but this time, every strike it lands pulls the hit Unit towards it. There’s a lot of room for creativity in just this single variable, so we’re looking forward to designing even more interesting bosses, minibosses, and even creatures based around this concept. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  9. Welcome to our twentieth blog post! Before we begin, we first would like to say thank you- the support and feedback has been fantastic as we’ve been doing these posts. We’ve been going strong for 20 weeks in a row now, and we hope to continue on forward. In this post, we conclude the chapter about our Open World system, so if you missed Part 1 or even Part 2, feel free to click the respective links and check those out. We’ll be continuing on from there. In this one, we want to talk about one key aspect about the “Real Time Strategy” genre, and that is one’s Home Base. For, in any RTS, especially this one, assembling your Structures for advancing your race is pivotal for expansion. In this particular game, your Home Base serves as your pivotal point from which you discover and explore the world from. It emphasizes all our various RPG-related elements for advancing your army further. And it, at a fundamental level, serves as a base point for building your army as it stands. We did some blog posts about how our current Structures will function, so you can check those out here with the Structure Overview, and also here with our Research, pt 2 post. As such, there’s some important topics we must discuss in regards to the persistence of Time as it relates to the Home Base. To start off, Player’s Home Base is separated from the world as a whole. This is done deliberately. Its set as its own “Node” in our node system for some important reasons we’ll go over shortly. The first reason is in regards to the computer and processor’s resources. One early design we wanted to do was to have both the “Active Map” and player’s Home Base map be loaded together, so while player is out exploring, they can quickly swap back to their Home Base, do whatever needs to be done there, then get back to the fight. This design is not only resource intensive (especially as Player creates more Structures in their Home Base), but also largely unnecessary. Smoothing out the parts between exploring the world and interacting with one’s home base can actually be done in a much smoother and better fashion, more befitting gameplay, and easier on the CPU. We’ll discuss what design we’ve decided to go with a bit further down in the blog. The second reason is it allows Player to have a safe-haven, and to establish one solid base point to conduct their exploration from. If we didn’t dedicate one explicit Map to just Player’s Home Base needs, then Player would have to build it into the Maps themselves, which, on the surface could be quite intriguing seeing as how you can build and establish anywhere, ends up being a disinteresting design. Placing structures anywhere would mean you’d have to travel there just to use them. Which means that Player would most likely end up just picking one spot for their major structures anyway. So why not give them a dedicated Map? The result is that we went with a combination of the two: your major structures can only be built within your Home Base. However, there are miscellaneous structures that can be built anywhere. The catch is is that if you ever leave this Map, those misc structures will be destroyed by the environment. Meaning your only persistent base is your Home one. The remaining pseudo-bases are merely there to establish a small place to rest before going on to more exploration. --- The next area we need to talk about is travel. Exploration is key, but establishing a connection across the world is pivotal for easier and smoother navigation. The first is the Waypoint- a simple Structure construct-able by the Player anywhere in the world. This allows for Player to create teleportation points anywhere they desire- destroying them and moving them elsewhere as necessary. The only drawback is the amount that can be spawned- they are in limited quantity, so choose carefully where they will be placed. They can always be destroyed and placed elsewhere, so keep that in mind at all times. Waypoints allow for transportation between each other- simply put, Player’s army will be teleported to that exact spot in the world the Waypoint was placed. In addition, there is a static Home Waypoint placed within Player’s Home Base. This allows for a dedicated Waypoint to be used to transport across all other Waypoints. This coupled with Player’s inherent Ability called Homeport, and Player has easy access across the world as they need. The Homeport is what we briefly mentioned above in regards to the Active Map/Home Base Map. The Homeport is very straightforward- Player is allowed to cast this spell at any point to immediately return to their Home Base. After doing so, Player now has a new, temporary “waypoint” added they can traverse to. However, this is temporary because when Player returns to their Home Base, do what they need to do, then look to go back into the world, if they don’t use the Homeport and decide to go somewhere else, the Homeport is redacted. Meaning Player must Homeport back Home, then Homeport back to the world in order to return to that specific spot; they can’t Homeport back Home, go somewhere else, then expect the Homeport to still be there when they get back- its a single use spell. This allows for Player to have an easy method of getting back to their Home Base and returning back into the world, without it being too abusable. This concludes our Open World System. Progress on it is going great, but there’s still a ways away before all features are implemented, tested, and ready. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  10. Welcome to our nineteenth blog post! We welcome you back to the second part of our Open World system. If you missed the first part and would like to check it out, click here. We’ll be continuing on from there. --- We must first begin with our Map Generator- we’re using a fairly interesting algorithm that allows for very organic shapes being randomly generated, with some (but not perfect) persistence via a Seed. This algorithm is known as Cellular Automaton (or Automata), and its quite an old, yet intriguing algorithm. The core algorithm is simple: randomly generate a series of 1s and 0s (1s representing Walls, 0s representing ground tiles), and over a series of iterations, determine which neighbors are “most like each other” to essentially get a very organic cave-like system. A simple definition means that a tile becomes a wall if it has 5 of its 8 neighbors as walls (well, the majority of its neighbors are walls). By repeating this process a few times (but not a lot of times), we can get a fairly good shape structure created. There are some great resources online for a general algorithm for this, like the ones on RogueBasin or TutsPlus, in addition to the dozens of other resources and generators available already. But a fantastic Unity-specific one was done by a guy named Sebastian Lague- if you’re interested in coding, especially with regards to Unity, you should definitely check him out. Here’s a link to his series. This project, Fragment’s Moonrise, is using a heavily modified version of the central idea behind the Cellular Automata algorithm, to of course fit our needs as it pertains to the project. There’s a series of things we need to ensure and enact in order for the algorithm to actually work and maintain stability. The first is absolute connectivity- our maps are guaranteed so that any “island’ is connected back into the mainland, so that all of the world is traversable. This is, of course, checked over to ensure there is no terrain that cannot be reached. We merely look for segments of unconnected land, and merge them into their nearest neighbor. The next is assembling the series 2D sprites, and to do this one, we need a little bit of help from Unity to fully complete. This is because a 2D map like this, especially one containing a 200x200 array of tiles, needs use of Unity’s Tilemap system in order to function and still achieve 60fps+. The Tilemap system essentially converts our array of tiles (GameObjects) into a single sheet, while still allowing it to be editable (which will be important when we begin adding in the Passageways). This single sheet genuinely converts thousands of GameObjects into pretty much just one, saving lots of memory, and greatly improving performance. Link to basic Tilemap. Link to a short tutorial. The last modification is to pair our generated Map as to work with our Pathfinder. We’re currently using Aron Granberg’s A* Pathfinder as its an incredibly smooth and very fast algorithm. More info here. To perform the pairing process, we just need to ensure that all our tiles denoted as a Wall are referenced by the Pathfinder so the Pathfinder understands that terrain cannot be traversed. This means, as part of the tilemapping process, we need to still have the impassable tiles denoted. --- Those are the core algorithms we are using to assemble and use our Maps. We decided to go with the Cellular Automata algorithm to give us a fairly open, yet dense land, and, more importantly, to give us a system of randomization so that no two maps are the same. This is key, for the game will definitely feature a good amount of replayability. In addition, the straightforwardness of the map generator allows us for easy modification as we see fit. Maybe in the future we’ll develop a much more varied and significantly more seamless open world system (something that can be done without the use of nodes, alongside an altered map generation system), but for now, this seems like the best base for the game. Now, let’s see how we’ll be tying our Map Generation in with our Node Generator to complete our Open World. Given that we have full access unto our map generator and tile system, as part of the generation process, we now begin to spawn objects we’ll be calling Passageways. Passageways have some unique characteristics about their generation- first and foremost, when looking at our Node Generator, you’ll notice that no Node is aligned to a grid: their all free-floating. This is critical to represent in the game world, as the Node Generator and the real Maps player will be exploring need to be in sync. So, the first thing we must do is examine two connected Nodes, and determine the angle between them. Using basic trigonometry, we can figure out the angle, in degrees, and utilize that degrees to determine our spawning location for the Passageway (its a simple "determine the angle between two points" sort of algorithm). We want to place the Passageway in the appropriate spot in the world so that it represents what the player will be seeing in the Node Generator. By treating our Map as a Circle, we can utilize the angle adequately in order to spawn our Passageways. By simply treating the angle as a ‘vector’, and traveling along its path to the edge of the Map (noting that the ‘center of the circle’ is the center of the Map), we have now found our spawning location (and, upon placing it, we can carve out the part of the Map back to the first walkable tile) Now, with our Passageways spawned, we can correctly hook them up. The logic is straightforward- when player gets near the Passageway, they are allowed to activate it, and upon doing so, they are brought to the next Map. Now, why didn’t we just take the significantly easier approach and align everything to a grid? The answer is just that- then we’d have to align everything to a grid. This approach gives us a significantly more organic system that’s much more fluid for exploration. Its much more expansive, and lends itself to additional uncertainty and unknowingness from the player as they explore the world. Implementing a grid system and our node system would have likely taken equivalent amounts of time to complete, and our node system gives us a much, much better result both aesthetically and functionally. This Passageway system allows for a nearly-seamless interpretation of an Open World while still retaining the core aspects of a Real-Time Strategy. The system is based around a series of Maps, but instead of loading them seamlessly (based on player position), we load them upon Player’s request. This gets us around the issue given that the player can have a multitude of Units, each going a different direction, and ensures stability with a solid framerate. There are some ideas we may play around with to get our system even more seamless, but as it currently stands, this is the best solution that still allows great performance. --- Lastly, something we want to touch on briefly is our aspect of Time. Time is critical, as our Maps are loaded in a single state, and unloaded when not used. We need to ensure things still ‘function’ as they would in an Open World (notably, with Player’s Home Base) without the need for having things loaded at a given instance. We can do this simply by timestamping things at specific moments, and retaining that across both Maps and also sessions (in which Player stops playing, shuts the game down, then restarts it at a later point). In the next part, we’ll go over how this will be explicitly used in regards to Player’s Home Base (the area we want Time to be persistent in), alongside go over some of our convenience features, like world traversal and teleportation across the maps. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  11. Welcome to our eighteenth blog post! With the advent of our open world system beginning its integration, we thought it would be a good idea to discuss how this system will work, as we’ve previously never gone over such a topic. As always, if you’d like to know more detail of how this was integrated, go ahead and send us a message. The core world aspect behind our project, Fragment’s Moonrise, is establishing an open-world setting while still emphasizing our real-time strategy based gameplay. There’s quite a bit of techniques and design philosophies that go into it to ensure playability is still at the forefront. In this short series, we’ll be going over how our Open World system will be integrated, and how it will work programmatically. We need to first start with how we’ll be basing our world- we want randomness, so each playthrough is unique and different, as exploration is key. Introducing our node-generation algorithm: it works quite simply, and allows us to essentially create a network of nodes that will be the basis for our open world. You can think of each node as a map- strung together via their connections. One thing to keep in mind while we discuss this algorithm is that our engine is Unity, and therefore we can utilize quite a bit of the engine’s features in order to further help us acquire this goal. Doing this purely mathematically can get incredibly complicated very quickly, so in order to ease our desired goal, and give us something Unity can understand, we need to base our code around our engine. We begin by placing nodes randomly. This serves as a base- we want X amount of nodes to represent the X maps player will be allowed to explore. Then, we can begin the connection process. What we want is a clean set of nodes- we definitely do not want the connections to be like a spider-web, meaning we don’t want anything to overlap. Thankfully, the engine can help us out quite a bit. We begin at our first node in our List, and enact a raycast determining all nearby nodes that we can hit with said raycast. We aren’t worrying about overlaps at this point- we’re just worrying about how many other nodes this particular node sees. We repeat this step for each node spawned. Bear in mind: we’re spawning physical gameobjects of the connections as a black line with a collider attached. Then, we begin to eliminate connections. Remember: our goal is a clean series of nodes. Taking both collision and length (distance) into account, we go through and check out which connections overlap (collide) with one another. When we find a collision, we look at the two connections, and pick the longer the two to eliminate. We do this because we only want the closest two nodes to be our connection, so the node system primarily considers its immediate neighbors first. We repeat this until we have no more colliding connections. This gives us a fairly clean series of connections, but, there’s still one more critical step: ensuring all are connected. Starting at any node (can be random, or can just pick the first one) we traverse across its connection(s) (think of this like Breadth-first search). As we traverse, we mark all discovered nodes, and, when we’re done with the traversal process, we merely check to make sure all nodes were discovered. If they aren’t, we can attempt to see which node(s) have not been discovered, and attempt to force a connection nearby, then run another check to ensure all are discoverable. While we could just check our nodes for if they have a connection or not, this could give us ‘islands’ in which some nodes are only connected with each other and not the mainland, and that is something we definitely do not want. We want our premise to be on total discoverability, and ensuring such a thing takes place. That’s just the algorithm for one particular set of nodes- this set being referred to as our “environment”. We now need to cross-connect them with other environments, to ensure traversal across the world as a whole. Our particular game is currently only utilizing 4 environments (with a few extras we’ll add later on). This makes cross-environment traversal much more simple, as all can be assembled and shaped like a square. Utilizing the same tricks of generating connections as before, we generate cross-environment connections to fully integrate the map system, and ensure connectivity across the world. You may notice the barrier between the environments- this ensures all environments are first generated unto themselves, and then when we are ready for cross-generation, we simply drop (ignore the collision of) the barriers. Finally, we can do all our other miscellaneous things, like add in our Sub-Environments to serve as unique territories, usually containing stronger enemies and bosses. There will, of course, be the necessary balance integration, to ensure players with weaker armies can get past those areas until their ready. But that will come much later. This was just step 1 of our Open World system- in the next blog post, we’ll go over how our map generation works, and how that will be integrated with our node generation matrix. We’ll also discuss time as it persists in the world, and how that can play a key role in ensuring things still function even while not loaded. We hope you look forward to it! --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  12. Welcome to our seventeenth blog post! There’s quite a bit of ‘teaching-tools’ demonstrated in specific boss design, to further enforce particular mechanics that are necessary to furthering one’s understanding to the game. Introducing the Wingless Whisperer, an adaptive, illusive boss that highlights some very core, fundamental aspects of this project’s combat. Let’s first go over some of its attacks, then go over why these are crucial to a player’s introduction to the world. The first attack it can utilize is its Right Claw- embedded within it is the ability to inflict Deep Wounds, a status ailment dealing great damage over time. Its next attack is where the miniboss gains intricacy- its Left Claw. It strikes no enemy with said claw- instead, it merely strikes itself. And, in doing so, both heals, and changes the dynamic of the fight- by invoking Truth Reversal upon itself. We’ll go into more detail about how this works, and why its a key factor, a little bit later. Its last skill is its Invisibility: while hiding from the player might pose some usefulness, what’s important to gain from Invisibility is how to fight it- many things within this world can turn Invisible, and its important to not only spot them, but also how to engage them. Invisible foes cannot be seen in any way, meaning that if the player wishes to engage them, they must do so manually. This is the Wingless Whisperer’s first teaching tool- an invisible target must be engaged directly. Thankfully, there are some tools to accomplish this. Any attacking spell can be cast on it normally; what this means is all you have to do is take a spell on the hotbar and cast it upon the fiend, and your warriors will do the rest. This dynamic is further emphasized with its movement- you need to actually target the creature to strike it, so be quick, and accurate. The next teaching tool returns back to its Right Claw- as you can tell by the image above, it strikes in a particular area. Simply put, this should directly indicate that having your warriors stationed together is a very, very bad idea, and spreading them out is a must. If spread correctly, only 1 warrior will be hit by the attack (or none, if you employ some dodging, but that is a bit more advanced and requires precise timing). Meaning you’ll only be having one warrior take the damage of Deep Wounds in a given instance. As that warrior loses health, its best to back it off from the fight and have the Wingless Whisperer target a new warrior, as to allow for healing the hurt warrior before it dies. The final teaching tool is one we alluded to a bit prior- Truth Reversal. Truth Reversal is, simply put, one of the many status ailments that alters one’s resistances. This one in particular is quite interesting- it, essentially, reverses the Wingless Whisperer’s resistances. You see, as the Wingless Whisperer stands at its core is high resistance to every element except for Truth. Abilities of the Element “True” can strike at the Wingless Whisperer without any issue. However, upon invoking Truth Reversal on itself, this is no longer the case. As you can see in the gif above, all our warriors are casting Mystic Bolt upon the Wingless Whisperer, and it is doing essentially no damage at all. However, with Truth Reversal active, our Mystic Bolt is now useful, and we can get some good damage in. This resistance alteration is pivotal for the game’s design: not only do many much stronger bosses utilize alternating resistances, so this is good practice before the real fights are to occur, but just simply understanding how resistances work at their core is crucial to engaging all the various foes of the world. Understanding what an enemy resists and what it doesn’t is critical to defeating it, and being able to swap from casting spells of Elemental type “Mystic” to Elemental type “True” as necessary is a part of the game that the player needs to understand. This boss teaches the importance of utilizing the element of a particular spell to its full advantage to overcome a powerful enemy. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  13. Yyanthire Studio

    Fragment’s Moonrise | #16 The Nightdrake, a newly-developed Boss

    Thank you for the kind words! We're going for a fairly intricate, micro-based challenge, and we think we're hitting it more and more as we develop new bosses, new content, etc. Thanks!
  14. Welcome to our sixteenth blog post! The Nightdrake is a dragon of transparency; it hides deep into the landscape, awaiting the first unsuspecting soul it sees for a deliberate ambush. The best approach is with stealth of your own: if you can sneak up on it undetected, you can get an easy counter-ambush, gaining a huge tactical edge in the beginning of the fight. Being able to strike first may be key, but its not the whole fight. At some point, you’ll see it, and it’ll see you. So having a plan for that point in the fight is critical. It can summon some very formidable foes. Starting on the left, the Necromancer Kasjowa is a strong enemy with lifestealing capabilities, alongside being able to Poison anything its acid touches. The Galf Spider is a summoner; its spells may not be too strong, but it can continuously summon spider underlings. These underlings may be weak, but they are quite powerful in numbers, especially when they surround you and don’t let you escape. On top of that, as the weak spiders die, the Galf summons even stronger spiders in its place. The last of the summons is the powerful Skeletal Ossuria. Strong physically, a formidable spellcaster, and a wicked summoner, the Ossuria is the worst of the Nightdrake’s summons. The Ossuria rapidly casts Fireball, a quick spell with great damage. Its health and durability is excellent; this foe will not go down without a fight. And its ability to spawn its underlings is its deadliest of spells: take down the Ossuria first before it creates too many of its lessers. The final thing to worry about when it comes to the Nightdrake is its Life Siphon- dealing massive damage to both health and mana, and fully stealing it for its own. It also inflicts deadly status ailments: poison, a vision deprivation, and a resistance reduction. All those whom are struck by Life Siphon begin to rapidly lose health due to Poison, lose the ability to see as far as they could originally via Vision Deprivation, and suffer from even more damage than before with the Resistance Reduction. When this attack is coming towards you, its best to rapidly move out of the way. The best plan for this fight is get in, get out. You’ll quickly be swarmed with adversaries, so its best to strike down the Nightdrake before you get too overwhelmed, then make for your escape. Our video below details the fight; it consists of two-parts: the first being a regular engagement with the fiend. The second shows off an alternative strategy, the ambush, utilizing the high damage output of our Apprentices of Mysticism to strike down the foe before it can lay down substantial damage upon us. Development behind this boss has been quite interesting- the original version of the Nightdrake was abhorrently powerful, and received a considerable amount of nerfs unto its current state. It originally had all its attacks strike in an area, and all of them had half their normal cooldown rates. With the game’s code, this meant that as player’s warriors stood in the AOE, particularly when it summoned things, that a separate creature would be summoned for each warrior there (alongside inflicting player’s warriors with a status ailment). This resulted in dozens of summons cropping up as the fight went underway, and given that the Nightdrake initially had 3000 HP (now, only 1000), this dragon quickly became a very scary boss, in need of a lot of changes. Our current plan is to bring this version of the boss back, likely to be referred to as the Elite Nightdrake, but this time as an end-game boss. One in which the player has an opportunity to fully advance their fighters, and truly hone their skills, before they have to engage. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  15. Welcome to our fifteenth blog post! In this one, we aim to stray a bit away from showing off gameplay to instead show off how some of our game’s code works, specifically with regards to Abilities. If you’d like to ask any sorts of questions with regards to how it was implemented or anything like that, we’d definitely be open to sharing with you. This post will predominantly cover the basics of what-does-what in the game. All of our data interpretation begins with our methodology of storing the data: JSON. JSON allows for a very convenient and easy way to not only store large amounts of data, but also conveniently write new data and, most importantly, access that data in a quick and reasonable fashion. The core of our load times when booting up the project are map generation and data-loading, so with JSON, we can get it as fast as it can possibly be interpreted and stored, ready for the game to call upon as needed. As a result, the game loads quite quickly, even though its quite literally handling thousands and thousands of lines of code. To begin discussing integration, we should first take a step back and talk about our Default Data. Every Ability in the game is comprised of parts: Damage, Element, Range, Area-of-Effect, and so forth. With that being said, there are quite literally 100-200+ different Abilities alone in the game as it currently stands, and dozens of various variables to invoke. And this is all plausible in a convenient manner via one core element of data interpretation: default data (as shown in the image above). Before we begin reading the JSON, we first run through and establish every entity as having this default data. And, from there, as we read the data, we merely update the entity with its correct information. Such as, a powerful fireball spell would have high damage and long range. But a buffing spell would not need any damage. With the default data, we can conveniently comprise every entity based on its unique information, and let the code handle setting non-important data necessary to run the Ability properly. This leads us into our desired data- each Ability is unique, and therefore must be treated as such. We want the game to read the unique data and do desired things with it, but treat the non-important data as nonexistent. Take our image example above- our Great Fireball spell has some key features we want to address with this particular Ability. Its damage, its Area-of-Effect, and its Target-Types are all critical pieces of the Ability. The Damage part is self-explanatory: deal damage to those hit by the spell. However, it gets mixed up with its first alternative feature: its AOE. This establishes that it should strike in an area of a particular Radius denoted. Then, the next tag might come as a bit confusing: its Target-Type. You’ll notice two Target-Types listed: one above, just saying “Enemy”: True, and one within the AOE bracket, denoted “SplashAffectsWhatTargetType”. You may be reading the “SplashAffectsWhatTargetType” and thinking its self-explanatory: this is what the AOE effects. But then you must ask: what does “TargetType” mean, with Enemy set to true? Well, it means that this spell can only be cast upon Enemies, which in turn means that when a unit’s AI is functioning, or player is attempting to cast said spell, they must target an Enemy for it to function adequately. So, Great Fireball is a spell which can only be cast upon a target of type Enemy, but its AOE can effect anything from enemies to allies to even the caster itself. However, that’s not the full truth of the spell: it also utilizes “GroundCast”. What this means is that the player does not have to just click upon an Enemy to cast the spell, they can also click upon the ground, and the spellcaster will cast the Spell there. GroundCast is a unique feature predominantly only useful for the player, but there are some various unique ‘tricks’ to it that we developed to make it usable by enemies as well, and we’ll talk about those in a little bit. Next, let’s look at a slightly different ability: Lifeless Spirit Poison. This Ability has a different parameter: “StatusEffectApplied”. It calls a Status Effect named Poison. This parameter is quite a unique one as it is calling a different set of JSON data to retrieve an element called Poison, and then applying that to the target as they are hit by the Ability. It also inflicts Mana Damage, which harms the target’s mana rather than their health. With some of those Abilities shown and briefly discussed, its time to talk a bit more about the coding side of their integration. Each parameter has a function, and its up to us as the programmers to determine what this function does. Our Damage variable is quite simple- as the Unit is hit by an Ability, have the value of Damage subtract from their health (or, if the Damage is negative, use it to heal them). Next is AOE: AOE is a bit strange as its design has changed quite a bit since it was first introduced. Originally, no spell would be considered AOE, it simply hit the target. But, as we developed the game and made things more unique, AOE now quite literally is enabled for every Ability. This was due to a major gameplay change done a while back: instead of targeting and tracking the target Unit, we target where they were standing when the Ability was launched, giving an opportunity to dodge the spell. Through code, we can conveniently make it so all Abilities utilize AOE, and the ones that explicitly list out their AOE data override the default instance. With AOE, we’re determining, upon spell landing, a specific area around where the spell landed do we apply ALL of the Ability’s effects (as if anything standing in that area were the ones struck by the spell). Since it applies all effects, we can do things like utilize another variable, “ConstructObject”, that spawns in a particular unit. And we can combine this with both AOE and setting our TargetTypes to “Corpse” to make it so all Corpses in a particular area are returned to life. There’s a lot of creative uses behind this code. Who and what we hit are dependent upon the TargetType, which lists out what effects what. We do this based on the type of the Unit casting the spell based on the type of Unit whom was hit by the spell. If two PlayerUnits are hit by a spell that only effects Enemies, none of them are effected. But if a PlayerUnit casts a spell upon an Enemy, that enemy is effected, and vice-versa, its just a simple check of typing. Where things get more complicated are with Neutral units: no AI will ever trigger on a Neutral, every action has to be deliberate, and that’s been accounted for. GroundCast simply means, upon clicking to cast a spell, are we allowed to cast it on the ground? If there is a Unit we can cast upon standing there, we’ll prioritize casting on the Unit. But if not, we’ll cast on the ground tile. This also has a bit of a unique integration: to make it work with non-Player AI, we made it so that if all TargetTypes are false that any non-Player Unit will attempt to cast said spell on a nearby tile at random. This is important for creating other unique spells like Dodge, which makes it so enemies teleport to a random nearby location upon spellcast (more heavily displayed with the Chimaera fight, as shown here), or with our various summoning spells to summon creatures. Lastly, with our StatusEffectsApplied, you’ll notice its not just a single object but an array of them. Meaning, you can have multiple Status Effects be applied upon casting a single spell. Status Effect integration is possibly the most complicated- on spell hit, we go into our Status Effect database, grab out the desired element, and then put it onto the unit for them to now be effected by (effects range from harmful to helpful and anywhere inbetween). Status Effects are, quite literally, a whole other world of effects on their own, just like Abilities are. --- We hope you enjoyed this rather brief insight into some of our coding practices, and thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!