![\"Image\"](\"https://www.tabularelf.com/images/uploads/wellyesbutactuallyno-768x432.jpg\")
Note: This is specifically for versions GameMaker 2022.5.0.8 and above, due to the following code relying on Time Sources.
\nI’ll admit, I have personally never needed a frame counter in my projects, especially given that I mostly focus on library-related work. That said, the thought does cross my mind from time to time. In the past, frame counters I’ve made only check for the current frames that have already been processed within the game. However I was at one point asked for a method to compare frames against the current step. While that particular use case was to make a simple alarm, it did spark my interest. So today, I want to introduce to you current_step. The rest of the blog post covers the whole process and how I handled it specifically. If you just want the full snippet, you may scroll down to the bottom of the post. Otherwise…
\n\nTypically the main reason you’d want to use a frame counter is to
\nThe first one helps us see how many steps our game has passed so far. The second one is really handy for only executing a small chunk of code every step, without having to rely on an alarm or a timer that we have to keep track of ourselves. Typically current_time and get_timer() are the two most popular options for tracking this, but they have some drawbacks that I will go over later in this post.
\nIf you’re familiar with GameMaker, you will know about objects and their many different events. They are used for a wide variety of things, but some in particular are used for managing specific systems. The main focus comes to mind is the begin step, step and end step events. With the exclusion of draw events and alarm events, these are the only events that process once per instance, per frame. In the order of:
You can read more in detail about the step events and the other events (besides alarms) by clicking here. But for this part of the post, we’re going to be solely focusing on these three events for now.
\nTraditionally, if you wanted to make a frame counter work with an object, you needed to design your game with a specific setup in mind. The first room within the game (In GameMaker 2.3.0+, this is managed by the Room Order section. In older versions, the first room that’s on top of all of the other rooms within the Room folder) had to contain a preferably persistent object (i.e. obj_game_controller), stored within a room that sets up most of your game before moving into another room (such as the main menu or game intro). Much of the code for a frame counter was setup like this.
\n// Game Start Event\nglobal.frame_counter = 0;\n\n// Begin Step Event\n++global.frame_counter;\nThe reason we call it in the begin step event is because now any time an object wishes to get the current frame counter, they can just fetch global.frame_counter. Here’s two reasons why I don’t like this approach.
\nThe second one is more of a specific rare case, but the first is more problematic. This is because the counter itself is managed by a single instance of that object. If you know anything about objects and instances… It’s possible to accidentally destroy said instance, thus rendering your frame counter completely and utterly useless! Of course, with good standard practices and proper management, both of these are mostly avoidable.
\nBut what if you didn’t want to rely on an object?
\nNow when I came across the question, one of my first thoughts was “Why not just use current_time?” Since it doesn’t use an object, and the value itself can’t be changed alone. We need to keep in mind however, current_time increments in milliseconds, whereas get_timer() increments in microseconds. The reason I’m using current_time here is more of simplicity sake. The code I came up with for this was shoved into a macro for easy use. If you’re unfamiliar with what a macro is, it’s essentially a keyword that gets replaced during code compiling with the specificied value or code in place. Some examples of macros in use:
\n#macro FPS_SPEED ("Current FPS: " + string(fps) + "\\nFPS Target: " + string((game_get_speed(gamespeed_fps))))\n\n// In the draw event\n\n// Print FPS stats\ndraw_text(8, 8, FPS_SPEED);\nDuring compiling, this gets expanded to
\n#macro current_step (current_time div game_get_speed(gamespeed_fps))\nThis is good, but it has one flaw with this kind of thinking. It’s quite hard to tell from a glance, but did you know that both current_time and get_timer() tick upwards separately from the rest of your game code? “Obviously it shouldn’t cause some kind of issue, right?” you ask. Well unless your intention is to have your frame counter count up once every real world second, any moments where your game freezes up is enough to cause a desync while it’s still executing. Especially anywhere within the current step, alarms or draw events! Let’s also not forget that we’re relying on game_get_speed(), which is a function that can be altered by game_set_speed() (or room_speed for those who still use it), and can influence the current frame counter. It also may at times start above 0, which we don’t want that kind of inconsistency. Ultimately, current_time, and by extension, get_timer() make for a pretty bad frame counter overall. There’s got to be something better, right?
\nUp until Game Maker 2022.5.0.8, objects were the one and only true way you could process logic every frame. However, since version 2022.5.0.8, GameMaker has introduced time sources! “So what is this time source you speak of?” Think about it like an object’s alarm event, except it’s not an object. It works solely independently from any and all objects. Aha, now we’re getting fancy here! “But how do we use a time source?”
\nTime sources are a bit more involved, and I’d recommend checking the documentation on all of their arguments on time source create here. But for our specific case, we’ll be actually just using this.
\nts = time_source_create(time_source_global, 1, time_source_units_frames, callback, [], -1);\nTime sources have two parent-based timers. time_source_global and time_source_game. We’re using time_source_global since it cannot be paused with time_source_pause() by accident (which can happen if you do time_source_pause(time_source_game)). The rest of the arguments determine that:
\nWhat we’ll be doing is taking one step further however, and creating a unique struct that contains our relative information. We’ll also be using said struct to store our frame counter value as well.
\nfunction __get_current_step() {\n // Initialize our static variable\n static _inst = undefined;\n\n // Check that our static variable is undefined.\n if (_inst == undefined) {\n _inst = {};\n _inst.ts = time_source_create(time_source_global, 1, time_source_units_frames, method(_inst, function() {\n ++currentStep;\n }), [], -1);\n time_source_start(_inst.ts);\n _inst.currentStep = 0;\n\t}\n\t\n\treturn _inst.currentStep;\n}\n__get_current_step(); // We call this once at the start\nSo what’s going on here? What is static?\nStatic is basically a value that gets declared once and binded to the function. You can perform any future code with it to change or alter said value, or its contents. But ultimately, you can use it to keep a permanent reference to a value. In our case, we’re using it to store a struct. The other benefit we gain here is that unless we expose that struct by returning it, this is effectively untouchable by any outside force (Well, besides static_get()). As for method(), Game Maker allows functions to be called from any instance, object, or struct by binding the function to it. This means that whenever that method is called, it’s executing as said instance. This current code works just as fine, so we can assign this to a macro in it’s current state.
\n#macro current_step (__get_current_step())\n“But, wait, when do time sources tick?” This may come as a shocker to some of you, they tick after the begin step event but before the step event! The goal of this is to also account for the begin step event, so does that mean time sources are also a dud?
\n
We can make this work with the begin step event, it just requires a bit more logic on our end.
\nTo begin, we’ll add a new variable to our struct
\n_inst.currentStep = 0;\n_inst.executedInBeginStep = false;\nNow just before we return currentStep, we also need this bit of code to be added.
\n // Check if we're in the begin step event\n if ((event_type == ev_step) && (event_number == ev_step_begin) && \n\t(!_inst.executedInBeginStep)) {\n _inst.executedInBeginStep = true; \n ++_inst.currentStep;\n }\n \n return _inst.currentStep;\n}\nBasically, since our time source doesn’t tick until after begin step event, this small snippet of code ensures that we’ve already incremented ahead of time. Now, you’ll already notice that our time source code will also still increment it, causing a double increment. To fix this, we just add in a check to our callback function.
\n _inst.ts = time_source_create(time_source_global, 1, time_source_units_frames, method(_inst, function() {\n if (executedInBeginStep) {\n --currentStep;\n executedInBeginStep = false;\n }\n ++currentStep;\n }), [], -1);\nEverything is good, right? If you were to call current_step in the create event and begin step event, while having it run in the very first room of the game, you’ll quickly realize that it has incremented an entire step despite the fact the game only just started (shows 1 instead of 0)! This isn’t technically a bug, although I do like to make my frame counters a bit more consistent. By ensuring that between the very start of the game, to the next begin step, stays consistently as “frame 0”. So I came up with another solution.
\nFirstly we’ll change currentStep during our struct setup to -1.
\n _inst.currentStep = -1;\n _inst.executedInBeginStep = false;\nAnd then add this snippet of code just below our check for the begin step event.
\n // Check if this is our frame counter is below 0, aka the very first frame.\n if (_inst.currentStep < 0) {\n return 0; \n }\nWe check to see if currentStep is less than 0 and return 0, since we are technically on the very first frame. Which corrects all of the remaining oddities, and makes calling it anywhere more in sync.\nOur code now is finally coming all together. What we end up with is a frame counter that not only updates every step event, but also actually starts from 0!
\nThis concludes the blog post on how we went from a basic frame counter, to a proper frame counter!\nI like to thank Homs from r/GameMaker’s Discord Server, for giving me a reason to spend some of my time thinking about the best possible solution to a frame counter! I also would like to give special thanks to Gizmo199 for helping me proof read all of this. (Staying up all night and writing does not mix very well.)
\nI’m always looking for more things to cover in regards to GameMaker, so if you ever want to see me tackle something else involving GameMaker, leave a comment below or join my Discord Server to talk to me directly! Also consider following me on my socials!
\nYou can get the full code from here, with some slight changes\nhere!
\n","tags":["frame counter","gamemaker","time source"],"date_published":"2023-03-01T00:00:00.000Z"},{"id":"https://www.tabularelf.com/posts/basic-saving-and-loading/","url":"https://www.tabularelf.com/posts/basic-saving-and-loading/","title":"[GameMaker] Basic Saving and Loading with JSON & Buffers","language":"en","content_html":"I’m writing this guide as I’ve noticed that there’s not a lot of up-to-date reading material that covers a good way of saving/loading important data. You can find videos of it online, but I prefer to scroll through webpages myself and study the material. The main topic we’re covering of course is saving/loading data from JSON. But, there’s a few things that we need to cover before we can get to that.
\n\nBefore we actually begin to learn how to save and load our data, we first need to understand how we can store our data as JSON. GameMaker fortunately does provide us some easy-to-use functionality, which are json_stringify and json_parse. These two will allow us to turn data into JSON and vice versa. Data specifically being structs.
\nIf you’re familiar with instances/objects in GameMaker, they’re a form of that, but without events or built-in variables. Put simply, they only contain data that you, the developer, specify. They’re by far the easiest to deal with, since they are garbaged collected. Which means that you don’t even need to delete them, like with arrays. You can just set and forget them.
\nDefining a struct is relatively straight forward.
\nvar _struct = {\n\tfoo: "bar",\n\tkey: "value",\n\tbool: false,\n\tnumber: 26\n};\nA struct can have as many keys as you desire, and they can hold whatever value you choose. In this example, foo is our key, and "bar" is the value. At this point of time, we can easily reference them. Just by either using the dot operator (_struct.key) or using the function variable_struct_get(_struct, “key”) (or the accessor _struct[$ "key"])
show_debug_message(_struct.foo);\nshow_debug_message(_struct[$ "foo"]);\nshow_debug_message(variable_struct_get(_struct, "foo"));\nDo take care in mind, that both the accessor and the function do the same thing, and are different from the dot operator.
\nThe major difference being that:
\nLet’s assume that we have an obj_player object. And in it’s main Create/Step event, we have the following code:
\n// Create Event\nx = random(room_width);\ny = random(room_height);\n\n// Step Event\nif (keyboard_check_pressed(vk_space)) {\n\n\tx = random(room_width);\n\ty = random(room_height);\n\n}\nGreat! We’ve got our code. Now every time we press spacebar, our player will place itself in a random position in the room.
\nThe fun part! We’ll use the obj_player x and y to save from our lil example. But to start off, we’ll take the knowledge from making a struct and applying it to our example case.
\nvar _struct = {\n\tx: obj_player.x,\n\ty: obj_player.y\n}\n\nvar _json = json_stringify(_struct);\nNow that we have our struct stringified, we just need to store into a buffer. Now I did sorta gloss over buffers entirely, but I’ll go down in some basic details shortly.
\nvar _buff = buffer_create(string_byte_length(_json), buffer_fixed, 1);\nbuffer_write(_buff, buffer_text, _json);\nbuffer_save(_buff, "player.json");\nbuffer_delete(_buff);\nBreaking it down what we’ve just done here.
\nYou might’ve noticed that in the manual for buffer_write, we have some additional types. We’re going with buffer_text since it’s by the most straight forward, and we’re not storing anything else. To complete our functionality, we’ll add them together and add a separate block of code of our obj_player‘s step event.
\nNote: Saving buffers ontop of files that already do exist, will overwrite them.
\nif (keyboard_check_released(ord("S"))) {\n\n\tvar _struct = {\n\t\tx: obj_player.x,\n\t\ty: obj_player.y\n\t}\n\n\tvar _json = json_stringify(_struct);\n\n\tvar _buff = buffer_create(string_byte_length(_json), buffer_fixed, 1);\n\tbuffer_write(_buff, buffer_text, _json);\n\tbuffer_save(_buff, "player.json");\n\tbuffer_delete(_buff);\n}\nLoading in our data is just as easy as saving our data. We’ll start by loading in the buffer and converting it back into a struct.
\nif (keyboard_check_released(ord("L"))) {\n\tvar _buff = buffer_load("player.json");\n\tvar _json = buffer_read(_buff, buffer_text);\n\tbuffer_delete(_buff);\n\tvar _struct = json_parse(_json);\nWe’ve now loaded in a buffer, extracted the JSON and then converted it back into a struct. Retrieving the x and y is as simple as what we’ve done above with our structs example.
\n\tobj_player.x = _struct.x;\n\tobj_player.y = _struct.y;\n}\nThat’s all we really need to do for that. Though, you might ask some good questions. What if the JSON doesn’t have an x and or y value, the JSON is invalid, or if the file doesn’t exist, then what?
\nIn most cases, as long as we know that the file does exist, then we don’t have to worry too much. We can easily adapt what we have above by checking first to ensure that said file exists.
\nif (keyboard_check_released(ord("L"))) && (file_exists("player.json")) { \n\tvar _buff = buffer_load("player.json");\n\tvar _json = buffer_read(_buff, buffer_text);\n\tbuffer_delete(_buff);\n\tvar _struct = json_parse(_json);\nVery little of the code needs changing to check that player.json already exists before attempting to load in. But, what if someone were to modify the save file to pass in an invalid JSON string? Well, in this case GameMaker will throw an exception. Frankly I find that to be an annoyance. But, we can get over that by simply adding in try/catch, which results our code looking like this so far.
\nif (keyboard_check_released(ord("L"))) && (file_exists("player.json")) { \n\tvar _buff = buffer_load("player.json");\n\tvar _json = buffer_read(_buff, buffer_text);\n\tvar _struct = undefined;\n\tbuffer_delete(_buff);\n\ttry {\n\t\t_struct = json_parse(_json);\n\t} catch(_ex) {\n\t\tshow_debug_message(_ex.message);\n\t}\n\n\tif (is_struct(_struct)) {\n\t\tobj_player.x = _struct.x;\n\t\tobj_player.y = _struct.y;\n\t}\n}\nThis will do for the most part, and will load our data in just fine. Though, we still run into the issue that if any of the values aren’t available (either by the developers end, or by players modifying the save file), while our try/catch will prevent the game from crashing, it will also skip the rest of the loading. That’s not good! Some of our values might be beneficial! How we can overcome this is by using a tenary operator. (It’s basically a one line version of an if/else block), represented as\nstatement ? value_if_true : value_else;
obj_player.x = !is_undefined(_struct[$ "x"]) ? _struct[$ "x"] : obj_player.x;\nobj_player.y = !is_undefined(_struct[$ "y"]) ? _struct[$ "y"] : obj_player.y;\nWhich makes up the rest of our loading system. Now we’re left with this.
\nif (keyboard_check_released(ord("L"))) && (file_exists("player.json")) { \n\tvar _buff = buffer_load("player.json");\n\tvar _json = buffer_read(_buff, buffer_text);\n\tbuffer_delete(_buff);\n\ttry {\n\t\tvar _struct = json_parse(_json);\n\t} catch(_ex) {\n\t\tshow_debug_message(_ex.message);\n\t}\n\n\n\tif (is_struct(_struct)) {\n\t\tobj_player.x = !is_undefined(_struct[$ "x"]) ? _struct[$ "x"] : obj_player.x;\n\t\tobj_player.y = !is_undefined(_struct[$ "y"]) ? _struct[$ "y"] : obj_player.y;\t\n\t}\n}\nNow not only do we check to ensure that the player file exists, but we also check to ensure that json_parse doesn’t throw an error, and that each and every variable from the struct is there, skipping over what’s not there. This makes our system step over many of the errors without completely halting the game. You might also be tempted to try out the idea of looping all of the structs variables (via variable_struct_get_names()) and then applying it to obj_player, but this would also mean that each and every entry that wasn’t intended at all, will be added. So I wouldn’t ever recommend doing that, unless you want to cause unintentional behaviour down the road.
\nWhile this concludes the basics, I will be looking to make further tutorials on the matter. Including saving multiple instances, asynchronous saving/loading and much more. As always, I’m happy to take in any suggestions and feedback between tutorials.
\nAnd while I won’t cover it today, there is a library with parsers for CSV, XML, YAML, Messagepack, Binary, Ini, JSON and more! I highly recommend checking it out if you’re interested in other formats as well as JSON. They work just as well with the code above. Just swap out json_stringify and json_parse for the equivilants.\nLink here: (https://github.com/JujuAdams/SNAP)
\nIn our next blog post on this topic, I’ll cover asynchronous saving/loading.\nRepo link (for the demo code above): https://github.com/tabularelf/BasicSaveLoadJSON
\n","tags":["gamemaker","buffer","json","loading","saving"],"date_published":"2022-01-16T00:00:00.000Z"},{"id":"https://www.tabularelf.com/posts/custom-game-restart/","url":"https://www.tabularelf.com/posts/custom-game-restart/","title":"[GameMaker] Why shouldn't you use game_restart","language":"en","content_html":"GameMaker offers a lot of powerful functions and flexibility for many of our needs. However, some of these functions are done in a sort of black box state. While many of GameMakers own functions/systems are genuinely fine, the problem becomes very apparent in the long run. More so when you start to build a very complex game, and let GameMaker handle more of the work than you. game_restart, being one of them.
\n\nTo understand what’s wrong exactly with using game_restart, we first need to know how it works.\nHere I’ve written some pseudo code that you can more or less replicate within GameMaker.
\nfunction pseudo_game_restart() {\n\t// This will destroy all instances. \n\t// Yes, this will run their cleanup events as well as well as their destroy event.\n\twith(all) {\n\t\t// Executes the instance game end event, if any\n\t\tevent_perform(ev_other, ev_game_end);\n\t\tinstance_destroy();\t\n\t}\n\n\taudio_stop_all();\n\n\t// Go to the very first room, as per room order\n\troom_goto(room_first);\n \n\t// Some internal system that tells instances to run game start event, \n\t// upon going to the very first room.\n\t// call_later, which was later introduced in 2022.8, will suffice.\n\tcall_later(1, time_source_units_frames, function() {\n\t\twith(all) {\n\t\t\tevent_perform(ev_other, ev_game_start);\t \n\t\t}\n\t});\n}\nAs you can see here, not a whole lot is going on. But this also lies in some of the many problems that happen with game_restart.
\nI’ll summarize the issues into dot points.
\nThe first three points aren’t only true, but it’s stated within the manual.\n4th and 5th points refer to less from my experience, but more from others experience amongst the GameMaker community. Take that as you will. The last point, as summarized above and with the pseudo code, more or less demonstrates why you shouldn’t use it in a big project. game_restart is meant for prototyping and debugging purposes only. It’s not meant to be used in an actual game project. Additionally, some libraries do not support game_restart for these points above. It’s not predictable enough for developers to consistently rely on for their actual projects.
\nBut then, what do we use if we do want to restart the game? It’s simple. We make our own game_restart function. Now the code I’ve posted above can be more or less used as is (I would advice removing the event_perform from it as you may not want to execute game end events). You can add/change how it works. And it works well enough for a basic start. But I do prefer this.
\nfunction __game_restart() {\n // This will destroy all instances. \n // Yes, this will run their cleanup events as well as their destroy event.\n with(all) {\n\tinstance_destroy();\t\n }\n\n audio_stop_all();\n draw_texture_flush();\n\n\n // Go to the very first room, as per room order\n room_goto(room_first);\n}\nWe can now use __game_restart to call our custom function. Game Start and Game End will never execute beyond their intended purposes. Allowing us to set and forget things we don’t want changing at all in the Game Start event. And everything else can be defined in the other events as per normal.
\nWe can extend __game_restart to do just about anything that we like. For example, handling some or all of those edge cases that game_restart doesn’t do. I won’t cover it here, as that would go in much further detail. But with some minor tweaks to the code, you can pull it off with ease.
\nI hope this not only brings out the issues with game_restart, but encourages you to look beyond what you expect from how your project should handle things when it restarts the game.
\n","tags":["game_restart","gamemaker"],"date_published":"2021-08-08T00:00:00.000Z"}]}