New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HealthComponent #1
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Throwing in some general comments hoping bits of it might be useful :-)
Another suggestion: Make a paired draft PR for the engine that removes anything this PR adds to the Health module, then update it over time. No intent to merge the engine PR for some time, but it might be good for visibility and being prepared. Then finally when Health is ready switch the engine PR out of draft mode (and/or recreate it fresh depending on how stale that branch went)
import org.terasology.network.Replicate; | ||
import org.terasology.rendering.nui.properties.TextField; | ||
|
||
public class HealthComponent implements Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well-written class level javadoc can be useful in very central components like this. Think long term: what might somebody like to see when they're fishing around for relevant components and run into Health?
@TextField | ||
public int currentHealth = 20; | ||
|
||
// Regen info |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer one-liner javadoc comments IMHO and document each field you think can be meaningfully enhanced. Example:
`/** Next tick time that will trigger regeneration */
|
||
public boolean destroyEntityOnNoHealth; | ||
|
||
public HealthComponent() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a practice it may be wise to leave a comment on the no-arg constructor to highlight the reason it is here: if it isn't and there is an arg-constructor then the "invisible" no-arg constructor disappears. That then breaks stuff as some of the magic relies on there always being a no-arg constructor :-)
public HealthComponent() { | ||
} | ||
|
||
public HealthComponent(int maxHealth, float regenRate, float waitBeforeRegen) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figure this constructor is here because it already existed - I wonder how frequently it is used and if it is really justified for it to exist? It might be a good practice for us to always encourage the pattern of setting whichever exact fields you need rather than use a custom constructor
HealthComponent health;
health.maxHealth = 123;
health.regenRate = 42;
//apply the component to something
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After searching in the mega workspace, I couldn't find any usage of this constructor. I am hence removing this constructor.
And, since the unique constructor is removed, the default constructor is not needed explicitly.
@@ -0,0 +1,70 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if this test should be here or in the MTE module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some more comments but mostly trivial / future thoughts so not going to block merging from it. Will push to merge without a merge commit so you can continue in your next branch without any updates needed. Can address any actionable review comments in a new commit during that effort :-)
Nice tests! They actually work for me for some reason, without hacking my workspace. I don't understand, but ... ¯_(ツ)_/¯
Haven't tested in-game as I don't know if that's ready yet.
private EntityManager entityManager; | ||
|
||
@In | ||
private org.terasology.engine.Time time; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for having this fully qualified?
@@ -4,6 +4,6 @@ | |||
"author" : "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to toss an author name in there :-)
|
||
} | ||
|
||
/** Handles DoHeal event to increase health of entity */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One-liner javadoc is good for simple fields, but methods should always use the expanded version including doc for parameters etc :-)
import org.terasology.entitySystem.event.Event; | ||
|
||
/** | ||
* Send this event to an entity to heal it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"to heal it ..." - fully? Or could a negative number be hurtful instead? Maybe that's covered in the System
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A negative value is supposed to cause damage, but not working at present. Will update the Javadoc when the issue is solved.
* Event sent upon an entity reaching full health if previously on less than full health. | ||
* | ||
*/ | ||
public class FullHealthEvent implements Event { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might this be more descriptive as OnFullHealthEvent
?
Would also put it more in line with OnHealedEvent
- although then I'd wonder if this would work better as OnFullyHealedEvent
plus wonder what the implications of both triggering would be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming it as OnFullyHealedEvent
, seems more apt for full health event.
} | ||
|
||
/** | ||
* @return The amount by which health changed. This is capped, so if the entity received 9999 damage and only had 10 health, it will be -10. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it though? This method just seems to blindly return the change - I don't see any capping here? It could happen elsewhere but then that'd make this javadoc somewhat presumptuous :-)
It also helps to still write out both statements separately - the method description and the return value. Sometimes that can be tricky to write in a meaningful way split into two fields but since they each go to a different place in displayed javadoc it is ideal to have both (IMHO anyway)
An alternative might be to throw a boolean into a single event that indicates whether or not it resulted in a full (or partial) heal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it does show the changed amount because the capping is done not in the event but in the method calling the event.
https://github.com/Terasology/Health/pull/1/files#diff-e0c50392da47b79c5d45c9c66a5ec5feR112
So, i think the javadoc should be modified to say so.
event.subtract(5); | ||
event.multiply(2); | ||
}); | ||
// expected = ( initial:10 + 10 - 5 ) * 2 = 30 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rewrite this ever so slightly for clarity. Like:
// expected = ( initial:10 + 10 - 5 ) * 2 = 30 | |
// Expected value is ( initial:10 + 10 - 5 ) * 2 == 30 |
For now, just moved the HealthComponent of Logic/Health to the new module.