Corrowland V1: Difference between revisions
Adamcolton (talk | contribs) Created page with "Basic 2D version using Go. == References == * golang websockets: https://github.com/Niessy/websocket-golang-chat/blob/master/chat.go == Architecture == I am going to write a nu..." |
Adamcolton (talk | contribs) No edit summary |
||
| Line 10: | Line 10: | ||
* instance: holds the state of the environment | * instance: holds the state of the environment | ||
* entity: computes entity interaction with the instance and with each other, | * entity: computes entity interaction with the instance and with each other, | ||
=== Web === | |||
When the server starts up, it loads all the resources into memory. Maybe watches for changes so I don't have to redeploy for every resource change (https://github.com/howeyc/fsnotify). | |||
I want to keep cookies to the minimum possible. If you're not logged in, there's no session. Once you log in, we open a websocket between the client and the server and that represents a session - no need for cookies. | |||
=== Accounts === | |||
Should be super simple. Database to keep track of users. This is account information. Character information is stored on Entity servers. Though we will have to keep a reference to which entity server the player is on. | |||
=== Entity === | |||
Entity servers handle both players and NPCs (hostile and friendly). | |||
Stages | |||
# Update from Instance / Entity | |||
# Calculate views (what the entities can actually see) and broadcast | |||
# Calculate NPCs | |||
# Calculate PCs | |||
# Send update to Instance / Entity | |||
# Wait for Update (perform deferred calculations?) | |||
I need to think about this, because the entity servers are going to spend a lot of time waiting around for the instance server - I'd like to reduce that as much as possible. | |||
The entity servers also form a tree. When and instance has finished computing a frame | |||
=== Instance === | |||
The core data structure of the instance is the map. It also stores representative (but not state) data about the entities. | |||
The instance also controls the timing mechanism for the entity servers. As soon as one frame is finished being computed, it sends out the tick alert to all the Entity servers and then updates all the web servers. | |||
== Program Objectives == | == Program Objectives == | ||
| Line 17: | Line 44: | ||
* map | * map | ||
* walk around | * walk around | ||
== A thought on Frames == | |||
Perhaps we don't need something frame based. Every action takes a set amount of time. When a character completes an action (assuming the action queue isn't empty) they start on their next action. Even if the server takes a little while start computing the next action, we know when the previous action finished, we can start the timer from that point. | |||
Revision as of 19:42, 22 November 2013
Basic 2D version using Go.
References
- golang websockets: https://github.com/Niessy/websocket-golang-chat/blob/master/chat.go
Architecture
I am going to write a number of "servers". Really, these can be run on a single machine, but for scalability, they will be separate scripts running on separate ports.
- Web: Runs on port 80, parses the users input, handles websockets
- Accounts: username, password, id
- instance: holds the state of the environment
- entity: computes entity interaction with the instance and with each other,
Web
When the server starts up, it loads all the resources into memory. Maybe watches for changes so I don't have to redeploy for every resource change (https://github.com/howeyc/fsnotify).
I want to keep cookies to the minimum possible. If you're not logged in, there's no session. Once you log in, we open a websocket between the client and the server and that represents a session - no need for cookies.
Accounts
Should be super simple. Database to keep track of users. This is account information. Character information is stored on Entity servers. Though we will have to keep a reference to which entity server the player is on.
Entity
Entity servers handle both players and NPCs (hostile and friendly).
Stages
- Update from Instance / Entity
- Calculate views (what the entities can actually see) and broadcast
- Calculate NPCs
- Calculate PCs
- Send update to Instance / Entity
- Wait for Update (perform deferred calculations?)
I need to think about this, because the entity servers are going to spend a lot of time waiting around for the instance server - I'd like to reduce that as much as possible.
The entity servers also form a tree. When and instance has finished computing a frame
Instance
The core data structure of the instance is the map. It also stores representative (but not state) data about the entities.
The instance also controls the timing mechanism for the entity servers. As soon as one frame is finished being computed, it sends out the tick alert to all the Entity servers and then updates all the web servers.
Program Objectives
0.0.1
- basic account management
- map
- walk around
A thought on Frames
Perhaps we don't need something frame based. Every action takes a set amount of time. When a character completes an action (assuming the action queue isn't empty) they start on their next action. Even if the server takes a little while start computing the next action, we know when the previous action finished, we can start the timer from that point.