Akhos
Member
(I'm not currently in the beta so I thought I'd pose the question here, hopefully someone can help me before the official release!)
So in my current project (a fighting game), I have the ability to save replays and play them back. I have a fast forward feature that lets you play through the replay faster which works by just executing all of the step events of each object in the room multiple times in a single event before going through the events normally. To ensure this works the same as the game just playing through things normally, I have to know what order the objects are going to be executed in. Fortunately right now in 2.2, the order of code execution is the same as the order you have your objects arranged in the resource tree, and multiple objects are executed in their spawn order. So if I have:
obj_fighter
obj_projectile
obj_effects
The code will be executed in that order, and in my room controller, I can just do event_perform using with statements in that same order to achieve the fast-forward effect that I need. This is also used for the netcode (in the future, haven't gotten that far), when the game needs to roll back to a previous state and play it back, I'll need to do the same thing to ensure things would be played back exactly as if it had played through those events normally, I can't just fast-forward by doubling animation/move speeds.
With the new asset browser and being able to organize any asset regardless of type, does this same order of execution still apply? For example, if I kept all of my objects in their own object folder and kept them in the above order, would the code still be executed in that order in-game?
Now for script_execute. Reading through the 2.3 blogs, I see that scripts have been changed in order to support functions. In my game currently, each character has a ton of scripts assigned to them, and I store the script names in ds_list to be easily accessed later. As a short example:
So it adds the script index to the ds_list. So for example, when I define an attack script for a character, I have which animation state the opponent plays when struck assigned to a number. So, say, hitbox_state[0]=33, references item 33 in the ds_list, which is stand_hit_high_light. So when a character is struck, it will set their script_index to 33, which will play that script for them getting hit. This allows me to just assign a single value that applies to every character, instead of having to have a massive switch statement any time a damage animation needs to be played and have to update all those switch statements any time a new character is added.
My question (I hope the explanation of how it currently works is clear); would this still work in GMS2.3? Or will I need to rewrite it all to use the new functions? In theory, using functions would make my current method a lot more convenient (IE have one script that defines all the damage functions for a character, and instead of assigning a script_index I assign the function name), but it would be nice to not have to rewrite everything with this new version.
Note; I can't really stick with GMS2.2 on this one. I want to use the YYC compiler so the game runs the best, but there's currently a bug where any call to the hat functions for gamepads returns undefined if you do that. So I need to know if I'd need to change how I handle things in 2.3, which I believe has fixed that issue.
So in my current project (a fighting game), I have the ability to save replays and play them back. I have a fast forward feature that lets you play through the replay faster which works by just executing all of the step events of each object in the room multiple times in a single event before going through the events normally. To ensure this works the same as the game just playing through things normally, I have to know what order the objects are going to be executed in. Fortunately right now in 2.2, the order of code execution is the same as the order you have your objects arranged in the resource tree, and multiple objects are executed in their spawn order. So if I have:
obj_fighter
obj_projectile
obj_effects
The code will be executed in that order, and in my room controller, I can just do event_perform using with statements in that same order to achieve the fast-forward effect that I need. This is also used for the netcode (in the future, haven't gotten that far), when the game needs to roll back to a previous state and play it back, I'll need to do the same thing to ensure things would be played back exactly as if it had played through those events normally, I can't just fast-forward by doubling animation/move speeds.
With the new asset browser and being able to organize any asset regardless of type, does this same order of execution still apply? For example, if I kept all of my objects in their own object folder and kept them in the above order, would the code still be executed in that order in-game?
Now for script_execute. Reading through the 2.3 blogs, I see that scripts have been changed in order to support functions. In my game currently, each character has a ton of scripts assigned to them, and I store the script names in ds_list to be easily accessed later. As a short example:
GML:
ds_list_add(script_list,scr_rock_stand_hit_high_light);
ds_list_add(script_list,scr_rock_stand_hit_high_medium);
ds_list_add(script_list,scr_rock_stand_hit_high_heavy);
My question (I hope the explanation of how it currently works is clear); would this still work in GMS2.3? Or will I need to rewrite it all to use the new functions? In theory, using functions would make my current method a lot more convenient (IE have one script that defines all the damage functions for a character, and instead of assigning a script_index I assign the function name), but it would be nice to not have to rewrite everything with this new version.
Note; I can't really stick with GMS2.2 on this one. I want to use the YYC compiler so the game runs the best, but there's currently a bug where any call to the hat functions for gamepads returns undefined if you do that. So I need to know if I'd need to change how I handle things in 2.3, which I believe has fixed that issue.