Design Best Way Of Storing Lots Of Strings?

G

GoneGamer554

Guest
Howdy All!

So, I have a quick design question regarding the storage of lots of strings for my game. And I'm talking like... 60K words-worth of strings that pop up in separate pages. Now, I've dabbled in storing them in files, but loading and processing them is kind of a pain. So, ignorant as to how GM2 handles its Scripts, I decided to simply use scripts to handle them.

Currently, I am using a tree system, with key codes that direct switch scripts to the actual script holding the needed string. This makes it so the system is only making a few comparison calculations to get to the desired string instead of having to dive through potentially hundreds. Like a file system, diving into successive levels without having to see the irrelevant entities.

Like comparing Chapter 1 which leads into comparing for Sub-Chapter 2 and then leads into the actual Page where the string is stored and then just returning (Ch1 - SCh2 - P1).

The big question? Would this really chug on system resources? Does GM2 load the script on call only? This way scripts aren't stored in memory until they're actually used... I'm assuming so...

Anyways, any help on this matter would be greatly appreciated! :)

And sorry if this is a stupid question. I'm still a noob with GM2! :p
 

sylvain_l

Member
60k words can sound like a lot of data (it's around a book lenght of text).
But if I'm not wrong in term of memory use it's only
6*60'000 = 360kB (very rough estimate, only ascii char -> 1 byte/char, and let's say 6/char per words (counting space, ponctuation, \n,...)
any picture taken with your mobile take much more memory than that; as most of your background sprite if they are HD. If you have any music files it's certainly a few MB too

so don't bother yourself trying to save memory for raw text, it's useless. (why bother for 360kB, while you don't for the 36MB+ of assets?)

edit: and to store them a ds_map or any LUT should do the job well (if require, just prefix your ds_map with the chapter, or have a ds_map per chapter if it make more sense)
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Yeah, text is very structured and optimized information that lends itself well for digital representation, it's almost always negligible compared to the space used by a bunch of OGG audio or texture pages.


EDIT: Putting all the strings in an array could be another option (or putting the SCRIPTS in one), since arrays are ordered it always takes the same time to read from them. Not quite sure what structure you're going for, but for a linear thing like a book you could have one array index per page, or per chapter, whatever strikes your fancy.
 
G

GoneGamer554

Guest
@sylvain_l
Thanks for the great explanation! Now that you put it that way... I suppose text really isn't something to worry about in the memory. And I might do a ds_map. Depends on how complex the keys are going to get. Definitely something to ponder. Thanks again for the great advice :):):):):);):)

@Yal
Thank ya as well! I am definitely considering using arrays. Though, the page/text progression isn't going to be very linear. I think the best comparison would be Mass Effect text version, with branching dialogue, textual interactions, and so forth. This means I'll have lots of unique progression pathways. And yeah, while I know that GM2 isn't much in regards to textual games, this isn't purely text-based. It's... kind of hard to describe but will have graphics, sounds, and interaction with just text being the main medium of interaction. RPG, turn-based combat, a movement system, and stuff like that. So, yeah, I'm liking arrays... maybe coupled with a few enums to keep things easier... Anyways, thanks :D
 

Yal

🐧 *penguin noises*
GMC Elder
maybe coupled with a few enums to keep things easier
If enums aren't color-coded & shows up in autocomplete (not sure if they do in GMS2 now, they didn't in GMS1) it might be better to use constants/macros instead.
 

NightFrost

Member
If enums aren't color-coded & shows up in autocomplete (not sure if they do in GMS2 now, they didn't in GMS1) it might be better to use constants/macros instead.
In GMS1 enums do color-code and autocomplete but the behavior is very quirky. I think a project needs to be saved at least once before they start behaving, maybe even closed & reopened. But I've also had enums that refused to cooperate at all, mixed in with ones that did.
 

Yal

🐧 *penguin noises*
GMC Elder
Sounds about as I expected... *shrugs*
The Macros/Constants interface is pretty annoying to work in, but at least it works as intended :p
 
Top