Blogs - AMCerasoli

Original Post

These days I have been working on the GUI of my game. This is the second time I create a GUI, my first game also used a very simple UI but this time I need something more flexible.

Sometimes I get overwhelmed by software and all its complexity. I used to think that creating user interfaces was something really difficult to do and in some extent they are, but for that reason I always try to reduce all the accessories, colors, and eye candies of every software to get the foundation or the purpose of that software.

Today user interfaces are really complex in the sense that they are: animated, "intelligent", very intuitive and well organized. User interfaces is what people use these days to communicate with the software, there are no more shells, terminals or configuration files, but at the end they're just a way of gathering information from the user.

Gathering information from a console program is easier because you're already working on a pre-made application or more than just an application it's an environment with certain patterns.

Working on console applications it's more or less like working on web applications, you send some kind of 'commands' to tell the console to display a message, the same as you do when working on a browser. When you want input from a user you also send another 'command' to the console and the console start getting keyboard input events until a certain character/key is pressed, normally Enter.

In HTML is the same you create an input tag and the user can start writing on that field.

But, when you're creating a videogame there are no such thing as input tags (like in HTML) or display message functions like those that the console-environment normally has. You have to create everything, and when I say everything is everything. Of course there are libraries like Allegro, that at least gives you a thin layer between raw OpenGL/DirectX and your game, but even though you need to create the rest yourself.

For example in HTML if you want to create an input tag you just wite the tag with some attributes and that is it. A field appears somewhere and you can start typing.

Well, when programming a videogame, you need to draw first the rectangle that's going to be the background of the font, if you want a border you need to draw that too, where you want to draw it using pixels, load the font, and draw the font but making sure that the string isn't bigger than the background other wise you end up with something like this:

And those are just a few points. However the good thing about working on UIs it's that depending of your game will be a very used feature and it's actually like creating the game itself, I mean, if done well, you'll feel pretty proud of your work when you see that is used extensively with no problems.

Another good thing is like I was saying before they are just a way of letting the user send info to the game and they are pretty repetitive. I have learnt a lot from HTML and I want to encourage everyone that is working on a UI to use some kind of markup language to create the panels or windows, widget and everything related to the UI.

This is of course applicable to other things too, but I think it's specially important when working with UIs.

Currently on my game to initialize a GUI I use tinyXML2 a really good library to parse the XML. And I have implemented a XML structure pretty similar to HTML in order to create my panels.

Is not finished, but it's looking good so far:

Introduction:

Hello future readers of this blog. It has been some time since I discover 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 and thus helps to actually finish the project. That's why I have decided to start a series of posts 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++.

Since I have already wrote about what is Emancipation (more or less) I want to jump directly into the technical stuff and game design. To start covering all the fields.

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 concrete 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 to allow 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.