Category: development

GameMaker adjusts business model

Today GameMaker announced changes to their pricing and business model. Moving forward, they will provide three tiers of product.

The Free tier is intended for non-commercial use, and should appeal to educators and hobbyist game developers. And great news, the free version is not limited or restricted in terms of features in any way, other than that if you want to build a game for commercial release, you need to buy a Professional or Enterprise license.

The Professional tier is a 1-time $99 charge, and does away with the subscription model for small indie developers who want to make commercial games but have balked at paying a subscription for the tools to create them.

The Enterprise tier is still subscription-based, at $800/year, and enables game console builds for PlayStation, XBox, and Nintendo Switch.

It’s great to see GameMaker giving affordable options to smaller developers. Most of GameMaker’s traditional userbase has been non-professional programmers who wanted an simplified tool that is inexpensive.

How I lost 3.5 hrs of sleep last night by being dumb

I use GitHub, like a lot of developers, to handle my project files.

I like GitHub a lot.  It’s great. I don’t understand it as well as I’d like, but what I do know and use, works very well, and is very useful.

I don’t really know git, the command-line program that GitHub is based around, which does all the version control magic you need. Because I’m a dummy, I only use GitHub Desktop for Windows.  But that’s fine; it does exactly what I need it to do, I haven’t hit any limits with it as yet, and I’m able to understand/figure out its interface to do what I need.  That’s the whole point of a tool. Who has time to read all the docs and learn the muscle memory to type all the commands manually, am I right?

But I say this because I need to make it clear, I’m not entirely clear where git ends and GitHub begins. I’d been hearing about git and how good it is for, I don’t know, years and years, before I finally started using it. About a year ago, I grew tired of all the obstacles that were preventing me from just sitting down and forcing myself to learn to use git from the command line, and decided to just jump in and use GitHub rather than figure out how to set up git on my own server and then do stuff with it via shell commands. I was still worried about doing something that made me look dumb in public, so I didn’t use my GitHub account much at first, until I grew tired of that fear blocking me, and decided to just spend the $7/mo on an account so I could set up private repositories and enjoy the ability to screw things up as much as I dared, without it being on full public view.

This was when I started to make serious progress with getting into GitHub. And I found that with GitHub Desktop, the Windows app that wraps a bunch of command line magic that I wish I knew, but don’t, was amazing. It took a little bit of trial and error to learn the ins and outs, and a very small number of minutes watching tutorial videos.  But that was what was so great about it.  If I had a question, I could search GitHub’s help, and most often I’d find a video that was, at most, about 2 minutes long, that answered my exact question. Most IT tutorial videos feel like they need to spend 20-30 minutes going through some process, and it’s too much to follow, but these bite sized videos were just what I needed.

Anyway, now that my background is explained, I’ll talk about something that happened last night.

I have a project that I’m managing in GitHub, my Ludum Dare 41 project, InvadTris. I had just spent the evening going over the project and made a few minor edits, which I checked in.  As I did my commit, GitHub Desktop notified me that it had an upgrade available.  Without thinking, I clicked the button to install the update.  It installed in a few seconds, and then I noticed that while I’d submitted the commit, I hadn’t yet synced it with GitHub.  So I went to do that, when GitHub prompted me to log in.  I entered my credentials, and authentication failed.  GitHub Desktop showed me as being logged in (I guess locally?) but authentication to github.com through GitHub Desktop was failing.

I tried logging out, then logging back in, as the interface recommended, but this did not fix the problem. I logged out of GitHub in my browser, and logged back in, just to verify that I did indeed have valid credentials, and this was successful.  I wasn’t sure what else it could be, so I tried removing my SSH key in my GitHub account settings, but this didn’t help, either.

I figured I’d open up a ticket with GitHub Support, and they’d give me a solution, so I started writing up a ticket.  I went to check the version number of GitHub Desktop, and in the About screen it told me that I was on the last version of this particular tool, which was no longer actively being developed.  I learned also from this that there was a new GitHub Desktop, and downloaded and installed that.

The New GitHub Desktop had no problem authenticating me.  Problem solved, right? Well, almost.  For some reason, the new GitHub Desktop didn’t pick up any of the local repositories that my old GitHub Desktop knew about.  So, to complete syncing, I’d need to manually add my repository, then I could sync.  Later, I could introduce all my other local repositories into the new Desktop, and then I could just use the new version from now on.

Well, for some reason, the New GitHub and the Old GitHub didn’t seem to agree with each other on the status of my local repositories.  This is where intricate understanding of how git and GitHub works would have come in very handy, but I didn’t have that.  All I had was Old GitHub telling me that I had a recent commit locally that was pending sync, and New GitHub telling me that it saw no changes, so had nothing to commit, nor anything to sync.

WTF? I still don’t know. I quickly went through some of my other local repositories, and found that they also disagreed with their check-in/sync status according to Old GitHub as well.

Fortunately, I eventually discovered that I could simply roll back the update to the old GitHub Desktop, and once I had done so, it was once again able to authenticate me to GitHub’s server, and I was then able to sync up my local files with the server.

I understand that the whole point of git is to have de-centralized version control, but I still think of the repository on GitHub’s server as The Repository.  The files there are backed up, are offsite relative to me, and I feel comfortable knowing that they exist somewhere else in case of disaster.

Now that I have everything synced with the server, I can switch over to using the New GitHub Desktop, and life will be good.  If my other repositories still have disagreements between the Old and New GitHub Desktop, I can resolve them, and it won’t be a problem.

In all, this took me about 3 and a half hours to resolve, from the time that I applied the bad update to Old GitHub, to restoring Old GitHub to the version that works and completing my sync.  Unfortunately, I was up half the night doing this.  I was in a panic, and whenever I have problems with a computer that means I am at risk of losing data, I just can’t sleep until the problem is solved.

So, my takeaway from this experience is that the primary cause of the problem was a failure of the tool, but it was compounded by my stupidly not completing my check-in/sync work before applying an update.  In recent years, software quality has gotten so good across the board that I’ve grown accustomed to upgrades going without a hitch.  I can install Chrome upgrades, relaunch, and it’ll remember all my preferences, all my tabs and sessions, and it’s not even a concern at all anymore. 10, 15 years ago, when I’d upgrade my web browser, it was this big ordeal of bookmarking any open tabs that I wanted to return to, checking all my extensions for compatibility with the new version, installing the upgrade, re-checking all my configuration customization, etc.  Such a pain.  It’s good to remember how much better things have gotten over the years.  This time, though, it bit me.  If I’d simply completed the work I was doing before applying the upgrade, I could have went to be a lot earlier, and worried about the authentication bug later.  So, that’s a good lesson to remember.

Also, as this article shows, I don’t mind being dumb in public after the fact, if once I’ve learned from the mistake, I can share what I’ve learned.  I still don’t know git, or GitHub as well as I’d like, and I’m sure I’ll never have perfect, full understanding of either, but they’re very good tools, and I’m glad I can use them well enough.

z3d Engine for GameMaker Studio

z3d is a fake-3d engine designed for simplicity, efficiency, performance, and ease of use. Full documentation + demo included.

In a 2D GameMaker room, x and y coordinates are used for positions in the 2D space. 3D requires a third variable for the third dimension, z. In the z3d engine, x and y are used to represent the “floor” plane as viewed from a top-down perspective, from a forced perspective that gives the viewer a full view of one side and top of objects, while z is used for altitude.

GameMaker Marketplace

Full Documentation

NESmaker kickstarter promises every 80’s kid’s dream

NESmaker is a no-coding IDE for creating games for the Nintendo Entertainment System, currently being kickstarted by The New 8-Bit Heroes‘ Joe Granato. When they say you can make a NES game with this toolkit, they mean real NES games, that you can play on actual hardware. This is pretty amazing.

The story behind it is that some NES homebrewers are turning the tools they’ve developed for their own use into a product for anybody to use.

Normally, if you want to program for the NES, you need to learn 6502 Assembler, and get really “close to the metal” — which is not for everyone. With NESmaker, supposedly you won’t need to code at all, although you’ll be limited to creating “adventure games” (think top-down zelda-likes). They are hoping to raise enough money to enable them to create additional modules to enable users to make games in various genres.

Although the developers have been using the tool internally on their own projects for a few years, it needs more polish before it’s ready for general use, so they are running a kickstarter right now to take pre-orders and to raise the necessary funds to complete their project. This includes not only the NESmaker software, but the hardware needed to flash a game pak so you can put your finished game on a cartridge and play it on real hardware.

How cool is that?

GMS2 alternative skins

So it’s little over a year since YoYoGames released the public beta for GameMaker Studio 2.

For a lot of the past year, I’ve been sticking with GMS1.4 in order to work on a project that isn’t yet ready to migrate to GMS2, but I’m also trying to use GMS2 when I can, to keep up to date with it and to get used to the changes. Overall, GMS2 is definitely better, and from a language standpoint GML is only slightly different, and what differences they’ve made to the language are all improvements.

On the IDE side, though, I constantly find myself wishing that YYG had made a less radical redesign of the user interface. I’ve had a number of issues with the new UI, from the way the new workspaces and chain-view windows work to the fact that saving works differently. But that’s not what I’m here to talk about today. (I’ll probably touch on those in future articles at some point.)

GMS2 Dark theme

The default Dark theme for GMS2.

One of the things that I haven’t been able to get used to with GMS2’s new IDE is the new Dark theme. For years, GameMaker has opted for a default IDE theme that uses light text on a dark background, and with GMS2, YoYoGames took this concept to its logical extreme, opting for a black background and white-on-black icons and white label text everywhere.

GMS1 GMgreen theme

The default theme for GMS1, GMgreen, was likewise dark.

I didn’t mind the dark grey background of the window panes of GMS1.x, and the resource tree’s pane used black text on a white background, and the code editor’s dark grey background with colorful, syntax-highlighted text, and the toolbas with their colored icons. While it’s not the standard Windows theme colors, it’s usable and reasonably attractive, and if you’re the sort of person who prefers to look at light text on a dark background, it’s quite good.

And to be fair, GMS1’s IDE definitely had its failings. Certain windows were “modal“, meaning that you could not switch focus to any other part of the UI when that window is open, when there was no good reason for them to be. And the user interface for the marketplace My Library had terrible performance-killing bugs with large manifests, which makes it all but useless.

But with GMS2, I feel the Dark theme has gone overboard with being too dark, particularly with the toolbar button icons. Being white-on-black only just makes them harder to read and harder to distinguish from one another, and this slows me down when I try to use GMS2, and this is frustrating, since the whole point of the tool is to make me more productive.

There has also always been a light theme that YoYoGames provides “out of the box” with GameMaker, in case you’re the sort of person who prefers to look at dark text on a white background.

GMS2 light theme

The light theme for GMS2, appeals to users who prefer reading dark text on a light background, but I still prefer something with a bit more color and contrast, and sharper outlines so I can easily differentiate between different parts of the IDE UI.

There are certain colors in the syntax highlighting that contrast poorly against a white background. These should be fixed, but YoYo’s attitude about it seems to be “you can fix it, so fix it yourself.” So they provide preferences that allow you to set the colors yourself if you want to. So, great, you can have exactly the color scheme you want in the code editor, isn’t that wonderful?

The problem with this is, if you want to take screen captures of your IDE and share them with others, your non-standard code highlighting will be apparent to your audience, and may hinder in their ability to parse the text. It’s hardly surprising that we become dependent on the syntax highlighting we see all the time, to the point that once we get used to it, someone else’s color scheme will look “wrong” to us and become more of a hindrance than an assist.

If you want a full makeover for your IDE, you have to go beyond the syntax highlighting colors, and create your own IDE theme. Doing so will give you full control over the appearance of the entire IDE. The downside is that YYG doesn’t support anything but their own themes, so if their themeing templates ever change, breaking your custom theme, you’ll have to fix it. Also, it’s possible that installing updates can either a) overwrite the theme directory, so keep a backup of your theme files. Fun! So instead of spending all your time doing game development, you can take a slice of your time hacking the IDE to do things that arguably the vendor should have gotten right, or at least implemented better so that you wouldn’t have such a temptation. Hopefully this doesn’t happen regularly.

While I like tools that can be customized, I prefer to focus on developing games, not customizing the tools that make games. Too much customizing turns me from a game developer into a game development tool developer. While the skillsets overlap, I really want to maximize the time I put into being a game developer.

Naturally, this has head to some third parties releasing their themes, sharing them with the user community, thus saving you from having to do all the work yourself.

GMS2 VS blue custom theme

Based on the default Windows theme colors and Microsoft VisualStudio, this custom theme called VS blue, is excellent. Very readable, and easy on the eyes.

I really like this Visual Studio-inspired theme. The missing option that YYG did not provide in addition to their Light and Dark themes was a “native Windows” theme, and this is pretty much that. In fact, I would love it if YoYo would embrace this theme, give the developer who created it, iluvfuz, a reward, and make it an officially supported theme. This would erase 100% of the snarkiness in this article.

It’s very similar to the GM8 theme for GMS1.x, in that it uses mostly system colors for the window chrome. The GM8 theme was my favorite on GMS1.x, so of course the VS blue custom theme is my favorite for GMS2.

GMS1 GM8 theme

The GM8 theme for GMS1.x was my preferred way to theme my IDE, because it mostly followed the Windows standard theme colors.

 

GameMaker Studio Tutorial: Getting Into Shaders

Shaders have been a part of GameMaker Studio for a while now, having been introduced in 2014. Since their inclusion, I have mostly remained mystified by them, with a vague and cloudy understand of what they are and what they can do, and haven’t used them at all. That will [hopefully] start to change today.

As always, when try I learn something new in programming, I find that writing up what I’ve learned helps me to remember and keep my learning organized. I like to publish my notes so that they can help others, and so that others can find errors and make suggestions for better ways to do things. I’m still very new to working with shaders, so I’m not trying to put myself out there like I’m some kind of expert, but here’s what I’ve been able to learn about using shaders with GameMaker Studio so far:

Shader basics

First, we need to understand what a shader is. A shader is a specialized program that processes graphics. Shaders are executed on the Graphics Processing Unit, or GPU, which is specialized hardware for accelerated graphics processing. Thus, shaders are very fast. As well, since they work on the GPU, using shaders will free up the CPU to do other tasks, which can further help to improve the frame rate of your games.

This sounds like enough of a reason to want to use shaders, doesn’t it? Well, it gets better. The main thing about shaders is that they can do amazing visual effects, which will can make your game look better, but can also play an active role in how the game plays. For example, you could use a shader to handle the graphical processing of a special view mode in the game, such as night vision or x-ray vision. One of my favorite shader-based gameplay mechanics that was centered on the use of shaders was Daniel Linssen’s Birdsong, winner of the “Overall” and “Theme” categories of the Ludum Dare 31 compo held in 2014. The theme of LD31 was “Entire Game in One Screen”, and Linssen’s approach to this was to create a giant one-room game, that was crammed into a single screen(no scrolling), and, using a fish-eye lens effect done with a shader, magnify the area where the player is so that it was large enough and detailed enough to be playable.

There’s virtually no limit to what graphical effects you can come up with using shaders, other than the limits of your imagination and of course your programming and math skills. It also helps to understand how computers work with graphical concepts such as color, pixels, binary math, and so forth. Additionally, scientific knowledge in disciplines like optics can be very useful. Shaders have their own specialized programming language that they are coded in — actually there are several related languages to choose from. Because of this, shaders are considered an advanced topic in programming, and there are numerous hurdles to surmount in order to be able to write them yourself.

That said, shaders are re-usable bits of code, and so one of the first things you can do when you start getting into shaders is to simply use pre-existing shaders that have been written by other people.

Getting Started with Shaders

Before you can use shaders, you’ll want to familiarize yourself with a few concepts.

Shader references

Here’s links to the relevant pages in the GMS manual on using shaders in the context of GameMaker Studio:

GMS1:

Shaders Overview

Shaders GML reference

Shader Constants

Tech Blog Shaders tutorial: 1 2 3 4

GMC Forums shader tutorial.

GMS2:

Shaders Overview

Shader Constants

 

Other shader resources (general)

Language References

The four shader languages that GMS supports are: GLSL ES, HLSL9, HLSL11, and GLSL. Which one you need to learn and use will depend on your target platform, but for this article we’ll focus on GLSL ES, since it supports the most target platforms (all of them, except Windows 8).

GLSL ES language specification

HLSL language specification

I haven’t gotten into the shader languages enough yet to know why you’d ever pick HLSL over GLSL, but presumably there must be some advantage to using HLSL when targeting Windows platforms, either in terms of correctness or performance. Otherwise, I would think you’d be better off just sticking with GLSL ES and be compatible with the most targets.

Tools

Shadertoy Shadertoy is a wonderful website that allows you to play with shader programming, running them in your web browser. Then you can share your shader creations with the community of users of the website, and in turn you can demonstrate and use shaders written by others.

Other graphical concepts in GameMaker, and how they relate to shaders

It’s not a bad idea to review and understand the entire chapter on Drawing in the GameMaker documentation. There are many concepts that you will need a working knowledge of in order to understand how to use drawing to its fullest capacity, and to get things working together smoothly.

But the manual isn’t the end of the story. Often I find that the manual doesn’t go far enough to explain how different concepts work. The sections on blend modes and alpha testing are particularly inadequate by themselves. The manual also doesn’t go very far to demonstrate or suggest how different features and functions can be connected to one another. That’s for the user to infer, and verify through experimentation. This is great if you are creative and love to experiment and discover. On the other hand, there’s so much that has already been figured out and discovered by others, and it would be nice if that was all documented in an easy to search reference somewhere.

Read the entire manual, cover to cover, if you can. Create little demo projects to test your understanding of what you’ve read, and figure out how to do things. Read it again. And refer to it whenever you need to. There’s no substitute for reading and understanding the manual. I’ll still touch briefly on the major concepts here, for summary:

Surfaces

All drawing happens somewhere, and in GameMaker that somewhere is called a surface. Behind the scenes, a surface is simply a chunk of memory that is used to store graphics data. You can think of it as a 2D grid of pixels, stored in the program’s memory, and drawn to the screen only when called for. You can also think of it as virtual “scratch paper” where you do some work “backstage” and then bring it out to use in the game when needed.

The application has an Application Surface, and by default everything is drawn here. But you can create other surfaces, which you can work on, composing a drawing off-screen, until you are ready to draw it to the screen. As you might imagine, there are countless reasons why this is useful, and endless ways to make use of surfaces.

Surfaces are relatively easy to use, but are considered an intermediate level programmer’s tool in GameMaker, for a couple of reasons:

  1. Surfaces consume memory, and need to be disposed of when no longer needed.
  2. Surfaces are volatile, and can be destroyed without warning, so should not be assumed to exist. For example, if the player switches focus to a different application, or if the computer enters sleep or hibernation mode, or if the game is saved and resumed, surfaces that were in existence at the time the application was last running may have been cleaned up by the operating system, and will need to be re-created if they don’t exist.
  3. All drawing must happen in one of the Draw events. If you try to use draw functions in other events, it may or may not work correctly, and this will vary from computer to computer. I once made a game where I did some set-up in the Create Event of an object, where I created a surface, drew to it, and then created a sprite from the surface, and assigned the newly created sprite to the object. It worked fine on my computer, but when other players downloaded my game to try it out, it did unexpected things and the graphics were glitched. Fortunately, I figured out what the problem was, and fixed it by moving this sprite creation into the Draw Event. Once I did this, the game ran correctly on everyone’s computer.

Drawings done to surfaces can be run through a shader, as input, and thereby be processed by the shader. In short, a surface can be the input image data for a shader, and the output of the shader will be the processed version of that surface, transformed by the shader.

Blend Modes

For a long time, long before GMS introduced shaders, GameMaker has provided blend modes. Blend modes affect what happens when GameMaker draws graphics over existing graphics that were drawn previously. Normally, when you draw something, it covers the pixels that were there before. But, by changing blend modes, you can do other things than simply replacing the previous pixels with new pixels, blending the old and the new in different ways according to the mathematical rules of whatever blend mode you had selected.

To be honest, I’m not sure what useful purpose there is for every blend mode. It would be great if there were more tutorials showing useful applications for them, especially the obscure ones that I don’t see used much, if ever.

The most commonly useful blend modes, in my experience, are bm_normal and bm_add. Normal blending is the default drawing mode, and is what you use 99% of the time in most games. Additive blending creates vivid glowing effects, and is particularly lovely when used in conjunction with particle systems to create glowing systems of overlapping particles, especially when you are drawing translucent pixels (using alpha < 1).

Blend modes are also useful for creating clipping masks. For more info on that, there are some good tutorials already written on how to create a clipping mask using surfaces and blend modes.

Some of the first questions I had when Shaders were introduced were: What do we do with blend modes now that we have shaders? Do we still need them? Can we combine them with shaders, somehow? Or do shaders make blend modes obsolete?

Basically, as I understand it, the answer seems to be that blend modes were kind of a limited predecessor to shaders, and enabled GM users to achieve some basic drawing effects simply, without exposing GM users to all that highly technical stuff that shaders involve, that I mentioned above.

Anything you could do with blend modes, can be done with shaders instead, if you wanted to. That said, if all you need is the blend mode, they’re still there, still supported like always, and you can go ahead and use them. They’re still simpler to use, so why not.

One thing to be aware of, though, when using blend modes, every time you change blend mode in GameMaker, you create a new “batch” of drawing. The more batches, the longer GM will take to draw the game each step. Thus, many batches can slow drawing down tremendously. This is an area where you may need to focus on optimization. And if you’re that focused on performance, then it might be worth looking into a shader-based approach instead.

Once you’ve become sufficiently comfortable with shaders, you may not have as much need for using GameMaker’s drawing blend modes.

D3D functions

I have not used GML’s d3d functions, much, either, so my understanding is very limited. Basically, as I understand it, the d3d functions in GameMaker wrap Microsoft’s Direct3D drawing functions, and enable drawing with more sophistication than is possible with the basic GML draw functions such as draw_rectangle, draw_line, draw_ellipse, etc.

Despite the name, the Direct3D functions are useful for 2D drawing as well as for 3D.

This article will not cover using GML’s d3d functions, as we’re focusing on shaders. But as any graphics in your game can be used as input into a shader program, anything you draw using d3d functions can become input for a shader to process.

Particles

Particles are “cheap” (efficient) graphical effects that can be created without having to instantiate an object. They are efficient because they do not incur all the processing overhead that comes with a full-blown object. Huge numbers of particles can be generated at very little cost. These can be used for all sorts of effects, so long as the particles do not need to interact with instances in the game, such as triggering collisions. Typically, particles are used for things like dust clouds, smoke, fire, glowing “energy plasma”, haze, rain, snow, and so on to create additional atmosphere.

To use particles, you have to create a particle system. As with Surfaces, particle systems take memory, and need to be disposed of when no longer needed, in order to free up that memory. Full detail on how to set up and use particle systems is beyond the scope of this article.

Several external utilities have been developed by GameMaker users over the years to make designing, building, previewing, and testing particle systems easier, and these are highly recommended.

In conjunction with shaders, I don’t know that there is any direct interplay between particle graphic effects and shaders, but certainly a shader may be used to further process a region of the room where particles exist, to create more sophisticated effects.

Using Shaders in GameMaker Studio

Right, now that we’ve introduced the concept of what a shader is, and reviewed the other main graphics concepts in GMS, here’s where we get to the heart of how to use shaders in GameMaker.

A shader is a pair of shader-language programs, consisting of: a vertex shader, and a fragment shader. Vertex shaders deal with the edges of the drawn area, while fragment shaders deal with the insides.

Let’s say you want to use a shader program that has already been written, perhaps by someone else. All you need to do is use this code in your draw event:

shader_set(my_shader);
 //draw stuff
shader_reset();

So, it’s a lot like drawing to a Surface. With surfaces, first you set which surface you want to draw to, then you draw, then you reset so that drawing resumes to the application surface. With shaders, you set the shader you want to use, draw the stuff that you want to be transformed by the shader, then reset to normal drawing.

Everything drawn between setting the shader and re-setting back to non-shader drawing will be drawn through the shader program.

Easy enough, right? Well, there’s slightly more to it than that.

Uniforms

“Uniforms” is a strange term at first, and was where shaders started to seem strange to me. This is a term that comes from the shader language itself. The GameMaker manual talks about them in a way that assumes the reader is already familiar with the concept, and doesn’t go into a lot of detail explaining it to newbies.

In essence, “uniforms” are input variables that can optionally be passed into a shader that is designed to use input values. Once you understand what a uniform is, it’s not that difficult a concept. You can read more about them at these pages:

The gist of it is, when writing a shader program, when you declare a variable, you can declare it to be a uniform variable, which means that the variable can be accessed from outside the shader, thereby giving the program that calls the shader a way to change the shader’s behavior during execution. To do this, you can’t just refer to the uniform variable by name; you have to get the uniform variable’s memory handle, using shader_get_uniform(nameOfUniformVariable), and then change the value of the variable using shader_set_uniform_f(nameOfUniformVariable, value). Uniforms are actually constants within the shader’s execution scope, so once a value is passed into the shader from the outside and it is set as a uniform, it cannot be changed (the value could be copied to another variable, and that variable could then be modified, though.)

If you’re using a shader that has uniforms that you need to set, it’s done like this:

u_color1 = shader_get_uniform(my_shader, "f_Colour1");
u_color2 = shader_get_uniform(my_shader, "f_Colour2");

shader_set(my_shader);
shader_set_uniform_f(u_color1, 1, 1, 1);
shader_set_uniform_f(u_color2, 1, 0, 0);
//draw stuff
shader_reset();

There are actually a few uniform functions in GML:

Conclusion

That’s about all I know about shaders, for now.

As I get more familiar with using shaders, I’ll update this with more complicated examples, such as (possibly):

  • How to use multiple shaders on the same drawing (eg chaining the results of one shader’s transformation of some drawing into the input for a series of shaders).
  • Other stuff…

How to write shaders in GLSL, if I ever do it, will be a topic for its own article (or series of articles).

Mega Maker

Mega Maker is to Mega Man what Mario Maker is to Mario. Except, it’s not an officially licensed Capcom product, and it’s free. Built by fans using GameMaker, it’s probably the best thing I’ve ever seen built out of GameMaker.

It’s awesome.

It’s very easy to use, and a lot of fun. Not that you really need it, but there’s a tutorial that explains everything in the editor with great style. Actually, the tutorial is very well done and I recommend using it to understand some of the finer points. But most of the point and click interface is intuitive to anyone who’s used a mouse-driven interface and knows a thing or two about Mega Man.

Mega Maker

I had my first level built and running in about ten minutes.

Unfortunately it only includes a small sample of the Mega Man resources from the first six games on the NES, but even so there’s a lot that you can do with the designer. There doesn’t seem to be any provision for designing your own enemies, bosses, or adding your own sprites or music. On the other hand, there’s zero coding needed, and it’s easy enough to use that an average grade schooler could get up and running designing levels in no time.

There’s an online community for uploading your level designs and downloading and playing the designs of other players.

So much work has gone into this, and it holds so much promise. I hope that Capcom sees fit to muzzle their legal team. If you’ve ever enjoyed a classic MM game, you really need to download this and give it a try.

Super Greedy Ghost Grab – A Cleveland Game Developers Summer Jam

This weekend, I took part in Cleveland Game Developers Summer Game Jam 2017. This year, I worked with a team consisting of Wally Pease, Bobby Lauer, and Colin Wolfe.

Our project, Super Greedy Ghost Grab, turned out really well. I really enjoyed working with our team, and I think everyone executed on our project extremely well. The deadline build isn’t perfect (and no game jam project ever is, so that’s not a knock on what we did). I’m very happy with what we were able to do in 48 hours.

Super Greedy Ghost Grab

The theme for the jam was announced: Identity. I didn’t have any good ideas at first, but eventually our team decided to make a game about a ghost who can “possess” things, becoming them, and assuming their identity.

At first we were going to have the ghost possessing people, but we quickly realized that the scope of such a project would be unmanageable for the time and resource constraints we would face, so we decided instead for the ghost to possess objects. To give the game a story, we decided to put the ghost in an art museum, and made the ghost an art thief, who must avoid detection by a security guard.

I came to the jam intending to work with Wally, but Bobby and Colin joined us and were very productive members of our team. We had two full-time artists (Bobby and Colin) and two programmers (Wally and me). Wally also recorded sounds and did some of the art as well. Between the two of us, he even did the bulk of the programming, laying out the main engine, player, and “possessable” art object, while I provided the “googly eye” effect for the possessed art objects, and implemented the guard, and also lent a hand with debugging, polishing, and general play testing. In addition to providing some of the art for the project, which included the Ghost and Statue sprites, and floor tiles, Bobby also did our level design. Colin contributed the guard sprite, the diamond, the vase, the paintings, and the pillars, and also touched up and organized the wall tiles. Their artwork was excellent, and they were able to produce exactly what the project needed. Everyone’s art worked well together, too, which I’m not sure how that happened, but it’s impressive that three different people working on art could come up with a consistent and seamless style.

This was my first game jam where I got to work with another programmer and shared programming duties. I found that things went very well overall. We had a few hitches when merging code, but nothing terrible. We didn’t use a formal version control system, which was part of the problem. At first we relied on Google Drive to share files between team members, but when it comes to uploading revised versions of files to Google Drive, some very strange things started to happen. Apparently when a user “deletes” a shared file on Google Drive, it remains available to the other users who have access to the shared item. Replacing the file with a newly uploaded copy doesn’t replace the original copy, and instead results in multiple versions of the same file. This created a lot of confusion at first, until I realized what was going on. At that point, we switched to using Dropbox, and handled code merging using BeyondCompare to handle comparing and moving the code files in the project .gmx. Wally and I sat side by side, which made it a reasonable way to handle merges. This worked passably well, BeyondCompare made it very easy to merge our changes. But I believe that a true version control system would have been even better.

We also were able to communicate with each other as needed, and be a second pair of eyes for each other whenever we had a “wtf?” moment. I’m really excited about working with Wally more in the future, and would be happy to have more chances to work with either Bobby or Colin again as well.

YoYoGames announces GameMaker Studio 2 Console build targets, Ultimate Edition

Coming with the release of GMS2.0.7, YoYoGames have released Console modules to allow developers to build for Microsoft XBox One and Sony PlayStation 4. There is as yet still no module to allow development targeting the Nintendo Switch.

The cost for these console development modules is $800 for 12 months. Each.

Additionally, customers who purchase a console module must be a registered developer program for the console in question.

Or, for “just” $1500/year, you can subscribe to GMS2.0 Ultimate Edition, which seems to be a response to popular demand to bring back the “Master Collection” package. Ultimate Edition is an “everything and the kitchen sink” bundle that includes any future modules that YYG may release for no additional cost. The price of Ultimate is much higher than the cost for Master Collection , however, and is subscription-based, rather than a perpetual license. GMS1.x Master Collection was originally introduced at a 1-time cost of $500, later $800.

Readers may recall that I predicted that YoYoGames planned to move GMS2 to a subscription model, and that their license activation was in fact already a de facto a subscription model, and today’s announcement bears out that assessment.

YoYoGames confirmed that the existing modules (Desktop, Mobile, HTML5, UWP) remain a permanent license that you pay for once. However, it’s been YoYoGames’ practice in the past to charge again for the product when it hits the next major release number. Accordingly, YoYo could, if it wanted, release GMS3.0 next year, and charge everyone for an upgrade to that, and drop support/updates for 2.x, effectively forcing everyone to pay for another upgrade at that point. It’s a good bet that at some point they will switch to a subscription-based model at all tiers.

YoYo seem to be pricing themselves out of the market with this announcement. While it’s not unreasonable to charge a premium for the console build targets, the price points announced today do not compare favorably with the competition. Unity3D is also subscription-based, now, but you can get full access to all Unity3D build targets for free, with an income cap of $100K. Game Developers earning revenue over $100K/year from their games must upgrade to Plus or Pro tiers, at $35 or $125/mo — the $125/mo Unity Pro tier matches the cost of GMS2 Ultimate.

The Unity3D IDE is Visual Studio, an industry leader, and the language is C#. By contrast, the GameMaker Studio IDE and GML language are quite limited compared to the capabilities of Visual Studio and C#.

It’s likely that most developers who are in the Microsoft XBox or Sony PlayStation developer programs are already experienced professionals accustomed to professional-quality, industry standard development tools, so it’s hard to see why they would want to take a step down and use GameMaker when they could use Unity3D, or Unreal, or some other tool at less cost. GameMaker Studio 2 Ultimate is priced comparable to Unity Pro, but the capabilities and tools around Unity are much stronger and more flexible.

YoYoGames: GameMaker Studio 1.4 sunset annonced for 2018

Today, YoYoGames announced that GameMakerStudio 1.4 support will sunset in 2018.

Over the next 14 months, until 31 July 2018, we will continue to mend major issues and support platform updates for Studio 1.4. After the 14-month period, Studio 1.4 will still function normally however, we cannot guarantee it will remain compatible with every platform’s future updates.

While this day has been expected to come since the release of the 2.0 beta back in November 2016, this is quite a bit sooner than expected. YoYoGames support for the 8.x version of GameMaker continued for years after GameMakerStudio 1.0 was released, only ceasing very recently.

It’s not entirely bad for the company to focus itself on development and support for the latest version of their product, but it’s unfortunate for users who for whatever reason are not able to move to the new version so quickly. This also makes it all the more important that GMS2 be as good as it can be. Hopefully, by focusing on the latest version exclusively, this will enable YYG to develop it even faster, adding new features, fixing bugs, and addressing UX issues with the brand new IDE.