Which makes total sense, and I predicted it about 5 years ago. They denied going to a subscription model at the time, because of course they did. Users at the time weren’t in favor of it, preferring perpetual licensing. But I guess everything changes when you get bought.
Of course, for development tools, everything gets stale if you don’t keep it updated, so a subscription based licensing model probably does make the most sense.
For professionals, anyway. For amateurs and hobbyists, though, it’s a lot of money to pay for a tool if you only use it occasionally. GameMaker’s bread and butter used to be the student/hobbyist/indie developer who could readily afford a one-time price of $40, then $100. Now it’s $100/year, or $9.99/mo. Which is still not that much if you use it a lot, but if you’re just not ready for that type of commitment, there’s really nothing like what GameMaker 8 once was, over a decade ago.
YoYoGames still offers a free edition, intended for student/hobbyist users, but it lacks exports, not even for Desktop OSes, so it’s of extremely limited usefulness for anyone who wants to actually build their projects in order to get feedback from peers and friends.
About 10 years ago, YoYoGames was talking about a Linux IDE for GameMaker Studio on their long-term roadmap. A few years passed, and the roadmap disappeared and all talk about a Linux IDE went silent. It seemed that PlayTech may have been responsible for killing the project when they bought YoYoGames.
I’d given up all hope of a GameMaker IDE on Linux long ago, but a few days ago, this article crossed my newsfeed. It looks like new YoYoGame owners Opera is developing a port, currently in beta. It appears it will be supported on Ubuntu only, but that’s better than zero Linux distros, and Ubuntu is a pretty good choice.
This would have really excited me a decade ago, and would have been the last obstacle to me completely ditching Microsoft. While better late than never, it’s still not really here yet. It sounds like the beta currently has some rather severe issues that make it less than suitable for production at this time. Hopefully this will change quickly. It will be interesting to watch and see how it goes in the coming weeks.
Editor’s note: [I originally wrote this as an Appendix to the documentation for Z3D Engine, but I think it’s interesting enough to deserve a slightly wider audience.]
I have to preface this section by saying that I have no idea what I’m talking about here, but am trying to learn. I like math, but I didn’t go to school primarily for it, and that was decades ago. I haven’t studied 3D geometry, or optics, or computer graphics in any formal sense. I’m figuring this out more or less by myself, learning as I teach myself.
So if someone who knows more than I do wants to explain this stuff better than I can, I’d love to hear from you. You can send me an email at the Contact page, or tweet at me @csanyk, or just comment on this article.
Thanks in advance!
I’ve called Z3D Engine a “Fake 3D” engine and “2.5D” engine, because those are fairly vague terms that I don’t have to worry about being right about. Someone asked me what type of view it is, and I couldn’t tell them. That bothered me, so I started reading a bit. I still don’t really know for sure.
a method of projection in which an object is depicted or a surface mapped using parallel lines to project its shape onto a plane.
a drawing or map made using orthographic projection.
I think this is sortof close to what Z3D is… maybe. What I can tell you about Z3D is this: You can see the full front side and the full top side of (most) objects. These do not foreshorten.
gerund or present participle: foreshortening
portray or show (an object or view) as closer than it is or as having less depth or distance, as an effect of perspective or the angle of vision.
“seen from the road, the mountain is greatly foreshortened”
The blue rectangle that represents the “player” in the demo is intended to show the player as a side view only, with no pixels in the sprite representing the top surface of the player. This is because I’m intending Z3D to be used for games drawn in a visual style similar to the top-down Legend of Zelda games, and in those games, no matter which way Link is facing, you can only see pixels in his sprite that represent his side, and nothing that represents the top of him, even though you’re viewing most of the rest of the terrain in the room from this weird view where you can see both the top and side of things like blocks and chests, and for other things like bushes you can only see the side.
Things in Z3D do not appear to get smaller as they recede into the background, or get bigger as they get closer to the foreground. As well, the tops of objects (that have tops), the top is drawn 1 visual pixel “deep” (in the Y-dimension) for every pixel of distance.
This doesn’t look correct, strictly speaking; if you’re looking for “correct” visuals this engine likely isn’t for you. But it is visually easy to understand for the player, and it is very simple.
What I’m doing in Z3D Engine is showing the top of everything (that has a top) as though you’re looking at it’s top from a vantage point that is exactly perpendicular to the top, while at the same time you’re also seeing the side of everything as though you’re looking at the side from a vantage point that is exactly perpendicular to the side. This is an impossible perspective in real life, but it works in 2D graphics that are trying to create a sort of “fake” 3D look, which is what Z3D does.
Imagine you’re looking at this cube:
At most, assuming the cube is opaque, you can see only three faces of the cube from any given vantage point outside the cube; the other three faces are occluded on the other side of the cube.
(That image above is properly called Isometric, by the way. Z3D is not isometric).
If you were looking at the cube from a vantage point where you were perpendicular to one of the faces, you could only see that one face, and it would look like a square:
(Since the faces of this cube are all nondescript, we can’t tell if we’re looking at the side or the top of the cube.)
Now, if it were possible to be at a vantage point that is exactly perpendicular to the both the side and the top of the cube simultaneously, the cube would look like this:
This is weird and wrong, but yet it is easy to understand, and it turns out that it is also very easy to compute the position and movement along 3 dimensional axes if you allow this wrong way of drawing. This is view is (or perhaps is similar to) a method of visualization known as a oblique projection.
More properly, if you were positioned at a vantage point somewhere between the two points that are perfectly perpendicular to the top and side faces, the cube would look like this:
Here, obviously, we are looking at the cube mostly from the side, but our eye is slightly above, so we can see the top of the cube as well. But notice, since we are not viewing the top face of the cube from a perpendicular vantage point, it does not appear to be a square any longer — it foreshortens, so that the far end of the top of the cube appears narrower than the closer end.
This is perhaps obvious, because we’re using to seeing it, because we see it every day, because that’s what real life looks like. But it’s because we see this every day that we take it for granted, and when we have to explicitly understand what’s going on visually with geometry, we have to unpack a lot of assumptions and intuitions that we don’t normally think consciously about.
If we were to put our eye at the exact middle point between the points that are perpendicular to the side face and the top face, the cube should look to us like this:
Notice that both the bottom of the side face and the far edge of the top face are foreshortened due to perspective.
This is how they “should” look in a “correct” 3D graphics system, but Z3D “cheats” to show both the side and top faces without doing any foreshortening, which means that it can draw an instance as it moves through any of the three dimensions using extremely simple math.
Visually moving 1 pixel left or right is always done at a hspeed of -1 or 1, regardless of whether the object is near (at a high y position) or far away (at a low y position). Likewise, moving near or far is also always done at a rate of one distance pixel per apparent visual pixel. And moving up and down in the z-dimension is also always done at a rate of 1 distance pixel per apparent visual pixel.
If we wanted to draw more convincingly realistic 3D graphics, we need to understand what’s going on with the eye, with perspective, and things at a distance.
The same object viewed in Z3D’s perspective is something like this:
(We’ve omitted the occluded faces on the back end of the cube relative to the viewer, for simplicity.)
These two “apparent” perspectives are combined at the point where the player’s real eye is, resulting in something like this fake-3D perspective:
So, in conclusion I’m not 100% sure that my terminology is correct, but I think we can call this perspective “flattened orthographic bi-perspective” or perhaps “oblique projection”.
(From this, we can begin to see how a corrected view might be possible, using trigonometry to calculate the amount of foreshortening/skew a given position in the Z3D space would need in order to appear correct for a single-POV perspective. But this is something well beyond what I am planning to do with the engine; if you wanted this, you would be far better off creating your game with a real 3D engine.)
It gets weirder when you realize that for certain objects, such as the player, we’re going to draw only the side view, meaning that the player will be drawn a flat 2D representation in a fake 3D space. Yet the player’s “footprint” collision box will likely have some y-dimension height to it.
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.)
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.
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.
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.
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.
The GM8 theme for GMS1.x was my preferred way to theme my IDE, because it mostly followed the Windows standard theme colors.
YoYoGames recently announced a new edition of GameMaker Studio 2. Called the “Creator Edition”, it is $40/year subscription.
I’d pointed out earlier in the year that YoYoGames had taken all the necessary steps to make ready to abandon perpetual licensing, and this announcement proves my assessment was right on. See, reddit? I was right.
Permanent subscriptions are still offered starting at $99, although the software license is active only as long as the machine it’s installed on is able to log your YoYo Account in with YYG’s license server. Which is to say, if they want to they can disable your license, and if they go out of business, or if the license server goes down, you won’t be able to use the software.
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.
YoYoGames posted a major, detailed update to their roadmap for GameMaker Studio 2 this morning. Seemingly not an April Fool’s joke.
The announcement contains lots of exciting, long-awaited new features and improvements, but not much detail as yet about when most of these might be forthcoming. And the usual disclaimers that these are plans, not promises.
There’s even more at the link above, but here’s what I think about these in particular: (more…)
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 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.
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.