Ideas for a card game setup

Psycho_666

Member
Hello everyone.
So I'm working on a game and I have reach the point where I need to start working on my card mechanics.
I'm pretty sure I know how to program what I want to do in-game. My issue is the initial setup.
I have a choice between 2 options.
1. Make a card data object and store all card data (unexpected, I know) in that object so whenever the game needs something it will call this object and fetch information from it.
2. Use external files. No coding needed, just notepad. Piling up content later on will be much much MUCH faster and easier.

Once I commit to one I don't want to have to change to the other,so what do you think?
 
Well, they're both essentially the same thing. You're pulling data from something. If you use scripts correctly, it'll only be a few lines of code to change between the two. Also, notepad is unlikely to be the solution you want for pulling data from an external file. A CSV file created in any one of numerous free spreadsheeting programs is going to be much more suited. Personally, I would go with the external file because, if you code it right, that means you'll be able to change card data on the fly while the game is running, allowing for quicker iterations on design.
 
I've done both over the years. I'd imagine the amount of data going into a card game is similar to that of an RPG, so if I were making a card game I would definitely go with external files. It's easy to organize huge swaths of data into a JSON file and you can load it into a ds_map simply and easily. It's easier to edit data in a purpose-built text editor compared to GMS2's code editor, and you can even set it up so you can edit values at runtime for even faster testing.
 

rIKmAN

Member
Just to add to what nacho has said about JSON, here's a tutorial that uses JSON to store data for a cards in a card game which will help you get a grasp of how to create, read, store and access the data in GMS when using this method.
 

Psycho_666

Member
Also, notepad is unlikely to be the solution you want for pulling data from an external file
Notepad is fine. I kinda use what I know and inserting spreadsheets into game maker is not something I even remotely know how to do.
Personally, I would go with the external file because, if you code it right, that means you'll be able to change card data on the fly while the game is running
Oh yeah... That's one of the reasons I want external files as well...
you can load it into a ds_map
If I load it in a ds_map I may as well not bother with external files. I want objects to fetch their data from the external file, not some internal structure. Else I will just code it internally.
if I were making a card game I would definitely go with external files.
Yeah, that's kinda where I'm leaning as well...
I'd imagine the amount of data going into a card game is similar to that of an RPG,
It's kinda not... Much much less data,but as a structure yeah, each card is like an RPG item with different stats and what not...
 
If I load it in a ds_map I may as well not bother with external files. I want objects to fetch their data from the external file, not some internal structure. Else I will just code it internally.
I don't understand; you'll have to set up some kind of method in-game for handling data either way. Whether it's cardName = file_text_read_string(file) or cardName = map[? "name"] makes no difference.

JSON is also much easier to understand than you're making it out. If you understand how ds_maps and ds_lists work, you already understand almost everything you need to know how JSON works. Anything encased in curly braces ({ }) is treated as a ds_map, and everything encased in square brackets ([ ]) is treated as a ds_list. You can even store these data structures inside one another to improve organization.
 

Psycho_666

Member
JSON is also much easier to understand than you're making it out.
I realize that, but I do not really understand it. It may be simple, and once it clicks in my mind I may use it for everything, but as of today I am still an amateur so I use what I know.
I have seen a lot of people recommend JSON for a lot of things, so I will most definitely take a look at it, but I don't want to bang my head against the wall understanding it, when I can use what I already know.
I don't understand
I want to do either method, not both.
If I want to use internal data I will store it in game in an object and not use external files. If I use external files I will read directly from them.
Using an external file to transfer data into an internal data structure is literally double the work.
 
I want to do either method, not both.
If I want to use internal data I will store it in game in an object and not use external files. If I use external files I will read directly from them.
Using an external file to transfer data into an internal data structure is literally double the work.
No, they're essentially identical in terms of work you'd need to do.

If you're storing card data through the IDE, the process is this:
Card cata -> Internal data structure -> Retrieve data script
With an external file, this is the process:
Card data (external) -> Internal data structure -> Retrieve data script

If you're going to go with your Option 1, you're going to end up with a huge script somewhere that looks like this:
Code:
//Card 1
card001Data[? "Name"] = "Card 1";
card001Data[? "HP"] = 120;
card001Data[? "ATK"] = 50;
card001Data[? "DEF"] = 20;
//Card 2
card002Data[? "Name"] = "Card 2";
card002Data[? "HP"] = 80;
card002Data[? "ATK"] = 90;
card002Data[? "DEF"] = 40;
//Card 3
...
And if you go with Option 2, (assuming you use JSON) you're going to have a huge text file that looks something like this:
Code:
[
    "Card001": {
        "Name": "Card1",
        "HP": 120,
        "ATK": 50,
        "DEF": 20,
    },
    "Card002": {
        "Name": "Card2",
        "HP": 80,
        "ATK": 90,
        "DEF": 40,
    },
    "Card 003": {
    ...
]
The only difference as far as work goes is that you would need to write an external file loading script. I would be surprised if that took longer than one or two days, even if you don't know how to do it when you start. I personally think the latter is much easier to read and deal with -- and thus makes up for the small amount of extra work required.
 
Last edited:

Psycho_666

Member
See, my plan is to completely skip one of the 3 steps you mentioned...
Card data (external) -> retrieve data script.
I don't need the internal data structure. The objects will just fetch the data directly from the external file.
I would be surprised if that took longer than one or two days
Oh it totally shouldn't. The thing is, that's just the setup and the internal mechanics of the game will be the thing, that will take more time to deal with.

I just wanted advice because I tend to do stuff the more complicated and unnecessarily difficult way. So I'm checking if there is some much easier and faster way.
Thank you for your time and help :) I think I will go with external files and direct reading from the objects...
 
C

Catastrophe

Guest
Well, to me, the only advantage of external files is the ability for modders and non-programmers in a team to help out with tuning and design. If you want players to be able to tweak things further down the road, you're already done: they just use your already built system.
 

TheouAegis

Member
You don't want to leave it all external. Reading data externally is slow; reading it internally is fast. You'd open the file fetch the data you need, store it in a map or array, then close the file. If you had a centralized structure, you could store the data in a globally shared map/array so only data for the cards actually in use will be loaded into RAM.

If you did the giant map/array method of keeping it all internal, the RAM load would be big, probably not anything a modern system would have issue with.

Or you could have a bunch of switches inside scripts. It's slower to fetch, but takes up the least RAM.

Or if you're nuts, you could make objects for every card, make them all persistent, dump them in the first room, then deactivate them, only reactivating them when changing rooms, and just reading their variables directly. It's more RAM intensive, but has the fastest fetch speed.
 
You don't want to leave it all external. Reading data externally is slow; reading it internally is fast. You'd open the file fetch the data you need, store it in a map or array, then close the file. If you had a centralized structure, you could store the data in a globally shared map/array so only data for the cards actually in use will be loaded into RAM.

If you did the giant map/array method of keeping it all internal, the RAM load would be big, probably not anything a modern system would have issue with.

Or you could have a bunch of switches inside scripts. It's slower to fetch, but takes up the least RAM.

Or if you're nuts, you could make objects for every card, make them all persistent, dump them in the first room, then deactivate them, only reactivating them when changing rooms, and just reading their variables directly. It's more RAM intensive, but has the fastest fetch speed.
It's important to note here that "fast" is relative. Unless your game has absolutely insane amounts of data (it doesn't), even the slowest method mentioned here will occur within only one frame and it will not even hang the game when it happens. You also don't need to worry about RAM at this point considering even PCs a decade old will have at least 1 free GB of RAM. Be careful of optimizing prematurely.
 

FrostyCat

Redemption Seeker
Using an external file to transfer data into an internal data structure is literally double the work.
The only difference as far as work goes is that you would need to write an external file loading script. I would be surprised if that took longer than one or two days, even if you don't know how to do it when you start. I personally think the latter is much easier to read and deal with -- and thus makes up for the small amount of extra work required.
I really don't understand why people get this idea from and make a big deal out of reading JSON files into maps. Yes, there is no built-in function for it, but the code for it is pretty trivial stuff:
Code:
/// @description json_load(fname)
/// @param fname
if (file_exists(argument0)) {
    var f = file_text_open_read(argument0),
        jsonstr = "";
    while (!file_text_eof(f)) {
        jsonstr += file_text_read_string(f);
        file_text_readln(f);
    }
    file_text_close(f);
    return json_decode(jsonstr);
}
return undefined;
Once you have this script by copying the above or downloading the extension it came from (100% GML by the way), loading data into map format is always a one-liner like this:
Code:
global.card_data = json_load(working_directory + "card_data.json");
Estimating this task at any more than 15 minutes is unreasonable to start with, especially for anyone who already understands the format.
 

Psycho_666

Member
I really don't understand why people get this idea from and make a big deal out of reading JSON files into maps
Once you have this script by copying the above or downloading the extension it came from
Estimating this task at any more than 15 minutes is unreasonable to start with, especially for anyone who already understands the format.
Hey. Thank you for your time and effort. Please, don't get me wrong, cause I really appreciate you taking the time to help me, but there are 3 issues with you post:
1. You say you don't know why people are afraid of JSON - basically because we don't understand it. Yes, I can copy paste this code, it will probably work but I do not truly understand it.
2. You say extension - I never worked with extensions either. So now on top of wrapping my head around JSON I have to lear extensions as well.
3. You estimate this task at 15 minutes. You estimate the task at 15 minutes. You probably could do my project in a day and I have been struggling with it for a week and I'm still nowhere near finished.

Look, I just don't understand most of those things. I am an amateur and that's a bit intimidating to me. I understand it may not be as complex as I thought initially, but it's still something I haven't played with before, so I will stay away from it for now.
I want to sit down, read about it, understand what it is, wrap my brain about it, play with it and then I will use it. Until then I rather not.
 
Top