Some cleaning
This commit is contained in:
Kayne Ruse
+242
@@ -0,0 +1,242 @@
|
||||
## Notes
|
||||
|
||||
The server holds the ultimate version of the world. The server has to handle log ons, logoffs, and world simulation. To do this, the server needs some sort of database system. I'd like to use something that is quick and efficient, which means that I'd probably end up using SQLite or something similar.
|
||||
|
||||
Monster AI/other world effects should be controlled with customizable scripts/specific file formats.
|
||||
|
||||
Should the server program have a UI? Or at least allow some sort of input at the terminal?
|
||||
|
||||
#### Template Item Information:
|
||||
* item type index
|
||||
* name
|
||||
* effect...
|
||||
|
||||
#### Template Item Information:
|
||||
* item index
|
||||
* item type
|
||||
* quantity
|
||||
|
||||
|
||||
#### Equipment
|
||||
Equipment should be items, but should the item object be placed in the equipment slot when it's equiped? Or should the slot gain certain traits, and the item is removed from the game?
|
||||
|
||||
#### Scratchings
|
||||
|
||||
* active time vs wait time battle system
|
||||
* the terrain you fight on affects the strength of spells and attacks
|
||||
|
||||
Server Room:
|
||||
* constructor
|
||||
* destructor
|
||||
* roomIndex
|
||||
* game map
|
||||
* player list
|
||||
* monster list
|
||||
* combat entrance list
|
||||
|
||||
Multithreading the network packets:
|
||||
* queue
|
||||
* function to push to the queue
|
||||
* function to retreive from the queue
|
||||
* Get the client running first
|
||||
|
||||
|
||||
I read in an article about magic being affected by the environment. What if in the ATB system, magic was affected by what type of terrain you were fighting on? Like, if you were in a volcano, fire magic was more powerful, but ice magic was weaker?
|
||||
|
||||
Unless you had an ice crystal to draw magic from, which makes up for the lack of ice magic sources, but the crystals only had limited amount of uses?
|
||||
|
||||
-------------------------
|
||||
|
||||
source: http://www.gamasutra.com/blogs/EvanJones/20130701/195361/Fewer_Options_More_Meaningful_Choices.php
|
||||
|
||||
Compare the tension created by this dynamic to that of the lack of drama inherent in the item system of most Final Fantasy titles. In those games, characters can suffer from a variety of status impairments that last for many battles (poison, blindness, silence, etc.) Each ailment has its own respective curative item that can cure no other ailments. Because the player is not limited by inventory space, she can always carry a wide selection of curative items at all times. Status ailments never feel particularly threatening: removing them is simply a chore to be dealt with rather than an interesting decision to be made. This also reduces the impact of items that can cure any ailment - why should a player be excited to gain access to these panaceas when she’s always had the ability to easily cure any ailment? The choice of what items to bring is rendered unimportant by the large amount of available inventory space.
|
||||
|
||||
|
||||
|
||||
|
||||
So I'm thinking about Boss Battles for the game. The game will have a drop in-drop out battle system, where if at least one person is still fighting the battle continues, but the people who drop out usually give something up in return (i.e. no exp, lose exp or gold, etc.) This will make permadeath easier on the players.
|
||||
|
||||
Anyway, for Boss battles, I want to encourage several people to take on a boss at once. one way to do this is to make the boss super strong, but I don't really want to rely on that. Another idea was to have several "minion" creatures that the boss uses.
|
||||
|
||||
i.e. You're fighting the Frog King, who summons four Frog Knights at the beginning of the battle. Every time a Frog Knight dies, a new one is summoned, so you're never fighting less than five creatures at once. The battle ends when the Frog King is dead, but the king never attacks you directly, instead summoning new Frog Knights, as well as healing and buffing the knights already on the field.
|
||||
|
||||
To defeat the Frog King, you can't just focus on him, since letting the Frog Knights attack you will almost always result in your death. So to defeat the knights and the king, the best strategy is to stun, incapacitate or draw the attention of the knights to other players, while one person attacks the king directly.
|
||||
|
||||
Now, although this would take a lot of mid level players to bring down, I could scale the number of knights being summoned in addition to the stats of the creatures for when there's only one or two players in the fight. With the drop in-drop out mechanic, I can scale the combat to match the number of players as well.
|
||||
|
||||
Anyway, this is ages away. I just wish development could go faster than it is right now. Making a video game is hard work, doubly so when you're doing it solo.
|
||||
|
||||
P.S. I need to add this post to the GDD.
|
||||
|
||||
|
||||
|
||||
|
||||
-------------------------
|
||||
|
||||
## 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
|
||||
|
||||
The server needs to handle the following content.
|
||||
|
||||
* server name
|
||||
* server version (including host name & modification status)
|
||||
* maximum player count
|
||||
* logon/logoff protocol
|
||||
* 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 upon connection.
|
||||
Resources transmitted include but are not limited to:
|
||||
|
||||
* map data
|
||||
* 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 [Map File Format](wiki/Map-File-Format).
|
||||
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.
|
||||
|
||||
* a singular "overworld", connecting different locations
|
||||
* dungeons, possibly instanced
|
||||
* 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
|
||||
|
||||
This is an ambiguous section, covering several situations.
|
||||
|
||||
* instanced dungeons
|
||||
* player combat
|
||||
* timed events
|
||||
* locational events
|
||||
|
||||
#### Active Entities
|
||||
|
||||
All entities on the server have a unique, unsigned index.
|
||||
|
||||
* players
|
||||
* monsters
|
||||
* combat instances
|
||||
* pirate ships/vehicles
|
||||
* loot drops
|
||||
|
||||
-------------------------
|
||||
## Server Architecture
|
||||
|
||||
#### Modules
|
||||
|
||||
* server metadata
|
||||
* server name
|
||||
* version
|
||||
* distribution (official vs custom/name of the owner)
|
||||
* major.minor.patch
|
||||
* available map packs, resources, etc.
|
||||
* player count
|
||||
* maximum player count
|
||||
* global client list
|
||||
* global player list
|
||||
* global room list
|
||||
* global combat list -?
|
||||
|
||||
#### Client Information
|
||||
|
||||
* client index
|
||||
* 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
|
||||
* client index
|
||||
* handle
|
||||
* avatar
|
||||
* current location (room, coords)
|
||||
* inventory list
|
||||
* equipment list
|
||||
* friends list
|
||||
|
||||
#### Room Information
|
||||
|
||||
* room index
|
||||
* map data
|
||||
* player list
|
||||
* monster list
|
||||
* combat list
|
||||
* loot drop list
|
||||
|
||||
#### Combat Information
|
||||
|
||||
* combat index
|
||||
* room index
|
||||
* player list
|
||||
* monster list
|
||||
|
||||
-------------------------
|
||||
## Client Requirements
|
||||
|
||||
The client needs to handle the following content.
|
||||
|
||||
* user settings (name, avatar, etc.)
|
||||
* logon/logoff protocol
|
||||
* resource downloading/loading
|
||||
* user input
|
||||
* drawing to the screen
|
||||
* playing the correct information
|
||||
* client index
|
||||
* player index
|
||||
* room data
|
||||
* player list
|
||||
* monster list
|
||||
* etc.
|
||||
|
||||
-------------------------
|
||||
## Client Architecture
|
||||
|
||||
#### Scenes
|
||||
|
||||
* 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 system
|
||||
* players
|
||||
@@ -0,0 +1,77 @@
|
||||
## Server
|
||||
|
||||
#### UserAccounts
|
||||
* userAccountID primary key
|
||||
* username unique
|
||||
* password --stored in the database (hashed)?
|
||||
* blacklisted {false, true}
|
||||
* whitelisted {true, false}
|
||||
|
||||
-------------------------
|
||||
|
||||
## Items
|
||||
|
||||
#### Notes
|
||||
* These are static; they're immutable during runtime
|
||||
|
||||
#### GlobalItemList
|
||||
* globalItemListID primary key
|
||||
* itemName unique
|
||||
* itemImage
|
||||
* type {mundane, consumable, equipment, etc.}
|
||||
* maxStackSize {1-max; -1 for false}
|
||||
* maxUniqueCopies {1-max; -1 for unlimited}
|
||||
|
||||
#### MundaneItems
|
||||
* mundaneItemID primary key
|
||||
* globalItemListID foreign key -> GlobalItemList.globalItemListID
|
||||
* TODO: attributes
|
||||
|
||||
#### Consumables
|
||||
* consumableID primary key
|
||||
* globalItemListID foreign key -> GlobalItemList.globalItemListID
|
||||
* TODO: attributes
|
||||
|
||||
#### Equipment
|
||||
* equipmentID primary key
|
||||
* globalItemListID foreign key -> GlobalItemList.globalItemListID
|
||||
* TODO: attributes
|
||||
|
||||
-------------------------
|
||||
|
||||
## Player
|
||||
|
||||
#### Notes
|
||||
* These change as the character progresses and grows
|
||||
|
||||
#### PlayerCharacters
|
||||
* characterID primary key
|
||||
* name unique
|
||||
|
||||
#### Player Statistics
|
||||
* currentLevel
|
||||
* currentExperience
|
||||
* maxHealth
|
||||
* maxMana
|
||||
* currentHealth
|
||||
* currentMana
|
||||
* attack
|
||||
* defence
|
||||
* etc.
|
||||
|
||||
#### Player Equipment
|
||||
* weapon foreign key -> Equipment.equipmentID
|
||||
* helmet foreign key -> Equipment.equipmentID
|
||||
* armour foreign key -> Equipment.equipmentID
|
||||
* TODO: etc.
|
||||
|
||||
#### PlayerInventoryItems
|
||||
* characterID foreign key -> PlayerCharacter.characterID
|
||||
* globalItemListID foreign key -> GlobalItemList.globalItemListID
|
||||
|
||||
|
||||
-------------------------
|
||||
|
||||
#### TODO
|
||||
|
||||
* customizable sprite
|
||||
@@ -0,0 +1,84 @@
|
||||
The Game Map
|
||||
|
||||
This section outlines the game’s map system. This system utilizes pagination to create a theoretically infinite game map, as well as supporting multiple tilesets in the same map. The goal of this design is to create a system with as much flexibility as possible, and simply enforcing a more rigid approach higher in the tool chain.
|
||||
|
||||
Tile
|
||||
|
||||
The Tile class is the basic unit of the map system, and is explicitly a POD (plain old data) structure. A tile has these members:
|
||||
|
||||
X Position
|
||||
Y Position
|
||||
Depth
|
||||
Width
|
||||
Height
|
||||
Tile Index
|
||||
|
||||
The tile’s X and Y positions are relative to their container region’s location. A tile’s depth allows multiple tiles to be drawn at the same location, and in the correct order; tiles with lower depths (including below zero) are drawn first. If a new tile has the same X position, Y position and depth as an existing tile, the old tile is overwritten.
|
||||
|
||||
The width and height members indicate the graphical size of the tile (not actually used when drawing), while the tile index is the specific tile for the sheet manager to draw. A negative value here is considered an error message.
|
||||
|
||||
Region
|
||||
|
||||
The region class has these members:
|
||||
|
||||
X Position
|
||||
Y Position
|
||||
Width
|
||||
Height
|
||||
Tile Container
|
||||
|
||||
Each region in a certain map must have the same width and height, and it’s X and Y positions must be multiples of those width and height values, respectfully. The outcome of this restriction is a theoretically infinite grid of region objects.
|
||||
|
||||
Each region holds a set of tiles corresponding to the region’s bounds. The tiles’ X and Y positions are relative to the regions’, so moving the region will move the tiles as well. A region object is created or loaded when a tile is place in it’s bounds; similarly, if a region has no tiles it should be deleted or removed from memory.
|
||||
|
||||
The exact width and height of a region has no significant impact, other than loading or transmission costs. The width and height of a map can be adjusted as needed.
|
||||
|
||||
Region Pager
|
||||
|
||||
The region pager class has these members:
|
||||
|
||||
Region Width
|
||||
Region Height
|
||||
On New Callback
|
||||
On Delete Callback
|
||||
Region Container
|
||||
|
||||
The Region Pager class holds a series of region objects, as well as creating and deleting them as needed. Every region theoretically exists at any time, so if a non-existent region object is requested, it is created and then returned. This class also has the Prune() method, which removes all regions out of bounds from memory, and the DrawTo method, which takes (among other things) the sheet manager for the map.
|
||||
|
||||
The width and height members must be set before the pager is used, and must not be changed while it still has regions loaded. These are used to create region objects as needed.
|
||||
|
||||
Each pager can also have two different callbacks set: “on new” and “on delete”. If either of these are set (that is, not null) then each region object’s address is passed to these after it is created or before it is destroyed, respectfully. The callbacks are intended to be used for domain specific processes, such as loading or saving data, or even requesting data from a remote server.
|
||||
|
||||
Tile Sheet
|
||||
|
||||
A tileset is a series of tile graphics stored in a single file. The tile sheet class loads a tile set into memory, and provides utilities for drawing them to the screen. The tile sheet class has these members:
|
||||
|
||||
Image
|
||||
X Count
|
||||
Y Count
|
||||
Total Count
|
||||
Begin
|
||||
End
|
||||
|
||||
The Image class is utilized heavily here by storing the graphical data and the tile size. Any file loaded into a sheet object must have all tile images arranged in a grid pattern, and they must all have the same width and height. The width and height must be provided when the file is loaded.
|
||||
|
||||
The X and Y counts are the number of tiles along the X and Y axis of the sheet’s image, and the total count is the number of tiles in the whole sheet (which is equal to the product of the X and Y counts).
|
||||
|
||||
Begin is the index of the first tile on the sheet (default is zero), and end is the index after the last tile (defaults to the value of total count). These indicate the range of the tiles, and are mostly used by the sheet manager. They are also used by the InRange() method, which checks to see if a certain tile is in that sheet.
|
||||
|
||||
Tile Sheet Manager
|
||||
|
||||
This class has these members:
|
||||
|
||||
Tile Sheet Container
|
||||
Range End
|
||||
|
||||
This class is a wrapper around a key-value container, using strings as the keys. Given a specific tile index, this class will draw the correct tile from the loaded sheets, or it throws an error.
|
||||
|
||||
Also, this class keeps track of the end of the sheet’s ranges.
|
||||
|
||||
TODO
|
||||
|
||||
Map File Format
|
||||
|
||||
TODO
|
||||
Reference in New Issue
Block a user