Tag: Game Maker Extension

Tutorial: Building a Game Maker Extension

[Update 1/13/2014: See the official GameMaker documentation and this MSDN blog entry for how to build GM Extensions directly inside of GM:Studio. The GM Extension Builder tool that I explain how to use in this article will build GEX that can work with GM 7, 8, 8.1, and GM:Studio. As long as the GML used in the extension is compatible with the version of GameMaker that the extension is added to, the extension should work. ]

One of the nice things about Game Maker is that it is extensible. Developers can make their code more re-usable by converting their GML scripts to Game Maker Extensions. Once the .gml code is packaged in a .gex extension, you can import the extension into Game Maker and use the functions it provides in any project with ease. This means over time you can build up an entire library of re-usable functions that you can bring into your projects, saving you time and allowing you to focus on building new stuff instead of re-implementing the same basic things again and again. (more…)

HealthHalo extension for Game Maker

I whipped this up in about a half hour at the April Cleveland Game Developers meeting. It’s a very simple, but useful function which draws a Health Halo [aka “health meter”, “life bar”, etc.] above the sprite of any Game Maker object that has member variables named life and maxlife.

Health Halos are very common in multiplayer and RealTime Strategy (RTS) games.

As always, the source is freely available, along with a demo project. Download the extension package .zip file from the Releases page

Safe Zone extension for Game Maker

I have completed my Safe Zone extension for Game Maker, and made it available.

Altogether, here’s what we now have:

SafeZone.gmk – the original proof of concept, which creates a non-wrapping, square safe zone around the protected object.

SafeZone2.gmk – improved proof of concept, which creates a circular safe zone which wraps around the protected object.

SafeZone5.gmk – Further refined, now the function incorporates parameters which control whether the wrap applies in the vertical or horizontal directions, or both, or neither.

SZ5.gml – the raw .gml of the script code written for SafeZone5.gmk

SafeZone_1_0.gex – The Safe Zone extension, v.1.0, based on the SafeZone5 code.

SZ_GEX_demo.gmk – a demo project which incorporates the .gex rather than scripts.

This extension could use further refinement, as it assumes that literally anywhere else in the room is safe to place the new instance. If you have solid objects in your room, or multiple other objects that you do not want to collide with upon spawning the new object, this obviously will not hold true. But for certain types of games, such as single-player free-flight games, this should be quite useful.

“Cannibalistic” AI Targeting for Game Maker 8

I’ve made an improved version of my 2D AI Targeting demo for Game Maker. My original AI Targeting was limited by the fact that an object could not target other instances of the same object type — doing so in effect would cause the seeker object to attempt to target itself.

The original AI Targeting routine used instance_nearest(), which works great if you are targeting an object of a different type. If you need to target the same type of object, however, instance_nearest() won’t help you, since the nearest instance of the same object is always self.

Using instance_nearest_extended by Kyle_Solo, I was able to come up with a routine that allows for “cannibal” AI targeting — that is, targeting an object of the same type as the seeker.

I struggled for a long time to use the instance_xth_nearest() method to accomplish cannibal targeting, which seemed to be suitable as it has a built-in criteria test, but was unable to get the function to work as desired. I’m still not entirely sure why, but I am guessing that it may be due to the “other” keyword being undefined or referencing “noone” when an object is not involved in a collision.

I ended up successfully completing the project using instance_nth_nearest and a bit of extra code which performed the criteria testing that I required. In order to get my testing code to work, I had to introduce a global variable to count the number of instances of the targeted object, so I could construct a loop to iterate over them using instance_xth_nearest(). I’m wondering if there isn’t a faster or more graceful way to accomplish this, but it works well for now.

In the video above, the Arrows target the nearest Arrow that is small enough for them to “beat”. The rule I am using here is that a bigger arrow must be 1.3x the size of a smaller arrow in order to be able to “beat” it, but this could be modified to some other condition by changing the can_beat() function. If a candidate target cannot be “beaten” the arrow considers the next nearest arrow, and so on, until all of the instances of the targeted object type have been checked. If no arrow is small enough to be “beaten”, the arrow flies in a straight direction.

Source .gml and a demo .gmk project is available at the Releases page; a .gex extension build will be released in the near future.

AutoFullScreen 1.1

After releasing my AutoFullScreen 1.0 extension for Game Maker, I noticed a minor bug with the way small rooms were being scaled up to fill the window.

When scaling up a small room, in 1.0 the scale factor is calculated by determining whether the room was taller or wider, and used whichever was the longer dimension along with the display’s corresponding dimension to calculate the scale ratio. This was close to correct, but not quite right.

In 1.1, the scale factor is calculated both ways, using the height and the width, and then use the smaller of the two room:display ratios rather than the larger of the two room dimensions. The difference is subtle, but the upshot of this is that if you try to scale up a 4:3 room on a 16:10 display using the 1.0 method, it fills the screen completely, distorting the dimensions of the room. In 1.1 the room does not get distorted, as intended.

I have fixed the bug and added a feature to the function to make the zoom function optional. If you prefer to have the room drawn at actual size, you now have that option.

The new version is up on Releases.

AutoFullScreen extension for Game Maker

I’ve now built a Game Maker Extension (.gex) version of my handy AutoFullScreen function. It is available for download on the Releases page.

The extension includes only AutoFullScreen, the version which I called AutoFullScreen2 in the .gmk that I initially released a few weeks ago. I’ll be releasing a separate .gex of the MiniMap functions eventually.

Note: To get the AutoFullScreen.gex to install into Game Maker, you must launch Game Maker using Run As Administrator.

AutoFullScreen and MiniMap scripts for Game Maker 8

I came up with some handy scripts for Game Maker 8 projects.

  • AutoFullScreen(Border_W,Border_H,objFollow):  This script automatically sets the game window to full screen mode, and sizes View0 to the pixel dimensions of the display. If the room is not as large as the display, the room is scaled up to fit the display, and will stretch to fill the display in both the horizontal and vertical dimension, which can result in distort the room if it has a different height:width ratio than the display.
  • AutoFullScreen2(Border_W,Border_H,objFollow):  This script automatically sets the game window to full screen mode, and sizes View0 to the pixel dimensions of the display. If the room is not as large as the display, the room is scaled up to fit the display, but does not get distorted by a different height:width ratio.
  • MiniMap(minimap_width,minimap_height,top,left): Sets up View1 as a minimap view of the room. Takes parameters which set the height and width size of the minimap in pixels, and whether the minimap appears in the top/bottom or left/right corner of the window.
  • MiniMap2(scale_factor,top,left):  Like MiniMap, but with a slightly different argument for sizing the minimap. Instead of sizing the height and width using absolute pixel dimensions, you provide a scaling value. The map will be sized to a proportion of the display size divided by the scale factor (e.g., a scale factor of 8 means you’ll get a minimap that is 1/8 the size of the main window.)

The .gmk file is pretty well documented, contains example rooms with reference implementations of the scripts, and can be downloaded from releases.

AI_targeting debrief

First, who would have thought that one small component of AI behavior for my game would have taken so long to get working?

I was on a good roll, making steady progress on my project for most of December. Then the holidays hit and I couldn’t work on the project as much as I wanted. I had also just started to run into some stuff that was a little tricky (not that it was really hard, just that it was new to me) around this time, so the lack of putting time into it also made me feel nervous that I’d get stuck. There’s no way I’m ever giving up this project until I complete it, and that’s that, but I’ve run into problems in the past with projects where I get stuck, don’t know where to turn, and it sucks a lot. Oftentimes that puts the entire project at risk. But this is a project that I’ll never accept failure on — I’m working on an idea I had 30 years ago, and if it’s been in my head that long, and not gone away, it never will.

So, into January, I had less time than I hoped to get back into the project. When I did, I wanted to make the time productive, so I tended to pick things that I knew I could do, and that needed doing, but not necessarily the thing I’d gotten stuck on. That’s OK, but normally when you see something is going to be hard for you to figure out, you should wade into it and tackle the problem. I didn’t do this with myself, so much as I tried an idea a little bit, and when it didn’t do what I was expecting, I put it aside again and worked on something where I had more traction. I had a fatalistic sense of “When I am ready for this to make sense to me, it will.”

Also, during a lot of this time I was spending a lot of my project time on reading documentation, not coding. It was a struggle to make sense of what I was reading. My mind kept tripping up on something that didn’t make sense to me, and which in the end turned out to be inaccurate (unless I *still* misunderstand something, but I don’t think so). So that wasn’t too helpful.

In the reading that I did, I discovered a lot of things that merited further reading, and had to trace down a lot of avenues that potentially could have led to my solution, but didn’t. This wasn’t wasted time, though, because a lot of that stuff may end up becoming useful later, and having a clue that it’s out there is going to be helpful down the road.

Ultimately, I was able to prevail over my problem, get un-stuck, and deliver a working proof of concept. I need to do some further work to turn this proof of concept into an extension that I can import into any future Game Maker project that I work on, and from there I still need to bring it into my game project. But that’s all academic, and I have no doubt that I will get it done, and so I’m able to confidently declare victory at this point.

My initial attempts to implement the solution I was after focused on doing it directly in the current game project. I’ll call that a mistake now. For one, the existing game already has a lot of stuff in it, and the complexity of it makes it difficult to see (or think about) any new problems clearly. I had several false starts which ended up failing, trying this way.

Eventually, I got to the point where I recognized that what I needed to be able to solve the problem was simplicity. So to get that, I started a new project, and threw into it just enough bare bones to provide me with the building blocks I needed to test out the AI code that I was trying to figure out how to write.

So I did that. Twice. The first time was almost right, the second time was right, at least so far as it went, and I’d figured out enough to know that what I’d built there would work for what I need, but I need to do the rest of it back in the main project. The first attempt help me to figure out what I was doing wrong, or rather, what I needed to do.

So, that exercise was very beneficial. The second attempt only took me about 5-6 hours of hacking away at it to get it to work, which is about par for every other feature that I’ve committed in the project so far. So the fact that it took a few weeks of thinking, procrastinating, reading, and trying various things doesn’t worry me so much. I know the next time I get stuck with a problem like this, I’ll get to the solution that much sooner because I can take this general approach to it.

What was the most useful for me in solving this was the stuff I built into the project to provide me with feedback so I had something to diagnose. I strongly recommend building instrumentation and logging capabilities into whatever code you write. Otherwise, you’re only able to see what you can observe from the outside, which often ain’t much, and is apt to be very confusing when the application is behaving in some bizarre, unexpected way that you can’t figure out based on what you thought your instructions were saying to the compiler or interpreter.