Node Refactor

[NimbusBP1729]

I advocated in single player a while back about refactoring nodes. I think I'm going to start doing all the changes I had proposed back then. This will make the code much simpler.

[NimbusBP1729]

Quoted from:
https://github.com/kyleconroy/hawkthorne-journey/issues/770

#762 requires a standard for node processing since we have a variety of ways of dealing with nodes.

The following is my proposal with a bit of justification:

on the client side we should need only a few things to correctly draw nodes:

Critical parameters in bold

1. type: e.g. token, enemy
2. name a subclass e.g. coin, frog
3. x,y location of the node
4. state: the type of animation sequence we're dealing with
5. position or frame within the current state
6. width, height: height is necessary for drawing objects in 2.5D floorspaces and both width and height are necessary for drawing liquids

NAME

we have absolutely no standard for dealing with the nodes correctly right now.
@bucketh3ad has already volunteered to refactor them.

What we need is the following: every node should have a type and if there are different kinds of this type that can be drawn it should have a name. For enemies, the "name" should be what we currently refer to as the "enemytype". Materials, doors, and weapons all follow this typical convention.

X,Y

We don't want to send the client's x and y position to the server. We will only send keyinputs or buffered keyinputs to the server that the server then processes and deals with. If we want to do additional client side prediction the client should do that without any additional knowledge from the server

source: https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Basic_Architecture_of_a_Client_.2F_Server_Game

This is the general structure of a client/server

POSITION(i.e. location in an animation sequence)

In the proof of concept client/server i send the position within an animation from the server to the client. What do we get from it?

1. we can accurately draw the position of holdables (e.g. the baseball) since these are only known by an agreement between the server's knowledge of the character's location and the character's hand position
   2)without this we would have no idea where to draw a weapon. @jhoff was recently requesting a refactor of weapons that should allow you to rapid fire swinging. without position info we have no idea that we need to restart drawing the weapon on the client side

That being said, if we want to do additional client-side animation when we lack consistent server updates, that's entirely up to the client.

DRAW()

client-side
ideally we should be able to take those 6 parameters and be able to predictably draw a node. nothing else should ever be necessary. If this were the only thing we fixed, we'd be fine. This should be the main goal of refactoring for the client.

UPDATE()

server-side(client-side too if you're using client-prediction)
modifies an object given changes in the environment