Introduction:

Hello future readers of this blog. It has been some time since I discovered that writing down my ideas and concepts helped me to get the whole picture of a project that I would like to bring to reality. That's why I have decided to start a series of posts that are going to be mostly synced between my website and Gamasutra.com about my future game (Emancipation) but instead of making it only for myself I'll make it public so others can learn from my experience.

These are the tools I'm using right now, depending on how development goes I could change or remove them.

For the client I'll use the next tools: Allegro5, SQlite3, Protobuf and tinyXML2.

For the server I'm just going to use SQlite3, Protobuf and tinyXML2.

Programming language: C++.

So what is this Emancipation game anyway? Emancipation is an in development strategy game about building and managing stores, companies and public places on a persistent online world. You enter in this game as an entrepreneur of a new society. Among the building you can place and manage are: food shops, clothes shops, private schools, hardware shops, etc... In this game the people (bots with AI) depend on the businesses (players) that are created, and the businesses depend on each other.

There is a constantly changing and improving article at the main page of the site explaining what it is so I'm not going to rewrite that here. I want to jump directly into the technical stuff and game design.

Challenges: Data Storage

Ok in this first series of posts I will be talking about the challenges I'll be facing. And to be more specific I want to write about data storage. I think that in any persistent world the most important aspect is data storage, is something that comes along with the word 'persistent'. 

I was looking for a way to store data in reliable way and by all means avoid having to create a system by myself so I chose SQLite3. I have to say that for those that haven't used SQLite it's and extremely good database and it comes with an incredible easy to use C API. I have used in the past not only for native applications but also for webpages and it has demonstrated to be really fast. At first I was dubious with this database not only now for the game, but also when programming web applications, but now I'm so confident about this database that it's going to be a big part of the server core.

So the first problem with any persistent world is that it needs to be really persistent, you can not allow yourself to get into scenarios where for some reason the server goes down, and a lot of users loss their achievements, because it's not just a match like playing COD, in those cases if something goes wrong at least the player lose some achievements but only for that match, it doesn't escalates further, even if the player was the best of that match and loses a lot of points it's really not big deal in comparison with losing who knows how many days of achievements an hours.

So my current implementation allows me to use the database as a direct way to fetch game data and provide that data to the players. Maybe I'll need to come up with some system to cache some data, a buffer, to avoid having to make too many request to the database which is a simple file after all (SQLite store the entire database on a simple file), but I have made lot of tests and speed is more than enough for my kind of game.

Since people (bots) are controlled by the game engine the client will be only a representation of what already has happened in the server. Imagine that one bot goes from its house and buy food on a local shop managed by a player. I send that information to the client: I'm currently sending a message like, make bot with ID 354 appear from houseId 789 and walk to shopId 1264 and buy food. All the animations happens in the client the server only execute the action, in the server the player has already bought the food, and the server it's just waiting a pre-calculated time depending on many factors as speed, distance, etc... Before sending another action to that bot.

So even when the game is in real time, the server doesn't need to send the exact position of that bot each ~50ms like in a FPS games for example, where 68 players may be on a match and the server must send each ~50ms position, angle, etc, of each of the players. That gives me a lot of free bandwidth that I can use to make the world bigger and allows a lot of players be playing the game simultaneously.

On the other hand even when I don't have to send info each ~50ms to all the player in this kind of game having like 1.000 bots on determined zones is something normal. And for that reason I'm thinking that in the future I'll probaly need not only a way to optimize the data fetching from the database but also a way to 'magically' make the client know what the server is thinking without any exchange of data and that's what I think I'll write about in the next post, I think is enough for now. I hope you all like it, and see you nex time! Bye.