Gathering? Waiting?

Oh, that's certainly hot topic. Countless debates, unlimited flames, and cause of infinite hate, frustration, suicides, recession.


Changes are iminent, be it cooldown time reduction or even changing approach to whole system. We'd like to present you couple of ideas that you might want to discuss - yeah like it hasn't been done before countless of times! Jokes aside, let's check it out.

Scavenging

During early times of open beta, the gathering for resources worked in slightly different manner. You were looking for various materials on the worldmap, there was a chance for particular resource being generated. After you've acquired it, there was no cooldown. This ended in constant entering/looking around/leaving, which was not only rather boring, but also highly farmable. However, the worldmap and encounters are playing big part in Fallout games, so we could tweak that approach, and use it once again:

• attach a chance to various zones to spawn various materials (be it junk, ore or whatever)
• disable ability to reroll material spawn when you force-enter from worldmap (that means you need to wander around and wait for next encounter check)

That leaves us with a system in which we still could calculate the average time in which a player is obtaining particular resource: encounter check is being performed every 5 sec, it's easy to calculate values on that.

What are the pros of such approach?

• no cooldown - or rather, it's being hidden
• corelating materials with encounters, that means, due to the level of difficulty, some zones could spawn high quality resources

How about the cons?

• it's all about encounters once again, may be frustrating to look around with no luck

Hunting

Well, but we could as well stay with current cooldowns, but we need a way for players to reduce them. Somewhat entertaining way, though that's subjective. For that, we could add items that reduce timeout - say food. You could obtain food by hunting (encounters again), or you could buy it at traders. That's additional task your player needs to do, but that's optional (well, some may find it mandatory, if they want to have the most out of it).

Pros:

• additional activities
• a way to reduce cooldown
  

Cons:

• The cooldowns stay (albeit reduced)
  

That's all for now. I think we don't need to encourage discussion, it's unavoidable!

Bases visibility

In previous posts I've explained how we're gonna use the documents stored in faction database (a.k.a. files) to remember various info, such as what bases are accessible, and what are not the the given player (whether it's a member or not).

I've focused on synchronization aspect, and I will follow that in this post, as the technical side of it affects how it's gonna work for you.

This is gonna be our hypothetical player's file:

{

"_id": "scypior",

"faction": "The Unity",

"bases": [ "bunker" ]

}

In this case it's of no importance whether this record is stored in The Unity's database and it's record for a member, or whether it's in some other database and we just want to specify the bases this player can access.

With such file, server is gonna synchronize its data in following manner:
- compare the incoming file with previous one, detect if any new base appeared on the list, or if any base got removed from that list
- take the list of new entries in bases list, fetch their location id numbers knowing their names (checking if such base really exist and belong to that faction), mark those locations as visible for given player
- take the list of removed entries, do the above magic for location id and mark those locations as invisible

Notice the difference to the current system, that was caused solely by the technical changes - the visibility is set/unset when the server synchronize the data, while currently, on the following events:
- invited member enters location (visibility set)
- non-member slain in the base location (visibility unset)

The change in first case, may make players happy actually - no more tedious inviting, everything is done automagically. While I certainly do not like when magic happens in game, it's often needed to avoid frustration (and you've got already shattered nerves...), so it's good.

The other case however, might also be liked (oh no, he may come and kill us in our base, better quickly revoke his access!!!), but I very much liked the fact you needed to kill that unwanted player on your own ground to settle things, so I could think of solution for this, if it is really needed.

What are your thoughts on that matter?

Revolutionizing Faction Terminal Data

This is the second part of the series on crazy ideas for factions terminal. In the previous post I described why the changes were needed, also I've shown why we could be potentially interested in externalizing faction databases and make them sitting on top of CouchDB, thus 'freeing' the data and handing it to the players, while providing html interface for everyone to use.

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

Revolutionizing Faction Terminal

Faction management, isn't it the main and central thing of this game? Or wait, shouldn't it be? After all it's common knowledge, that it's been called Faction Mod from the beginning. And one of the first thing implemented, was that 'handy' faction terminal that allowed you to invite other players to the base, build structures of your gang, store data about outer world (other players).

But it has not worked as expected, and many things changed since then. First and foremost, it was build around the standard dialog interface functionality, due to the limitations that was imposed during that time. Because of that, managing faction became tedious and annoying task. Also, it turned out that players do not need all those functionality - not always they need to have four ranks for their members, sometimes maybe they would like to have more than one leader, maybe they would also like to have their radio channel changing randomly automatically. Maybe they also would like to have customized messaging system, in which everyone could post a message on the terminal, to be later read by others. Lots of possibilities, but the main issue was usability. That meant it required changes, or even complete overhaul.

Lots of time has passed, and the engine has grown up to the point almost everything is possible (with varying amount of work). But still, we have not improved that core functionality - chasing other stuff, or simply because of lack of time.

I started to think about the changes quite time ago, and wanted also to expose that stuff to the world by providing web interface for players (along with account management). First, I wanted to put emphasis on that, so that once registered playername always belong to some account, and it cannot be taken after wipe. And on top of that, I wanted to reimplement the very same functionality we've got in faction terminal, but also expose it to the web interface and store data in some persistent, wipe-safe storage (SQL database to be precise).

I started implementing it, but soon I realized it needs some amount of customization, otherwise it might just fail the same way as old system did - providing some useless functionality, being used only partially etc. Of course, I began to think how to inject some flexibility into it - that seemed to be lot of work. Then I stumbled upon something, that entirely changed my ideas and made me to start implementing it almost from a scratch again.

Document databases, namely - CouchDB.

To those interested, CouchDB is non-relational database, that allows you to store your data in form of documents in JSON format (Javascript Object Notation). That means - no relations, only documents. Hey - that sounds good, after all, faction terminal is just a database where you store documents, right? In traditional SQL approach, you would have something like:

table Factions
table Players

connected with relation 1 to many. Then, if you want to fetch all players records stored in faction A, you need to join those 2 tables to prepare output records. Oh nice, this is what the world is doing since ages, it works. But why to impose such rigidness on that, in non-relational database, you would just create database for faction A, and store documents about players there. Nice!

But that's not all. It turned out that CouchDB, because of the fact its protocol is HTTP, is able to serve HTML (and other HTTP content) directly. So I can build web interface (web application) in it, no need for additional tier, no need for additional dependencies. Great? Yeah, I started to love it.

Now, another surprise - it's designed in a way, that each web application is stored in some database, right? And previously, we stated that we will do it the way that each faction would have its own database. That means, each faction could have its own, fully customized web interface (of course, default one is gonna be provided). And it requires only HTML + Javascript knowledge.

Ok, that all sounds fine, but also it feels a bit dangerous. We are allowing players to store the data they want, and we also want to server (gameworld) react to it in proper way. So we need some way of communication, between CouchDB and FOnline server. Seems hard, but part of it already works.

Hopefully, this is the first part of the series about new factions interface. Please note, that's not yet stated when it's gonna be finalized and introduced. To my excuse, I've got real reasons why it's taking so long:)

In next post we will dissect how it might work and how the data will be synchronized, or maybe I'm gonna throw in some technical details, just for fun.

The Vault Dweller dissects FOnline: 2238!

It took months after the launch of FOnline: 2238 before The Vault Dweller of the NMA decided to try it out. One way or another, his FOnline: 2238 review is finally up on the NMA. The review itself did get old in the meantime, simply because everlasting new features were added recently, while publishing of the review was delayed for the reasons unknown to us - nonetheless, it is good to hear an opinion of such an unbiased reviewer, no matter what.


We appreciate the effort the VD made in order to write this article; the least we can do to show our appreciation is to read it ourselves, as well as to recommend it to you. In the end, we also do hope that our endeavors shall inspire him during his perilous article writing journeys in the days to come.

Development Diary: These damn animations

So, this one is a small one. Everyone is waiting for the next smaller update-- hey, we too! Anyway, to not abandon this place, here is some insight on what is the reason why it takes and took us so long:


Right now, we are fighting some little ugly problems with the animations of killed critters. That is, flipping around on death, not working flamethrower attack animations and so on and so on. This is, in fact, the last thing we have to do until the next update can get out of the cage. We aren't sure if we can handle the flamer attack animation in the short time, but at least killed critters will stop flipping around while getting killed.

Also as the one or the other might have heard already, we are adding a new armor item. It's a sand colored robe, created by x'il (who also worked on the long hair and bald head dude), some of you might know it already from the Fallout modding community.


The robe will be available for cheap money at most of the traders in the wasteland. Let's not be that blue anymore all together! Switch yer bluesuit to the new sandsuit and be a hipster too!

Additionally and as always, we made lots of map changes, dialog fixes and so on. I'll guess various changes on the maps will be the most obvious ones. You for sure will recognize it in the game after the update has been done.

So far, that's it for now.

Stay tuned for more.

WIP: 3D Model Screenshots

To post something new in here, we got three screenshots of some of the new work in progress 3d models for you guys. Animations and models are 100% community work.