Inspirations:
Here are some of the main games that gave me the thoughts of "hey, this would be a cool idea to play around with"
Freeciv: (The Freeciv project)
--- Underlying client-server code design
--- Procedurally generated worlds
--- 2d tile based world
--- Turn based
Globulation2: (Globulation2 Team)
--- Delegating micro-management away from the player
--- Focus on unit development
--- AI
Minecraft: (Mojang)
--- Combination of survival/build attitude
--- Randomly generated terrain and biomes
--- Permission system (more from the mod community)
--- Why whitelists are a good thing
--- Tech tree. There's no tech tree in mc, but the crafting progression influenced how I designed mine.
--- Much of my exposure to game dev is from looking at the open source mods.
--- Community-server relationship
Setting:
The terrain is generated procedurally to make a climate template, then when a new game is started a map is created from the template. The first thing generated is the raw height map; a number of points are chosen to have the terrain raised around it, and sea level is relative to average height. Next, temperature is calculated by latitude and altitude. Finally, ocean currents and temperatures are calculated, and from that the precipitation map is made. The final result is the template file, representing an evenly spread 2d array of points describing elevation, precipitation, and temperature. Alternatively a template could be made by hand or by some 3rd part software; the file format is a pretty simple list of tab separated values. Future server versions may (and probably will) have the terrain generator tweaked and changed, but the format shouldn't change much. The idea is for them to have the basic information to generate a full map, but be easily transferred or modified while being version agnostic. And also be reusable by default.
A game map contains the information for the current game instance: a 2d region map of an of array of tiles, the players involved in the game, the entities, etc. The game map will likely be stored in a light database; my current plan is to use sqlite. The data stored on disk will be the game state at the latest turn. The internal data format may very well be version-specific, and not easily transferable. The region map will be generated by reading a template, and deducing flora/fauna distributions, local weather patterns, rivers, mineral deposition, player starting positions, and whatever else I may dream up.
Plot:
There really isn't much one outside of 'conquer everything'. It's more or less up to server owners and players to decide how a game should be played: cooperatively, competitively, aggressively, passively, or trying to reach some custom objective. However, the overall goal is to survive, build, and thrive on the regional map by collecting resources, growing a population, and building infrastructure.
Challenges will be managing and distributing resources for each player's population, defending against wild monsters (the main obstacle), surviving in the facing of changing weather (affecting things like crop growth), competing and fighting with other players.
Game Mechanics:
When a game starts, all of the players get placed in semi-random locations scattered across the map with beginning stock resources and starting characters. Players placed in less friendly areas will be given more to start with as compensation. Characters are the units of the game and they have traits and affinities. Traits are the ability to do tasks more efficiently, whereas affinities for traits are the ability to learn traits faster. Characters build up traits by doing work in the related field, whereas affinities come from the distribution of parent traits and can be temporarily modified by leader traits. Hence as the game progresses, a player's population starts off generalized and progresses towards specialization. For instance the population of characters controlled by a player based in a cold icy biome would naturally specialize in things like hunting and fighting, while a population in a temperate fertile area would have better skills with farming and building. Population growth is tied to happiness of characters. Unhappy and/or sick characters will not reproduce. What raises happiness is: food surplus, access to multiple types of food, good health, pets, high success rates at getting tasks finished, better housing and resources, and access to luxury goods.
Game time progresses per turn. My idea is somewhere around 1/100th of a year to 1/20th of a year per turn; I haven't really decided. Turns will have a time limit set by 125% of the time it took for the first person to finish after 50% of the players have already finished their turn. The numbers may be configurable, and minimum and maximum limits may be set. Players that finish earlier have their and their AI's actions committed before those who finish later.
Now, there may appear to be a problem here. It would seem that the game would easily get dull and slowed down with long turns that represent a relatively short amount of time in game. It wouldn't be so bad if the turns were much shorter in length, hence the time limits. But there are so many things to get done!
Management (The Central Game Mechanic):
Well, this is where the main game mechanic comes in: leadership and delegation.
So at simple as it can get: a character can do assigned tasks. A task is composed of getting required resources, following a set of steps, and having some end goal done. The internal set of steps can also invoke other tasks. A character does tasks based on priorities. If a character is automated by itself; the priorities are more or less survival. Get food, find/maintain shelter, and that's about it.
Enter the leader, who's job is to look at the task lists of the subordinates, figure out the collective needs, and assign priorities to different tasks. Naturally, the next step is to allow leaders to manage lower-level leaders, with the idea that higher level leaders can look at the needs and abilities of subgroups, and shift around responsibilities and goods. Now, information about what subordinate characters need doesn't come free, and doesn't move around instantaneously. For one, either the leader-subordinate must meet in person, or a carrier must transfer over information about a sub-groups needs, resources, and capabilities. Furthermore, characters have very bad memories. So after the lowest level, record keeping facilities will be needed for more advanced and larger networks.
Thus, as the game advances and the player's population grows in size and abilities to do new tasks, it'll become important to develop an efficient bureaucracy to micro-manage and leave the higher-level decision making to the player. How the characters are organized into the hierarchy of command is left up to the player; the game itself has no notion of predefined governments or economies.
Networking Protocol
:The low-level protocol for communicating with a game server is simple. A client sends a command packet in the form of " | ;", and gets a response in the form of " | ; ; ". All text based, so it's possible to communicate with the server telnet. The echo string is predominately for the client's use; the server just spits back the echo string the client sent to help the latter track packets. The server's responses are all in table form, being as a lot of the data the server works with is tabular anyways.
The server API are the set of commands, and are bound to their string names during run-time. The API commands also have basic information describing their functionality, as well as their associated parameters. For instance, when the client sends "con|/dat/lsf -d /chat/msg;", it is asking the server to display info on the parameters of messaging function in the chat domain, which is the command that clients use to send text to the server's chatrooms. The server responds with "con|Query:name|letter|minArg|maxArg|minUse|maxUse|info:message|m|1|1|1|1|Message to say:room|r|1|1|1|Chat room for message", which pretty printed looks like:[code=nocode:0]Header: Query+---------+--------+--------+--------+--------+--------+----------------+| name | letter | minArg | maxArg | minUse | maxUse | info |+---------+--------+--------+--------+--------+--------+----------------+| message | m | 1 | 1 | 1 | 1 | Message to say || room | r | 1 | 1 | 1 | 1 | Chat Room |+---------+--------+--------+--------+--------+--------+----------------+
The commands are grouped together in domains, and domains can be nested. For instance, account management commands are grouped in /acc. Admin related commands are in /acc/man, whereas non-privileged account commands for player clients to use are in /acc/log.
The server life cycle is more or less to start up, load basic information like command bindings and the account index, load up incomplete games, then sit and wait for incoming packets. Except for time-sensitive jobs, much of the game specific code will be called from the command functions, as opposed to being called directly in the main loop.
The client life cycle is to start up, connect to a server, then log in to an account if available. By default, the only permissions newly-connected clients have on the server is to talk in the main chat lobby, log into accounts, and submit tickets to server ops to create a requested account. So playing on a server is white-listed, but connecting isn't.
Now onto the permission system. Like the command system, the permissions are nested in a tree of domains. Permissions are granted when there is an entry that matches the command name, or any domain containing the command. For instance, to give an account admin privileges over account management, just add the entry /acc/man. Or to give all admin privileges, just add / to their permissions file. Connected clients not logged into an account get the default client privileges set out in the clientPermissions file. Thus this gives the server operators a good deal of fine-tuned control on customizing who has access to what, while not requiring extra code for each special case.
Modding, Scripting, and Extensibility
These features will probably not be worked on until after release, and have low priority. The simplest form of modding is overwriting existing commands or just adding new commands to the API. In the future, I may add the ability to load new/overwriting command functions from dll's as plugins. Command binding is already done dynamically, so this isn't a huge stretch to implement.
Scripting may be done with a simple interpreter that understands some basic operators (add, subtract, string operations, etc), variables and the table data structure (ed accessing specific fields of a row), flow control (eg for (row in table) {*stuff*}), and calling the API commands. Again, low priority, getting the game playable comes first. But batch-like processing would be a nice touch.
