Category: development

GameMaker Tutorial: Instance Pooling for performance optimization

2016-Dec-14

development, GameMaker Tutorials, programming, Tutorials

Instance pooling is a design pattern which can potentially help performance in games where you are creating and destroying a lot of instances.

If your program is spawning and destroying objects very frequently, calling the Create and Destroy Events many times per step, it’s potentially a lot of extra processing. Creating instances and destroying others constantly seems wasteful. Why destroy the instances that need to be destroyed when instead you can re-use them, and avoid having to call the Create event on a New instance every time you need one?

The Code

You can download my demo code here:

The GMS2 demo is an import of the 1.4 demo, cleaned up to remove the Compatibility scripts.

Looking at the project code, you will see that I have used inheritance to make the Control and Instance Pool test implementations as close to identical as possible. I have included telemetry code, which tracks the FPS of the game while it runs, so that performance is quantifiable. In the GMS1.4 version of the project, all of the telemetry code is neatly separated from the demo code into its own Execute Code action. This makes it easy to modify the project for your own use, and get rid of the telemetry code entirely if you don’t need to quantify runtime performance, and only want the code that actually implements the Instance Pool pattern.

How it works

The basic concept of the Instance Pool pattern is simple. The goal is to minimize the amount of times we create new instances of some object in large numbers during the game. A good candidate for objects to use Instance Pooling with would be bullets, bonuses, and enemies. Instance Pooling is particularly beneficial when the object in the pool is somewhat “heavy” — that is when the Create or Destroy events cause a lot of processing to happen.

The way we achieve this goal is by re-using already-existing instances of the object. This is done by deactivating the instance rather than destroying it. We add the id of all deactivated instances to our Pool. Then, when a new instance is needed, we first check the pool to see if an already-created but inactive instance exists, and if so, we remove it from the pool, activate it, and re-use it.

The most efficient way to create and manage our pool is with a stack. Stacks are elementary data structures in computer science. Imagine a stack of pancakes. The stack gets bigger as you add more pancakes to it. If someone orders a pancake, you take the top one off of the stack, and give it to them.

This is what’s known as Last In, First Out, or LIFO data access. This happens to be just what we need. The stack gives us an easy way to keep track of the id of all of our deactivated instances, and when we need to activate one, we just pop it off the top of the stack. This is very simple to do, and therefore very fast. In GameMaker, stacks are created by ds_stack functions. If you’ve never used them before, take a moment to read up on them. It will help you understand how the demo works.

The code at the heart of this is quite simple. It looks like this:

//First check the pool to see if it has any deactivated instances in it that we can use
 if ds_stack_empty(pool)
 {
 //If not, we need to create a new instance. No performance gain.
 instance_create(x,y,oInstancePoolBullet);
 }
 else
 {
 //If the pool has an instance we can use, take it out and activate it.
 var bullet = ds_stack_pop(pool);
 instance_activate_object(bullet);

 //Reset the state of the instance. 
 //**If** this is cheaper than a new instance, we gain performance.
 bullet.x = x;
 bullet.y = y;
 bullet.direction = direction + random_range(-20,20);
 bullet.alarm[0] = bullet.TTL;
 }

There’s only a little bit of other code that you need. You need to create the ds_stack, most likely this is best done in the Create Event, using ds_stack_create(). And when the pool is no longer needed, you need to destroy the ds_stack using ds_stack_destroy(), most likely in the Destroy Event.

Of course, we also need to push instances to the stack when they are no longer needed. To do that, we do this whenever we would ordinarily destroy the instance:

ds_stack_push(oInstancePoolPlayer.pool, id);
instance_deactivate_object(id);

So, don’t destroy instances that you want to pool; deactivate them instead. With our bullet demo, I do this by giving bullets a “time to live” and then setting an timer. When the alarm goes off, the instance’s id is added to the stack, and the instance is deactivated. Then it just waits for the game to need it. In a full game, you would need to look at other occasions where you need to deactivate the bullet, such as when it goes outside the room, off the screen, or when it hits an object.

That’s basically it. But you may need to think about some additional concerns, which I will cover in the Findings section of this tutorial.

Running The Demo

Open the project with GameMaker Studio, compile, and run.

The Demo consists of an Instance Pool demo and a Create-Destroy demo for comparison.

Press the Space bar to spawn bullets. Press Tab to switch from one demo to the other.

The FPS is displayed at the top-left of the screen. The first number is the minimum fps, the middle is the average fps over the last 30 steps, and the last number is the maximum fps. The minimum and maximum fps reset once per second. The average is a rolling average over the last second.

In the Instance Pool demo room, hold the space bar down until the first bullets to spawn reach the end of their life. At this point, the instance pool is filled, and no more instances will spawn; instead, deactivated instances will be re-used. At this point, you should notice the FPS dramatically shoots up and stays consistent.

Findings

To my surprise, I did not find that there was much benefit to creating an Instance Pool for bullets. Create and Destroy is about as fast as Instance Pooling with simple bullet objects in GameMaker. I expect the reason for this is that the GameMaker runtime engine is not particularly fast, but even when I did a YYC build, I still saw no real advantage to using an Instance Pool, at least in terms of fps.

Over a long game session, it may be that there is a reduction in memory fragmentation since we are updating values in RAM that has already been allocated, rather than rapidly allocating/de-allocating memory when we create new instances and destroy them constantly. But I haven’t tested that, so it’s merely speculation for now. Update: This benefit of reducing memory fragmentation is confirmed by Mike Dailly of YoYoGames.

In order to show a benefit to Instance Pooling, I had to weigh down the Create Event for my bullets. To do this, I ran a simple repeat loop to increment a variable. This is obviously inefficient and pretty pointless, but it serves the purpose of simulating a complicated object with an init script that takes some time to run. If that init script needs to be run only once, and not every time the instance is re-used, then there is a benefit and using the Instance Pool pattern will help.

When does it make sense to use the Instance Pool pattern? When there is a performance issue, and the Create or Destroy Events are more expensive than instance_activate_object() and instance_deactivate_object().

Setting up and managing the instance pool is pretty simple, but it does take some work, and incurs some overhead. It’s not worth it to incur this overhead unless there’s a tangible benefit in the form of noticeably improved performance.

Run the code profiler, and see where your code is spending the most time. If it’s heavy on Create and Destroy events, an instance pool might be just what the doctor ordered. Otherwise, you may want to look elsewhere for your low framerate fix.

Additional Considerations

As I mentioned, there are a few other considerations that you should think about when implementing an Instance Pool, which I will discuss here.

Should we Prime the pool?

In my demo, we only create new instances when there are none in the stack. This means that until we’ve deactivated our first instance, the stack is empty, and there is no performance gained by having it.

In fact, since we’re checking the stack before we create each new instance, there’s actually an infinitesimal hit to performance. When you run the Instance Pool room, we see pretty much the same fps performance as we did in the Create-Destroy room, until the first bullets start to be recycled. Only then do we see fps shoot up.

Well, what if we want the performance to be high from the very first bullet? We can do that, by priming the stack, by creating a bunch of bullets, and then immediately deactivating them and pop their id’s onto the stack.

We could create a special object that we might call oPoolPrimer, which lives for several steps, creates the instances we need and deactivates them, adds them to the Instance Pool stack, and then destroys itself when its work is done.

The best time to do this is when the performance hit won’t be noticed, such as when the game is in a menu screen. Alternately, we can create the instances gradually, over a longer time than would introduce a noticeable performance penalty.

To be effective, you will need to have a good way of calculating maximum the number of instances you need to have active in your game at any given time. Prime your pool with that many instances. That way, even when you have all of them active, you aren’t creating new ones, and your fps will stay high.

Trim the pool?

One of the downsides of the Instance Pool is that all those deactivated instances take up resources. Even though the CPU may not be spending as much time with those instances, they do incur some processing overhead to manage even when disabled, and as well they use some RAM.

Depending on your game, you might have a moment when you need a huge number of instances active, but in other parts of the game the action isn’t as intense, and you won’t need so many. For example, in my demo, I spawn 100 bullets per step, for 20 steps, resulting in some 2000 instances max if you hold the space bar down the entire time. But if you don’t need to shoot all the time, all those disabled bullets end up in the stack. Do you really need 2000 disabled instances? If there isn’t going to be as much shooting going on, you might not. We can free up resources by trimming the stack every so often.

One way to do this would be to set a recurring alarm so that every few seconds, the stack is trimmed if it goes over a certain size.

///Alarm0 Event:
while ds_stack_size(pool) > trim_limit
{
 //remove the top instance from the stack and destroy it
 with ds_stack_pop(pool) {instance_destroy();}
}
alarm[0] = reset;

This will keep the stack small when it doesn’t need to be so big.

Delete the pool?

If you delete the stack, you should realize that any disabled instances that we were tracking in the stack still exist. They will continue to do so until the game ends, or you change rooms. If you don’t change rooms right away for some reason, you may want to run through the stack before you destroy it, popping all the instances out of them so that they can be destroyed as well. Otherwise, those inactive instances will continue to take up resources.

while !ds_stack_empty(pool)
{
 //remove the top instance from the stack and destroy it
 with ds_stack_pop(pool) {instance_destroy();}
}
ds_stack_destroy(pool);

Benefits in network multiplayer games

This comes from GMC Forums user JuJu: There’s a nice implicit benefit of instance pooling: It makes handling multiplayer netcode for complicated scenes easier if you can refer to instances by a common index across all machines.

GMS2 Impressions: Tilesets and AutoTiling

2016-Dec-07

development, GameMaker Tutorials, reviews, Tutorials

2 Comments

One of the best new features in GameMaker Studio 2 is the improved tile system.

I never used tiles much in GMS1, because they were such a pain to work with, and did so little. In GMS1, tiles were a type of background resource. In the GMS1 room editor, you had to select your tiles manually, then place them one click at a time, which was very tedious. GMS users developed complicated auto-tiling scripts that would select the correct tile and place it in the room at runtime. This solution worked well, but was complicated to understand, set up, or modify. GMS1 tiles did not support animation, so if you wanted animated backgrounds, you either had to use sprites, or else come up with some sophisticated tile-swapping script that would programmatically animate your background tiles.

If you wanted your tiles to represent some kind of interactive object in the game, you had to also place an invisible object behind the tile, and program it to do whatever behaviors you needed. To me, there wasn’t much point in using tiles when I could just assign a sprite to the object, and use the object directly. If you did work with tiles in GMS1, then you may have to unlearn or relearn a few things before you feel comfortable with the new system.

I’m happy to say that in GMS2 the situation is much better. GMS2 tiles support animation and auto tiling. You can draw tiles in the room by the mouse without having to click each and every time you want to place a tile. This makes working with them much easier than it used to be.

However, there is still a lot of learning to do in order to develop the understanding necessary to set up tilesets and get the full use of them in your projects.

It took me an evening to figure out, about 4-6 hours, which isn’t bad. But after I had figured it out to the point where I have auto tile working, I realized that I could save others a lot of frustration by going a bit further to explain it.

Getting into GMS2 Tiles

First, the help manual articles on the Tileset Editor is essential reading. There are several articles which you should read first. And maybe a few YouTube videos are also helpful, to see the process of setting up a tileset for use within your project.

It’s actually pretty easy to use after you’ve gone through the process once so you understand it, but until you’ve completed your first working tileset, you’ll probably have a lot of questions and uncertainty about how it all works and what you’re supposed to do.

This article will guide you through that first time, and explain things so that they are easier to understand, and you’ll have an easier time of it than I did.

Before getting into that, there are a few constraints that you need to be aware of when working with tiles.

The tile grid size must be a power of 2. So, for the most part, 8×8, 16×16, 32×32, or 64×64 tiles will be the sizes to work with.
Any tile-based animations must have a number of frames that is a power of 2: 2, 4, 8, 16, etc.
Tile positions in a room are constrained to a grid in GMS2. You can no longer position them at an arbitrary position in the room; they must snap to a grid the size of the tile.
However, that entire grid may be offset, using the X Offset and Y Offset properties.
Tiles are placed in layers, and you can use as many Tile Layers as you like in the Room Editor.

Now that we’ve covered that, let’s look at the Tileset setup and usage workflow.

GMS2 Tileset Workflow

First, let’s take a general overview of the entire workflow, before we dive deeper into each step:

Tileset setup

Before you can use a tileset to decorate a room, you have to set up a Tileset resource. A Tileset resource is a resource that depends on a Sprite resource, and defines how the image in the Sprite is sliced up to create a set of tiles.

Create a sprite that will hold the image data for your tileset.
Create a tileset asset.
Define the tileset.
1. Add the sprite from Step 1 to the tileset.
2. Set tile size to split up the image into tiles.
3. (Optional): Create any brushes, animations, and auto tile sets that are needed.
Create additional tilesets, as needed.

Tileset usage:

This is where you put your tiles to work in the game. It’s all about creating and managing Tile Layers in your rooms, using the Room Editor.

Add a tile layer to a room
Select a tileset to use in the layer
Add tiles to the tile layer.
Add additional tile layers to the room, as needed.

Now that we’ve covered the workflow of Tile setup and usage at a high level, let’s go back and look at each step in depth.

Tileset Setup

Create a sprite that will hold the image data for your tileset

The first thing you need to do is create a Sprite resource, and add an image to it containing your tiles.

If you’re drawing this yourself, you’ll need to learn how to lay out this image. The first thing you’ll need to understand is that your tiles need to conform to a grid. You should set up the grid in the Image Editor to the size you’ll need for your tiles. I found that using an Image Editor grid that is half of what I want my actual tile size to be works well, so for a tile image that I wanted to draw that would have 32x32px tiles in it, I set the grid size in the Image Editor to 16×16. Then I drew out my tiles, using chunks that were 2×2 grid cells.

An important thing to realize in drawing your tiles is that your tile images should include some solid pixels as well as negative space surrounding the solid part of the tile. This is difficult to understand, especially at first, and it takes some getting used to the idea. To explain this properly, I need to illustrate.

As you can see here, I have drawn a brown rectangle, representing a solid object in the game room, and overlaid a green grid on top of it, showing how the tile borders should look if they’re done properly. Noticed that each tile (except for the center ones, which are completely solid) shows a certain amount of solid space and some white space.

I think a lot of people probably mistakenly think that their grid of tiles should look like this:

I know I did, at first. It’s hard to understand why tiles don’t work the second way — it seems a lot more obvious to position them that way, doesn’t it? After all, it takes fewer tiles, and there’s no overlapping into the negative space surrounding the solid object. If you’re just thinking about a simple rectangular platform or wall like this, it’s easy to think that it should simply be a 2×4 rectangle of solid brown tiles, all the same. The thing is, if you go back to the first illustration, you can see that in that illustration, we have many different types of tiles, representing edges, corners, and solid areas, working together to create the same rectangular platform, and since they’re not all the same tile, you can re-combine them in many different arrangements, to create other shapes.

Since the point of making the tile set is to enable you to create all the different types of edges and corners, you want to make sure that the sprite your tiles are drawn in is laid out in such a fashion.

We really need to create a ring so we can have inner and outer corners represented in our tile. We also need to have a tile representing a completely open space. By convention, GMS2 auto tile sets reserve the top left tile grid for this empty tile. Here’s a better image that shows all the different corner and edges that we’ll need for a complete tile set:

With this arrangement, we are able to create almost any arrangement of blocks, but we still have a few more tiles to create. We actually have a few duplicates in this tile set, which I’ll color code in the next illustration, as well as number the unique tiles.

As you can see, we have 14 unique tiles in this image, and a few duplicates. There are actually two more tiles that we’ll need to create a universal 16-tile auto tile set. They are:

We can consolidate space in our earlier image by eliminating some of the redundant tiles and replacing them with the ones we needed, like so:

Really, these tiles could be arranged in any ordering; this is just an example of one such arrangement.

There’s also a 47-tile auto tile but I think now that we’ve walked through the 16-tile auto tile set creation, you should be able to figure out the 47-tile version on your own. The ideas are the same, it’s just more work.

But just to make things convenient, here are two templates that I’ve created for 16×16 and 47×47 auto tiles, matching the order that the GMS2 Tile Set editor uses for its template:

16-tile tileset template for GMS2

47-tile tileset template for GMS2

You can right-click the images above, save, and use these for laying out your own tiles. No need to ask permission or give credit.

If you need 32×32 sized tiles, or larger, just scale the image up to whatever you need. Then import the image into the GMS2 Sprite Editor, set the grid to the size you need, and draw over the template in a new layer until you’ve built up your tiles!

I will point out here, that this sheet that we’ve created above just gives us a starting point to create a single auto-tile set. Most games will likely need several tilesets, for different areas of the game. Auto-tiling is best for your basic terrain, such as walls, floors, and platforms.

We could also choose to include numerous additional tiles in one sprite image if we desire, for decorative things that do not make sense to do auto-tiling with, or create additional tiles to represent terrain features in the game such tables and chairs, or other furniture, or trees, bushes, you name it. Or we could store each type of terrain, decorative elements, etc. in its own tileset resource.

We could also duplicate this 16-tile layout multiple times, and include in a variety of different terrain types, or different colors, all in a single large tilesheet. Or we could have multiple tile sheets. But be cautious about making the sheet too large. You’ll want to read the Texture Groups section of the manual to understand the limits of how large your sheets can be.

One last thing: If you wanted to create an animated auto-tiling tileset, you would need to create additional copies of our 16-tile auto tile layout, and draw each one as a different frame of animation. We’ll explain how to do this in the section on creating tile animations.

Create a tileset asset

Now that we have a sprite holding the image for our tile set, it’s time to create the tile set asset. To do this, right-click on the Tile Sets section of the resource tree, and select Create. You can name the new Tileset something meaningful, such as grassland, or ocean, or city, or indoors, or whatever suits your game.

Define the tileset

The Tileset editor looks like this:

The first thing to do is to add the sprite from Step 1 to the tileset. Click on Select Sprite, and select the sprite. Next, set tile size to split up the image, by entering the information in the Tile Properties fields at the right, as appropriate. The sprite image will appear sliced up by a grid as you change these values. At this point, we could use our newly created Tileset right away, by going to the Room editor, adding a Tile Layer, and drawing in some Tiles from our newly created Tileset.

(Optional): Create any brushes, animations, and auto tile sets that are needed

Once the grid looks how you want it, we’re ready to create any Brushes, Animations, and/or Auto Tiling sets that are needed. These are very useful, and powerful, new features that have been added to GMS2’s tiles. Not every Tileset needs Brushes, Animations, or Auto Tiling to be defined for it, but when you do use these, especially Auto Tiling, it will make creating your rooms much easier and faster.

This is where it really starts to get good.

Brushes

A brush is a selection of tiles, grouped together and added to your tile layer as one. Let’s say you have something in your tile that takes up more than one tile. This could be a large terrain feature, such as a building, or a mountain, or a tree. Without using brushes, every time you wanted to plant one of these multi-tile features in your room, you’d need to select each tile one at a time, place it in your Tile Layer, in the correct arrangement… this is tedious work and easy to screw up. So Tile Brushes make this easier by collecting the related tiles together, so that they can be added to the Tile Layer with just a single click to place the entire Brush.

You can use Brushes not just to place multi-tile graphics, but to place arrangements of platforms. Say you have a particular jumping puzzle that you want to repeat several times in a level; you can create a Brush with the tiles spaced out in just the way you want them, then place them quickly and easily into your Tile Layer.

Animation

Setting up Animation Tiles is pretty easy. Simply add a new Animation, specify the number of frames (which must be a power of 2), and then add the tiles that make up the animation one at a time until you’ve filled out the animation.

It’s worth noting that you don’t have to use Tilesets to do animation. You can place any sprite resource into a room directly, without the need to place an instance of some object to draw the sprite for you. These can be added to asset layers or background layers. Background layers can tile or stretch or both, and can move. So consider whether you need to do your animations in tiles or if you can do them more easily another way.

Auto Tile

Setting up an auto tile set is pretty easy too, although at first it seems complicated. Taking the sprite that we created, above, we have all the tiles we need to create a 16-tile auto tile set. GMS2 also supports a 47-tile system, but it is much the same to set up.

Create a new Auto Tile set. The auto tile set will present a template which you have to fill in with tiles from your tileset sprite. Simply go through the template by clicking on each tile in the template, then click on a tile from your tileset sprite to connect it to the template. The currently selected tile in the template is red, and as you go through your tileset adding tiles to the auto tile template, it will fill in the tile you selected, then advance to the next tile in the template automatically.

GMS2 auto tile editor The key to understanding the auto tile template is that the light grey parts of the template are meant to represent the solid parts of your tile, and the dark grey parts are meant to represent the empty space. If you didn’t know this up front, it’s very difficult to read the template correctly, and this was one of the most confusing parts of figuring out the auto tile editor.

Each of auto tiles (remember, there can be more than one in a tileset resource) is called an auto tile library. The image above shows two auto tile libraries about to be created; a 16-tile library, and a 47-tile library, just to show what they both look like.

It’s also important to understand the buttons to the right of the auto tile templates, which look a bit like a yinyang. These control how the tileset treats the borders of the room. Outside the edges of the room, the tileset must make an assumption: either the tiles outside the room count as empty, or as filled. This influences the auto tile system to select the appropriate tile at the room edge, and will result in an edge border around the room if the outside is treated as empty.

Once you’re done setting up the Tile Set resource, when you go to the Room Editor, in the Tile Layer editor, you’ll see a section in your tile palette called Libraries. Here, you can select Brushes, Animations, and Auto Tile sets to draw, rather than selecting individual Tiles from your Tile Set.

Pro Tip: An auto tile library will not work until and unless every tile in the template has been assigned. If you try laying out auto tiles in a tile layer and they just won’t draw, no matter what you do, go back and look at the template. Somewhere in there, some part of the template has not been assigned to a valid tile in your tileset.

The auto-tiling section in the manual illustrates this pretty well, with some nice animations showing how it works.

Animated Auto Tile sets

To create an animated Auto Tile set, simply make sure that each tile in your Auto Tile set is the first tile in an Animation set. In the room editor, the tiles will not animate, but as long as you place animated tiles in the editor using the first image in the animation, they will animate at runtime.

Re-Auto Tiling (Auto Tiling at runtime)

What if your room changes once the game starts? For example, if you have destructible terrain, and a piece of a platform gets destroyed, will the tiles automatically adjust accordingly? Unfortunately, no. Not yet; Dynamically re-auto-tiling at runtime is not supported by GMS2 at present, but it is a planned feature according to YYG lead programmer Mike Dailly, albeit with no release date announced yet.

This means that, at least for now, your auto-tiled setup will not automatically update the tiles if something changes during the game, for example if a new platform is created, or an existing one is destroyed, the tiles in the adjacent region will not update. This can cause things to look weird.

Presently the only way to handle this would be through a custom coded solution to evaluate the neighbors and determine an updated arrangement of tiles. This is pretty much the old system from GMS1, when auto-tiling was done at runtime.

There are scripts published on the GMC Forums and available for purchase in the Marketplace that will do auto-tiling for you, and YouTube videos describing how they work. These will need to be updated in order to be compatible with GMS2. At this time I haven’t evaluated these solutions, so I won’t be making a recommendation for any here. Hopefully YYG will provide a built-in solution in the form of GML functions, and there won’t be a need to invest time into developing custom solutions.

Create additional tilesets, as needed.

Your project can have as many tilesets as needed. Create as many as you like, to allow you to create as many different environments as you need for your game. It’s probably best to start simple and just create one at first, and then once you’re happy with it and satisfied that you know how to use the tile system, create additional Tilesets.

You can use multiple Tilesets in the same room, and in different layers, overlapping them. This is how you can develop very nice looking rooms.

Can a tile layer move/scroll?

Short answer: Yes. The functions tilemap_x() and tilemap_y() allow you to move a tile layer around the room. For complete details of all the things you can do with tilemaps, consult the manual.

The individual tiles in the tile layer have to align to their grid. So you can’t offset individual tiles, and make them move. But you can move the entire tilemap. If need be, you could put a few tiles in a layer that moves, and use this to create moving terrain features. For things like crumbling tiles, or tiles that break loose and drop one at a time when the player stands on them, it’s better to handle these with objects rather than tiles; of course, you can just use a sprite that looks the same as the tileset that you’re using, so everything blends together.

Tile Collisions

GMS2 can handle collisions between instances and tiles directly, without the need to use instances of hidden collision object behind the tiles. This is very handy, since you no longer need to lay out a bunch of instances in a room, then tile over them, and as well it offers greater performance, because there’s much less overhead involved with tiles than there is with instances.

Tile Collisions are meant for solid, stationary objects, such as platforms in a side-scrolling game, or walls in a top-down game, not for handling all possible collisions in your game. You will still want to use normal collision events for handling collisions between different objects in the game.

I mention them here so you’re aware of it, but rather than make this article even longer, I recommend you watch the tutorial video by GMWolf, which explains one approach for how to make a tilemap collision system in GMS2. His approach is to create a separate, invisible tile layer for the collision tilemap, which separates collisions from the decorative tile layer, which allows you to have decorative tiles which have rough edge texture, for surfaces like tall grass or uneven rock. The collision checking is performed by the objects in your game, which check to see if their sprite’s collision mask overlaps the tiles in the collision map.

It’s a very good approach, but it is just one way to do it. In GMWolf’s demo, a player object is prevented from entering into the region covered by the collision map. But there may be other types of collision checking, for example to determine if the player has entered a region that does damage, or is overlapping a ladder tile. Each of these situations can be handled by some variation of this basic approach, using additional collision tilemaps for different types of collisions. For example, you could have a collision tilemap for solid platforms, another collision tilemap for ladders (which triggers your character’s climbing behavior), one for water (which triggers water physics), one for slippery platforms, one for danger zones, etc., as many as needed. You can even use a collision tilemap to trigger events, such as to spawn or activate enemies when the player reaches a certain region of the game. There are many possibilities, so use your imagination.

Isometric and Hexagon tiling?

Because of GMS2’s requirement that tiles align to grid, you can’t lay out isometric or hexagonal tiles in a single tile layer. You’ll need to use a two layer approach, with the second layer offset horizontally and vertically, so that the two layers blend together.

This approach has its downsides. Having to switch back and forth between the two layers when laying them out in the room editor is a pain. And checking both layers for collisions doubles the amount of work the game needs to do at runtime for handling tile-based collisions.

I hope that something is done about these problems, I would like to see an “isometric grid” checkbox in the layer editor that allows aligning to a half-sized grid, or perhaps a new tile layer type for isometric tiles. But for now a two layer solution seems to be the best approach.

Update: YYG lead developer Mike Dailly recommends that we refer to the Isometric demo in GMS1.x for their recommended approach to do isometric games, and adapt that for GMS2 as necessary. (Hopefully a GMS2 Isometric demo will be happening eventually).

GML move functions and Tiles

If you use the GML functions

move_bounce_all() move_bounce_solid()

move_contact_all() move_contact_solid()

move_outside_all() move_outside_solid()

these work with the collision mask of objects, not tiles. So they will not be helpful to you if you’re implementing a tile-based collision system.

However, you can write your own version of these functions to work with tiles; to do so you just need to understand how the built-in functions work, and how to detect collisions with tiles.

The function move_bounce simply reverses the hspeed and vspeed of the bouncing object:

So, first determine whether the tile collision is horizontal or vertical, then use:

hspeed *= -1;
vspeed *= -1;

to reverse the appropriate speed variable.

If the bbox_left or bbox_right is in collision, set hspeed *= -1. If the bbox_top or bbox_bottom is in collision, set vspeed *= -1.

The move_bounce functions also take a boolean argument to turn on “advanced” collisions, which use the collision mask to do precise checking. These are slower to calculate, and the manual recommends not to use advanced unless it’s necessary, but they otherwise work the same. If you wanted to, you could come up with a tile collision check that uses the sprite’s collision mask to check for collisions with tiles, and use that.

The move_contact and move_outside functions work by using a while loop to check for collisions with the calling object, moving it one pixel at a time until the while condition is satisfied. This is easy enough to implement in a tile-based system as well.

GameMaker Studio 2 impressions: importing from GMS1.4

2016-Dec-06

development, programming, reviews

Comments

YoYoGames announced a game jam to celebrate the GMS2 Beta a couple weeks ago, and I’ve decided to try to participate. I don’t have a lot of time to work on my project, but I wanted to do something to warm up for Ludum Dare 37 anyway, so this was just the excuse I needed.

Since I’m short on time, and am very interested to see how well the GMS1.4->2.0 import feature is, I decided to work on an update to my LD35 entry, Shape Struggle.

Import and Compatibility Report

First, I made a copy of my source code. Then I imported it into GMS2, which was easy. A few seconds later, the project had been converted.

Immediately, GMS2 presented me with a Compatibility Report which details all the conversions it had to make, and the report itself appears as a file in my project resource tree under Notes.

Mostly, the conversion report details involves replacing calls to obsolete functions with compatibility scripts that do the equivalent thing. In my case, the game converted nicely, and I was able to build and run it without any problems. But, I expect that if the conversion process ran into problems, perhaps a function call that it could not convert to GMS2, the Compatibility Report would make mention of this, and I might have some additional work to do before the project would run.

YYG’s documentation says that the compatibility scripts should NOT be messed with, they are not intended to be human editable, so I haven’t tried messing around with them, but it leaves me curious about what might happen if I did. Not being able to go into these functions and make changes makes me question how maintainable an imported project is; and if it is not very maintainable, it mostly defeats the purpose of importing and converting an old project.

I haven’t done enough yet to know whether this is a legitimate concern or not, but it’s a worry for now until I know more. It seems to me that in order to have complete control over your project code, you’ll eventually need to go through and re-write any code that makes calls to compatibility scripts, to do the equivalent thing in a manner which is completely native to the way GMS2 wants things done. In many cases, this could be a simple and straightforward transliteration of the old code into new code which eliminates deprecated functions. Depending on the project size, though, this could get very tedious.

Update: Reading the Help documentation more carefully, I misread. Only compatibility scripts starting with a double underscore should be left alone. From looking at the compatibility scripts that I have reviewed so far, it seems like a fairly straightforward wrapping — the old, deprecated function call is used to create a script of the same name, and the script calls the equivalent GMS2 GML function(s) needed to achieve the equivalent results. It should (in principle) be possible to replace the call to the compatibilty script with the code inside of the compatibility script, and thereby convert the project to pure GML2. This does not apply to __compatibility scripts, however. If your project converts with these, it may be necessary to rewrite your project a different way to make it pure GML2. Or you may be able to leave it alone and hope that you don’t need to maintain that part of the project.

Collision Mask problems

Although my project would build and run, the conversion process was not 100% perfect. I noticed that some objects seemed to be colliding in a way that indicated that there was a problem with their collision masks. Sure enough, when I went into the Sprite Editor to have a look, I found that the collision masks were all wrong.

Upon further investigation, I determined that the only type of collision mask that currently works in GMS2 is a rectangle mask. Diamond, Ellipse, Precise, and Precise Per Frame masks are available options, but when I use them none of them work — collisions do not register and no event happens.

Moreover, I found that the collision mask editor does not seem to draw the mask shapes very well. When I tried to draw an ellipse mask, the right and bottom edges of the ellipse were flattened. I spent a lot of time trying to re-draw them to fix this problem, but the editor just overrides what I try to draw, and there’s no way to override it.

What’s more, if I tried to adjust the Alpha Tolerance on the mask, it would reset the mask to fill the entire sprite.

Very likely these are bugs due to the software still being in Beta status, and will not be long-term issues with the import process once GMS2 is officially released from Beta. So, clearly, the Sprite Editor has some issues and a long way to go before it is ready for release, including features which apparently have yet to be implemented.

Image Editor WTFs (Woes To Fix)

I also had a lot of problems with getting used to the new Image Editor. Most of this is a matter of UI polish, but there’s so much that is familiar, yet different, in the Image Editor UI that it’s giving me a lot of frustration. I fully understand the need for a user interface to change over time, but I do not understand many of the changes that have been made with the Image Editor. It’s tough to even know how to formulate my questions about them.

I find that Select and Copy operations don’t behave like I’d expect them to — copy creates a new Brush in m brushes palette. I can’t simply paste the pixels I’ve selected, and expect them to appear in the image at the position where I copied them from. This makes aligning static elements appearing in different frames in an animation a huge pain. Unless I’m missing something. Yes, there’s onion skinning, which is a great feature to have, but I don’t want to have to do painstaking image placement, I want to simply paste and see the content draw in where it was in the frame where I copied it from.

There’s also no replace color tool in the new Image Editor. In the GMS1.x Image Editor, there used to be a handy tool that would replace all pixels in the image matching the color you clicked on with the color set in the tool. For example, you could turn all red pixels green, with a single click. This was a useful tool, and I miss it.

I find the Text Tool in the Image Editor to be in need of a great deal of additional refinement. Currently, it is not very usable. I need to be able to reposition the text after I’ve typed it, but before committing. Most modern graphics editors allow this, but in GMS2’s Image Editor, once you click, there doesn’t appear to be any way to move the text that you’ve started typing, which makes positioning it correctly largely a matter of guesswork. There’s also no font preview, so when you select from the list of font names, unless you’re already familiar with the font in question, you won’t know what it looks like until you start using it. Currently it’s a huge pain to use the Text Toolf.

Summing up

Still, overall I’m very pleased that the code conversion process resulted in a project that could compile and run without throwing errors. There are still issues that need to be resolved, namely problems with sprite collision masks not coming through correctly in the conversion. And a lingering question about how maintainable an imported project is, if we cannot touch the compatibility scripts. I expect in time, with some more experience with converting projects, it will become apparent what the best approach to take is with modifying a game after importing it from 1.4.

Fun enum ideas for game development

2016-Dec-05

Game Design, GameMaker Tutorials, programming, Tutorials

4 Comments

Most video games have a counting, ranking, or level system of some sort. It’s often good to have a thematic flavor to your counting systems. This way, rather than calling your level progression by boring old regular numbers, you can give each level number a meaningful, or flavorful, name. This can add character or meaning to your game world, or it can be used to help disguise the underlying math, resulting in a game where the underlying mechanics are masked away from the player, leading to a more mysterious experience where they need to experiment and discover. What’s cooler: a “level 3 sword?” Or “the sword of autumn?” What’s more powerful: the knight sword or the rook sword?

To that end, I thought I’d demonstrate a few example enums that you can use to spice up your game design.

ENUMerate all the things!

Alphabet {A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z}

Greek Alphabet {Alpha, Beta, Gamma, Delta, Epsilon, Zeta, Eta, Theta, Iota, Kappa, Iota, Kappa, Lambda, Mu, Nu, Xi, Omicron, Pi, Rho, Sigma, Tau, Upsilon, Phi, Chi, Psi, Omega}

Military Phonetic Alphabet {Alpha, Beta, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliett, Kilo, Lima, Mike, November, Oscar, Papa, Quebec, Romeo, Sierra, Tango, Uniform, Victor, Whiskey, Xray, Yankee, Zulu}

Army (simplified) {Private, Specialist, Corporal, Sergeant, Officer, Lieutenant, Captain, Major, Colonel, General}

Navy (simplified) {Seaman, Petty Officer, Ensign, Lieutenant, Commander, Captain, Admiral}

Chess {Pawn, Knight, Bishop, Rook, Queen, King}

Rainbow {Red, Orange, Yellow, Green, Blue, Indigo, Violet}

Elements {Earth, Air, Fire, Water}

CardRank {Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King, Ace, Joker}

CardSuit {Clubs, Diamonds, Hearts, Spades}

Zodiac {Aquarius, Pisces, Aries, Taurus, Gemini, Cancer, Leo, Virgo, Libra, Scorpio, Sagittarius, Capricorn}

Seasons {Spring, Summer, Autumn, Winter}

Months {January, February, March, April, May, June, July, August, September, October, November, December}

Weekdays {Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday}

Lunar Cycle {New, WaxingCrescent, FirstQuarter, WaxingGibbous, Full, WaningGibbous, ThirdQuarter, WaningCresent}

Some of these may not necessarily have a natural order to them, but might just be a set of categories which you could use to organize something in your game. That something could be worlds, or items, or creature types, or powers, or anything else you can think of.

What else?

What else is there? Probably a whole lot! You could probably make a good basis for a game system out of gemstones, or metals, or barnyard animals, or anything, really!

If you know of a set of things that would make a good enum that I’ve left out, leave a comment below.

Using enums in GameMaker Studio

Enums are covered in the manual in the article on Data Types.

The basic syntax is as follows:

First, you have to declare the enum.

enum <variable>{<constant> [= <value>]}

You create the enum using the enum keyword, naming the enum <variable>. Then, in brackets, you list all the constants that make up the values in the enum. You can explicitly declare values for the enum constants, or you can leave them implied, in which case GameMaker will assign them integer values starting at 0, and increasing in order through the collection. You can even use expressions rather than a static value.

To access the enum constants, you use the syntax enum_variable.constant.

In your code, there are all kinds of situations where using an enum is potentially useful. Here’s a few things to look for in your code that might signal a good opportunity to use an enum:

Conditionals for checking state

Consider the following ways of checking the state of some object:

//check state using string matching
if state == "state_idle" {//do state actions}

//check state using literal numbers
if state == 0 {//do idle actions}

//check state using variable
state_idle = 0;
[...]
if state == state_idle {//do state0 actions}

//check state using enums
if state == enum.value {//do state actions}

Out of these, using enums is the best approach. Why are enums better?

Conditional checking by string matching is much slower than number matching. Your string value provides semantic meaning to the reader, making the code easier to understand when a human reads it. But when the program goes to check the conditional, it has to check every letter in both strings to see if they match.

As well, this approach is fairly error prone. It’s very easy to type the strings in slightly wrong. If you’re not careful, it’s easy to type one string where the state is assigned, and another string value where you’re checking state in order to do something state-specific. If you don’t catch the error, you’ll have a hard to diagnose bug because the conditional check won’t match what you’ve set the state variable to. One extra space, or misspelled word, or inconsistent use of capital letters, and the string match check will fail. The compiler won’t help you catch this sort of bug.

It’s a lot faster to do conditional checking via numbers. But naming your states with literal numbers: 0, 1, 2, etc. provides no meaning. Is 0 the idle state? is 1 running? is 2 jumping? Keeping track of this stuff in your head makes your work as a programmer harder, and makes the code hard to read, and brittle. You can do slightly better by creating a named variable and assigning the number value to it. The named variable can be expressive, e.g. state_idle = 0, state_running = 1, etc. But variables values can change, and storing each value takes a little bit of memory. By contrast, an enum value is constant — it cannot be changed once it is declared. And enums are global, so they are only declared and set in memory once, and thus require fewer resources. Even if you have ten thousand instances that use your enum, the memory used by them is the same as if there is only once instance.

Create an enum that provides expressive labels on these values, and you have the best of both worlds: expressive code that checks conditions fast, and uses computer resources efficiently.

Iteration over a set

Conventionally, programmers often rely on conventional looping variable names such as i or j to iterate over a collection of things, such as the members of an array, or other data structure. While this is OK, you can make your code more expressive by using enums to denote important numbers.

For example, it’s common for programmers to use a nested for loop iterating over the variables i and j to create a grid structure. Instead of using i and j, we can use variables named row and column instead. As we iterate over the range of rows and columns, we can use enums as flags to do something special at row (or column) == enum.constant.

Another example:

Say we want to implement an inventory equipping system for the player. The character has inventory slots for head, body, gloves, right hand, left hand, shoes. We decide to create an array, called inventory[], and assign the equipped item in each slot.

We could simply index the array with numbers:

inventory[0] = hat;
inventory[1] = armored_breastplate;
inventory[2] = iron_gauntlets;
inventory[3] = sword;
inventory[4] = empty;
inventory[5] = double_jump_boots;

Now, it’s not too hard to tell what each inventory slot is for. But it’s not as easy as it could be, either. Is the sword in the left hand or the right hand?

Let’s use an enum, and make the code easier understand.

enum inv_slots{head, body, gloves, right_hand, left_hand, shoes};

inventory[inv_slots.head] = hat;
inventory[inv_slots.body] = armored_breastplate;
inventory[inv_slots.gloves] = iron_gauntlets;
inventory[inv_slots.right_hand] = sword;
inventory[inv_slots.left_hand] = empty;
inventory[inv_slots.shoes] = double_jump_boots;

Now, it’s quite easy to see that the double_jump_boots are being worn on the player’s feet, rather than being carried in the player’s hands. It’s simple to keep track of which slot is which.

Creating a set of related, named values

Here’s a useful enum for direction angles for a top-down game:

enum compass {e = 0, ne = 45, n = 90, nw = 135, w = 180, sw = 225, s = 270, se = 315};

It’s much easier to remember and understand direction = compass.sw instead of direction = 225. You can use this enum for 4-direction and 8-direction movement or aiming, and you could even expand upon it if you wanted by adding constants for ene, nne, nnw, wnw, wsw, ssw, sse, and ese, like so:

enum compass {
 e = 0, 
 ene = 22.5, 
 ne = 45, 
 nne = 67.5, 
 n = 90, 
 nnw = 112.5
 nw = 135, 
 wnw = 157.5
 w = 180, 
 wsw = 202.5
 sw = 225, 
 ssw = 252.5
 s = 270, 
 sse = 292.5
 se = 315,
 ese = 337.5
 };

(I like to format my code like this; lining up the variable names, equals signs, and values makes it easy to scan down the file, and makes it clear that these values are all related.)

If I wanted, I could go a step further and use radians to make it clearer that these values are fractions of a circle:

enum compass {
 e = 0, 
 ene = radtodeg(pi * 0.125), 
 ne = radtodeg(pi * 0.25),
 nne = radtodeg(pi * 0.375), 
 n = radtodeg(pi * 0.5), 
 nnw = radtodeg(pi * 0.625),
 nw = radtodeg(pi * 0.75),
 wnw = radtodeg(pi * 0.875),
 w = radtodeg(pi), 
 wsw = radtodeg(pi * 1.125),
 sw = radtodeg(pi * 1.25),
 ssw = radtodeg(pi * 1.375),
 s = radtodeg(pi * 1.5),
 sse = radtodeg(pi * 1.625,
 se = radtodeg(pi * 1.75),
 ese = radtodeg(pi * 1.875)
 };

You can group together, and name other values that go together in a system using enums in this way, too.

Parting thoughts

Hopefully, these examples will help you see how enums can be useful to make your code more expressive, easier to read, and easier to maintain. Look for opportunities to use them in your code. They can really help!

GameMaker Studio 2 impressions: Preferences

2016-Nov-17

development, games, programming, reviews

Comments

Looking at the Preferences in GameMaker Studio 2 for the IDE, we have a lot of them, and they are logically grouped, and well-organized. Most of the preferences allow customization of cosmetic look-and-feel and UI behavior options.

The IDE is very customizable. Most of the configurable preferences come pre-set to defaults that make sense, and I don’t see much need to change them, but it is good that you have the control to change them if it suits you. I’m sure YYG anticipated that users would have countless nitpicky complaints about anything in the IDE that they couldn’t configure, and so wisely saw fit to give us the option to make ourselves comfortable. These options are by and large very straightforward and fairly dry to drill through, so I don’t see the need to go through them in depth here. The online manual has all the detail you need.

One very notable change from 1.x does merit mention, however:

There is no longer a backup folder. The old “save the n most recent backups” method of source control that was the only option available in GM8.x dsays, and carried over to GMS1.x, is gone completely from GMS2. Using a real version control system, such as git, has long been available, and is what everyone should use, but this does make version backups a bit more advanced for complete newbies. Nevertheless, it is now the only way to go.
Source-control integration doesn’t appear to be enabled yet in the GMS2 beta, or if it is I haven’t found it, so if you do want to use version control during the beta, you will have to manage the repository management and file check-in externally to the IDE.

With regard to GMS2’s default preferences, I found very few things that I wanted to change. But there were a few that were important to me:

One of the changes that I made was to set “Disable IDE transition animations” to true. While the IDE transitions are nice eye candy, I prefer things to be as fast as possible, and watching the Object editor open up and seeing the Workspace scroll to its location is time wasted, to me. Others might find it helps them to remain visually oriented to leave the animations on.
Another was to enable “Automatically Reload Changed Files”. If I work on an sprite sheet using an outside editor, or edit a code file in notepad for some reason, I want those changes to be reflected in GMS2 automatically.
The other thing I did was disable showing the background image in workspaces. While pretty, I prefer a plain, uncluttered background of solid grey. You can also set a different background image if you so desire.

Skins

There are two IDE skins, Dark and Light. Dark is the default, and I find that I do prefer it. Light is a bit too light for me, as it has a pure white background, rather than a light grey.

If it were light grey, I might prefer it over the Dark skin. One thing I did like about the Light skin is the code editor’s colors for syntax highlighting, which feels a bit more muted than the bright, rainbow-y colors in the Dark theme.

Fortunately, these colors are all customizable individually, if you want to tune them.

Will we have the capability to author our own skins, or add additional skins? I don’t normally want to spend a lot of time on cosmetic customization, but it might be nice for some to have the capability.

Room for improvement

It would be nice if the code editor settings could be saved collectively, to a profile document, and then loaded, so that you could export them and share with other users, and so you could avoid having to carefully re-set every setting one at a time if you need to reinstall or something.

Indeed, it would be nice to save the entire IDE’s configuration options as a profile, so that I could then switch between different IDE profiles as desired, allowing me to rapidly reconfigure GMS2 for different types of projects, for example I might find that if I’m doing a game that uses 3D graphics, I would want different settings for the Room Editor than I would want to use in a 2D Isometric game, and so on. I can see myself wanting to set up specific settings for grid sizing and snapping in both the Room Editor and in the Image Editor for different types of projects. If I’m maintaining multiple projects, switching back and forth between them, this would be a must-have.

The preferences you set are stored in %appdata%\GameMakerStudio2\[user id]\local_settings.json — this file is human readable, easy to backup, edit, share, and swap if you so desire. This has to be done manually, for now, but it’s my hope that YYG would give us some UI in the GMS2 IDE to save/import/manage preferences as a profile.

Game Options and Configurations

Outside of the File>Preferences dialog, we also have Game Options and Configurations, which is where we find settings that are project-specific. If you’re not sure where to look for some setting, ask yourself: Am I trying to change something in the IDE, or in the game I’m building? If it’s the IDE that you need to change, look in File>Preferences. If it’s some game setting, look at the Options or Configurations branches of the project resources explorer.

A few important things to point out with the project specific Options and Configurations, especially for users coming from GMS1.x:

Room_speed is no longer a thing in GMS2. Instead, there is a setting under Main Options – General, for Game Frames Per Second, which is a global replacement for the old per-room speed. The default is 30.
The default draw color for the project is also configurable here. I’m used to setting this in GML using the function draw_set_color(). To be honest I don’t know why YYG decided to make this a setting, perhaps just to make it simple for Drag and Drop users to find it, but whatever the reason, it’s here.
Interestingly, there are some timekeeping settings here, as well, that allow you to automatically keep track of the Project Start date, Project Use Time, and the DateTime when the Project Last Changed. Potentially, this could be used for billing users for the use of GMS2, if YYG decided to change their business model to something subscription-based, or metered. It’s also neat for if you are trying to track how many hours you have put into a project — although, the time tracked is simply how long GMS2 has been running, not necessarily how long you’ve been actively using it — if you went away for a break and left it up and running, the meter is still counting.
You can find settings for project GUID and author here as well.

In addition to General options, there are also platform-specific options for your game project. In the GMS2 beta, we only get to see the ones for Windows, but I expect users who have purchased additional build targets will find options for each of them here.

For Windows, we can set our display name, project name, version number, company, copyright statement, Graphics options for interpolation, fullscreen, window and mouse cursor, and a few other options. These are much as they were in GMS1.x.

GameMaker Studio 2 impressions: IDE/UI

2016-Nov-16

development, games, programming, reviews

Comments

The biggest change in GMS2 is the new IDE. Completely re-coded and largely re-designed, it has some things in common with the old IDE, but overall it has been re-organized and updated in many ways.

Every form in the UI is dockable, and can be moved around into whatever layout works best for you. This is great. Even better, you can pop out any part of the IDE into its own window, which means that you can spread your IDE out over a few display screens if your computer is set up this way. GMS1.x didn’t play nearly so well on multiple displays.

The resource tree is probably the most familiar element of the new IDE. By default, YYG have positioned it at the right side of the screen, presumably to follow other development environments such as Microsoft Visual Studio. It’s a simple matter to drag it and dock it to the left side of the window if you prefer the GMS1.x way.

Workspaces

Probably the biggest change to the IDE is the introduction of Workspaces. These are tabbed regions where you can dock different forms, so you can organize your project in a way that makes sense to you. For example, if you have a set of objects that are related to each other, you may want to set up a workspace where those objects can be arranged together. You can have as many workspaces as you wish, and you can name them something meaningful. This helps greatly to reduce clutter, and should improve productivity as you can leave workspaces set up and switch between them at will, without having to re-arrange windows and forms all the time.

I love the idea, but after using them for a few weeks, I’m convinced they have some serious issues that need to be addressed.

Workspaces can get very spread out, and this implies scrolling a lot. There is a new shortcut, ctrl+T, which will help you navigate the project more quickly than scrolling:

Press CTRL+T to quickly search through your resources in #GameMakerStudio2 pic.twitter.com/9DDxcUCzLe

— YoYo Games (@YoYoGames) November 10, 2016

Another navigational shortcut is to middle-click on a resource name in the code editor. Doing this will take you to the resource’s editor window.

A major problem with Workspaces is that the Workspace region only fills a small section of the GMS2 window. Dockable regions at left, right, and bottom make the Workspaces area relatively small compared to the size of a maximized window.

Inside the Workspace area, you have (potentially) multiple Editors open. Certain Editors use Chain View (see below) which spreads out the sub-editors visually, in a way that takes up quite a bit of space, and will all but certainly require you to scroll, both vertically and horizontally, in order to see the whole thing. Vertical scrolling can be done by mouse wheel, but horizontal scrolling is done by CTRL+Clicking in an empty region of the workspace and dragging, which is slow and awkward.

Another problem is the Dockable areas in the GMS2 window. These do not update contextually according to which Workspace you’re in, or what Editor you’re in. If you open the Room Editor in one workspace, the Room Properties will appear in the Dockable area at the left side of the GMS2 window. Switching to another workspace and opening up a Sprite, the Room Properties are still there in the left Dock, where they are useless for the current context, and serve only to distract and confuse, and take up valuable screen real estate that could have been used to present the Sprite Editor UI and/or provide a larger portion of the screen to display the sprite canvas. Fixing this should be a simple matter of showing/hiding the appropriate panels in the Docks for the current context you’re working in. Whichever editor has focus, its Dockable panels should be the only UI visible (apart from the Menu bar and Resource tree).

Maximizing an Editor should make it fill out the entire visible area of the Workspace. And whenever an editor has focus, its entire form should fit on one screen/workspace area without the need to scroll the workspace. I’m fine with a scroll bar within an Editor, for example if I’m in a really long code file in the Code Editor, or if I’m zoomed way in on an Image in the Image Editor. But I don’t want to have to scroll about the Workspace just so I can see from one end of an Editor to the other. I really don’t want to scroll around looking for different editors that are floating about in the Workspace. I would much prefer a tabbed interface where I can easily switch between tabs. Workspaces could be better implemented as groups of related tabs.

The worst part is when you go to open a code editor. The code editor is used in three situations: 1) when working on a Script resource; 2) when coding Events in the Object Editor, and 3) when editing Room Creation code in the Room editor. In the Object and Room Editor use cases, the Code Editor is chained to its parent editor. The code editor is almost never entirely visible in the visible area of the Workspace pane, meaning that very often the right and bottom of the Code Editor will be out of frame, and necessitate scrolling to see. So you’ll often be unable to see the ends of your longer lines of code, and the helpful code tips that appear at the status bar area in the bottom of the Code Editor will also be out of view. This is awful, and needs to be addressed. Code Editing is a primary activity in GMS2, and when doing it, the Code Editor deserves a maximized view, with minimal distractions surrounding it.

I believe the issues with Workspaces are fixable, but as they are now, they’re a bit of a disaster. I find that they make it easier to get lost, and I spend a lot of time flipping between them and scrolling, hoping to find what I’m looking for. They navigational shortcuts may be helpful, but they don’t come second nature to me, and so far I find that they’re so unfamiliar that I have to shift my mental focus form the programming task I’m working on to “how do I navigate to the bloody resource I need to look at?” which takes me out of “The Zone.” They make a 2048×1152 screen seem small and cramped.

Chain view

Another major new feature is called “chain view”. This is a new view for forms that have several sub-forms. For example, the Object editor has a main form that allows you to set the Object’s properties, and then if you add Events to an Object, these are managed in a sub-form that is chained to the main form. From there, Actions are in a sub-form that chains off of the Events sub-form, with a separate tab for each Event’s actions. This keeps related forms together, making it easier to see relationships between different open windows, and reduces clutter. They do spread out more, since the sub-forms do not overlap each other, and this takes some getting used to.

Menu and Tool bar

One thing that can be a little weird, and takes some getting used to, is the Menu bar. Depending on what form you have focus on, the Menus that appear in the main window’s menu bar will change.

For example, if you’re in the Image Editor, the main window will receive some Image Editor menus, to the right of the Help menu, and not in the Image Editor form.

Open the Image Editor, and some additional menus will appear in the menu bar.

This felt weird to me, at first, when the Image Editor is sharing the main window with whatever other forms you have open — I expected all controls specific to the Image Editor to be contained within the Image Editor’s form. However, if you break the Image Editor out of the main window and into its own window, it feels right.

Quick import your Asset files

Importing sound and image files into GMS2 is easier than ever. Just drag a file icon, or even a folder, into the resource tree, and the file will automatically be imported into the project, and a resource created for it.

Quickly import external resources into #GameMakerStudio2 #GameMaker #gamedev pic.twitter.com/4Fwj8k5dXw

— YoYo Games (@YoYoGames) November 9, 2016

Nice!

There is a lot more to cover in the IDE, but rather than make this article too long, I will be covering them separately in future articles focusing on the various Editors: Sprite, Image, Object, Room, etc.

Keyboard shortcuts

I won’t list them all (look in the manual, under Quick Start) but these are some of the most important/useful shortcuts, which everyone should know and use.

F5 – build and run the project.
Ctrl+T – Opens the Goto window to search the workspaces.
F2 – In the resource tree, rename the selected resource.
Ctrl+K – In the code editor, comments out the selected text. (Ctrl+Shift+K to un-comment.)
F2 – In the code editor, opens the code snippets menu.

UPDATED – YoYoGames Marketplace EULA now allows Creative Commons licensing

2016-Nov-14

development, games

Comments

Update: It turns out that it has always been possible to link a Marketplace asset to another EULA; I had never noticed this before!

YoYoGames apparently has added Creative Commons licensing to their standard EULA for purchases made through their Marketplace with the Creative Commons Attribution-ShareAlike 2.0 Generic license.

The old GameMaker Marketplace EULA is still in use for some assets:

Assets sold under the Creative Commons license show a different EULA:

Oddly, though, YYG have set up the checkout so that people purchasing assets for GameMaker Studio can make a donation to Creative Commons during checkout. At first, I thought that this was a donation to the asset maker, which would effectively allow a “pay what you want” model for free assets. But after clicking the Donate Now button, it became evident that it was for donating to Creative Commons, the organization that created the Creative Commons licensing. While I’m glad to see the Creative Commons organization getting support this way, it’s a bit confusing at first to someone who just wants to pay for their marketplace purchase.

Creative Commons licensing is a great idea and is exactly the right fit for the purpose here. I’m thrilled to see YoYoGames using CC licensing as another option in addition of their own license.

GameMaker Studio 2 impressions: Pricing

2016-Nov-03

development, games, reviews

3 Comments

[Rather than posting a long article that takes days to organize, I’m opting to do short-form posts that focus on a narrow aspect of the new GameMaker. This means more frequent, smaller posts, which will hopefully be more timely and more digestable for readers. For more articles in this series, just follow the GameMaker Studio 2 tag.]

This is all very early to talk about, and I recognize this, but a lot of people are talking about how much GameMaker Studio 2 will cost.

YoYoGames have put out their “prospective” pricing out on their website:

Currently, it looks like this:

Analysis

First, I am very happy that YYG did not try to go with a subscription-based model with their pricing. This shows that they have listened to their users, nearly all of whom despise the idea of paying a subscription on an ongoing basis for software. For hobbyists and occasional users, it’s not a good deal to pay for a subscription if they’re not going to use it all the time and really get the value out of it.

I find that the costs are basically in line with what I was expecting. Sure, Master Collection is a few more dollars than it was when they released it 6 years ago, but guess what, that was 6 years ago. Stuff gets more expensive as time goes on. That’s how it’s always been

The upgrade discounts are reasonable. 40%-50% off is not bad for an upgrade.

I do question why certain modules are so much more expensive than others. I would rather see the Android/iOS bundle and HTML5 bundle cost the same as the Desktop bundle. The UWP an Console bundles, I can understand somewhat more, as those build targets are of prime interest to commercial game developers who, it’s understood, make money from the games they produce, and it makes sense that they should be willing to pay more for those tools, and if by paying more for them, it helps subsidize the other users, then great.

I’m sad to see no free edition, apart from the Trial edition. Depending on the limits of Trial edition, it could still be viable for hobbyist developers, but it sounds like it’s more intended as an evaluation edition to allow people to decide whether they want to pay for a real edition that can actually build games.

Community Chatter

So, predictably, most people who are talking about it are complaining that the cost is too much. That’s a subjective judgement, and of course everyone wants to pay as little as possible, and get everything for free if that were possible somehow.

Some people think that all software should be free (as in beer). Mostly, these people just don’t have enough money to afford to pay for software. They spend as much money as they have on just getting a new computer, and then they can’t believe that the cost of the software they need to run can more than double the price of the system. I sympathize, because when I was younger I was definitely one of those people, and if it wasn’t for deep discounts on student licenses, bundles that came with new hardware, and so on, I couldn’t have afforded to buy much software.

Fortunately there has always been a lot of good quality, low-cost or free software available, as well. Different products are aimed at different markets. Companies that sell to big businesses charge a lot of money for their software, in part because they can, but also because they need to, because in order to develop they need big budgets and a lot of employees. But some software is the product of a single developer, who doesn’t have all the overhead that a large company has, and they can afford to sell for a cheaper price, or even give away if they feel like it. Additionally, there are developers who feel that they get paid to program, not to sell copies of software, and they can get funded to do a project that someone who has money needs, but then turn around and give away the software as a public good, and as long as the cost of development is met by a few, everyone benefits from it.

GameMaker’s history started out with a single developer, who sold the software very cheaply at first, and always had a free edition, and a paid edition that cost $20-25. Later, as GameMaker grew, it became too much for one person to maintain, and he sold it to YoYoGames, who are a larger company, and who therefore have more overhead and need to charge more in order to cover their costs, pay salaries, continue R&D and support, and turn a profit.

YoYoGames initially raised prices, from $25 to $40, around the time of GM8, and users howled that it was too much. And we can see in retrospect what a bargain it was, and how childish people who complained back then were. GM:S has been considerably more expensive, anywhere from $70-200, although they have continued to provide a free edition. YoYoGames can’t continue to exist if they just give away software for nothing.

And YYG charge more for extra GM:S features, up to $800 for their “Master Collection” bundle which includes everything, including stuff they haven’t come up with yet, later for no additional cost. $800 is very expensive for most people, and unless you’re making money with the software, or are wealthy enough not to care, it’s probably not for you. It’s aimed at companies that can look at the purchase of software as a capital investment that is part of the cost of doing business. And if by charging more to these customers, it enables YoYo to keep costs lower for individuals, students, and hobbyists who otherwise couldn’t afford to buy what YoYo would have to sell it for, I think it benefits everyone.

Maybe low-budget amateurs will gripe about not being able to get all the features, but they do get something.

You also have to compare GameMaker against what else is out there. And there’s a lot else out there. There’s stuff that’s completely free, like vi + gcc, which is very high quality and extremely powerful, but that isn’t necessarily the best option for everyone, because it requires a huge amount of learning and knowledge and work to create games with. In more direct competition are tools that are geared specifically toward game development, such as Unity3D (which is more expensive, and uses a subscription model now) and Construct, and free tools such as Godot, Love, and Defold, which may not be as well supported, well documented, or easy to use. And many others besides these. The bottom line is, if you don’t like GameMaker because of what it costs, you have plenty of options to choose from, many of which are very good.

So for people who are complaining that it’s too much, I don’t have much sympathy for you. It’s very likely that at various points YYG will have sale events, as they’ve had in the past. If you don’t want to pay the release day price, you can probably wait a year or two and hit a Steam sale or a Humble Store sale and get it at a pretty good discount then. By that time, it will be even better, with more polish and more features. In the meantime, if you have GM:S1.x you can continue use it, it will continue to receive support and bugfixes, and 2.x will be ready for you when you decide you can afford it.

GameMaker Studio 2 impressions: New Project

2016-Nov-02

development, games, programming, reviews

Comments

If I click on New Project, I have to choose between creating a Drag & Drop project or a GameMaker Language project.

Weird; I can’t use both in the same project anymore? [I haven’t actually created a new project yet; I don’t know. But that seems to be the implication here.]

Really, I expect that most GMS users use GML, but I’m glad that they’re keeping DnD, because for beginners and non-programmers it is much easier to learn. And it looks like they’ve really improved the Drag-n-Drop system by leaps and bounds over what it’s been up until now. (I’ll cover this in a separate post in more detail…)

But I think it’s odd that I have to pick between one or another coding system when I create my project.

Really, what I had hoped for was that there would be a “Convert DnD to GML” button that users could use, and this could facilitate learning how to code in GML by starting out in DnD, then converting to GML and seeing what it generates for you. I don’t know whether this is a feature that YYG have planned or not, if it is I haven’t discovered yet. Or, even better than a one-way conversion, YYG could have made DnD and GML completely equivalent, such that there was full coverage of the entire GML language with DnD actions, and allowed the developer to switch between views, viewing the code as visual drag and drop actions, or as GML code, and develop however they’re more comfortable at the moment.

I think this “one or the other but not both” approach could potentially cause problems, and will result in pushing users to using GML-only. When a new programmer begins to learn GML, at first they typically start out by going through a project they’ve created using DnD, and replacing the DnD actions an instruction at a time with equivalent GML. If you can’t do that in GMS2, it will make transitioning that much harder, because you would have to start a new project, and code exclusively in GML, before you’re totally ready. Rather than make a gradual transition to becoming a GML coder, the neophyte GMS2 developer will need to develop sufficient confidence in their understanding of GML to start a new project from scratch and use it exclusively.

~~This pretty much destroys GMS’s gentle learning curve that makes it great for first-time programmers.~~ Update: GML-DnD conversion is exactly how it works! Right-click in the object-editor and there’s an option to convert from DnD to GML, and vice versa.

GMS2 allows you to convert DnD directly to GML, and GML can be converted to DnD (it just shoves the GML code into an Execute Code DnD action, so it’s only semi-reversible).

Oddly, the DnD2GML conversion warns you that this is a one-way change, but that is apparently not the case (although converting GML to DnD simply puts the GML code into an Execute Code DnD action).

I suspect that many users look down at DnD disparagingly, but really there’s nothing wrong with using it. It’s quick, and if it’s all you need, it’s all you need. For what would be a simple, one-liner GML script, I often opt to use DnD when I’m in a hurry, because it’s expedient.

GameMaker Studio 2 impressions: Start Page

2016-Nov-02

development, games, reviews

Comments

Here’s what the new Start Page looks like:

Observations

My display resolution is 2048×1152, and yet the Start Page still doesn’t fit all on the screen without scrolling. Wow.
The top third of the Start Page is taken up by a rotating slide show of images. Personally, I find this annoying. Granted, the Start Page is not a screen I’ll be spending a lot of time looking at, but I just don’t care for the rotating images. I find them distracting. I want a dev tool, not a marketing delivery system. It’s one thing to have the “did you know” tips that provide useful information, and I of course love the news and release notes, but a image that updates every few seconds when I just want to set up a new project is a bit much for me. The images don’t do anything for me, and they take up a lot of space that could be used for something more useful.
Hovering over the rotating slideshow, I noticed the cursor changed to the pointing finger which indicates I’m hovering over a hyperlink. Intrigued, I clicked, wondering what would happen. This is what happened:
Where did Getting Started and Explore go to? How do I get them back? Why did clicking the image at the top of the screen make that happen? It took me a few minutes, but I figured out that if I click the GameMaker Studio logo at the top left of the Start Page, in the transparent ribbon overlaying the rotating slideshow, it puts the Getting Started and Explore sections back.This is really weird navigation. They should just have left and right arrows at either side of the sections, or tabs.

UI suggestion: Rather than switching between [Getting Started|Explore] and [Tutorials] by clicking on the slideshow or the GMS2 logo, which have no apparent connection to these sections, just use a straightforward left/right arrow navigation system to switch between them.

Clicking links on the top, which aren’t even obviously links, which have no apparent relationship to the bottom half of the screen, just isn’t good UI design.
I notice Start Page is a tab within the GMS2 window, but I can’t close the tab. What other tabs will appear here when I start using the software?

← Older Posts

Newer Posts →

Category: development

The Code

How it works

Running The Demo

Findings

When does it make sense to use the Instance Pool pattern? When there is a performance issue, and the Create or Destroy Events are more expensive than instance_activate_object() and instance_deactivate_object().

Additional Considerations

Should we Prime the pool?

Trim the pool?

Delete the pool?

Benefits in network multiplayer games

Share:

Like this:

Getting into GMS2 Tiles

GMS2 Tileset Workflow

Tileset setup

Tileset usage:

Tileset Setup

Create a sprite that will hold the image data for your tileset

Create a tileset asset

Define the tileset

(Optional): Create any brushes, animations, and auto tile sets that are needed

Brushes

Animation

Auto Tile

Animated Auto Tile sets

Re-Auto Tiling (Auto Tiling at runtime)

Create additional tilesets, as needed.

Can a tile layer move/scroll?

Tile Collisions

Isometric and Hexagon tiling?

GML move functions and Tiles

Further Reading/Videos

Share:

Like this:

Import and Compatibility Report

Collision Mask problems

Image Editor WTFs (Woes To Fix)

Summing up

Share:

Like this:

ENUMerate all the things!

What else?

Using enums in GameMaker Studio

Conditionals for checking state

Iteration over a set

Creating a set of related, named values

Parting thoughts

Share:

Like this:

Skins

Room for improvement

Game Options and Configurations

Share:

Like this:

Workspaces

Chain view

Menu and Tool bar

Quick import your Asset files

Keyboard shortcuts

Share:

Like this:

Share:

Like this:

Analysis

Community Chatter

Share:

Like this:

Share:

Like this:

Observations

Share:

Like this: