Daily news, dev blogs, and stories from Game Developer straight to your inbox
Emancipation, the very beginning.
Today I start a new series of posts about my future game: Emancipation: Two Steps back. I want to talk about the tools, game design and concepts that I'll be using to program this game.
Armando Miguel Cerasoli Quintero
April 14, 2014
5 Min Read
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.
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.
Read more about:Blogs
About the Author(s)
You May Also Like
Accessibility and fancy footwork with GLYDR's John Warren - Game Developer Podcast ep. 40Feb 28, 2024
Exploring the 2024 State of the Game Industry report - Game Developer Podcast ep. 39Feb 2, 2024
Phantom inspiration and the ethical auteur with Xalavier Nelson Jr.Dec 8, 2023
Designing Killer Queen: from playground experiment to modern arcade sensationOct 18, 2023
Get daily news, dev blogs, and stories from Game Developer straight to your inbox
Subscribe to Game Developer Newsletters to stay caught up with the latest news, design insights, marketing tips, and more