Thanks for watching the video, I appreciate the support. SUPPORT YOURSELF AND READ THE FOLLOWING: So, in this I don't say what a UML (Unified Modeling Language) is, but at about 3:26, I'm showing a SUPER basic one (because this is only a five minute video I couldn't go more in depth, but will once we get into the Building Placer). It would be worthwhile to research a little bit further into how to diagram one (www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/) because they are incredibly helpful as you set up your projects. It will help you: 1. Delineate the classes/objects you need for a solution. (in this example; the Raycaster, Build Manager, Build Placer, and Input classes) 2. Show the dependencies between those classes (Ex. Buildmanager depends on Raycaster and Raycaster only depends on UnityEngine static functions) 3. If you want to create a really detailed UML, you can show the attributes of each object and their functions. This takes care of a great deal of the planning, makes it simple and easy to read, and helps you to encapsulate information and increase the security of your namespace (not from hackers, but protects you from creating unintended side effects).
I usually get excited when I first start a class and I end up building something monolithic. It is a good idea to think about this architecture sooner rather than later. Good video reminder, thank you.
Thanks for watching the video, I appreciate the support. SUPPORT YOURSELF AND READ THE FOLLOWING:
So, in this I don't say what a UML (Unified Modeling Language) is, but at about 3:26, I'm showing a SUPER basic one (because this is only a five minute video I couldn't go more in depth, but will once we get into the Building Placer).
It would be worthwhile to research a little bit further into how to diagram one (www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/) because they are incredibly helpful as you set up your projects.
It will help you:
1. Delineate the classes/objects you need for a solution. (in this example; the Raycaster, Build Manager, Build Placer, and Input classes)
2. Show the dependencies between those classes (Ex. Buildmanager depends on Raycaster and Raycaster only depends on UnityEngine static functions)
3. If you want to create a really detailed UML, you can show the attributes of each object and their functions.
This takes care of a great deal of the planning, makes it simple and easy to read, and helps you to encapsulate information and increase the security of your namespace (not from hackers, but protects you from creating unintended side effects).
I usually get excited when I first start a class and I end up building something monolithic. It is a good idea to think about this architecture sooner rather than later. Good video reminder, thank you.
I think it happens to all of us. I think monoliths are good for prototyping but bad for long term success.