Let's think now about the faction terminal/database, and the data that lives there. Basically, it's all about players. The main part of it is just a list of players - members, and non-members as well. Currently, each player record (let's call it file for future reference) contains:
- faction to which described player belongs to
- status, i.e. his relation to the faction that owns the database
- rank - call it a 'level of importance' for the faction the player belongs to
Notice how some of that data does not really affect gameworld. For example, the status - if the player is the enemy for your gang, the gameworld (npcs, monsters and other script-driven aspects of the game) does not care about that fact. But should it be the terminal of an NPC faction, then such status matters.
Ok, so what we've got here is some kind of file for a player. Essentially, a document, so it should really be a breeze trying to put that in the CouchDB. Using JSON, as this is the notation used for CouchDB, our file would look like:
{
"_id": "scypior",
"faction": "The Unity"
"status": "enemy",
"rank": 4
}*
*Of course the interface will be reponsible for handling this format, the UI layer should look better:)
I think I don't need to get into the details of JSON format, it really looks intuitive.
The first field in our file structure is the _id. It's identified in such way, because this is how CouchDB handle documents, it does not allow you to have more than one document with same id. So, choosing a player name for that field seems like good idea in FOnline case.
The other fields - this is where we are trying to describe the faction the player belongs to, his status within our ranks and his rank in his own structures. For purpose of this example, assume it's record for non-member.
We may fill up our faction database (remember, each faction holds its own database in CouchDB ecosystem) with thousands of files, but what does it really do? Surely, some aspect of it is to store data for players information, but it cannot only serve that case. Game itself might be interested in some of that data. Of course, the most important should be the faction field. Ok, what we should do about it? We need a way for a server to fetch the data it's interested in, and react accordingly. We need synchronization. And we need the server to decide what kind of data it needs.
It definitely needs data describing the faction membership. So how we could work with that data? Surely we cannot just fetch the file document from database, and act upon it. We cannot change the player's faction, just because it was said so in some database, can we? Well, in one case: if the player's faction is the same as the one we're currently grabbing data from, and the document on that player states otherwise. That means someone (someone with permission for that database) has changed the faction on his member hence we need to clear faction on that player (not change it to the one that's in file now).
What about acquiring faction membership? Currently, we need to accept an invitation. This won't change - if player attempts to join some faction, we first are gonna check if his file in that faction database describes his status as invited. Then we can proceed with membership change.
If we're keeping with current system, there is also one field left - rank. As we've said previously, it does not really matter when the database belongs to a gang. After all, those files are read by players, so they might want to set those ranks to any values they want. But say, we're now talking about NPC faction database. The mechanics for reputations in game decrease your reputation with regard to some faction, if you attack its members. The amount of reputation deduced depends on the rank of the victim. So in that case, we should impose restrictions on the values that may be used for members in such NPC faction.
But so far, that's the very same functionality we've already had, let's see how we could implement new functionality.
Multiple bases. Oh yeah, that's something needed. Say, we acquire the base somehow (it doesn't matter how, whether it will be just 'buying' from some NPC (like now), or whether it will be built like a house from resources (not saying something like that is there:) ). Of course we would like to manage the players, that have access to those bases. To recognize a base, we need to name it. Once we've got a name, we may just fill some additional field in the player file, that's showing us to what bases he's got access to:
{
"_id": "scypior",
"faction": "The Unity",
"status": "enemy",
"rank": 4,
"bases": [ "dacha", "bunker", "depot" ]
}
Oh great, not only we are stating that player scypior is the enemy, but also we're giving him an access to our bases? Well, our bad. But that's not important here, we've filled that data, and we want the server to react (show the green circles on his worldmap). For this, the data needs to keep up with the standard of course, otherwise, server won't have any idea what we mean. Synchronization procedure in this case might look like this:
- take the bases list
- check if the names of the bases are describing locations that really belong to given faction we're fetching the file from
- take the player that the file describes
- mark those locations as visible for him
Similarily it should work for bases that are no longer visible for him (some kind of blacklist), it needs to be in different list.
Ok, so far - great. But you may ask - I was saying a lots about customization, about freeing the data and handing it to the players. But so far, the data was needed to be laid down in some standard format, otherwise server would have not know what to do with it, and hence, such additional data was useless.
That's true, because players cannot customize the way server works. What they can customize however, is what the terminal is showing and what it does for them, players. I already said that we may put whatever data we want there, display it in the terminal (by customizing some html) - various messages, notes, other info, but that's not very connected to the gameworld. Would be good, if such database would contain info on some gameworld elements that are of interest to us (and within our permissions). Following ideas are hypothetical, but we could just fill the faction database with lots of data and let players decide what to use and how to use.
For example, imagine we would like to know what items are in which base. If the server would tirelessly help us filling it, we could use such info, and make various inventories etc.
But that may be a lots of data to cope with. What do you think? What would be useful to see out there in those terminals? Or maybe it's not needed at all?
PS. Next time, I may describe some inner details of how one can implement communication with such external source, that could be useful for those of you interested in FOnline modding, or maybe I will follow the musings about the customization, we will see...
Posts
