0 votes

Hi everyone! I'm currently making a Football Agent simulation game.

My problem is how do I represent enormous data that the game world has so I can read from it when I load the game and write it out when I'm saving the game.

Naturally (is it natural?), I've decided to represent data with JSON. So, my objects, simplified are represented like this:

{
  "leagues": {
    "league1": {
      "name": "Liga prima",
      "clubs": {
        "club1": {
          "name": "club 1",
          "players": {
            "player1": {
              "name": "Mark",
              "overall": 10
            }
          }
        }
      }
    }
  }
}

This seemed nice to me but when I realised I'll need to provide a reference to a player of what club he plays in, or provide a reference to an agent what players he currently has and vice versa, I've realised this design isn't the best.

My next conclusion was that is probably better that I make a giant list of all players, do that in JSON too, and add a unique ID to every player. Then I do the same for clubs, nations, coaches, agents and every other object I have in the game. Inside these objects instead of references I slip the IDs of the objects when representing my data in JSON and then when I want to load the data I match every ID with their owner and supply the ID's. This somehow works like tables inside a database and it seems natural.

Is this the right way? What could I do better/differently? It also seems slow, so I was wondering what were the best practices with these type of problems.

asked Feb 22, 2018 in Engine by brane (31 points)

1 Answer

+1 vote

The possibilities explained here are quite comprehensive. For your specific case I would go for a real database connection. I'm not sure if the SQLite module still works for Godot 3 but you should give it a try.

If that does not work and you are not able to implement some database driver logic your best bet is to create your own db system. I'm not sure if this would be feasible but you could learn a lot on the way.

My best bet would be:

  • Create multiple files for each entity in the game (leagues, clubs, players) - you can go with json because it is easy to handle and has some advantages over plain text or binary data
  • Modell classes to implement the logic behind each entity (e.g. an instance of a club has member variables like name, coach and country and functions like add_player(player), move_player_to(club), win_match(), get_active_players() etc. // a player instance has a name, current_club and other information and can do the things a real player can do)
  • At the start of your game open every file and instantiate each element of your enitities and keep a reference in a list so you can work with them by their name or something like that
  • If a match starts gather the needed information of the playing clubs with functions like get_active_players() and then create nodes based on their data to represent them with images or something you want
answered Feb 23, 2018 by rolfpancake (1,006 points)

Thank you for taking the time to respond.

I already have a (bad) system implemented and all of the functions you've mentioned. My question is more of a why should I implement a certain system and not the other. Why should certain logic work better than the other.

Your third point is something that is the foundation of my question. What kind of reference? What's fastest, what's safest?

Thank you for mentioning SQLite module that could help!

"My question is more of a why should I implement a certain system and not the other. Why should certain logic work better than the other."

There is simply no best approach/system. It always depends on every decision you have taken while desgining your game mechanics. Possibilities are endless and a system which would be a horror scenario in my football agent simulation game could be the solution to hundreds of problems you encounter in your game.

Most of the time the process in finding the best fitting system boils down to: lets give it a try. And this means that you should think of as many approaches as possible and build a lot of prototypes. Then the corner points of your game design become visible and you are able to decide which system works best.

A rule of thumb in game dev that worked for me is:
If you have a working system, you know how to handle it and you can't find a better way to do it now - you shoud stick to it.

So my advice would be to try the SQLite module and if you can't get it working: no problem, you already have a working system - So why bother before it crashes on one of those far edge cases?

"What kind of reference? What's fastest, what's safest?"
By reference I simply mean a pointer to your objects. Simply put: When you create an instance of a class and address it to a variable like var body = RigidBody2D.new() the variable does not hold the object itself - it holds a pointer to the object. In Godot you often deal with references instead of values (like get_node("...")) and this gives you a massive boost in performance. (If you aren't familiar with handling object instances with pointers google some tutorials about C++ pointers - This is a must topic when working on huge game titles.)

So if you are interested in game programming patterns that are common, fast, well tested and therefore safe to use you should get in touch with design patterns:

Thank you again for your time. You are right. I'll try some stuff and then if it's too slow find a better solution.

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.