While I didn’t start these patterns with the core library, it is actually a foundation to all of the rousr projects, though it’s more of a jack-of-all-trades than anything with a big heavy hitter. As a result, this entry is more of a “grab bag” of helpful scripts I’ve added to our core library to give you some concepts you may not have considered.
I wanted to make sure I gathered everything I’d need for any project and had a very easy way to access it, so while they don’t follow much of a common theme in total - their common theme is “necessity.” You’ll notice a bit of it is heavy on the idea of “caching” and “re-using data” which are really the main tenets of what the sr_core library is attempting to abstract. In addition, it aims to eliminate as much project “boiler plate” code as it can.
(Boiler plate code is a term used for tidbits of code you have to add to each and every one of your projects, so why not make it small and as painless as possible?)
Some of you may be familiar with RousrSuite - the ill documented extension that is included with the other Rousr extensions. RousrSuite is a collection of small GML Extensions, generally each with a singular purpose, that are used by Rousr projects.
The current make-up of RousrSuite is:
RousrCore - a grab-bag set of functions used at the core of most Rousr code. This includes much of the basic functionality we’ve wrapped up… such as ensure_color and ensure_font which store a global for the current draw_set_* variable and when passed a color or font, they’ll do a draw_set call if its not already that. Of course, there’s things like math and debugging functions in here as well!
RousrDs - a set of new data structures that are based on arrays, as well as some helper functions when working with the native ds types.
RousrInput - an (unfinished) set of functions to wrap up the paradigm of named actions being mapped to controller inputs in an attempt to add a layer of abstraction to input.
RousrUI - an (unfinished) set of UI widgets and basic GUI functionality you’d expect. This is intended for in-game use, which differs from the ImGuiGML debug-use case.
It’s available to be downloaded on the YYMP, but mainly is intended to be used internally by our extensions. I do hope one day it’s an extensively usable library of functions for anyone!
A complaint often made about using GameMaker Studio is that the language doesn’t include built-in support for Objects in an OOP sense. Now, if you’re not quite familiar with Object-Oriented Programming, you might want to do a little reading up on it before continuing, but this article still may give you some ideas on better ways to organize your own code.
A consistent, thorough naming standard has some huge advantages for us as programmers. If we’re consistent with our naming standard, then we have guidelines on how to write code that looks like everything else in our project - this makes a project much easier to read and much easier to maintain. Why? Simply because you’re not learning a new style or wondering what a variable is - the consistency is familiar so you immediately can understand _oh_this_variable_was_declared_in_this_file or ThisMustBeAnObject.
With about a year and a half of experience with GameMaker Studio 2 I’ve started to develop some useful habits that has allowed me to start really accelerating the pace of my development. I’m pretty sure that you might find some of them useful to adopt, or at least get some new ideas for how you’re using GML, so I’m beginning a new series of articles I’m calling GML Programming Patterns.
Each article goes over a core concept or pattern that we’re using with our Rousr GameMaker Studio 2 projects with the goal of helping you organize better and write better GML… or get at least you thinking. The first article, Naming Standards, is published today as well as a bit of a primer, but you can see some upcoming articles below!
Let’s say we had an object PupperManager with the goal of managing all of our game’s Puppers. Since it doesn’t make much sense for more than one thing to manage a group of objects like this, PupperManager is a great candidate for the singleton pattern. You can look up a really computer-sciencey explanation for Singletons, but primarily our goal here is to create an object that fits the following requirements:
This weekend I released Dissonance for GameMaker Studio 2, but also, for the first time, with GameMaker: Studio 1.4 support. Since it’s been awhile, I’m also going to talk a little bit about some upcoming new stuffs, and a lil’ stuffs I’ve been doing.
During a “final push” this week to get LuaRousr 1.0 out, I delved into the land of CMake, Ubuntu, and macOS. Learned how to build my C++ extensions cross-platform, and also exporting from GameMaker Studio 2 with both the macOS and Ubuntu modules! While I’m still working on LuaRousr’s export (I ran into some issues that seem to be on the [GMS2] side), I did add support for Ubuntu to outsideTheBox as well as fix a couple lingering bugs I didn’t realize existed. ;)
Since I intend to add support for both OSX and Ubuntu exports for LuaRousr, I’ve recently had the pleasure of trying to get an Ubuntu pipeline working. (Note: I have yet to start on OS X, and without a Mac I expect some fun there in a later article). The YYG Article was a great help, but I had a few additional notes to add, figured I’d walk you through the whole thing.
If you’re a more advanced user, I’ve already done this for outsideTheBox, you can check out the CMakeLists.txt file in the the DLL extension’s source for one way to build extensions for Ubuntu use.