LF2 GM Progress Thread

[Gad]

Bamboori, why don't you just ask at GM phorums, how to make a script readable from the outside of program? That can't be thaaat hard, lol.

[A-Man]

Bamboori, why don't you just ask at GM phorums, how to make a script readable from the outside of program? That can't be thaaat hard, lol.

I guess it would be, since he will have build a GM compiler (in GM) which will compile the data at run time.

I never used GM, so I am not sure. You might be able to find a ready script that does it for you.

[Bamboori]

sadly not... in earlier versions there were simple functions for this, but they got removed because the yoyogames team was too lazy to code the compilers for other platforms.

i could do a windows only version that is moddable...
or make a helluva character editor. im not too sure though how much it would slow down the game, since i could only change variables which are read from ini files.

...uhm, i think i should rewrite this later so its more understandable :P

also i cant create an account on the official forums for whatever reason.
doesnt really matter though since the only way to make custom files is from ini or image files (or sound for that matter).
i mean i could make an editor that converts the code to a bitmap, then import that bitmap into game maker and make a color pixel parser buuuuut...

for now i wont concentrate on that but rather rewriting the current engine (was pretty messy) and then focus on online multiplayer yaaaaaaay so much fun

[Eddie]

i could do a windows only version that is moddable...
or make a helluva character editor.

If you would like, I'm working on a similar project at the moment. My idea though is that I create a lot of different customizable clothing pieces and drop their position correctly on a 'base anatomical frame', stamp it into a bitmap/png/whatever is easier/lower HDD usage and then that would save the character and all of their moves/etc before the game actually begins (essentially producing what would be a spritesheet in the style of LF2 characters).

Also doing it through the GNU GCC compiler for C++ so cross compatibility will not be as limited. Once again, just a thought, if you need or would like the assistance (and giving me general practice/a target to reach) then I would be more than happy to do so. Can PM me on here or skype me (we both know you can haz my skypeeez).

As far as it goes though, AWESOME.

Eddie

[Bamboori]

uhm... so i think i can make it customizable after all
im not sure to what extend youll be able to use the extra functions (ifs and switches in frames etc), but ill see what i can build into the parser without producing too much lag.

now i just gotta see about online multiplayer

[A-Man]

HA! So you ended up with a parser too :P. But yeah, coding basic stuff like switches and ifs for your scripting language can get as frustrating as hell (THAT"S WHY I LOVE INTERPRETED LANGUAGES MORE). Goood luck on getting the networking done XD! Keep this up!

[Bamboori]

:P well i realized i can do most stuff with .ini data.

it will look a lot like xml for you guys.

but yeah networking will be hell xD

[Bamboori]

so the entire data handling will be done via .ini files.
.txt and .bin would work as well, but i'd need to parse everything, whereas in ini files i can read out variables way easier.

....just as i was writing down my current method i realized it could be done way easier

right now i would have to create a dummy object for every possible object/background/char etc.
ill see what i can manage to come up with.

right now my method would be:

• a set of lets say 1000 dummy objects, each named 0-999.
  
• for every 'id' there would only be a path for the .ini file.
  
• in the .ini file there would be an identifier section, which then would copy the type of the data (background/char etc) to the corresponding dummy object.
  

that would also mean that the 'id' would be limited to exactly 0-999.

im not too sure whether i will include backgrounds in this as they are coded differently altogether.
im not really sure about backgrounds at all yet tbh

[Silverthorn]

I don't like that organization. What speaks against a map? You'd still have the linkage between id and object but you won't be limited to those id-values. Then again, I don't know GM but your current method seems... well, not technically wrong, just awkward

[A-Man]

so the entire data handling will be done via .ini files.
.txt and .bin would work as well, but i'd need to parse everything, whereas in ini files i can read out variables way easier.

....just as i was writing down my current method i realized it could be done way easier

right now i would have to create a dummy object for every possible object/background/char etc.
ill see what i can manage to come up with.

right now my method would be:

• a set of lets say 1000 dummy objects, each named 0-999.
  
• for every 'id' there would only be a path for the .ini file.
  
• in the .ini file there would be an identifier section, which then would copy the type of the data (background/char etc) to the corresponding dummy object.
  

that would also mean that the 'id' would be limited to exactly 0-999.

im not too sure whether i will include backgrounds in this as they are coded differently altogether.
im not really sure about backgrounds at all yet tbh

Looks promising! Not really sure what you meant by "create a dummy object for every possible", but that sounds more like allocating an array of your object's type for all the objects that are going to be loaded; and that's how it was done with LF2 as well. But let me share my thoughts :P:
1-Allocate an array of type "object" for the game objects, another array of type "bg" for the bgs, and a 3rd one of the type "object_copy" that stores info about objects on the screen.
2-The "object" array will store the actual objects that are loaded fir the game; including the frames, sounds and the sprites.
3-The "object_copy" array, however, will store data and info about objects on the screen (its current frame, x_y_z_position, the current HP, MP, x_y_z_velocity, the key clicks buffer..etc).
4-In your object[xyz].update() function, set a parameter of type "object_copy" to pass the data of that object on the screen; You surely don't want to load bandit's sprites and stuff 3 times in order to have 3 of them on the screen. You will just load it once, and then create 3 instances of "object_copy" that stores each one's position, hp and etc.

Goood Luck! (finally getting to the fun part, eh?)

Edit: Plus I think that actually specifying the ids like that makes more sense, since an id is supposed to act like the "address" of an object/oranything. Plus it can force modifiers to be more organized.