honerlaw / archived-traph Goto Github PK

Most things in the game are actions.

Basically for instance you click on food. You eat the food. Clicking the food is the incoming packet. Eating the food (and healing / removing the food) is the action.

Now we don't want PID to be an issue (specifically for combat). Since combat is based on actions we will use a queue to manage actions.

Basically we handle the incoming packet instantly and create actions based on the incoming packet.

We need to keep track of what players have what actions so we can cancel their actions.

Each entity will have an action manager (this handles their actions). Each action gets register with two things. The action manager (so we can cancel / manage their actions / prioritize them). And the global action queue. The global action queue will be looped through every 600ms.

There can only be one action in the action queue at a time per entity.

Here is an example.

Action One is registered with the action manager / global queue. Action Two is then triggered by the player to be added. Since Action One is not cancellable we completely ignore action two (or send out an error to the user).

Another Example

Action One is registered with the action manager / global queue. Action Two is then triggered by the player. Since Action One is cancellable we remove Action One from the queue and push Action Two onto the end of the queue.

So basically it becomes first come first serve type of deal.

Ability to create and load scripts. We want to dynamically be able to update scripts.

Scripts are used specifically for handling incoming packets and doing an action based off of that. Scripts are also used to control the state of different pieces of content (if the content has state).

Also need to be able to access other scripts inside a given script (e.g. allow Woodcutting Script to interact with a minigame script).

Not sure if the above is necessary at all or would be necessary so maybe we can leave it alone.

Script Engines

• Groovy (upside is it is already a JVM language)
• Nashorn (implemented in Java 8 by default - no idea if it can support what we want to do though).

Most likely will use Nashorn if possible (supports what I think will be needed in the future).

Incoming packets can trigger multiple things to happen. An action is simply something that was triggered that cannot be executed immediately (has an initial delay or a post delay) and also can not be trigger in parallel with other actions.

Actions are used for pretty much everything. They are suppose to be as generic as possible so they can be used for a lot of different things. (E.g. opening a skill menu, attacking other entities, talking to an npc).

-- First Come / First Serve
-- Basically we put actions in a global queue
-- The first one in the queue is the first one to have their action executed
-- The players won't know this because the actual update cycle takes place every 600ms
-- So basically we don't loop through each player and update them. When a packet comes in
-- we place an action into the queue of actions to execute. The action is then executed however it needs to be executed
-- If the action has an initial delay we skip it in the queue and move to the next action
-- Once the initial delay has passed we remove it
-- If it has a post delay then we do the same thing and skip it and move to the next action
-- Once the post delay has passed we remove it
-- Only one action can exist in the queue at a time (so if you spam click but already have a non cancelable action it just ignores it).
-- If you have a cancelable action then we can immediately disregard it and execute the next action (insert it into the queue).
-- Every 600ms we cycle through the queue and remove / execute the actions

Entity Updating (Ideas?)

So the player has update segments Each segment consists of one or more blocks These blocks are added to each segment based on flags

So entities have update segments

A segment writes bits (basically we always need to write these bits)

A segment can contain blocks

Blocks write data (bits or bytes) and are optional

Blocks have flags associated with them

Flags may have data associated with them as well

Known Segments (Player)

State (8 blocks) -- Blocks --- graphics --- animation --- chat --- face entity --- appearance --- face coordinates --- primary hit --- secondary hit
Movement (2 blocks) -- Blocks --- placement (teleport / etc) --- movement (stand, walk, run)
Add Player (no blocks)

Implement a way to easily send packets to the client.