Видео

That's because I don't follow that specific coding convention for my own projects. I find it adds some useless noise. Years ago, it might've been useful but nowadays, IDEs make it easy/fast to peek at the declaration of a class/interface. Furthermore, I come from a C++ background where interfaces aren't really a thing (at best, classes with only pure virtual methods) so it never quite became a habit. That being said, if I work with a team that uses that convention, so will I.

​@@fluffygamedev From what I understand, the "I" prefix helps to distinguish whether you're inheriting from a class or from an interface. Like class CustomClass : IDamageable would be different from CustomClass : Damageable. (Damageable could be a monobehaviour abstract class) It's understandable if you don't use it in your own projects, but i believe it's a good practice and it should be worth adding/mentioning in your tutorial.

Yes

Heya! You are actually right, I was using xNode before I planned the reboot. There were a couple things I didn't like with how it was architectured. Prior to that, I had actually planned to use Bolt but quickly realized I didn't quite fit my needs. What I needed was merely a tool to have some visual representation of the dialogue data. Whereas Bolt/UVS brings so much more since it's for Visual Scripting. Now of course, that can be extremely useful and can make extending the dialogue edition Easy. However, on the other hand, I feel that having an overly generic tool can hinder specific usages (since the UX is planned to be generic) and can also cause some performance overhead. I have heard however of some Unity supported API to make nodal editors. It's still in experimental but I'd like to have a look.

Thank you ! To be honest, there are a couple things I'd change such as the fact that there are too many scriptable objects. 😅 But still, I'm glad you found this tutorial useful. 😁

As I said, units may not be the perfect example to illustrate the use of visitors. To be honest, normally, I'd most likely use something like DOTS to implement units (or some other Data orient Approach). That being said, you point is a good one! :) Your solution would definitely work. Plus, it'd help separate generic unit behaviours from specifc behaviours. Come to think of it, Units could benefit from a Flyweight pattern. We could have the logic in the flyweight class, the intrinsic data in a scriptable object, and the extrinsic data in the unit class. Regardless, the point i wanted to make here is that with the Visitor pattern, we can easily add behaviours to all classes of a hierarchy without having to modify the classes in said hierarchy.

Technically speaking singletons are meant to be used when we want to restrict a class to having a single instance. So should we want multiple channels (ex: audio channels), using a singleton would make less sense. That being said, nothing stops us from hardcoding multiple static instances. Regardless, I agree, in many cases, we just want one channel. In those cases, it'd be perfectly alright to use a singleton.

I'm glad this was helpful. If there's even the smallest thing you'd do differently, feel free to let me know. ;)

I'm glad this tutorial was helpful ! :) If there's anything you think should be done differently, I'd be curious to know. 😁

Thank you for the kind words! I found that not many gamedev channels explained "applied" software architecture. That's what motivated this channel. 😁

That's a very good idea ! I'm adding that to my roadmap !

@@fluffygamedev thank you! I really can't wait to see it. Also, are your road map and future series plans public or just something you write for yourself? I'd love to be able to see what you plan on putting out next

@@izzydev05 Technically yes. It's pinned on a bunch of social media accounts. But I don't advertise it all that much. Here's the link: trello.com/b/aRbntrIi/fluffy-gamedev-roadmap

Thank you ! 😁 If there's a specific subject that you want me to cover, do let me know.

you could make so a charakter has also a picture shown when he speaks. and the picture of the oponent he talks to should be on the other side of the textbox

Found this video after a lot of head-scratching following your original video. I'm a novice and much of the system you've created goes over my head for now - but I'm absolutely stuck on the m_CurrentNode being null when I try to initiate dialogue (CanStartNode() is the exception point). I brute forced currentNode to be "m_CurrentNode = node" above CanStartNode check, but then the dialogue breaks on the end rather than beginning. I know it's easier said than done - but I would like the next video to better explain the process/have no red herrings. I initially implemented most of your flowstate scripts - not realising they weren't part of the tutorial per se. I would recommend that if a component or script is not part of the tutorial that the footage is re-shot to exclude it completely from the footage. Viewers like me are watching, and then re-watching pausing and unpausing every 1-2 seconds - the voice explanation will often be lost in this process. On-screen labels and text explanations would be an effective way to include more optional information without overwhelming the viewer. As it stands now, I have no idea where or how to initialise m_CurrentNode to = the first node. I can probably work it out with enough trial and error. Lastly, a lot of effort for you but hopefully worthwhile too: It would be great to see a companion video for each core tutorial video where you have a 2-up screen going through tick-by-tick how the code executes on the left, and how the game looks at that point in the code on the right (maybe 3-up if there are inspector elements to view). e.g. m_CurrentNode is given the value "here", which then feeds into this class, etc etc. I could use such a thing to diagnose where I've gone wrong. At any rate - the confusion says more about me than you. I like what you're doing here - showing systems that are actually good rather than ones that work well enough for a youtube click but end up chugging your project or being incredibly limiting. Subscribed!

If that can help, you can find that file on github. github.com/FluffyGameDev/DialogueSystem/tree/main/Assets/Scripts/UI/Dialogue I usually don't elaborate too much on the UI on this channel since interfaces can vary greatly from one game to another. But I guess I can talk about them at least a bit more. 😅

Let's just say I have a few plans regarding edition. It may take a while for me to release a tutorial on that (since there are other videos I need to do to explain nodal edition). But very soon, I'll post an announcement regarding the future of the dialogue system.

@@fluffygamedev cool, looking forward to it!

Very good question! I don't have a final answer to that yet, but here's what I've come up with so far. One problem we have to solve here is that we can potentially have as many health bars as we have enemies. In practice, we don't have to display all of them. For example, we can display only the health bars of closest enemies in the FOV. Or perhaps we can display only the healthbar of the focused enemy. All of that is decided by the game design. Regardless of the design, if we want to use event channels, we'll need some way to match Health Bars to the right channels. So one thing we can do is have enemy entities create their own health channels. And when we want to display that enemy's health, we get its health channel and have the health bar listen to it. I'll have to think some more about this. In the mean time, I hope this helps. :)

@@fluffygamedev Thanks for the response! Do you think it would work to attack an int to the event call that relates to an ID? like we get a call for ChangeHealth<int ID> and cycle through all the IDs to find the correct object with that ID? I'm gonna try it out and see!

@@TheIronicRaven It definitely could work. It's worth trying.

I have sooo many plans !!! XD Data Components and a Save System are indeed among them. ;)

Fluffy GameDev awesome I’ll keep an eye out for them.

Glad to be of service ! 😉

Damn ! Time goes too fast ! I'm pretty sure I'll have something ready by may. But yeah, so far, my 2022 plans haven't been too successful... 😅

Mostly lack of knowledge in C#. 😅 (I'm a C++ programmer by career) In any event, thank you for pointing that out ! Guess have to update all my projects !

@@fluffygamedev there are more options, you can use public C# event, private C# delegate + public methods for Add/Remove listeners or UnityEvent.

I agree. I plan on doing a refactor of this system. One improvement I'll do is to have one node type to display text. I may still have extra node types. For exemple, nodes that trigger events or nodes that check conditions.

@@fluffygamedev cool

The game is called Iconoclasts! Great game btw!

Good question ! The way I'd implement that kind of inventory is a bit counter intuitive. The idea is that that kind of inventory differs from others only by its UI. The back end (the Inventory System) does not care about data like the position of the items in the inventory. That's some UI specific data. As such, the way I'd implement this type of inventory, the slots would not correspond to the individual squares in the inventory grid but rather to the various item stacks within the grid. As such, The number of slots could change as the game progresses. For example, and empty inventory would have 0 slots. But an inventory with 7 different item stacks would contain 7 slots. In practice, to implement this kind of inventory, I'd have some UI-specific class to map item stacks/slots to their position in the grid. The dimensions of those stacks could be in a DataComponent in the Inventory Item GameObject (see part 2 to find out more about those). I hope this helps! :) If you want we can discuss all this further on Discord. ;)

@@fluffygamedev I sort of get what you're saying, but I am a total noob so a lot of it went over my head. I'd feel really guilty bothering you about it more than this, since I'd need explanations for basically everything and that's a bit too much work to ask of someone lol It at least gets me sort of in a direction to start looking.

If there's anything I can do to make things easier, feel free to contact me on Discord. ;)

I may have exaggerated a bit on that intro. ^^' Using ifs that way can be alright. In the end, I guess what matters is to know various solutions to a problem. From there, we can make an informed decision based on the amount of time we can spend on the game and how much that code may change in the future.

Thank you very much! This means a lot to me. :)