*Timecodes* 1. 0:40 .... Having Game Logic in UI 2. 3:45 .... Having giant classes 3. 6:40 .... Having everything be public 4. 9:10 .... Having setters with side effects 5. 14:25 .. Having giant prefabs 6. 17:05 .. Not using interfaces 7. 20:45 .. Ignoring Garbage Collection 8. 22:30 .. Sharing and Feedback
Same here...I get the basic gist of it, but managing loading multiple scenes and everything is a shallow understanding at best and something I'm definitely going to need to solidify.
@@ProdigiaGames state machines, basically a list of states. You then use these states to do, "whatever" according to a specific state. You can create them with many different variable types (array of name, array of bool, array of int, enumerators), as long as each state has their own individual representation (value) inside the variable.
Interfaces are also especially useful in the early stages of game development when you don't know EXACTLY how a specific system will be implemented. You can fairly easily prototype multiple implementations in your code and then "swap" one out for the other to change which gets used in your game at runtime. The benefit of this is that you won't have to go through all your code and update the references (since they only reference the interface). This is essentially an example of the "Strategy Pattern". Great vid Jason!
I recently discovered the Strategy Pattern and I must say it seems the most natural to me now. I was struggling with terrible spaghetti code before. I despise switch statements with a passion now because I was so prone to them in the beginning. A combination of the Strategy Pattern with SOLID principles and the observer pattern helped me get around that.
@@CodeGaff interface support is atrocious in the Editor tough :( found my self repalcing a bunch of them with abstract base classes just to avoid the hastle.
Using too many interfaces too early is a great sign that you have no idea what you’re making and you think if you just abstract enough then the design will come to you without doing the hard work of designing it. Early abstraction is a sin not a pattern.
I think I learned all that the hard way... One crucial thing I learned in software development is to always ensure your codebase is as testable as possible, you can split your codebase to multiple projects, game engine-dependent and pure classes, so you have more ways to test your game other than built-in game-engine tools and manual testing. Many say code structure is not that important for games that is known for performance but the small "quick and dirty" solutions pile up over time (technical-debt) and will bite you real hard. also if someone's interested, look into domain-driven design, no need to implement it, just learn why it is design that way, it made my life easier
"is this right? should I be exposing it? should this be public? does it make sense?" this can apply to so many things other than programming. I love this.
An EASY GOING PROFESSIONAL - what a breath of fresh air. Great honest appraisal, you can always work out the people who really know there stuff, as they don't use the knowledge as a weapon. It was true in the early days of computing and is, as true, now.
I always feel demotivated to code and make games, idk why. Somehow watching your video for 2 minutes motivated me to think of a game and get motivated to work on it. You are a magic man, I don't know how you do that, but I'm not complaining.
Initially did a bit of a doubletake, wondering why I was getting a notification of a video by some guy called Jason Weimann :) You are most definitely the brand so I'm cool with the name change! Great info, as always
Great vid! I would personally be interested in a Unit Test lesson using a real game dev scenario, where the expected answers mostly depend on user input / other entities or functions don't really give a printable answer. All I can find are tutorials where they explain everything using a "MultiplyBy5()" function.
You should look into Dependency Injection. You can pass a class which is responsible for user inputs for example into the class under test. In your unit test you could inject a custom test class which does fake user inputs for example.
This was a fun video. I wanted to contribute my point of view so I can stop thinking about it and get back to work. Really glad Jason made a video on this, because it helps me highlight important things to keep doing within my own projects, so I thought I'd dump some reading below: 1. @0:40 .... Having Game Logic in UI Things just work when keeping classes small, there is this moment where the code just comes together and works so elegantly, its a nice feeling that often comes with keeping classes small. Or in other words, maintaining the Single-Responsibility Principle as part of the SOLID principles. 2. @3:45 .... Having giant classes Ultimately I wouldn't have the Vehicle class implement its own potentials. It would just be a holder/implementer of other potentials that Vehicle know how to use. This way we're still able to obfuscate the unimportant 'inner workings'(which is good) while maintaining the readability of what these potentials are trying to do. It also makes things like 'order of operations' very easy to read and change since Vehicle can call upon its potentials in the order that makes sense to it as method calls. 3. @6:40 .... Having everything be public Yeah so, I don't make anything public unless making whatever public is part of using that class in general such as a ScriptableObject. I'll always differ to creating a GetMethod that returns my data, and if these GetMethods become unruly I would sometimes wrap the data request with a struct in order to decimate large data calls to single requests. Or, I'll use an interface to expose the data I need since these have to be public, may as well have some readability (and some nifty GetComponent possibilities) to go along with my public data needs! 4. @9:10 .... Having setters with side effects get and set, I tend to use set to limit a value then create a new value or just have some sort of conditional contingency if the data is sensitive to mutation get is a good opportunity to implement other strategies of data propagation like grabbing a value from a database, or doing some complex math to return back a value. As such, these gets methods would usually be in a class who's job is to define a data-set that then gets implemented by an object to handle its data. But honestly I don't really use get or set as I love to practice Immutability for all of my data by propagating my values through the composition of objects rather than reading and writing values. I don't know if this is weird, but I think this is one of the funnest parts of coding :P 5. @14:25 .. Having giant prefabs This is exactly what I'm working on right now where I have an Attribute system where a base component 'Player' holds onto various other gameobjects such as 'equipment, statsheet, abilities', which then hold onto other gameobjects 'equipment> weaponSlot, armourSlot etc' that then hold onto other gameobjects 'weaponSlot> weapon' and again 'weapon > mods'. It made me think, did I just make a giant prefab? But no, ultimately, this prefab of player has slots that then propagate additional prefabs which then again grabs a smaller prefab. Larger prefabs do some work, then differ to smaller prefab, which does work then defers to yet another smaller prefab and etc. The ability to change the functions of the core prefab means you just slot in something else. When swapping out base data from a prefab in order to change enemy01 to enemy07, one really cool way is to just use a ScriptableObject that holds all base values along with images and any other Unity-based variable that fits within the limitations of Scriptable Objects. Scriptable Objects are so easy to serialize as well if you want to store them within a simplified data structure on a database. This method gives the benefit of being able to sort ScriptableObjects by querying data on those objects. It helps to know stuff like what enemy has the highest base attack? Sort through a dictionary of simple values that point to a scriptable enemy, then grab that one and use this within the respective battle. 6. @17:05 .. Not using interfaces Firstly, from a website MVC point of view, Interfaces are great ways to simplify complex data needs to a very literal question of "I need this data to do my work, I don't care how you do it or who you are, just give me what I need". So with game applications, any UI component should receive some sort of interface as a resource before it updates its information - this is a nice readable way for a gameobject to source predictable info to a component of UI that it doesn't know anything about nor does it care. 7. @20:45 .. Ignoring Garbage Collection GC its a tricky one where there are beginner related issues and professional related stuff as well. For a beginner these issues show up as null errors where you expect information to exist, but GC has already gotten rid of it. This was and still is a growing pain for me because of how collections work and how complex game calculations can be. Then when it comes to professional use, thankfully Unity has improved the tracking of data within their Profiler tools because even pros can have memory leaking issues. 8. @22:30 .. Sharing and Feedback See the wall of text above, yay! Also, thanks for the TimeStamps, Coco Nut. I think its crazy so many people are asking about state machines when it was briefly mentioned in the video. This is awesome, I often preached that all a video game is, is a data layer paired with a state machine. So good on all of you for requesting this as a video, I bet Jason will do a great job on this - spoiler alert, maybe start looking up how to use 'event' and 'Action' ya know. :D
Thanks for describing Interfaces properly for everyone. Lately I've joined a few in-progress projects that use them incorrectly (i.e. they should be using a class with private/protected variables) and I find it very frustrating
Great info in the video! I want to suggest one missing 'mistake'. And this would be relying on inheritance and creating large inheritance hierarchies. These get quickly very brittle and you and up copying classes around just to change a few lines and you end up with huge chunks of duplicated code. Use composition instead of inheritance whenever you can.
Wow, thank you so much Jason. This is some of the more in-depth tips I've been looking for. Just having some input on best practices and simple explanations as to WHY. Wonderful video, thank you so very much for taking the time to share. :)
+1 for State machine to control a game love to see a different and more generic way than your previous video on state machine (it was great and helped me a lot)
I appreciate the mention of interfaces as I find them vital in cases where a component needs to reference and communicate with another component in the scene (rather than using a concrete class reference). I'd also be very interested in your thoughts on state machines. I've written a few implementations of them in the past and would find a different perspective very insightful.
I should probably use interfaces to get more flexible camera target behavior. I hate having to use a "find player" method or having to reference a transform in the scene controlled by a public field in a component exposed on the prefab. It should be more like the camera has an "I take targets" interface and players, enemies, and other agents have an "ITarget" interface. However, I then have to write behavior which binds the camera to the target I want to use in the scene, but this shouldn't be too hard, and it beats inserting a scriptable object that includes the players last known transform.position into the camera follow script using an exposed public field. ScriptableObjects are super easy to use but they can make things very messy if you use too many of them, especially in the wrong context.
Yes, need video on fsm and not just small example code, but realworld examples. Like Character controller for a beatem up style and how to make them managable
It's been so hard to find a good state machine tutorial. They're always in the context of animation and AI. I would kill to have one about game control.
Awesome channel, I'm really learning a lot from this. It can be really hard to find people to learn from who aren't also on a learning path. So this channel is one hell of a find.
Some great tips man! Having giant classes I think is the easiest basic seemingly innocuous beginner mistake. I feel a lot of beginner Unity scripting tutorial needs to emphasize decoupling and separation of concern concepts. They're such important concepts that forums and Udemy course just kinda gloss over.
I'm not a professional game developer, but some of this applies to development in general. You should usually follow this whenever you write code. Decoupling, encasulation, not building huge monolyth classes and so on. I'm guilty of having additional stuff in my setters though. Like a property changes a value and triggers change event. I guess this is hiding complexity in a way, but I've not found a better way to do it. For example. A health property or set method that triggers an event that other things can listen to. If someone else does to much in the event handler, it's the event handler's fault, not the thing triggering the event. That's my point of view, but if you think I should start doing it some other way, please let me know. It's very convenient for UI updates for example.
Yes please about the state machines. Also how to use state machines in an RTS style game - eg. send a unit off to chop a tree, and the unit will chop the tree, collect the firewood and return it to a building.
Your videos are always a treat to watch.... Have implemented your State Machine scripts in several games and they work like a charm... And I am specially in love with the simple GameEvent and GameEventListener script.... Those are real gems... With an addition of a Raise button on the GameEvent it makes testing so much easier... It'd be pretty cool if you could do a video on the new Prefab Variants and nested prefabs... I always find it little confusing on when/how to use them... Keep up the good work Jason...
Good video but I would suggest clarifying the behavior of a separate "setter" function instead of using a property set. Creating a "setter" function does nothing to actually alleviate the original problem you are attempting to avoid - behavior obfuscation. If I'm calling a SetDamage() function I expect it to validate the input and set the value, nothing more. I would suggest a "mutator" function that better expresses the semantics of the function. In this case something like TakeDamage() or ProcessDamage() (or even OnDamage() I guess) would be much better. The only other thing I would suggest is that people get familiar with the basics of the core principles and good practices of both OO design and OO development. Even having a rudimentary knowledge of these topics can help reduce the amount of problems like this that are introduced into code. You may not understand them at first but over time their purpose and application become a lot clearer. Totally diggin the cactus though!
Not sure how much I can agree with #4.. I mean that's the whole point of setters/getters in my mind. If all you are doing is making a setter just set the value then there isn't much point having the setter in the first place.
I think both is right - Jason is right so far, that there shouldn't be too complex behavior in a setter, beside data management and regarding specific data management, I go totally with you, John. A setter is there to trigger data management to prevent that specific steps are missed, like replication, notifications or persistance. Doing stuff like triggering an animation, complex processing or modifying multiple referenced objects within the setter are a no go and belong into properly named methods. So, at least the examples where not choosen thoroughly, as they mix both spheres.
Jason telling all like it is, i found quite funny that on official unity site there some courses which teach to expose public fields trough UI, but well its just more work to deal with states only trough code.
"If you are interested in...." Yes. I am, gimme. For real, I am curious how a pro would do all these things. So i can compare with the way i do and see what i can improve.
Thank you for this, i didnt even know which things i should whatch out for, as always a very clear and elocuent explanation, i appreciate the love and passion you put into this. we can tell Dinamic loading and prefab variants would be awesome!,
I would like to see more unity specific polymorphism. I often run into situations where I'm tempted to use a switch statement or something similar; example. My last project has a single switch statement in the scriptable object on my character's to determine if it's a Rogue, Warrior, or Wizard and then makes new scripts based on an Enum in the ScriptableObject. I recently managed to solve my problem with a combination of more abstraction, addition factories, interfaces, generics and events. But I feel like a more in-depth on using these things cohesively with one another and how to avoid the switch statement anti-pattern specifically would benefit a lot of people. a DOTS series would be amazing too! .... oh and in depth Unity ML Agents!
Another suggestion, instead of using public variable, if the another class is only reading the variable value then use Get declaration. This way you can protect the variable from getting overwritten using a hack tool. If player health is a public variable, then the hack tool can look it up in memory and change the value, thus your player never dies, and thus the "god mod". C# Example: public int PlayerHealth { get {return health; } } private int health;
+1 state Machine. For anyone wanting to play with them, check out the free asset Surge, made by the guy who made iTween, PixelPlacement. It has tweening and state machines.
This is soo funny. I just wrote a state machine to control my code last night. My 1k line GameState class became super modular after that. I don't know if you are releasing this video tomorrow cos I need to verify my method. UI is a plus
Hi Jason. Great video. I did many of the mistakes you mention. Recently I came across a book by Martin Fowler called Refactoring. Now I am no software architect but I am starting to see that its hard to design the games code structure early on. The best way seems to be to constantly look at the code and refactor it when you add new functionality and something you reuse looks off. At the same time the more solutions you know - like the ones you mention in this video, the easier it is for a programmer to apply them early on. Would you say it is a valid approach according to your experience? Thanks!
Nested prefabs are the future. Nested everything is the future. It just works. 2122 alt+x unicode apparently doesn't work in TH-cam comments for creating a trademark symbol, but please imagine that I inserted one following the previous sentence.
Interfaces are useful when you have a part of behaviour which should be in multiple classes. Like IDamageable, IInteractable or IPickupable. The benefit is that you can interact with those Objects only by the Interface. For example in the onCollisionEnter(Collision other): other.gameObject.GetComponent()?.TakeDamage(DAMAGE_AMOUNT);
Hi, i would really like to watch your video about states machine. I am learning to code with playmaker wich is a state machine. But I struggle to know how to structure game logic, and organise code. I love your videos so far as it get into the general design of code. Would really appreciate a state machine approche of code. Thank you for sharing your knowledge!
You mentioned #5 being Giant Prefabs and breaking them down into variants ect ect… Ever used Synty Studios Modular Characters? They throw all the models into one prefab for male/female/and universal. I was actually curious if that was a good way of doing things but after playing with them for my RPG project I ran into strange issues. So far I took that base prefab and made variants of it for both male and female characters...basically just disabling the parts. State machines would be great or give me a modular inventory system to work with.
Hey, Jason! Thanks for your great video. I would like to see a new video about state machines to control game state :) Also, I would like to watch video about prefab variants.
good and sound advice. about the interfaces though, is there a deeper explanation on this? i do not fully understand how i can call the same thing ("Itakedamage") on 2 different classes if they do not inherit from the same base class?
i mean, if the player and crate are based on the same base class and override a shared virtual function, that works. but if they both independently declare a function with the same name, i dont understand how the compiler would allow that.
Can you please make a tutorial on how to load fbx model files and fbx animations separately and make characters animate through coding during gameplay so that only the needed animations are loaded depending on the user interactions.
great video! I'm new to Unity and have a noob question: What's good practice to organize related assest, prefabs, sounds etc? Should I maka e empty GameObject in the hierarchy and drop everything in there? Or should I stuff it in a folder in the Project window? Cheers!
If, for example, I have a class called "humanoid", that has health, energy, etc. Then I create some child classes like "orc" or "elf", is there any advantage over this in using an interface called "humanoid" (instead of just a class)? Great video dude! Your videos are in that sweet point of not being too simple and just advanced enough to understand and inspire to learn more! thank you!
You've probably figured this out by now but for thing is that is that you can implement multiple interfaces while you can only inherit from on class Also there's often the case where for example you want to be able to interact with a weapon but also a door but there's no good common base class in this case that's where the interface comes in and allows us to interact with both.
For making worlds, do you want to use an external tool for the whole thing? Or make objects (like a chair, table, etc), and then make the map in Unity?
Also how would you break a prefab apart based on collision? So when a section of a prefab gets hit it would take damage only on that section of the prefab.
I would like an example of choosing an interface over a subclass. I use interfaces in UI for inventories, but I use sub classes for my take damage. Maybe I'm doing it wrong?
*Timecodes*
1. 0:40 .... Having Game Logic in UI
2. 3:45 .... Having giant classes
3. 6:40 .... Having everything be public
4. 9:10 .... Having setters with side effects
5. 14:25 .. Having giant prefabs
6. 17:05 .. Not using interfaces
7. 20:45 .. Ignoring Garbage Collection
8. 22:30 .. Sharing and Feedback
Thank you.
Thank you.
Awesome, thanks.
Really appreciate it mate
not all heroes wear capes
I would love to learn more about states in game coding.
Where the state machine video?
Me too
Same here...I get the basic gist of it, but managing loading multiple scenes and everything is a shallow understanding at best and something I'm definitely going to need to solidify.
Yeah would love one!
@@ProdigiaGames state machines, basically a list of states. You then use these states to do, "whatever" according to a specific state.
You can create them with many different variable types (array of name, array of bool, array of int, enumerators), as long as each state has their own individual representation (value) inside the variable.
Everyone: State machines.
Yes more state machine plzzz!
Interfaces are also especially useful in the early stages of game development when you don't know EXACTLY how a specific system will be implemented.
You can fairly easily prototype multiple implementations in your code and then "swap" one out for the other to change which gets used in your game at runtime.
The benefit of this is that you won't have to go through all your code and update the references (since they only reference the interface).
This is essentially an example of the "Strategy Pattern".
Great vid Jason!
I recently discovered the Strategy Pattern and I must say it seems the most natural to me now. I was struggling with terrible spaghetti code before. I despise switch statements with a passion now because I was so prone to them in the beginning.
A combination of the Strategy Pattern with SOLID principles and the observer pattern helped me get around that.
@@FullMe7alJacke7 Glad to hear it! Writing well-architectured code is super satisfying, I'm sure you'll agree :D
@@CodeGaff interface support is atrocious in the Editor tough :( found my self repalcing a bunch of them with abstract base classes just to avoid the hastle.
Using too many interfaces too early is a great sign that you have no idea what you’re making and you think if you just abstract enough then the design will come to you without doing the hard work of designing it. Early abstraction is a sin not a pattern.
I think I learned all that the hard way...
One crucial thing I learned in software development is to always ensure your codebase is as testable as possible, you can split your codebase to multiple projects, game engine-dependent and pure classes, so you have more ways to test your game other than built-in game-engine tools and manual testing.
Many say code structure is not that important for games that is known for performance but the small "quick and dirty" solutions pile up over time (technical-debt) and will bite you real hard.
also if someone's interested, look into domain-driven design, no need to implement it, just learn why it is design that way, it made my life easier
Green light for state machine. I would love to learn more. Also more in-depth look into interfaces would be awesome, and unit testing...
"Green light for state machine"
I see what you did there
"is this right? should I be exposing it? should this be public? does it make sense?"
this can apply to so many things other than programming.
I love this.
Video about prefabs (variance and nesting) is a good idea. Thank you!
Yes especially the new 2019 Prefabs which open up a whole new way to share assets (with all the good and bad that can happen)
need more state machine!!!
definitely more state machine please!
An EASY GOING PROFESSIONAL - what a breath of fresh air.
Great honest appraisal, you can always work out the people who really know there stuff, as they don't use the knowledge as a weapon. It was true in the early days of computing and is, as true, now.
I always feel demotivated to code and make games, idk why. Somehow watching your video for 2 minutes motivated me to think of a game and get motivated to work on it. You are a magic man, I don't know how you do that, but I'm not complaining.
Clean up as you go. Never have wiser words been spoken in a programming video.
Initially did a bit of a doubletake, wondering why I was getting a notification of a video by some guy called
Jason Weimann :) You are most definitely the brand so I'm cool with the name change! Great info, as always
Yea I did the same thing because Ive always associated Jason @Unity3d.College but I agree it with the name change...Jason reminding us to refactor.
Great vid!
I would personally be interested in a Unit Test lesson using a real game dev scenario, where the expected answers mostly depend on user input / other entities or functions don't really give a printable answer.
All I can find are tutorials where they explain everything using a "MultiplyBy5()" function.
You should look into Dependency Injection. You can pass a class which is responsible for user inputs for example into the class under test. In your unit test you could inject a custom test class which does fake user inputs for example.
This was a fun video. I wanted to contribute my point of view so I can stop thinking about it and get back to work. Really glad Jason made a video on this, because it helps me highlight important things to keep doing within my own projects, so I thought I'd dump some reading below:
1. @0:40 .... Having Game Logic in UI
Things just work when keeping classes small, there is this moment where the code just comes together and works so elegantly, its a nice feeling that often comes with keeping classes small. Or in other words, maintaining the Single-Responsibility Principle as part of the SOLID principles.
2. @3:45 .... Having giant classes
Ultimately I wouldn't have the Vehicle class implement its own potentials. It would just be a holder/implementer of other potentials that Vehicle know how to use. This way we're still able to obfuscate the unimportant 'inner workings'(which is good) while maintaining the readability of what these potentials are trying to do. It also makes things like 'order of operations' very easy to read and change since Vehicle can call upon its potentials in the order that makes sense to it as method calls.
3. @6:40 .... Having everything be public
Yeah so, I don't make anything public unless making whatever public is part of using that class in general such as a ScriptableObject. I'll always differ to creating a GetMethod that returns my data, and if these GetMethods become unruly I would sometimes wrap the data request with a struct in order to decimate large data calls to single requests. Or, I'll use an interface to expose the data I need since these have to be public, may as well have some readability (and some nifty GetComponent possibilities) to go along with my public data needs!
4. @9:10 .... Having setters with side effects
get and set, I tend to use set to limit a value then create a new value or just have some sort of conditional contingency if the data is sensitive to mutation
get is a good opportunity to implement other strategies of data propagation like grabbing a value from a database, or doing some complex math to return back a value. As such, these gets methods would usually be in a class who's job is to define a data-set that then gets implemented by an object to handle its data.
But honestly I don't really use get or set as I love to practice Immutability for all of my data by propagating my values through the composition of objects rather than reading and writing values. I don't know if this is weird, but I think this is one of the funnest parts of coding :P
5. @14:25 .. Having giant prefabs
This is exactly what I'm working on right now where I have an Attribute system where a base component 'Player' holds onto various other gameobjects such as 'equipment, statsheet, abilities', which then hold onto other gameobjects 'equipment> weaponSlot, armourSlot etc' that then hold onto other gameobjects 'weaponSlot> weapon' and again 'weapon > mods'.
It made me think, did I just make a giant prefab? But no, ultimately, this prefab of player has slots that then propagate additional prefabs which then again grabs a smaller prefab. Larger prefabs do some work, then differ to smaller prefab, which does work then defers to yet another smaller prefab and etc. The ability to change the functions of the core prefab means you just slot in something else.
When swapping out base data from a prefab in order to change enemy01 to enemy07, one really cool way is to just use a ScriptableObject that holds all base values along with images and any other Unity-based variable that fits within the limitations of Scriptable Objects. Scriptable Objects are so easy to serialize as well if you want to store them within a simplified data structure on a database. This method gives the benefit of being able to sort ScriptableObjects by querying data on those objects. It helps to know stuff like what enemy has the highest base attack? Sort through a dictionary of simple values that point to a scriptable enemy, then grab that one and use this within the respective battle.
6. @17:05 .. Not using interfaces
Firstly, from a website MVC point of view, Interfaces are great ways to simplify complex data needs to a very literal question of "I need this data to do my work, I don't care how you do it or who you are, just give me what I need". So with game applications, any UI component should receive some sort of interface as a resource before it updates its information - this is a nice readable way for a gameobject to source predictable info to a component of UI that it doesn't know anything about nor does it care.
7. @20:45 .. Ignoring Garbage Collection
GC its a tricky one where there are beginner related issues and professional related stuff as well. For a beginner these issues show up as null errors where you expect information to exist, but GC has already gotten rid of it. This was and still is a growing pain for me because of how collections work and how complex game calculations can be. Then when it comes to professional use, thankfully Unity has improved the tracking of data within their Profiler tools because even pros can have memory leaking issues.
8. @22:30 .. Sharing and Feedback
See the wall of text above, yay! Also, thanks for the TimeStamps, Coco Nut.
I think its crazy so many people are asking about state machines when it was briefly mentioned in the video. This is awesome, I often preached that all a video game is, is a data layer paired with a state machine. So good on all of you for requesting this as a video, I bet Jason will do a great job on this - spoiler alert, maybe start looking up how to use 'event' and 'Action' ya know.
:D
Thanks for describing Interfaces properly for everyone. Lately I've joined a few in-progress projects that use them incorrectly (i.e. they should be using a class with private/protected variables) and I find it very frustrating
Great info in the video! I want to suggest one missing 'mistake'. And this would be relying on inheritance and creating large inheritance hierarchies. These get quickly very brittle and you and up copying classes around just to change a few lines and you end up with huge chunks of duplicated code. Use composition instead of inheritance whenever you can.
Wow, thank you so much Jason. This is some of the more in-depth tips I've been looking for.
Just having some input on best practices and simple explanations as to WHY. Wonderful video, thank you so very much for taking the time to share. :)
I also would like to see the video on game management state machines. Great video this one btw.
I am always interested in seeing more about implementing state machines.
+1 for State machine to control a game
love to see a different and more generic way than your previous video on state machine (it was great and helped me a lot)
Jason I'd love to see more on state machines. hope we get enough support to promote an updated video on on this.
Thought this video would be more about specific about game dev, but it's all about good programming practices :) makes sence
I love the Logic/Simulation/Presentation architecture. There's a Unite talk about that.
Would love a video on prefab variance, thanks for the offer!
I appreciate the mention of interfaces as I find them vital in cases where a component needs to reference and communicate with another component in the scene (rather than using a concrete class reference). I'd also be very interested in your thoughts on state machines. I've written a few implementations of them in the past and would find a different perspective very insightful.
I should probably use interfaces to get more flexible camera target behavior. I hate having to use a "find player" method or having to reference a transform in the scene controlled by a public field in a component exposed on the prefab. It should be more like the camera has an "I take targets" interface and players, enemies, and other agents have an "ITarget" interface. However, I then have to write behavior which binds the camera to the target I want to use in the scene, but this shouldn't be too hard, and it beats inserting a scriptable object that includes the players last known transform.position into the camera follow script using an exposed public field. ScriptableObjects are super easy to use but they can make things very messy if you use too many of them, especially in the wrong context.
Yes, need video on fsm and not just small example code, but realworld examples. Like Character controller for a beatem up style and how to make them managable
Would definely interested in a prefab variants video. Thanks mate.
It's been so hard to find a good state machine tutorial. They're always in the context of animation and AI. I would kill to have one about game control.
Awesome channel, I'm really learning a lot from this. It can be really hard to find people to learn from who aren't also on a learning path. So this channel is one hell of a find.
16:13 this also sounds awesome. I have not used prefabs all that much but this sounds like something I will be doing in the future.
Some great tips man! Having giant classes I think is the easiest basic seemingly innocuous beginner mistake. I feel a lot of beginner Unity scripting tutorial needs to emphasize decoupling and separation of concern concepts. They're such important concepts that forums and Udemy course just kinda gloss over.
I'm not a professional game developer, but some of this applies to development in general. You should usually follow this whenever you write code. Decoupling, encasulation, not building huge monolyth classes and so on. I'm guilty of having additional stuff in my setters though. Like a property changes a value and triggers change event. I guess this is hiding complexity in a way, but I've not found a better way to do it.
For example. A health property or set method that triggers an event that other things can listen to. If someone else does to much in the event handler, it's the event handler's fault, not the thing triggering the event. That's my point of view, but if you think I should start doing it some other way, please let me know. It's very convenient for UI updates for example.
Yes please about the state machines. Also how to use state machines in an RTS style game - eg. send a unit off to chop a tree, and the unit will chop the tree, collect the firewood and return it to a building.
Please make a video about prefab variance. I think this topic is very important for a good workflow.
Your videos are always a treat to watch.... Have implemented your State Machine scripts in several games and they work like a charm... And I am specially in love with the simple GameEvent and GameEventListener script.... Those are real gems... With an addition of a Raise button on the GameEvent it makes testing so much easier... It'd be pretty cool if you could do a video on the new Prefab Variants and nested prefabs... I always find it little confusing on when/how to use them... Keep up the good work Jason...
Prefab variance sounds fun! I'm guilty of some of these, but prefab variance might help me for prevention.
Yes Jason I'd like to know more or see more example of statemachine for player control and for game states.
I would love to see a video about state machines, how to tie states to animation events, and best practices.
Good video but I would suggest clarifying the behavior of a separate "setter" function instead of using a property set. Creating a "setter" function does nothing to actually alleviate the original problem you are attempting to avoid - behavior obfuscation. If I'm calling a SetDamage() function I expect it to validate the input and set the value, nothing more. I would suggest a "mutator" function that better expresses the semantics of the function. In this case something like TakeDamage() or ProcessDamage() (or even OnDamage() I guess) would be much better.
The only other thing I would suggest is that people get familiar with the basics of the core principles and good practices of both OO design and OO development. Even having a rudimentary knowledge of these topics can help reduce the amount of problems like this that are introduced into code. You may not understand them at first but over time their purpose and application become a lot clearer.
Totally diggin the cactus though!
Not sure how much I can agree with #4.. I mean that's the whole point of setters/getters in my mind. If all you are doing is making a setter just set the value then there isn't much point having the setter in the first place.
I think both is right - Jason is right so far, that there shouldn't be too complex behavior in a setter, beside data management and regarding specific data management, I go totally with you, John. A setter is there to trigger data management to prevent that specific steps are missed, like replication, notifications or persistance. Doing stuff like triggering an animation, complex processing or modifying multiple referenced objects within the setter are a no go and belong into properly named methods. So, at least the examples where not choosen thoroughly, as they mix both spheres.
Yep keep it simple.
state machine tutorial would be a godsend
Good points, but on the interface, didn’t sound like a case for interfaces rather a case against bad abstraction that needs to be overriden a lot
I started saving for your game dev course, hopefully I can get it some day in the future :D
A video on prefab variance would be great!
Jason telling all like it is, i found quite funny that on official unity site there some courses which teach to expose public fields trough UI, but well its just more work to deal with states only trough code.
love to hear more about prefab variants
"If you are interested in...." Yes. I am, gimme.
For real, I am curious how a pro would do all these things. So i can compare with the way i do and see what i can improve.
Thank you for this, i didnt even know which things i should whatch out for, as always a very clear and elocuent explanation, i appreciate the love and passion you put into this. we can tell
Dinamic loading and prefab variants would be awesome!,
+1 for the TuPac Shakur Legacy Book
Yes I want to see more videos of all those things.
I would like to see more unity specific polymorphism. I often run into situations where I'm tempted to use a switch statement or something similar; example. My last project has a single switch statement in the scriptable object on my character's to determine if it's a Rogue, Warrior, or Wizard and then makes new scripts based on an Enum in the ScriptableObject.
I recently managed to solve my problem with a combination of more abstraction, addition factories, interfaces, generics and events. But I feel like a more in-depth on using these things cohesively with one another and how to avoid the switch statement anti-pattern specifically would benefit a lot of people.
a DOTS series would be amazing too! .... oh and in depth Unity ML Agents!
Another suggestion, instead of using public variable, if the another class is only reading the variable value then use Get declaration. This way you can protect the variable from getting overwritten using a hack tool. If player health is a public variable, then the hack tool can look it up in memory and change the value, thus your player never dies, and thus the "god mod".
C# Example:
public int PlayerHealth
{
get {return health; }
}
private int health;
Really thanks for sharing these leading knowledge and reducing the walls where we usually bang. Appreciate it.
Excellent video as always very informative. Waiting for the state machine video :D
Would love to see a video about more complex uses of state machines, ie concurrent and nested
I would love a video about a game state style manager in Unity. It's something I've been struggling with a lot.
I have only found a few videos and Unity's site on state machines and would like more on it. As there's many ways to do it and structure it.
+1 state Machine. For anyone wanting to play with them, check out the free asset Surge, made by the guy who made iTween, PixelPlacement. It has tweening and state machines.
Hi I’m new to unity and your channel and I find it really useful so thanks, keep it up 👍
This is soo funny. I just wrote a state machine to control my code last night.
My 1k line GameState class became super modular after that.
I don't know if you are releasing this video tomorrow cos I need to verify my method.
UI is a plus
Hi Jason. Great video. I did many of the mistakes you mention. Recently I came across a book by Martin Fowler called Refactoring. Now I am no software architect but I am starting to see that its hard to design the games code structure early on. The best way seems to be to constantly look at the code and refactor it when you add new functionality and something you reuse looks off. At the same time the more solutions you know - like the ones you mention in this video, the easier it is for a programmer to apply them early on. Would you say it is a valid approach according to your experience? Thanks!
Nested prefabs are the future. Nested everything is the future. It just works. 2122 alt+x unicode apparently doesn't work in TH-cam comments for creating a trademark symbol, but please imagine that I inserted one following the previous sentence.
Thanks for another great video, Jason - really helpful!
I'd love it if you did a video on Unity's new UIelements system.
I would say properties could also do validation like clamping a value if it's out of the valid range
State Machine Video, Yes please! You are awesome!
i would be very much interested in videos about implementing state machines && using prefab variants.
Interfaces are useful when you have a part of behaviour which should be in multiple classes. Like IDamageable, IInteractable or IPickupable. The benefit is that you can interact with those Objects only by the Interface.
For example in the onCollisionEnter(Collision other): other.gameObject.GetComponent()?.TakeDamage(DAMAGE_AMOUNT);
It's november and I am craving for statemachines.
I'm in for your tips on state machines for game managers.
I'd love to see a video on state machines.
More state machines please!!!
Setters can also notify the UI for updates
Can you make a video about unity Extensions? How can we use them in a best way? (Suggestions: DoTween, UniRx, Easy Save 3 etc...)
That's awesome idea, tutorials about generic usage assets will help a lot. DOTween is one of the best tools for adding "live" to the project
Hi, i would really like to watch your video about states machine. I am learning to code with playmaker wich is a state machine. But I struggle to know how to structure game logic, and organise code. I love your videos so far as it get into the general design of code. Would really appreciate a state machine approche of code. Thank you for sharing your knowledge!
Please do more state machine videos!
You mentioned #5 being Giant Prefabs and breaking them down into variants ect ect… Ever used Synty Studios Modular Characters? They throw all the models into one prefab for male/female/and universal. I was actually curious if that was a good way of doing things but after playing with them for my RPG project I ran into strange issues. So far I took that base prefab and made variants of it for both male and female characters...basically just disabling the parts. State machines would be great or give me a modular inventory system to work with.
Hey, Jason!
Thanks for your great video. I would like to see a new video about state machines to control game state :)
Also, I would like to watch video about prefab variants.
+1 for state machine to manage game state lesson(s)
Your vids are super helpful!!! I really appreciate these.
I would love to learn more about state machine in Unity
I'm interested in prefab variants too
good and sound advice. about the interfaces though, is there a deeper explanation on this? i do not fully understand how i can call the same thing ("Itakedamage") on 2 different classes if they do not inherit from the same base class?
i mean, if the player and crate are based on the same base class and override a shared virtual function, that works. but if they both independently declare a function with the same name, i dont understand how the compiler would allow that.
Did you ever do a state machine video to control the gameplay?
Can you please make a tutorial on how to load fbx model files and fbx animations separately and make characters animate through coding during gameplay so that only the needed animations are loaded depending on the user interactions.
State logic of Game management. Cool
3:30 this sounds awesome. Would you please make an update to your state machine logic?
State Machine for Game Control. Should I have menu states for states before and after the actual gameplay? I'd appreciate vlog on it :)
great video!
I'm new to Unity and have a noob question:
What's good practice to organize related assest, prefabs, sounds etc? Should I maka e empty GameObject in the hierarchy and drop everything in there? Or should I stuff it in a folder in the Project window?
Cheers!
If, for example, I have a class called "humanoid", that has health, energy, etc. Then I create some child classes like "orc" or "elf", is there any advantage over this in using an interface called "humanoid" (instead of just a class)?
Great video dude! Your videos are in that sweet point of not being too simple and just advanced enough to understand and inspire to learn more! thank you!
You've probably figured this out by now but for thing is that is that you can implement multiple interfaces while you can only inherit from on class
Also there's often the case where for example you want to be able to interact with a weapon but also a door but there's no good common base class in this case that's where the interface comes in and allows us to interact with both.
For making worlds, do you want to use an external tool for the whole thing? Or make objects (like a chair, table, etc), and then make the map in Unity?
I want to see the state machine to control the game stuff!
Do state machine please i am doing exactly the mistake you said in my current project
I would love to learn more about state machines.
aand prefab variants
Also how would you break a prefab apart based on collision? So when a section of a prefab gets hit it would take damage only on that section of the prefab.
more please
State machines - yes please!
I would like an example of choosing an interface over a subclass. I use interfaces in UI for inventories, but I use sub classes for my take damage. Maybe I'm doing it wrong?