Why do we even have a parent class if we are just copy and pasting a lot of the code from Player’s scripts to Enemy’s scripts?
There are sections of code that could be refactored back to the base State class. The challenge is that reliance on the stateMachine is tricky because some components are in the PlayerStateMachine but not in the EnemyStateMachine.
There are a couple of ways around this.
You could put components like ForceReceiver and CapsuleComponent to the StateMachine class… This would allow State to access them.
You could take common methods in PlayerBaseState and EnemyBaseState and parameterize the references. Here’s an example with FaceTarget
protected void FaceTarget(Transform target, Transform transform, float deltaTime, float rotationDamping)
{
if(target==null) return;
Vector3 lookPos = target.position - transform.position;
lookPos.y = 0;
transform.rotation = Quaternion.Lerp(transform.rotation, Quaternion.LookRotation(lookPos),rotationDamping * deltaTime);
}
With this method now in the State class, you’ll have to pass in the transform of the target, the transform of the statemachine, the deltatime and the rotation damping to the method. For example, in PlayerTargetingState()
FaceTarget(stateMachine.Targeter.CurrentTarget, stateMachine.transform, deltaTime, stateMachine.RotationDamping);
Lastly, you could put these convenience methods in StateMachine itself:
public void FaceTarget(Transform target, float deltaTime, float rotationDamping)
{
if(target==null) return;
Vector3 lookPos = target.position - transform.position;
lookPos.y = 0;
transform.rotation = Quaternion.Lerp(transform.rotation, Quaternion.LookRotation(lookPos),rotationDamping * deltaTime);
}
In which case, you would call FaceTarget like this:
stateMachine.FaceTarget(stateMachine.Targeter.CurrentTarget, deltaTime, stateMachine.RotationDamping);
or in the Enemy states
statemachine.FaceTarget(stateMachine.Player, deltaTime, stateMachine.RotationDamping);
1 Like
Mmm this is not a good example of what I mean.
I’m talking about how similar say the two impact state classes are, or the dead state classes are. We are talking about a whole class copy’n’pasted with one line of code difference. I think if you are doing that there is something wrong.
There is very little difference with how the player character and enemy character behave here. I think a lot of the coding can be in like “parent” state classes as well as in the parent state machine.
For example both character can have a target, just for the enemy the target is always the player, and in the player we are adding an extra step of introducing a “targeter” class. Seems this could just be shared in the parent, instead of being totally separate.
Just look at the Enemy State Machine and Player State Machine, and count how many variables we declare in the first 20 or so lines that are identical across both classes.
This goes for the methods too. Like you can have a child override or add to it’s parent’s methods. If the course introduces parent/child classes it should defiantly be mentioning and using that. Instead of constantly just “oh we are going to copy and paste this from the other character and change one line”.
I understand these classes can have students that have never made a game before so they need to be simplified. But I feel at times they are oversimplifying and in the process passing down bad habits/precedent to students. I don’t think coding is about trying to get to the highest line count. And in the context of getting a job in the industry what employer is hiring someone that is wasting so much time doing things like this.
Which is essentially what I was saying. I was showing examples of one specific method that could be pulled up to the State or StateMachine class.
I didn’t say you weren’t saying it, I said the example you gave was not the best.
Can I please get a different “Teaching Assistant”?
Hi Final_Synapse,
I am sorry you feel that the course was not up to what you were expecting at a coding level.
One of our key principals is to teach people to code by making games not how to make games so the courses come at different levels and this being an entry level teaches the basics in a method that is easily understandable by beginners.
You may find that our RPG course if you choose to continue with our courses is much more structured in the way you would expect for an intermediate course rather than this course that is base on a stepping stone to the more intermediate coding structures that would used in the gaming industry.
If you are still unhappy with the course purchase you have your guarantee with udemy or with our support to that you can contact either of us for a refund of the course.
Marc Carlyon
Support Leader
I understand that the code could be refactored to support a more polymorphic/inheritance based structure but, a point I would make is and as others have said, it’s easier to learn for someone not familiar with such programming concepts and also, by typing the code multiple times, it gives you more time to overview what’s happening at different sections of the algorithms.
Although familiar with programming fundamentals, I don’t mind learning in this manner and then later refactoring the code into my own style, for me, what I’m getting out of this, is the solutions of common game development challenges, which I can then expand upon or fall back on if I should need to in my own projects.
Also I started this course shortly after release and then took a break from my project, when I came back, it was refreshing to go over the code a second time as reminder of where I left off.
Overlooking the simplification of class structure (although, I imagine newer developers would still consider it difficult to digest) I think it would be wrong to not acknowledged that, there is still a lot of really beneficial things to be learned/taken away from this course so far
3 Likes
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.