How do I implement a lot of constant data efficiently?

0 favourites
  • 10 posts
From the Asset Store
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
  • Hi Guyz,

    It's already 3rd day I think how should I do it the right way, so I thought maybe you could give me your opinion.

    The game

    The game is a single-player 2d action shooter, where you have 10 different weapons and each weapon has 10 upgrades so it's like 100 weapons. And each weapon has a primary and a secondary shot. Each weapon upgrade gives different stats for the weapon and those are:

    - fire rate (primary shot)

    • fire rate (secondary shot)
    • min damage (p. shot)
    • min damage (s. shot)
    • max damage (p. shot)
    • max damage (s. shot)
    • radius of impact (p. shot)
    • radius of impact (s. shot)

    So 8 variables (constants actually) per one level of each weapon which gives after all 800 numeric variables.

    BTW: game is dedicated to be released on desktop (Steam) so I have to think locally (no MySQL etc.).

    The problem

    My problem is that I am not really sure how should I implement these data to C2 the right way. I mean here to do not make a mess in the code and to be able to easily change it whenever I need.

    Possible solutions

    Solution 1 - XML

    First thing that came to my mind was XML. I can create some XML file and put data there, then load it on start of the game. But I don't really want to have an external file somewere in the project directory which could be "hacked". I was thinking to encode it with some salt using some two-way encryption algorythm like Base64 or so, but then again there is nothing implemented in C2 and I don't really want to use any third party plugins here, cause I had a lot of performance issues with previous game.

    Solution 2 - Dictionary/Array

    I can also put data to some C2 data holder like Array or Dictionary. But I would have to set all data programmatically at the start, and this involves a lot of index constants etc... Then for any change it would be really not readable searching among 800 "set" functions... for some reason it gives a messy feeling.

    Solution 3 - local constants

    At the beginning that seemed to me the worse idea, but it starts to be the best in my opinion. First of all constants are the fastest to read for engine I believe. Second thing is that I have each weapon behaviour in separate event sheet so I would put only 80 local constants per event sheet. They seems to be readable and easy to change. I have even implemented part of this solution.

    But still I'm not 100% sure it's the best way to keep the readability and architecture clean.

    Any suggestions would be very appreciated.

  • If you don't want to use a project file, but still read from a xml file, you could paste in the contents of your xml file into the xml load action.

    I'm not sure how much minifying does to that string. Perhaps you will still end up with a "hackable" solution, just less obvious. Though imo my philosophy would be "let people hack the game, if it is fun for them", as long as it is single player.

    If you don't want to use project files or pasting file contents in somewhere, I think it only leaves the solutions of setting the values in events / variables.

  • If you don't want to use a project file, but still read from a xml file, you could paste in the contents of your xml file into the xml load action.

    Thanks for reply Setting XML directly as a string into loading function would be a horror to edit it later

    "let people hack the game, if it is fun for them", as long as it is single player.

    Well... ye... I had that thoughts as well... hmm...

  • Setting XML directly as a string into loading function would be a horror to edit it later

    Just curious: why? (I'm not saying it is easier maintainable than the variables spelled out in the engine, just don't see a big hurdle)

  • Because it would be a pure/raw string data. XML for 800 values would be pretty big so to use it in a comfortable way you would expect collapse/uncollapse options for nodes and surely a syntax colorization. C2 does not have XML syntax colorization for string values. I could use a second editor only for this XML but then again it's getting messy to me. I like code to be tidy and readable.

  • I think you would use your prefered xml editor on the sidelines and after you are done editing, copy it over again into the Construct 2 field.

    (I wouldn't do it either, but wouldn't have a big problem with it ^^)

  • Allright... maybe I overreacted with this "horror"

  • Did you end up coming up with a good solution? I'm dealing with the same problem atm. For me it all comes down to scale-ability and how well I can change things and how efficient it all is. I am considering 3rd party plugins such as rexrainbow's csv, csv2array, asv2dictionary.

  • Try my CSV plugin

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I don't think you can avoid hacking in a local HTML game, even if you store it in memory.

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