![]() ![]() ![]() There are also parameters for the host card to require a specific position or face. By extension, this class also includes overideable logic for processing these Target Parameters. The parameters that you see in orange are BUILT IN to the DORCardEffect class. I know it's ugly right now, but I've still got work to do on custom editors: Once you select it you'll be greeted this HORRIFICLY SCARY looking inspector. Sweet, you've created and named your first effect. You can set numbers negative to deduct as you can see.but making the effects work is more important to me than making the lingo 100% at this time) (All Screenshots Are Considered Work In Progress BTW."Increase LP" is a lie. I want to create an effect that tolls the player who controls this card 50 LP each time it's involved in a battle. Let's see what this looks like in action. Since each effect is also a ScriptableObject, the DORCardEffect class also includes parameters for narrowing down the effect execution parameters by card type, card stats, card attribute, and more. Battle Terrain: The grid spot that this battle is taking place.Opposing Card: The card that Host Card is facing in battle.Grid Space: The full game grid, for searching. ![]() Host Card: The card that this effect was on when the game told it to execute.PerformEffect is where all the logic goes, and PerformEffect requires: I've started with the easy ones, the effects that you can create and configure currently are as follows: EffectBonusATK, EffectChangeBattleResult, EffectFlipCards, EffectModifyLP, EffectModifyATK, EffectSpellbindCard, EffectTransformMonsters, EffectTransformTerrain.Įvery single one of these classes inherits from DORCardEffect and implements MINIMALLY abstract method PerformEffect. Out of those, about 60% are effect monsters with effects ranging from, "Transforms the occupied space into WASTELAND terrain when engaging in a battle." to "Select a spell card from your graveyard and revive it in your own summoning area." The initial sample section is the first 140 cards in the game. And of course, modifying the way one effect worked would also change the way others based on it would work. There's been a lot of testing involved with each card effect I add. However, as with any programming solution it is not always cookies and cream. With ScriptableObjects, it just made sense to have a few configurable & reusable effect classes and instantiate and configure them as assets then assign them to the cards. Public abstract class DORCardEffect : ScriptableObject I glanced over the card effects in my spreadsheet and outlined the types of effects I would need to represent as classes. So not only are all 600+ monster cards represented by ScriptableObjects in a folder in my Unity project, their card effects are also represented by ScriptableObjects. The best part is that referencing them in the Unity Editor is just as simple as referencing a texture. This asset can be a store, it can represent a configured machine (more on that later), or can represent simple constants. ![]() Have a class that needs to be referenced by multiple objects in the scene? ScriptableObjects let you represent that class an asset in the editor. If you're not familiar with ScriptableObjects put simply: they make data in Unity easy. Currently, every single card in the game is represented as a ScriptableObject in Unity. I believe the game wouldn't have been where it was today if I hadn't taken the route I had with the card database. In less than 48 hours, I was successful in building mechanics, grid, type matchups, and 5 days later I was importing the card list from the official Yu-Gi-Oh Wiki as a CSV, of course ) On February 28th, 2020 I had the bold idea to recreate the mechanics of Yu-Gi-Oh Duelists of the Roses in Unity. Hi all, today I'd like to catch you up on the state of the Duelists of the Roses remake. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |