Reviewing the wiki and the design plans

Kayne Ruse
2013-06-20 15:24:26 +10:00
parent 3f456982ce
commit 474baaf013
3 changed files with 94 additions and 53 deletions
+17 -6
@@ -1,6 +1,8 @@
Welcome to the Tortuga wiki!
This guide should help you to understand this project, as well as helping me to plan out the expected features. This project uses C++11, which is available via GNU (or MinGW) 4.7, or Visual Studio 2012.
This guide should help you to understand this project, as well as helping me to
plan out the expected features. This project uses C++11, which is available via
GNU (or MinGW) 4.7, or Visual Studio 2012.
If this wiki is missing something, it means I haven't gotten to it yet.
@@ -38,16 +40,25 @@ If this wiki is missing something, it means I haven't gotten to it yet.
## Copyright
Tortuga is released under the [zlib license](http://en.wikipedia.org/wiki/Zlib_License).
The current version of Tortuga is released under the
[zlib license](http://en.wikipedia.org/wiki/Zlib_License).
Copyright (c) 2013 Kayne Ruse
This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
This software is provided 'as-is', without any express or implied warranty. In
no event will the authors be held liable for any damages arising from the use
of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
Permission is granted to anyone to use this software for any purpose, including
commercial applications, and to alter it and redistribute it freely, subject to
the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software in a
product, an acknowledgment in the product documentation would be appreciated
but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
+76 -39
@@ -1,4 +1,14 @@
An unmodified client must be able to connect to any server, be it vanilla, custom or modded.
### Overall Requirements
An unmodified client must be able to connect to any server, be it vanilla,
custom or modded.
A server must allow the client to operate correctly.
If any information causes issues, it must be resolved.
If the source of the issue is the vanilla software, than that is the
developer's responsibility to bring the software into line with the expected
features.
If however, the problem is caused by modified software or assets, than it is
the responsibility of the server operator to resolve the issue.
-------------------------
### Server Requirements
@@ -6,31 +16,41 @@ An unmodified client must be able to connect to any server, be it vanilla, custo
The server needs to handle the following content.
* server name
* server version
* server version (including host name & modification status)
* maximum player count
* logon/logoff protocol
* maintaining the client list (dropouts)
* persistent player data
* maintaining the client list (handling dropouts)
* persistent player data (in a database or custom format)
#### Game Resource Distribution
If the client lacks a resource, the server needs to transmit that resource to the client.
If the client lacks a resource, the server needs to transmit that resource to
the client upon connection.
Resources transmitted include but are not limited to:
* map data
* tilesets
* sprites
* sound effects
* music
* graphical assets
* tilesets
* sprites
* audio assets
* sound effects
* background music
* scripts
* AI scripts
* locational triggers
#### World Maps
The maps on a server are called rooms. For the data format, See [maps](wiki/maps).
The maps on a server are called rooms. For the data format, See
[maps](wiki/maps).
This is an example of the structure that a server's world can have. This isn't
a requirement, but it can offer the easiest solutions.
* overworld, connecting different locations
* a singular "overworld", connecting different locations
* dungeons, possibly instanced
* player owned pirate ships, which in turn can travel around the sea
* any numer of possible rooms running at the same time
* collision detection in each room
* player owned locations, like pirate ships, depending on a server's theme
* any number of possible rooms running at the same time
* each room is it's own little world
#### Game Events
@@ -48,7 +68,7 @@ All entities on the server have a unique, unsigned index.
* players
* monsters
* combat instances
* pirate ships
* pirate ships/vehicles
* loot drops
-------------------------
@@ -57,7 +77,7 @@ All entities on the server have a unique, unsigned index.
#### Modules
* server metadata
* name
* server name
* version
* distribution (official vs custom/name of the owner)
* major.minor.patch
@@ -67,23 +87,24 @@ All entities on the server have a unique, unsigned index.
* global client list
* global player list
* global room list
* global combat list
* global combat list -?
#### Client Information
* client index
* channel
* address
* last contact time
* ping count (number of times this client has been pinged, disconnect if it's too high)
* player index
* channel/address
* last contact time (ping/keep alive)
* ping count (number of times this client has been pinged, disconnect if it's
too high)
#### Player Information
* player index
* username
* avatar index
* current location
* client index
* handle
* avatar
* current location (room, coords)
* inventory list
* equipment list
* friends list
@@ -95,43 +116,59 @@ All entities on the server have a unique, unsigned index.
* player list
* monster list
* combat list
* loot drop list
#### Combat Information
* combat index
* room index
* player list
* monster list
* origin room
-------------------------
### Client Requirements
The client needs to handle the following content.
* user settings
* user settings (name, avatar, etc.)
* logon/logoff protocol
* resource downloading/loading
* user input
* rendering the resources
* drawing to the screen
* playing the correct information
* client index
* player index
* player list
* monster list
* room data
* player list
* monster list
* etc.
-------------------------
### Client Architecture
#### Scenes
* SplashScreen: start of the program
* MainMenu: program hub
* OptionScreen: configuration saved on exit
* Lobby: find available servers
* ping the network
* phone home
* InWorld: the player is on the map
* InCombat: the player is in combat
* SplashScreen
* start of the program
* load the boilerplate resources
* display the kr-studios logo
* MainMenu
* program hub
* OptionScreen
* custom config saved on exit
* Lobby
* find available servers
* broadcast to the network
* phone home -?
* InWorld
* the player is in a room
* walk around the map
* communicate with others on the map
* InCombat
* the player is in combat
* return to the original room when finished
#### Modules
* Map Loader
* player
* map system
* players
-7
@@ -1,11 +1,4 @@
* Each client needs to know about each other client now.
* Have multiple players moving around the server at the same time
* keep the docs up to date!!!!!
* Player's internals a weird.
* clarify some of the names in the server project
* reimplement the server's time system.
* Overall, I think the server needs restructuring
* zero the packet data?
* Update the networking outline
* I should really use "index" instead of "ID" for naming things
* What if a bounding box could have a vector added to it?