Someone asked me how I do branching choices in my list-based system and I decided to share the info with everyone. Basically: I have a surprisingly flexible label system that’s inspired by “goto”s in machine code.
I have “label” commands that I insert into the scene, and then a couple methods of jumping to different “labels.” You can build out pretty extravagant loops and branching paths with just this. It’s not as fancy as some visual editor or twine or whatever, but it gets the job done.
Here’s what some of that code looks like.
Label is just a “blank” cutscene command. All it does is return true.
“GotoLabel” is the fancy one. It searches the entire list of cutscene commands (including previous ones–nothing gets deleted until the cutscene ends) for “Label” commands. Then it looks for the arguments for those “Label” commands, and if the argument matches what it’s searching for, it changes the cutscene position to that command.
There are a few other scripts that access this logic in different conditions. For example, in my first screenshot, we prompt the player with an “Ask” command–and depending on what the player picks, it goes to a different label. Another more all-purpose one is this CheckData command…
Basically it checks if a data entry is greater or equal to some given value. Then it jumps to either Label 1 or 2 depending on the outcome of that comparison.
The weirdest quirk is that to use the GotoLabel on line 12, it has to make a new list containing the intended arguments and pass those to the script, rather than just giving it arguments, since once the cutscene is running this is how it’s all formatted behind the scenes. Then it has to destroy that list immediately to save memory space.
Messy messy blah blah, but this lets me jump to different cutscene branches depending on the game state, and prior choices.
Wandersong is a musical adventure game, and it has a LOT of different scenes! From the get-go I knew this was going to be a game about exploring lots of places, so I wanted to make a system that simplified the process of building new unique scenes, with lots of different kinds of shapes (no tiles!!!)… and that’s how the game ended up looking like this!
Everything is constructed out of handmade shapes! I wanted to share some of how I implemented this in GameMaker, because understanding it may help other people create games with unique visual styles and effects… and it also forms the basis of more interesting systems, like the physics and collisions (!!!). Even if you’re not using GameMaker, the philosophy and methodology has plenty of applications elsewhere. So. Let’s dig in!
Points
These are the building blocks of geometry itself, and our starting point for making shapes. AND, our first stumbling block, because… GameMaker doesn’t have anything like them built in! In theory, for 2D, a point is basically just a position in the world… an X and a Y. To use them in Wandersong, I basically had to make up my own “point” system from scratch. I’ve done it many different ways for many games in the past, but the system I’m using now has been the most stable for me.
I use a built-in GameMaker data structure called a grid to represent a point. A grid is basically a table of information, like a 2D array if you’re familiar. But grids are messy to deal with, so I wrote a bunch of helper scripts that do all the work with grids, but let me work with them as if they were points. This is something that in programmer-terminology is called an Interface. Here are all the building blocks of my “point” system.
point(x,y)
This makes a new point with the x,y position that I specify! This returns the new point, which you have to make sure to keep track of. Because they are secretly grids, they follow the same rules. Once made, a point exists in memory forever, until it is manually deleted. So you have to be sure to delete them yourself when they aren’t being used anymore!
point_destroy(point)
That’s what this does.
point_set(point,x,y)
This changes the position of an existing point to a new position.
point_add(point,x,y)
This moves an existing point by x,y units!
point_x(point)
point_y(point)
And these tell you the x and y position of an existing point.
Not actually that much code, but it forms the basis of everything, and makes all the code that deals with points much easier to follow and understand! Now we can say something like:
This makes a new point at 100,100, moves it by 50 on the x axis and 50 on the y axis, shows its x position, and then deletes it. The message should say “50,” the same as 100 + 50. Makes sense so far? It’s going to get more complicated now.
Shapes
A shape is just a list of points! GameMaker has a data structure for this, helpfully named list already. This terrifying ugly diagram shows shape might look like, theoretically:
To the left is (a pretty version of) how it exists inside the computer’s memory. Just a list of points, one after another. On the right it shows how you might visualize that same shape. Although it isn’t specified anywhere, it’s useful to imagine that each point has an imaginary arrow to the next one, and the last point has an arrow back to the first one… that’s what forms the edges that make up the “shape” (!).
(A note about GameMaker: ‘positive’ Y actually goes DOWN, and negative ‘Y’ goes UP, which is contrary to the standard in other engines… something to keep in mind).
And here’s the pieces that would make an interface for shapes. To be perfectly honest, there is so little code in these and they’re so close to just being regular ds_list_ functions that I hardly ever use them… I’m comfortable working with lists directly, so I just do that. But they might be helpful to you.
shape_create()
Creates and returns a new empty shape!
shape_create_ext(point, point, etc)
This makes a new shape, but with points in it! So for example, you could say something like:
A way to find out the contents of the shape. For “index” you give a number, starting from 0. So for example, to find out the first point in a shape called coolShape, I would say firstPoint = shape_point(coolShape,0)
shape_size(shape)
This tells you how many points are in the shape! Because you count from 0, shape_size(shape) - 1 is the index of the last point in shape. For example, if a shape has 3 points in it, they will be at indices 0, 1 and 2… there is no index 3!
Triangulation
So now you can make points and shapes of any kind you want! Great! But so far they only exist as numbers and data. What if you actually want to show what they look like on the screen? This is where things get really abstract. To actually display these shapes on the screen, there is a very important middle step that has to happen called triangulation, as in, “to make into triangles.”
Why do you have to do this? You might be familiar with the way a pixel is the building block of a digital image. Well, there’s two basic standards we can think of with digital rendering… raster and vector. A “raster” image is made up of rectangles, or pixels… but to render shapes like this, we are really thinking in “vector,” which is to say, an image computed through points and lines. It’s a much more mathematical way to structure visual language, and the basis of all 3D rendering. The way computer standards are designed, to render shapes to a screen, you break them down into triangles… they’re basically the visual building blocks of a vector image, just like pixels are for raster.
Image is here solely to break up all the boring text with something nice
I’ll save you a lot more boring explanation, and say that there’s plenty of existing solutions for this problem. I adapted this code written by xot to handle my shape-and-point system. It’s way too long to paste here and already has comments to explain itself, so you can just get it here!: http://pastebin.com/asCE3NcA
This script takes a shape, and returns a new list. It re-uses the points in our original shape, but arranges them in sets of 3 that form triangles. It’s actually a fairly slow (not perfectly optimized) process, so I always make sure to do it once when the shape is first made, and then store that new triangulated list and don’t touch this script again unless/until the shape changes.
One thing to keep in mind forever is that the order of points matters. Not just because their arrangement forms the shape, but because they have to be ordered in a counter-clockwise fashion as standard for this triangulation math to work. There is
really no reason why it’s counter-clockwise instead of clockwise; but you have to be consistently one or the other so you can do math on them quickly! I do counter-clockwise because it seems to be more standard.
This might be the hypothetical “Create” event for a box shape object:
So much explanation, but as you can see the use is actually pretty easy… just two functions and we have a box shape, triangulated and ready to render! (Notice how the points we define for the box are made in a counter-clockwise order…).
Yes. We’ve arranged all the ingredients and organized everything nicely, so the job of rendering is now pretty straightforward. GameMaker comes with a very nice set of functions to render basic shapes to the screen given a bunch of points. In GameMaker, they’re called primitives (as in “primitive” or “basic” shapes). And the act of putting something on the screen is called drawing.
The way it works in GameMaker (as it does fundamentally in most engines) is you start or initiate the drawing of a primitive. You supply it a bunch of points, one by one. Then you tell it you’re done drawing the primitive. It takes all those points you gave it, does some math, and makes a shape appear! Nice!
Here is what we might put in the draw event of the above box object:
Actually, we could change the shape in the create event to basically anything, and this code would work. Because our “triangulated” list is just a list of points, we can use the same shape functions to get information from it, even though they are not arranged in the usual way I described above. As you can see, we just loop through every point in the “triangulated” list and draw its position to the screen. It’s important to note that when we draw_primitive_begin we specify the “trianglelist” type to let GameMaker know we’re going to give it sets of 3 points that form triangles. There’s other ways to organize our points, but this is the only general-purpose one that can be used to draw ANY SHAPE.
If we put our box object in an empty black room, it would look something like this:
So much work and explanation to do something so simple!!! But once you get the hang of it, this system can be built upon to make very elaborate stuff. Like the entirety of Wandersong!
That’s a wrap for now. Feel free to send me questions for things that were unclear! Now take this knowledge and make awesome games with it!!!
Wandersong is a musical adventure game about a bard, and it has a lot of characters and cutscenes and conversations! As a result of this, there are a LOT of very small bits of information the game needs to keep track of… The most common being, “how many times have I talked to this character?” It seems like a pointlessly small thing to write about, but it comes up a lot and I have a solution for it that I very much like, so I figured I’d share.
A typical conversation
In short: all data is stored into a giant dictionary. At the start of a new game it’s completely empty, and entries are added as the player interacts with things. If an entry doesn’t exist in the dictionary yet, it’s treated as being set to 0.
Sounds stupid simple, right? OK, it is. But it’s powerful! What follows is an explanation of how it’s implemented in GameMaker Studio.
Instead of “dictionaries,” GameMaker has a data structure called a map. For the uninitiated: a dictionary/map contains data stored in pairs, a “key” and a “value.” The “key” is kind of like an entry name or label, and the “value” tells you what it’s set to right now. At the start of the game, I make a blank map like this:
And then I have but two scripts that deal with this data.
data_set
Which takes two arguments, an entry name and a value. It either adds a new entry to the dictionary, or updates it if it already exists… and for good measure, it autosaves the game too, because why not. (Actually I forgot it did that until now, but I guess it happens so fast I never noticed, so…?)
and data_get
You give it an entry name, and it tells you what’s stored there. Or 0 if it doesn’t exist yet. (This is important!)
And here is how it typically would get used, in the interact-with-a-character event:
So for this event, I used an entry called “talking_to_bob”. I check what’s stored there, give you a different piece of dialog depending on what it is, and then set it to something new for next time. Typically in Wandersong, an NPC conversation tree follows the logic (conversation 1) - > (conversation 2) -> (conversation 3) -> (conversation 2) -> (conversation 3) -> etc. But you can do whatever you want with this.
There are a couple big advantages here. When I save the game, I just save the contents of the game_data dictionary–which is just a couple lines of code to do–but that’s flexible enough to include any amount of data, forever. So I can add new conversations, new conversation branches, or track anything I want anytime while I’m in the middle of writing a scene, and I don’t have to worry about bookkeeping anywhere else. It lets me be flexible and loose and have weird ideas as I’m going, and it makes it very easy to add new responsive content. It’s considered bad practice to save data under a string name as I do here, since I could easily typo “talking_to_bob” and there would be no easy way to track errors that stem from that (unlike a variable name, where a typo would just make game crash). But that “talking_to_bob” entry name is not written out ANYWHERE ELSE IN THE CODE except right here, so it’s easy to correct errors.
The other advantage is the synergy this has with my cutscene system. Or really, the way it deals with my system’s biggest weakness. This is going to be a little abstract. The weakness is this: I send instructions for an entire cutscene all at once to the scene manager, and then sit and wait for the entire scene to play out over time. This is mostly great, but what if I want the cutscene to change depending on data that gets altered after it already started… like in this one, where you enter your name and it’s read back to you?
To make this work, when the cutscene instructions are sent off, instead of supplying the player name, I supply a dictionary entry to look at for the player name… this way, as the cutscene is running,the text can update as the dictionary entry updates. In GameMaker, crucially, you can’t use a regular old variable this way…
And that… covers it! It’s not as glamorous as my last how-to, but I think the usefulness is actually much broader. With all my tools and systems, I’m always looking to get the most power and flexibility with the minimal amount of typing and actual organization/management. If you’re going to make an entire game by yourself, especially one that’s overfilled with content, you have to think this way or you’ll never be done! Anyways. I hope this is useful to you. Feel free to send me questions if I left something unclear!
Wandersong’s a musical adventure game about a bard, where you use singing to solve the world’s problems. It’s made in GameMaker Studio. And it has a big emphasis on story, with a lot of characters and unique scenes. People often ask me how I implement all that behind the scenes, so I figured I’d share my tools a bit.
(Above: a typical conversation, and some of the code that drives the scene)
The basics are pretty straightforward. There’s a cutscene manager objects who hangs out invisibly in every screen of the game. When one of the special cutscene scripts is called, it passes instructions to the cutscene manager, who always keeps a list of instructions running. And whenever the cutscene instruction list has anything in it, the cutscene manager broadcasts that a cutscene is happening, and processes the instructions in its list one by one, until they’re done.
The most important detail of this implementation, I think, is that it lets me write cutscenes inline with the rest of the game logic, and it’s all very natural and fluid, so I can focus on being creative and making it as I go. Other games will often separate the writing and scene stuff into separate files or systems, like an XML data file or a LUA interpreter or something, so that it’s easy to collaborate with a writer without them having to deal with programming, and it can be exchanged later with translated versions. But since I’m also doing all the programming and animation anyway, it’s easier for me to put it together all at once. I’m pretty far along on a solution for translations, too, but that’s for another time…
I’ll share some nitty-gritty on how I make it work specifically in game maker below.
Here’s a typical cutscene script, marked up a bit. All of them follow this structure, which, right out of the gate, is pretty hacky, heh heh. There’s actually two completely different uses for each script, one for when it’s used by the scene manager (red), and one for when it’s used by anything else (blue). The blue part is the one that happens first, so I’ll start there.
The blue part is basically identical in every cutscene script, actually, and I always make a new scene script by duplicating an old one because of this. First, it adds the name of the current script to the objSceneManager’s “scene” list. In Game Maker the name of resources like scripts, sprites, sounds etc. are automatically special words that let you point to them (for example, when you want to play a sound file, typically you’ll tell it the name of the sound so it knows which one to play). So the script basically adds itself to a list somewhere.
Second, it makes a new list that contains all of the “arguments” passed to it. This script is for setting the position of an object during a cutscene, and I give it the name of an object, an x position and a y position… so all those values are stored into a list, and then it adds that list to objSceneManager’s “scene_args” list. Lists of lists might sound kind of silly, but this game is full of them behind the scenes, and they also excite me in ways I don’t fully understand.
This little pile of code is the key that makes the rest of it run, basically. The line underlined in red is the big one. The scene manager tracks where it is in the cutscene with a variable called “scene_moment,” and every frame it looks at that spot in the scene and scene_args lists and runs all the instructions left there. The arguments we passed to the scene initially are stored in lists, and we pass those lists back to the script when we run it from the scene manager. Scene scripts when run from the scene manager always return a true or false, to let it know if they finished their job or not. The scene manager runs them from a “while” loop, which goes forever until it gets a “false” from one of these or runs out of them. The blue section shows what happens when it runs dry… basically it just clears and resets everything.
Back to here, now, looking at the red section… this is how it runs from the scene manager. Instead of looking at arguments, we look at the list passed to us in argument[0], and evaluate the contents of that list like arguments instead. Then we do a little code and return true. Actions that take time or need input, like a textbox or a “Wait for x amount of time” command, will return false until their conditions are all met, at which point they return true. This way I can have many actions parsed in the same frame, like a camera movement and a sound being played, and other times I can create timings by adding in pauses and stuff.
Ta-da! That’s it. I hope it wasn’t too hard to follow. I’ve done a number of games with lots of text and scenes before, but this basic system was a new idea for this game and it’s been by far the most useful and flexible system I’ve been able to work with. Feel free to lift the structure wholesale and make sweet cutscene-filled games with it. And also, feel free to send me questions if I wasn’t clear enough about something.
