Multiplayer Mastery Course - game.courses/mp/ Game Dev Course for Beginners - game.courses/bc/ Join the Group - unity3d.group/ Join this channel to get access to perks: / @unity3dcollege
I love your videos, always learn a lot and I've been having a rough time with demotivation and lack of confidence, but you always motivate me and remind me I love learning new stuff! ty so much
I've done it this way a number of times, and I usually do the targeting in the overrided Use() (maybe through a targeting manager like it was said in the video - or similar). Also worth saying that: It's just so nice to be able to have spells, buffs, items stats, stat-trees, and more all using the same system - if the 'property' is made well, it can pretty much be applied to anything with a high degree of trust that it will 'just work'. - aka: not only can you use it for offensive aoe spells, but for equipped item stats and skill trees as well... think path of exile and unique items that grant you passive tree bonuses... makes life a whole bunch easier and gives the designers more room to create interesting items and skills or whatever. Also great advice not to turn every little thing into a swiss army knife of customizability. Every little addition and customizable feature EXPONENTIALLY increases the complexity and weakens it against bugs and fringe cases. DRY is stupid advice when it comes to functionality - if something functions differently, it really should be its own different thing... it's pretty rare to find a maintainable god method/class that actually improves the codebase... what it usually turns into is a mess of switch statements and most all fringe cases are broken and a complete nightmare to fix.
Thanks for the video! I wasn't aware of structs, and your set up looks a lot nicer than the one I built! Thanks for making your content it really helps me out.
This is an issue I run into all the time! I usually create a second wrapper object that encapsulates the final call which takes in whatever parameters in whatever format, but exposes a parameterless Execute()/Use()/whatever function via an interface that then calls the ability with whatever parameters it needs; so that when you get around the finally calling the chain that actually triggers the ability, that chunk of code only needs the single interface to work with.
Can you elaborate a bit more how this would work? Am I getting this right, that you would call Use(), and then in the Use function, it then figures out which target/position is selected?
4:50 create a so that checks for the target type null then if location apply an aoeRange field, then have use find all enemies within range of the target location and apply damage
Something I've been doing in my game which has a large ability system is to extract consequences into an abstract class as well. Then abilities have an array/list of consequences that can be changed on the fly. This is a better approach for iteration as it mimics the relationship you'd have with a second person doing game design. You create generic consequences (Heal, Damage, Interrupt, AddEffect, etc.) that can be composed and modified on the SOs. It's been a huge help in allowing me to make tweaks rapidly and expand the suite of possible consequences. If I later decide some skill should also poison the enemy it's a small change in the editor rather than a code change.
That's how many of the systems I've seen are built too. With effects/consequences that can be either conditional or sometimes chained through graphs. Works great for more complicated abilities and RPGs imo :)
@@dbweb.creativeIt's important to note the difference between stack and heap. Passing an object as an argument also "copies" the value, however the copy is just the pointer address. I.e cheap. So in his case the memory difference is negligible and avoids heap alloc. Or was your point that modifying the struct won't actually make any changes?
@@PixelBlight no, in C# object of a struct type is not passed as a reference into a function. It's passed by value, meaning the whole object gets a copy, and that copy enters a function. So for example if you have a 100 strings and ints inside a struct object - all of them will be duplicated in memory, just for that single use as an arg in a function call. Of course you also will not be able to modify original struct object, but only a temporary copy of it.
@@dbweb.creative yes that is correct 👍 however the copy is on the stack so it's far from as bad as most people are saying. But yeah, 100 strings in a struct would not be the intended use case for structs 😅 In his example, converting x amount of function parameters into a struct is in practice copying the same amount of stack bytes (except for strings like you say)
Wouldn't it be better for Ability Target to be Abstract and have 2 (but possibly more) implementations of it, with public methods that can handle the specifics of returning a stored position, or the position of a stored entity? That way the entire pipeline is determined by what implementation of Ability Target you feed into it and what each implementation returns. The abilities don't need to know about the structure of Ability Target and both can evolve in parallel as long as Ability Target still returns valid values when queried for a position.
It could be depending on the number of implementations and mixing. If I got to a point where there were a few other target types and they mapped to specific types of abilities, I'd probably do something like that to split out the flow. Depends a lot in how the design setup is too, if the abilities get more complex, they could take a variety of target types in different scenarios, lots of possible options I think
Programming patterns like command and observer are exist for these very reasons especially in C this is why we encapsulate our small methods into larger abstractions People need to learn how delegates work on the back end with scriptable objects
Are you going to be covering any form of persistence in your multiplayer coverage with the dedicated server segment, or is that too far out of scope? Thanks for the video!
Yes, starting in the first lesson. Characters and all data is persisted via cloud save and cloud code, and it's easy to swap that persistence with anything g else like txt files, dbs, etc :)
DO NOT use structs for parameter use. This is because in C# struct is passed by VALUE, which means the object will be duplicated in memory just for the purpose of being used as an argument. So avoid as much as you can. You can replace a struct with an instance of a class, or even something static might work.
Or use ref keyword for parameters so the struct is passed by reference. Also, passing struct by value is not necessarily bad, unless the struct is big and/or you are performing operations hundreds to thousands of times within a frame with many functions for such a case. Then you will see a dip in performance, and should consider using ref keyword or use a class instead to reduce performance hits for the function calls.
