Corrowland V1 - Revision history

Adamcolton: /* Program Objectives */

2013-12-03T14:25:15Z

Program Objectives

← Older revision		Revision as of 14:25, 3 December 2013
Line 43:		Line 43:
	* basic account management		* basic account management
	* map		* map
			** cave map (more fun)
			** views with proper lighting
	* walk around		* walk around

Adamcolton at 14:23, 3 December 2013

2013-12-03T14:23:34Z

← Older revision		Revision as of 14:23, 3 December 2013
Line 64:		Line 64:

	Option 2 makes path finding very difficult - that's really the sticking point.		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

Adamcolton: /* A thought on Frames */

2013-11-22T20:18:33Z

A thought on Frames

← Older revision		Revision as of 20:18, 22 November 2013
Line 48:		Line 48:
	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.		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 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.

Adamcolton: /* A thought on Frames */

2013-11-22T20:06:11Z

A thought on Frames

← Older revision		Revision as of 20:06, 22 November 2013
Line 47:		Line 47:
	== A thought on Frames ==		== 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.		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,

Adamcolton at 19:42, 22 November 2013

2013-11-22T19:42:20Z

@@ Line 10: / Line 10: @@
 * instance: holds the state of the environment
 * entity: computes entity interaction with the instance and with each other,
 == Program Objectives ==
@@ Line 17: / Line 44: @@
 * map
 * walk around

Adamcolton: 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..."

2013-11-21T21:43:24Z

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..."

New page

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,

== Program Objectives ==

=== 0.0.1 ===
* basic account management
* map
* walk around