Corrowland V1
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
- cave map (more fun)
- views with proper lighting
- 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.
We may also be able to better utilize compute cycles with a look-ahead; if we know an entity is projected to follow a path, we can look ahead for collisions. As entities come close to each other, we can ear-mark them for collision checks or mark that they cannot collide for X frames.
Views
Option 1
All tiles in the game fall into two categories - viewable and non viewable. Viewable tiles are computed when the map is created with a flood algorithm starting from the spawn point(s). Any tile that can be reached, is viewable. Players (and non-players) can request the full map at any time (that version may not be up-to-the-second accurate).
As entities move around, the map reveals details not available on the viewable map. This includes resources (so a mineral vein will appear as rock on the over-map), items and other entities.
Option 2
No over map is available. Players can only see what is immediately viewable.
1 vs 2
Someone will eventually make a fog-of-war version which will begin a cascade of requests. Maybe that's ok.
Option 2 makes path finding very difficult - that's really the sticking point.
Regions
There will be a number of regions that people can jump between with portals. This is necessary because it is not a 3D game.
- Overland: Has trees plants, is always lit (or day/night cycle)
- Caves: dark, lots of rocks
- Ruins: smaller than caves/overland, brick walls