csanyk.com

video games, programming, the internet, and stuff

Category: development

A tale of two GML scripts: code optimization through iterative development

Today I wanted to share two versions of a function that I wrote, in order to show how my iterative approach to software development works when I am doing code optimization to improve performance.

This example comes from my iMprOVE_WRAP asset.  It’s a function that returns the shortest distance (taking into account the wrap capabilities of the calling object) between the calling instance and a target object.

The first implementation works, in that it correctly does what it’s supposed to do, but I never released it, because I wasn’t satisfied that it was good enough code to ship.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
///iw_distance_to_object(target_obj, x1, y1, x2, y2, do_wrap_h, do_wrap_v,)
 
///@description Returns the distance_to_object from an improve_wrap object calling this function to another instance. 
///Compares all relevant points for the iw_object and returns the nearest distance, taking the wrap range into account.
///@param target_obj id of the target object to determine the distance to.
///@param x1 left x boundary of wrap range
///@param y1 top y boundary of wrap range
///@param x2 right x boundary of wrap range
///@param y2 bottom y boundary of wrap range
///@param do_wrap_h set whether the horizontal wrap is on (true) or off (false)
///@param do_wrap_v set whether the vertical wrap is on (true) or off (false)
 
 
//get the distance from the nine virtual positions
//return the shortest distance
var obj = argument[0];
var iw_distance, iw_distance_up, iw_distance_down, iw_distance_left, iw_distance_right, 
    iw_distance_up_left, iw_distance_up_right, iw_distance_down_left, iw_distance_down_right;
var tempx, tempy, shortest;
var x1, y1, x2, y2, range_width, range_height, do_wrap_h, do_wrap_v;
 
//keep track of original location of target object
tempx = x;
tempy = y;
 
//set up wrap range
x1 = min(argument[1], argument[3]);
y1 = min(argument[2], argument[4]);
x2 = max(argument[1], argument[3]);
y2 = max(argument[2], argument[4]);
range_width = x2 - x1;
range_height = y2 - y1;
 
do_wrap_h = argument[5];
do_wrap_v = argument[6];
 
//check distances
//check center
iw_distance = distance_to_object(obj);
 
if do_wrap_h && do_wrap_v //wrap vertical and horizontal
{
  //check corners
  x = tempx - range_width;
  y = tempx - range_height;
  iw_distance_up_left = distance_to_object(obj);
 
  y = tempx + range_height;
  iw_distance_down_left = distance_to_object(obj);
 
  x = tempx + range_width;
  iw_distance_down_right = distance_to_object(obj);
 
  y = tempy - range_height;
  iw_distance_up_right = distance_to_object(obj);
 
  //check left and right
  y = tempy;
  x = tempx - range_width;
  iw_distance_left = distance_to_object(obj);
  x = tempx + range_width;
  iw_distance_right = distance_to_object(obj);
 
  //check up and down
  x = tempx;
  y = tempy - range_height;
  iw_distance_up = distance_to_object(obj);
  y = tempy + range_height;
  iw_distance_down = distance_to_object(obj);
 
  shortest = min(iw_distance, iw_distance_up, iw_distance_down, iw_distance_left, iw_distance_right, 
                iw_distance_up_left, iw_distance_up_right, iw_distance_down_left, iw_distance_down_right);
}
if do_wrap_h && !do_wrap_v //do_wrap_h
{
  //check left and right
  x = tempx - range_width;
  iw_distance_left = distance_to_object(obj);
  x = tempx + range_width;
  iw_distance_right = distance_to_object(obj);
 
  shortest = min(iw_distance, iw_distance_left, iw_distance_right);
}
 
if do_wrap_v && !do_wrap_h //do_wrap_v
{
  //check up and down
  y = tempy - range_height;
  iw_distance_up = distance_to_object(obj);
  y = tempy + range_height;
  iw_distance_down = distance_to_object(obj);
 
  shortest = min(iw_distance, iw_distance_up, iw_distance_down);
}
if !do_wrap_h && !do_wrap_v
{
  shortest = iw_distance;
}
 
//return calling instance to original location
x = tempx;
y = tempy;
 
return shortest;

Let’s take a moment to appreciate this function as it’s written. It’s well-structured, documented, and expressive. First we declare a bunch of variables, then we do stuff with the variables, then we get our answer and return it. And this gives a correct result…

So what’s wrong with the above? It’s an inefficient approach, which checks each virtual position of the wrapping object. If the calling instance wraps vertically and horizontally, it has to temporarily move the calling instance 9 times and check the distance from each of 9 virtual positions, then return it back to its original position, only to return the shortest of those 9 virtual positions.

There’s also a lot of code duplication.

Still, it’s not horrible code. But it’s up to 9x slower than the distance_to_object() function it’s based on, if you’re wrapping in both directions, which will probably be common. I didn’t think that was good enough.

Rather than check each virtual location to see which is the shortest distance, we just need to know whether the horizontal and vertical distances are more than half of the width and height of the wrap region. If they are, then it’s shorter to go around the wrap. To know this, you simply take the x and y values of the two positions, subtract one from the other, and compare to the size of the wrap range. Once you know which virtual position is the closest one, you can temporarily place the calling instance there, and use distance_to_object() to get that distance. Put the calling instance back where it was, and then return the distance.

I realized as well that depending on whether the calling object wraps in both directions, you may not need to check for a wrap shortcut in the horizontal or vertical. So we can potentially avoid doing some or all of the checks depending on whether the do_wrap_h and do_wrap_v arguments are true or false. As well, this means we can avoid declaring certain variables if they’re not needed, which conserves both execution time as well as RAM.

I usually create local script variables in a var declaration, and assign the arguments to them so the code will be more readable, but I wanted to avoid doing that so that this function could be as lean and fast as possible. This might be an unnecessary optimization, but that’s hard to predict since I have no way of knowing ahead of time how this function might be used in a future project. In a project with many wrapping instances, it could very well be called many times per step, and every optimization could be critical. Since the script is intended to be included as a function in an extension, once I have it working properly it shouldn’t be opened for future maintenance, so making the script readable is not as important. So I opted to remove the local variable declarations as much as possible and just use the argument[] variables directly.

Also, to ensure that the wrap range is defined properly, in the non-optimized version of this function, I declare x1, y1, x2, y2 and assign their values using min() and max() so that (x1, y1) is always the top left corner, and (x2, y2) is always the bottom right corner of the wrap range. Technically for this function, we don’t care precisely where the wrap range is, only what the width and height of the wrap range are. That being the case, I can further optimize what I have here, and rather than use min and max, I can just take the absolute value of the difference of these two values.

It turns out that the process I went through to optimize this function is pretty interesting, if you care about optimizing. So I’ll go into greater detail at the end of this article about the approach I took to get there. But for now, let’s skip ahead and look at the finished, optimized function. Here it is, re-implemented, this time doing only the minimum amount of work needed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
///iw_distance_to_object(obj, x1, y1, x2, y2, do_wrap_h, do_wrap_v)
 
///@description iw_distance_to_object returns the shortest distance in room pixels between two objects in the wrap range, 
///taking into account the horizontal and/or vertical wrap properites of the calling object.
///@param obj the id of the target object
///@param x1 left x boundary of wrap range
///@param y1 top y boundary of wrap range
///@param x2 right x boundary of wrap range
///@param y2 bottom y boundary of wrap range
///@param do_wrap_h set whether the horizontal wrap is on (true) or off (false)
///@param do_wrap_v set whether the vertical wrap is on (true) or off (false)
 
 
if !(argument[5] || argument[6]) //not wrapping actually
{
 return distance_to_object(argument[0]);
}
else
{
 //We're going to figure out which virtual position is the nearest to measure from
 //To do that, we have to compare the h-distance and v-distance of the calling instance and the target position
 //If this distance is <half the range size, then the original position of the calling instance is closest
 //Otherwise we have to use one of the virtual positions
 //Then we're going to temporarily put the calling instance in that location, get the distance, and put it back 
 
 //arguments
 var tempx = x, tempy = y;
 
 if argument[5] //do_wrap_h
 {
   var range_width = abs(argument[3] - argument[1]);
   if abs(x - argument[0].x) > (range_width * 0.5)
   {
     x -= sign(x - argument[0].x) * range_width; 
   }
 }
 
 if argument[6] //do_wrap_v
 {
   var range_height = abs(argument[4] - argument[2]);
   if abs(y - argument[0].y) > (range_height * 0.5)
   {
     y -= sign(y - argument[0].y) * range_height;
   }
 }
 
 var d = distance_to_object(argument[0]);
 
 //return calling instance to where it was
 x = tempx;
 y = tempy;
 
 return d;
}

We don’t need to measure all nine distances to know which is the shortest; we can tell by comparing the direct distance to the size of the wrap zone — if it’s less than half as big as the wrap zone, the direct distance is the shortest. If not, then we need to wrap. We can check the x and y axes separately, and if both are called for then we can just combine them.

The second function should be much faster to execute, and uses less RAM. How much faster? Well, let’s do a test project using my Simple Performance Test and compare.

Download the iMprOVE_WRAP distance_to_object test project

It turns out that the improved code runs about 50% faster than the old code! That’s a measurable and worthwhile improvement. Although, that said, the old function ran well enough that I could have released it, and likely it would not have been a problem for many uses, particularly in Windows YYC builds.

Appendix: Optimization through Iteration

(more…)

iMprOVE_WRAP 2.2 released

iMprOVE_WRAP 2.2 has been released.

I’ve added two new GML functions to the asset: iw_point_distance() and iw_point_direction(). These functions work much like the built-in GML functions point_distance() and point_direction(), except they take into account the iMprOVE_WRAP wrap region.

Release Notes

Version Notes
2.2 New functions:

  • iw_point_distance(): returns the shortest distance between two points, taking into account the wrap zone.
  • iw_point_direction(): returns the direction of the shortest distance between two points, taking into account the wrap zone.

Get iMprOVE_WRAP

GameMaker Marketplace

itch.io

Full Documentation

iMprOVE_WRAP 2.1 released

iMprOVE_WRAP 2.1 has been released. Get it at GameMaker Marketplace or itch.io.

Full Documentation.

Release Notes:

1.0 Initial release
1.0.1 Updated iw_draw_self_wrap() to use image_blend rather than c_white for the color argument.
2.0.0 Added new functions:

  • iw_draw_sprite_wrap(): an iMprOVE_WRAP version of draw_sprite()
  • iw_draw_sprite_ext_wrap(): an iMprOVE_WRAP version of draw_sprite_ext()

Improvements:

  • Boundary drawing now occurs at wrap corners as well.
  • Phantom collison checking also occurs at wrap corners.
  • iw_collision_wrap() and iw_collision_wrap_map() functions now incorporate do_wrap_h and do_wrap_v arguments, and only perform collision checks where they are needed. They still return a value for all locations, but where no check is needed, they return noone.
2.0.1 Improvements:

  • iMprOVE_WRAP demo resources have been placed in folders to keep them tidy when importing the asset into a project.
  • oIMprOVE_WRAP_demo sprite has been updated to allow for more precise positioning. Sprite is semi-transparent, with a yellow pixel at the origin
  • oIMprOVE_WRAP_demo object now draws guide lines indicating the height and width of the wrap range. This is useful in confirming that clone drawings and wrapping is occuring where it should.
  • iMprOVE_WRAP demo dashboard text has been updated to be a bit more clear
2.1 New functions:

  • iw_distance_to_object(): returns the shortest distance to the target object from the wrapping object, taking into account all directions available.
  • iw_distance_to_point(): returns the shortest distance to the target point from the wrapping object, taking into account all directions available.

New demo room for the iw_distance_to_object() and iw_distance_to_point() functions

 

GameMaker Studio 2.0 officially released, no longer in Beta

Yesterday, YoYoGames announced that GameMaker Studio 2.0 is out of beta.

Perhaps not coincidentally, I’ve noticed a bit of an uptick in purchases of my assets on the GameMaker Marketplace in recent days.

I have not yet updated any of my Marketplace assets for GMS2, but I believe that most of them should still work, although they may require the use of compatibility scripts generated by GMS2 on import in order to run in GMS2.

If you happen to have downloaded any of my assets, and find an issue with it, I am easy to reach for technical support.

The best way to reach me would be to send a message through the asset page on the GameMaker Marketplace. My email address is also in the documentation for the asset. And you can also reach me via the Contact page on this website.

YoYoGames announces license portability for GMS2

YoYoGames have announced in an update to their GameMaker Studio 2 FAQ that the beta for GMS2 for Mac OS X will be coming out in the near future. No exact date has been given yet. But their announcement also mentions that the Mac edition will be available to users of GMS2 who have already purchased a license for the Windows edition, at no extra charge. In other words, purchasing a license will entitle you to run GMS2 on whichever platform you prefer, and you don’t need to decide that at purchase time, and you can change your mind at any time, or even switch between OS X and Windows boxes.

GMS2: License FAQ

This seems to align with the GMS2 license model, which ties your GMS2 license to your YoYo Account, not your computer.

I think this is great for longtime users who wish to get off of Windows PCs, and are willing to switch to Mac. I only wish that YoYoGames had plans to port GMS2 to Linux, as had briefly been floated back in 2014.

Getting ready for Game Jam Weekend, part 2

Take inventory

Ahead of the weekend, it’s good to take a personal inventory. Conceptually, I like to break this into three main areas: Skills, Tools, and Supplies.

Skills

Skills are your personal abilities, your strengths that you will bring to the project. Are you a good designer of rules and systems? A good programmer? Visual artist? Audio designer? If you don’t really know what your strengths are, it’s time to reflect on what your capabilities are, and think about how they might be applied to the project. Even if you think you know what you’re good at, or what you’re going to be doing, it’s good to review everything you know how to do, just in case you might have overlooked something or taken it for granted.

Really, just about any skill can be useful in game development. It’s not just design, programming, art, audio, and project management. Things like math, physics, psychology, humor, and acting are all important skills that have obvious application to different parts of game development. Be open minded and creative, and ask your friends what they think you’re good at or what your strengths are. You might be surprised by what they see, that you wouldn’t have thought of.

Tools

What are you working with? If it’s equipment, get it all together before jam weekend and make sure it’s in good working order, that any cables or accessories that you need are not lost, and so on. Musical instruments, microphones, game controllers, and any other hardware that you can think of should be on a list, and packed up ahead of the Jam weekened. Do you need batteries? Are they charged? Do you have enough of them?

If it’s software, check for updates and make sure it’s installed and launches, that the license is activated, and so on.

Are there other things you can set up ahead of time, like your version control repository, project website, mailing lists, etc? Get it together ahead of time.

Supplies

Supplies are things that you’re going to need for the weekend that are consumable. Things like food, sleeping bag/blanket and pillow, toilet paper, etc. Or things like paper, pens/pencils/markers, and post-it notes. Or game pieces like dice, pawns, cards, and so on.

Make a list, and get everything together ahead of time. If you’re running around last minute, you’re going to forget something, and at the very least you’ll be more stressed out than you would be otherwise. Preparing everything ahead of time means you can relax, clear your mind, and focus on having a productive weekend.

Set goals

Although I said in my previous article that you should approach your physioligical preparation for Jam Weekend like you’re gearing up for an intense athletic competition, a Game Jam really isn’t a competition. The experience is what matters, not just the outcome. Failing is fine! It’s only a weekend, and part of the reason it’s only a weekend is to set the stakes low enough to allow you to take risks. So take them! Do something that might not work, or that you’re not good at, or that you haven’t tried before.

My first Global Game Jam, I wanted to simply complete a project in a weekend that was playable. I didn’t care how good or bad it was, although obviously I wanted to put my best effort into the project, and did. But my main goal was to have something to show for the weekend that I could call “finished” and show to others. That was a fine goal to have.

But there are other goals that you could have. And it’s entirely up to you what those are. Just think about them, and let them guide you. Your goal could be to work with or learn about a specific tool or technique that you have never used before. Or you could make your goal be to make the best game you know how to make, and so focus on execution rather than learning or experimentation, sticking with what you know and what you do well, and simply be as productive at what you’re already good at as you possibly can.

Your goal could be to focus on team work and collaboration, or on being a good project planner/coordinator. Or your goal could be to have a good time, or to ensure that someone else has a good time with their first jam experience, by creating a positive atmosphere and giving encouragement. Maybe your goal is just to find out whether this is something you can really do.

There are many, many dimensions to a game jam, and you can set goals respective to any of them. It doesn’t matter what your goals are, it matters that you have them.

Teaming

I see basically three approaches to participating on a project: solo, on a team, or as a freelancer.

Solo developers, do everything for their project themselves. This works well if you’re well rounded enough in your skills inventory to handle everything yourself. But most people are strongest in one or two skill areas, and are weaker or nonexistent in other areas. It can be limiting to work alone, or it can be liberating. But it all falls to you.

A Freelancer is a jammer who focuses on a particular skill, and provides services to as many teams as need it. This often works well for musicians or artists. Rather than remaining a dedicated resource for a single team, they will work on several projects. This keeps them busier than they might otherwise be. Oftentimes the artists are idle in the early stages of a project, prior to the game design being at a point where it’s ready for the artists to start working on things. And often they can finish the assets for a game quickly, and then have little else to do, and so are able to provide assistance to other projects.

Teams are when a group of people work together on a project. If you’re teaming, either you’re aware ahead of time who you plan to work with, or you’re not.

If you know your team members ahead of time, that’s great, because you can plan and coordinate and prepare ahead of the jam. Just knowing what your capabilities and skill levels are helps, but it’s also good to know what your goals and tastes are. Get together and go over your skill and tool inventories and figure out what your team’s strengths, weaknesses, goals, and interests are.

Get an idea of what role each team member will play, and then each team member can focus their preparation more narrowly in support of that role. If you have more than one programmer, make sure they’re on the same version of the tools that you’re using, and that you all have access to the version control repository that you’re using. Pre-jam is a great time to do stuff like set up your web site, your version control repository, Trello boards, Slack channels, and so on. Make sure that everyone on the team has access to any common tools that they will need to function on the team, and that they have at least some familiarity with them.

If you don’t know who you’ll be working with, and just go into the weekend intending to work with whomever has an interesting project and needs help, you can still prepare by getting to know the people who’re going to be at your jam site ahead of time. Make friends, and see who you might feel like you can work well with.

You can also prepare inwardly, too, and work on your presentation skills, and social skills. Practice pitching ideas, focusing on being brief, interesting, and persuasive. It can be hard to articulate ideas and explain them to other people, but practicing doing that can help.

A good exercise is to think of a game that is familiar to you and that you like, and describe it in less than a minute to someone who has never seen the game before in a way that would give them an understanding of the game and make them want to play it. Or focus on one aspect of a game and explain why it is successful at what it does. Being able to clearly describe a thing that does not yet exist is a critical skill in the early stages of developing a game. If you can do this clearly, succinctly, and compellingly, it’s more likely that you’ll be able to get others on board and aligned with your ideas.

It’s equally important to be good at listening to the good ideas of others, and to be able to negotiate compromises. Think about what it means to be a good listener, a good mediator, and a good conflict resolver and problem solver.

Another critical skill for teaming is managing the team and the project. How do you keep everyone on track, keep tabs on what each member is working on, and ensure that what they’re working on will integrate with the other pieces the team is working on? Communications should be ongoing throughout the weekend, with frequent check-ins to report status, verify that everyone understands what is needed and who’s responsible for it. How do you like to hear feedback? How can you help someone to understand what you’re telling them when they’re not clear?

In short, think about all the interpersonal dynamics of working with others, and ask yourself what kind of person would you want to work with. Remember that when you’re working with your team, and be that person! Thinking about it ahead of time will help you hit the mark, and avoid getting caught up in being short sighted in the moment.

Getting ready for Game Jam Weekend, part 1

Global Game Jam 2017 is coming up soon. I’ve been talking with my fellow game developer friends about how to prepare. It seems like a good topic for a blog post or two.

Preparing mind and body for the game jam

In this article, we’ll cover the mental and physical preparation you should think about doing ahead of time, and during the weekend, to maximize your performance and your potential.

Approach Jam Weekend like you’re getting ready for a major athletic competition.

(Normally this means a season’s worth of training on specific skills and physical conditioning, but we only have a few days, so I’m going to skip that part of it. It is what it is.)

A game jam is more a mental activity than a physical one, but the same ideas apply. Just as you would prepare for a chess or poker tournament, or a triathlon or ultra-marathon, you should strive to enter Jam Weekend at your peak. That means healthy, well rested, energized, and in top condition.

Be well rested and well nourished. Jamming for a whole weekend is seriously taxing on the mind, and the brain needs energy and rest, just as the body does.

Sleep

DO count on getting good sleep during the weekend.

Some people will stay up all weekend, but I don’t recommend it. You’re more productive when you’ve gotten adequate rest. If you can’t sleep well at the Jam site, and it’s pretty unlikely — there’s a lot of noise and chaos and activity going on at all hours — I recommend going somewhere you can get good sleep when it’s time, and if that means off-site, then so be it.

“Crunch time” is a common anti-pattern in software and game development, and is almost always unnecessary and detrimental in the long run. In the short run, people can and do get away with it — mostly when they’re young enough that their bodies and minds are able to withstand such stresses and recover from them.

Because it’s only 48 hours, a lot of people treat Jam weekends like they’re crunch time, and will stay up 36 or even 48 hours. I did that during my first Global Game Jam (in 2011) and learned from it that I wasn’t a 20-something college undergraduate who could pull consecutive all-nighters anymore.

My brain was determined to complete a project by deadline, and due to buggy beta software corrupting my project files, I ended up having to start over twice, redoing my entire project, which really sucked, and meant I basically had no choice but to stay up all weekend or else drop out, and I elected to stick it through to the end.

I finished my project, but my mind was not working anywhere near optimally during the last 12 hours or so, and at times I could’t keep a train of thought going. I’d stare at the keyboard trying to remember what I was trying to do, and what the next step was. If I’d just taken a couple hours for a power nap, I probably would have been better off, made fewer mistakes, and gotten more done. Although my project compiled and ran, I discovered that it was buggy and unwinnable, and had to fix it after deadline. Every project is likely to be buggy, of course, but working under extreme sleep deprivation is only going to make that worse.

Still, some people do seem to thrive on short term sleep deprivation, and become more creative, more focused, or just more crazy, and if that’s you, and you know what you’re capable of, do what works for you.

Nutrition

Eat good food beforehand, and bring or order good food for the weekend.

At my local Global Game Jam site, there will be food provided, and probably they’ll take orders for delivery from somewhere, but a lot of it is junk food or comfort food, and not necessarily what’s best for being well nourished. So consider doing better by yourself.

Preparing a healthy balanced meal is a lot better than eating convenient junk food and caffeine. I wouldn’t dream of specifying a recommended diet, but if you don’t know what’s healthy, look at physical trainers and what they recommend for athletes. A lot of starchy food like pasta or potatoes can be good for storing energy. Fresh vegetables and good lean protein is also an excellent choice.

You don’t want to spend a lot of time on prep and cleanup during the jam, so if you don’t have non-jammers supporting you with food service, then either order out for yourself, or prepare meals to bring that you can reheat easily.

No outside distractions

It goes without saying, perhaps, but try to have your outside life well in order so that it doesn’t intrude on your weekend. Anything can happen of course and if you have to bow out due to some family emergency or something, well, you do what you have to do. Always have your priorities in order, and follow them. If something comes up, hey, that’s life. But plan ahead, and do what’s necessary to keep your plate clear so you can focus on the one thing, and keep yourself free of distractions and other responsibilities as much as possible.

GameMaker Studio 2 impressions: Object editor

The most notable change in the Object Editor is that sub-windows are “chained” to the main form, in what YoYoGames is calling “Chain view”.

GMS2 Object Editor

The idea is that different parts of the Object editor should all be visible, not overlap each other, connected visually.

The main Object window shows the object’s basic properties: the Name, Sprite, Collision mask, and Visible/Solid/Persistent/Physics properties, as you can see. Chained to it are the object’s Events, and the Code Editor (or DnD Editor) will be chained off of the Events sub-panel. If your object happens to be a Physics object, or has Parents or is a Parent, then the Parent and Physics sub-panels will also chain themselves to the main Object editor form.

GMS2 Object Editor chain

This takes some getting used to, and occupies quite a lot of space on screen, which for users with smaller displays can make it a problem to work with Objects inside of a Workspace.

Fortunately, Object Editor windows, like any other window, can be broken out of the main GMS2 window and maximized, to fill up the entire screen if desired. Users will either love or hate Workspaces and Chain View windows, and if you’re one of the ones who hates them, you’ll need to get used to breaking the editor out into its own window and maximizing it, as this seems to be your only recourse for now. There’s a few Preferences in the Text Editors section that will make this easier for you, should you want to configure them:

GMS2 Text Editor Preferences

The GameMaker Community Forums have been very active in discussing the UX issues created by the new UI, though, so don’t be surprised if YYG do make a few changes in future updates.

DnD or GML?

The Object Editor comes in two flavors: Drag-n-Drop (DnD) and Code Editor (GML). Which variant you get is currently determined when you create a new Project, but you can switch at any time. Most users will probably prefer to create GML projects and work in the code editor, but beginners, younger users, and non-programmers may prefer the DnD option.

Probably the most important feature of either variant is its interface for defining actions in your Object’s events.

I’ll be focusing mainly on the GML version, since that’s what advanced users will use. But briefly, Drag-n-Drop has been completely overhauled in GMS2.

The new Drag-n-Drop system

Vastly expanded in GMS2, there are now DnD equivalents to just about every function in GML. Unfortunately, this means that there are vastly more icons needed to represent all of these new DnD actions, making them harder to learn. Similar to Chinese or Japanese, where every written word has its own symbol, there’s a DnD icon for every GML function. While it’s reasonably easy to pick up a DnD library with a small number of actions, this quickly becomes unwieldy as the number of actions grows. Unfortunately I expect this will have the undesired effect of making DnD too complex to use for beginners and non-programmers, making it questionable how valuable the DnD system will be in the future. Learning to code by typing out instructions isn’t that hard, and is arguably the better way to learn in the first place. But it’s nevertheless true that for certain people, they feel intimidated by programming or typing, and an intermediary step of using DnD like “training wheels” until the new user has an understanding of GameMaker’s fundamentals and is ready to move on to GML, has been one of GameMaker’s defining features.

In GMS1.x and earlier, DnD Actions were iconographic representations of special GML functions that started with action_ for example, action_set_hspeed(number). These functions were mostly redundant, being equivalent to other GML functions and expressions, for example hspeed = number;

The action_ GML functions are obsolete in GMS2, and are no longer needed. DnD Actions can convert directly into GML with a single menu command. This is a one-way conversion, and should help users who want to “graduate” from DnD programming to GML programming. Formerly, in previous versions of GameMaker, there was no way to convert DnD to GML code, other than to manually re-write everything. If you try to convert GML into DnD, rather than a sequence of DnD actions, you’ll get your GML code wrapped up in an Execute Code DnD Action, and the Object Editor will switch to DnD mode, allowing you to continue programming with DnD actions. While not particularly useful for advanced GMS users who are already familiar with programming in GML, it’s a nice improvement to the way the DnD system works.

GML Code Editor

The new GML code editor is still somewhat rough, but shows promise of numerous improvements. Indenting is standardized, to 4 spaces per tab by default, although this is configurable, and there are subtle guidelines showing where tabs will align to in the background. Row lines are numbered, again configurable if you don’t want to see them.

GMS2 Code Editor

The most obvious difference is the new color coding for syntax. This may take a bit of getting used to, but at first I found that my code looked very rainbow-y, and I found this to be somewhat of a distraction at first, but after a few days I found that I had adjusted. Every color is customizable, if you want to bother with that.

Auto-completion and hinting is improved in the new editor. All project variables, macros, etc. are included, not just the built-in GML keywords.

GMS2 Code Editor AutoSuggest

The completion hints at the bottom of the Code Editor window are very helpful to remember all the arguments that must be provided to a function, in the right order. And for any scripts which you author, if you use JSDoc commenting, you can provide hints for your own functions as well.

GMS2 Code Editor Completion Hint

Rough Edges

Cursor navigation keys are either different from standard Windows text editors, or else not yet fully implemented. I’m accustomed to, and very reliant upon, using Home|End|Page Up|Page Down|Shift|Control|Arrows to move the cursor about the window, to select text, and for copy/pasting. In the GMS2 code editor, these keyboard shortcuts do not all work as expected, which can be pretty annoying.

In most text editors, Home and End keys will make the cursor jump to the 0th or last position in a row, or if Ctrl+Home|End is pressed, the 0th or last position in the file. Presently, Home and End do not appear to be supported at all in GMS2.

The Arrow keys move the cursor around the document one character at a time, and if Shift is held down, the characters that the cursor passes over are then selected. Holding Ctrl down will speed the cursor up, moving it a word or a paragraph at a time.

For some reason when selecting text using Ctrl+Shift+Arrow, with the horizontal arrows, the selection gets “stuck” at the beginning/end of a row, and will not advance beyond that unless Ctrl is briefly released. This is a relatively minor annoyance, but should nonetheless be corrected. Normally, Ctrl+Shift and the Left or Right Arrow key will select to the next word, and will wrap lines if it reaches the end of a line.

Up or Down Arrow will move the cursor up or down a row, and with Ctrl+Shift held down, should move up/down to the next blank line. This is standard behavior in pretty much every text editor I’ve used in Windows, or Mac OS for that matter, but it is not the behavior in GMS2 at the time of this writing. I am hopeful that this will be addressed before the end of the Beta.

But by far the biggest thing that users are complaining about in the Community Forums has been the way the IDE wastes space in its default configuration, due to the way Workspaces and the Chain View UI work. Fortunately, breaking out the Code Editor into its own, maximized window is an easy workaround to this problem, and largely addresses it to my satisfaction.

Apart from these issues, I like the new UI for the Object Editor, and the Code Editor very much.

GameMaker Tutorial: Instance Pooling for performance optimization

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.

csanyk.com © 2016
%d bloggers like this: