Should the Health Manager tool be used for large projects?
Hey everyone,
I have been working on a project over the last few months and have been focusing on making scalable gameplay mechanics. I want to make sure that it is easy to add things like items, characters, menu options, and other gameplay elements. I am in the process of revamping all of my logic before moving forward.
I would like to get some input regarding use of the Health Manager for larger projects. I only ask this because some of the other dreamers that I follow generally do not use them for storing player and/or NPC health values. On the puppet for the main character gameplay I have already replaced most of the default puppet logic with my own, and the Health Manager is one of the only remaining default components.
Currently, I really only use the Health Manager to send a signal that the player is receiving damage. I also have a test dummy that uses it but again only to signal that it's taking damage. Other than that, the current health is stored in it's own variable and the max health is dependent on the player level. Also, the health must be stored in a persistent variable and set when entering another scene anyway, which is a bit inconvenient. I am highly considering removing all of my Health Managers before moving forward, and just using variables to manage all of the health values.
Any way let me know what you guys think, and please let me know if anyone has encountered any issues from either using them (or not using them) for large game projects. Thanks in advance!
-
As you say, the health manager detects health modifications. This is by far the most efficient and reliable way to transfer damage to targets, so you can just use that.
Unless you test some piece of logic and find it causes problems, I'd recommend just using that logic. Don't replace something with something more complicated if you don't need to, you know? Assuming that any logic you see has to be rubbish and bad for your project isn't a good way of going about building, or even optimising.
Test stuff, run experiments based on the expected uses of that logic, and expected scale of how much of that logic will be active at any given time. Base your decisions of how you want to change the logic on real data. Then a) you can make your own mind up on whether you "should" or "should not" use a given logic setup and not look for someone else to tell you, and b) the decision will be made for your specific circumstances instead of what someone on the internet who has no idea what your project involves said.
In summary: there's nothing inherently bad or inefficient about any gadget or tool in Dreams. You can tell that by the fact it's in Dreams. What makes a gadget bad is if it's not doing the thing you need it to--in which case scrap it and use something else that does the thing you need it to. What makes a gadget inefficient is if it has performance issues or uses too much thermo for what you need it for--in which case, see if you can change its settings to optimise performance, or use another method that uses less thermo. Until you *know* it's bad for your project, there's no need to worry about it.
Anyway... I hope this helps you move forward with your project.
-
Sounds good, thanks for the feedback. I had decided to go ahead and continue using it for now. After going through everything it looks like it wouldn't be that much work to go back and move the health systems to over to variable-based systems anyway, but that probably won't be necessary.
Please sign in to leave a comment.