Storing lots of data

0 favourites
  • 3 posts
From the Asset Store
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
  • I need to store quite a lot of data to detail star systems in my game (about 100 or 200 systems, with maybe 10 planets each). Off the top of my head, I want to store them as sprite objects (with no graphic obviously) with about 20 or 30 variables for each, but this sounds very wrong. An array would do the same trick I suppose, but it still sounds wrong to have 2000 arrays. Would this cause problems with memory or performance and if so, how would I be better off storing this amount of data?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Use ARRAY. This is what it's built for as you get a nice Download and Load feature using JSON storage. So it's a great way to use webstorage or AJAX.

    I can see you need a lot of data and I'm not sure if 3 levels deep is enough. I would suggest maybe an alternative storage model than 1 node = 1 piece of data. Check out the manual for Expression on strings and tokenate function. Tokenate splits string data by character.

    String = "name|x|y|gravity|wealth|minerals|foo|...."

    example = "Zebes|100|200|0.5|poor|low|hostile|...."

    so then you array can be

    Array[systems][planets]

    Or you can use Spritebank(plugin) which I think will store all your sprite data and reload them when you want.

    edit:

    By default browsers easily allow up to 5mb of data. Past that browsers prompt users for the website to use more data. However even at 200 systems * 10 planets. You will still have enough room.

  • Thanks, I'm not sure what I was thinking, clearly an array is the answer. It's funny, when I used to use arrays for everything (in the 'old' days) and then OOP appeared, I really hated not using arrays. Now I really hate arrays! I don't like having to remember which element contains which value, but in this case it's definitely the way forward. I like your idea of tokenising string data to simplify the storage, I might use that :)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)