Tag: GameMaker

GameMaker Marketplace new checkout system now allows direct downloads!

business, development, games
Comments

Yesterday, 9/7, I noticed a big spike in downloads of my GameMaker Marketplace assets. I also happened to notice when looking around on the Marketplace that they’ve changed the checkout so that you can download the .gmex files directly through your web browser, bypassing the My Library interface in the IDE.

As I’ve remarked several times in the past year, My Library is crippled by terrible performance when the user’s purchase manifest exceeds some number that is far too low. Allowing purchases to be downloaded directly through the browser makes a lot of sense, and is probably the simplest solution to the performance issues, which still plague GM:S as of 1.4.1760.

It remains to be seen whether this spike in downloads will be sustained as the new normal, or represents pent-up demand for users who were reluctant to buy due to the poor performance of My Library. Despite the seeming smallness of this change, I’m really excited that YoYoGames have made it, as it alleviates a significant pain point that I’ve been complaining about for well over a year, and means that I’ll likely be making more use of extensions in my projects.

Graph showing sales spike on 9/7/16. Could this be due to the change in delivery method?

On 9/7, 18 downloads. The other spike earlier in August was due to my Ludum Dare 36 sale, when I put my paid assets on sale for $FREE

Update: 9/8 saw another 18 download day.

Tutorial: GameMaker Object with multiple collision zones

Best Of, development, GameMaker Tutorials, Tutorials
Comments

GM Version: GameMaker:Studio 1.4 (concept should work in earlier versions)
Target Platform: ALL
Example Download: https://csanyk.com/cs/releases/games/LD48-36_AncientTechnologies/LD48_36_Ancient_Technologies_csanyk.gmz
Links: http://ludumdare.com/compo/ludum-dare-36/?action=preview&uid=10473

Summary:

How to make an object that handles multiple collision zones by using multiple sub-objects

Tutorial:

I used this technique in my recent Ludum Dare game, Ancient Technologies. The project has a TON of extraneous code in it, some of which is pretty messy, so I’ll replace the download link with a cleaner example project of just this technique in coming days.

If you look at the Atari 2600 console in this game, it is actually multiple objects, made to look like a single object. This enables each switch to have its own collision detection and mouse events.

I accomplished this with a few simple techniques that work really well:

The console itself is the main object. Then there are 6 objects for the 6 switches on the console.

I then took the image I wanted to use for the sprite, and cut out all the different clickable regions, putting each into its own subimage by itself. Then once all the subimages were created, I removed each subimage into its own sprite, and set the collision mask to cover just the pixels in the image

Atari 2600 clickmap sheet

As you can see, this approach results in a lot of “wasted” space in the sprite sheet in the form of transparent pixels, but if you’re concerned about this, you could always achieve the same effect by using sprite origin and sprite offset to position the images without all the whitespace in the sprite sheet. I skipped using sprite origin because I didn’t feel like bothering with counting pixels and setting each sprite origin differently. That would have been tedious, and if I had ever needed to change the sprites, could have thrown everything off and required extensive rework to recalculate again. If your sprites are tiny, it probably doesn’t matter too much, but if they’re quite large, then you should probably use sprite origin/offset.

(Note: With the small pieces, you’d need to use origin numbers that are larger than the dimensions of the sprite itself, or possibly negative values for the origin. You’d also need to carefully calculate the distance to set the origin so that the images all line up precisely. The goal is to make all the images align when each instance’s x and y are identical. This makes them easy to move around together as a group, without having to deal with offsets and so on. To make everything align easy, I created sprites that have the same height and width, so that getting them to align takes no extra effort or calculation at all.)

Next, use the “main” object to generate the collision zone objects, in the create event:

Note the example code below isn’t exactly the code in my project, but is cleaned up a bit for easier comprehension.

///oConsole Create Event:
power_switch = instance_create(x, y, oPowerSwitch);
tv_type_switch = instance_create(x, y, oTVTypeSwitch);
left_difficulty_switch = instance_create(x, y, oLeftDifficultySwitch);
right_difficulty_switch = instance_create(x, y, oRightDifficultySwitch);
select_switch = instance_create(x, y, oSelectSwitch);
reset_switch = instance_create(x, y, oResetSwitch);

Since these objects all use sprites that are the same size, they all line up together when their x,y position is the same. Now you have an easy way to place just the main object and have it create all of its collision zone objects, perfectly aligned.

If the main object needs to be able to move, you just need to update the x,y of all the objects whenever you need to.

Another great thing is that each of these instances can have its own animation which is completely separate from the rest of the collection of objects. This means you can do really sophisticated animation rigging.

Also, you can access the instance variables of the collision instances by using the main instance, like so:

oConsole.power_switch.position = UP;

is (essentially) equivalent to:

oPowerSwitch.position = UP;

This allows you to use the collision zone instances’ instance variables like you would use properties of a helper class in another language, which may make accessing these variables easier if you’re used to other programming languages.

As well, if each of these switch instances were of the same object, using the id returned by instance_create() would allow you to differentiate between them. This could be useful for, say, a battleship with multiple turrets that are all of the same object type.

Finally, you’ll want to be mindful that if you destroy the main object, you’ll likely want to destroy all the sub-objects. Perhaps not — maybe you’re doing a spaceship with an escape pod or a rocket with multiple stages that break away. But in that case you’ll wan to be sure that once the main object is gone, you are handling whatever remains somehow.

YoYoGames discontinues sales of GameMaker for Mac

games
Comments

YoYoGames announced yesterday that they have discontinued sales of GameMaker for Mac (the GM7-based IDE for Mac OS X, not the build target module for GameMaker: Studio to allow building games for Mac OS X).

I don’t expect that this move surprises or disappoints many. This version was long out of date and did not include features from the 8.x and Studio 1.x sequences of the product, and had languished while YYG focused its resources on the success of GameMaker: Studio.

YoYoGames stressed that users who already own GameMaker for Mac are still supported and can install and use the product that they already own. YoYo say that they are still committed to supporting development on the OS X platform with a future release of GameMaker: Studio, but the expected release date for this is as yet unannounced.

One would hope that with the ending of sales for the old version, the replacement product might be coming soon.

It’s good to see YoYo communicating its intent with the product like this. The announcement was clear, addressed possible misconceptions, and came through an official outlet.

GameMaker EULA restricts developer creativity

development, games
Comments

[Editor’s Note: After a busy year or so of low posting frequency, during which I started but never completed many articles, I’ve been going through my old drafts, working to complete old articles that still hold relevance. So this is an old topic, though not out of date, which I started writing in May of 2015, and I don’t mean to stir up new debate over it, but it’s worth being aware of.]

YoYoGames has restrictions in the EULA for GameMaker which states in essence that users agree to allow YoYo the authority to determine whether a game produced by the user is in line with their moral standards, and the right to terminate your license if they wish should you produce something they deem objectionable, without explicitly spelling out what counts as objectionable.

An April 2015 discussion on the old GameMaker Community forums raised this issue, but is now hidden due to the closure of the Suggestion Box subforum, but still available through the Internet Archive’s Wayback machine.

To summarize the discussion, YYG don’t seem to be actively policing their policy, nor are they specific in explaining their standards for acceptable content in games. They seem to be treating the EULA clause as something they can invoke if they so choose, but not actively evaluating published games to ensure they don’t violate it. And currently they seem to be pretty lenient about what they deem acceptable — for example, they deem Hotline Miami to be clear of violating their standards. Accordingly, I don’t read YYG as bad actors here.

But this does give rise to what one would have to do in order to cross the line with respect to YoYo’s standards, and why have them in the first place. It seems the answer to the latter question is to allow YYG the contractual authority to nix a license more or less arbitrarily, in order to make clear that they do not have any relationship with a developer who they deem too offensive. Which is to say that if a game produced with GameMaker were developed and it generated negative publicity for YoYo, that’s probably ultimately what their standards boil down to.

YoYoGames motivation seems to be that they (understandably) do not wish to be associated in any way with a game that someone else develops, if that game is “deeply offensive” (whatever that means — it varies from person to person what offends them). Considering that many games these days address topics which many might find “controversial”, and thus may be offended by, it gives a developer pause. And even those games that are not exactly controversial routinely depict subject matter which upon a moment’s reflection make us wonder why they’re not considered offensive. A huge proportion of videogames depict violence in a casual, matter of fact, even joyous manner. But most games would be instantly get a Mature Audiences rating if they depicted nudity, even if the context isn’t sexual.

It’s tough to say what the guidelines are for producing a game that is free of these concerns, and YoYo weren’t very interested in stating their guidelines explicitly. “Use common sense” seems to be their question-begging non-answer. Common sense falls down in controversial cases precisely because they are controversial. There’s undoubtedly a whole classification of things that are offensive to marms and nuns but that teenage boys think is fine, but the only answer that matters in this case is, “is what’s considered offensive by YYG?” Debating “what is too offensive?” is an endless quagmire but “What does YYG consider too offensive?” is something that can have a start and an end to it, and is probably a succinct bulleted list, which people may be free to disagree with or not as they choose, but still helpless to change.

I surmise that there are things that are commonly topics addressed by the medium of videogames, such as violence and war and crime that are not included in the “truly offensive” category, but that a game could step over the line by being too explicit in its depictions of these things, or by appearing to advocate for doing these things in real life, or by appealing to the player’s “prurient interests” in such depictions. The “common sense” approach seems to be a way for YoYo to say, “We don’t want to say because it’d probably just give horrible people a to-do list, but if everyone could avoid things such as explicit torture, rape, and so on, that’d be great.”

Still, the fact that someone else can tell me what I can or can’t put into a game that I’ve designed, is inherently offensive to me. I think it unlikely that I’d produce something that would cause YoYo to take notice and strip me of my license, but the fact that they can, and that they think that it’s right for them to have such power, is offensive to me. To me, there is a boundary where their responsibility ends and my responsibility takes over, and I should be responsible for my creations; once the tool they’ve produced is in my hands I don’t need their sense of responsibility for their creations to encroach upon my creativity.

It’s tough to see why YoYoGames would be associated with a game that was developed by someone else, even if they happened to use GameMaker. One reason might be their logo is used as the default splash screen and application icon when a game is built with GameMaker. These are removable by the developer, but are often left as-is by amateur developers. But there, a simpler remedy would be to compel game developers to remove YYG logos from games that they do not wish to be associated with at their request. Or, if YYG wanted to, they could ban games that they deem unfit from being sold or otherwise distributed through their online store, while not taking away the developer’s liberty to release the game through other means, or to continue using GameMaker to develop other games.

YoYo declined to change the policy, taking a “take it or leave it” attitude, and then closed the forum topic to quash further discussion. It seems to be the YoYo forums general policy to kill topics when moderators deem that further discussion is “pointless” since they are firm about not changing their minds. Obviously that’s not the case, as there may be much to discuss whether or not YoYo change their minds, and getting YoYo to change their minds is not always the aim of discussing some topic on the forums. Really, it’s about stopping discussions that may lead to users expressing views deemed critical or negative to YoYoGames, which they (wrongly, in my opinion) feel is harmful or threatens their brand.

Which, since it’s their forum, that’s their prerogative, but I can’t say that I like or agree with the practice. And now that they’ve restricted access to that particular forum, the topic is no longer visible. And this is one of the reasons why I have my own website where I can exercise my right to free speech without censorship.

The Case for GameMaker, and a defense of criticism

business, development, games
Comments

In recent weeks, I’ve been fairly outspoken and critical about the velocity with which YoYoGames have been delivering change in their core product, GameMaker: Studio, since being acquired by PlayTech.

In response to this, Twitter user and fellow GameMaker developer @doppp pointed out that my remarks about YoYoGames’ failings with GameMaker of late serve as an anti-sales pitch for my GameMaker assets:

Well, I suppose that’s a fair point to make.

I gave @doppp my short answer: if you’re already using #GameMaker and are happy with it, there’s no reason not to purchase assets that look useful.

A long answer demanded more space than I can put into a tweet, or a series of tweets.

So how can I simultaneously ask people to pay money for the assets I’ve created while criticizing YoyoGames?

Criticizing isn’t bashing. Or negative.

When a problem is real, pointing out that it exists and that something needs to be done about it is NOT being negative. People like to say that it is, but it isn’t! Ignoring problems and acting like they don’t exist is worse.

As a user, I’m entitled to criticize the product, to say what I like about it as well as point out problems and ask the developer for remedy. Why? Because I’m a user! These are my experiences! That’s why.

Also, GameMaker is closed source, so I can’t freely modify it to better suit my needs. That’s why.

And because I paid for a license. That’s why. I paid for a Master Collection license, which costs around $800.

To be sure, even a user who’s never spent a dime on GameMaker can have a valid opinion about it. And the fact that I’ve spent money on a license doesn’t make my opinions more valid. But it does show that I have a larger stake in the product than does someone who hasn’t.

My time is valuable, I’ve sunk quite a bit of it into GameMaker, and I want GameMaker to continue to improve and be successful.

I’ve been using GameMaker since version 8.1, for a good six years now. I was an early adopter of the GameMaker: HTML, and GameMaker: Studio. I purchased a Master Collection license for Studio in order to have full access to every feature the product offered or would offer. I’ve contributed technical review to two published books on GameMaker.

I have the experience to offer valid opinions on it. Does that mean I know everything, or am right about everything? Of course not. But it does mean that my opinions are not uninformed.

Software development doesn’t happen in a vacuum. Developers depend on users to make it known what their needs are and what their pain points are. Providing this feedback in a useful and productive manner is a valuable service, and developers ignore stakeholder input at the peril of the product they’re producing.

Obviously, any company has limited resources and can’t do everything that every customer wants, and YoYoGames is no exception. But it’s still necessary and important for their customers to provide feedback. I haven’t once felt that the employees of YoYoGames resented my feedback. They may not always agree with it, and that’s fine. I respect them, while at the same time striving to make the best case for the validity and importance of the feedback that I offer to them.

Let’s be clear: We all know that there are pros and cons to any product. The cons are negative. Acknowledging that they exist, pointing them out, and discussing them isn’t negative.

OK but it’s not fair to slam YoYo in public. You’re hurting their reputation and their sales. Therefore, you cannot say you like them.

First, I would dispute that my public comments re: YoYo are “slamming” them. I do my best to offer fair and valid criticism. And doing so publicly is actually my last resort, something I do sparingly and reluctantly.

I’ve actually provided feedback to YoYoGames in a number of ways over the years. I submit bug reports. I engage with YoYoGames support. I post suggestions on the official community forums. All of this gets read. Generally speaking, the bug reports and support requests are handled well. Bugs that turn out to be real issues get prioritized and fixed.

The situation with the My Library bug that I’ve been publicly vocal about, has not been handled well. After submitting a support request and opening up a bug report for this issue, I’ve waited well over a year, and seen no remedy to the problem, other than a suggested workaround to deactivate some of the Marketplace assets that I own, until the performance My Library becomes reasonable. This is not a solution, and even as a workaround it’s not very good. YoYo needed to address this issue as soon as it came to light, and they didn’t.

Fortunately, subsequent to my article appearing in public and getting some significant exposure, YoYo Community Manager Shaun Spalding started a discussion in the new Forums asking people for what they’d like to see done with My Library. I take this as a sign that they’re listening and starting to take steps in the right direction. Would that it were sooner, but at least it’s happening now. Maybe that discussion wouldn’t be happening if I hadn’t sounded off about my frustrations. Sometimes you need to speak out.

The other situation I’ve been vocal about was the poorly handled migration to the new community forums. Here, YoYo should have done a better job of explaining to its users what was going on. They didn’t, and after two months of waiting with no official word about what was happening, I felt it was necessary to state the reasons that this was unacceptable. The only place I had available to do this was in public.

Brand management, community relations, and customer service are extremely important, and it was very distressing to see YoYo failing so badly at it. It was entirely appropriate to express serious concerns over the future of the product.

Bottom line, YoYoGames exists in public. It’s fair to talk about public things in public. Whether or not YYG’s hands are tied to talk about their product in public, the public is going to talk about their product. The best way to get people to say good things about you is to be good, and to fix things when you are not good.

Overall, YoYoGames have been very good owners of GameMaker. I’ve yet to see reason to believe that PlayTech is a good owner of YoYoGames. I don’t know what goes on behind the scenes, so I can’t say for sure, but it feels to me like YoYo was doing more, better, sooner before they got acquired. That may or may not be true, but that’s how it appears to me.

OK but if your criticism of YoYoGames is true, then why should I sink any money into GameMaker development when it has these problems?

Well, that’s something everyone has to decide for theirself, but of course that answer won’t suffice here.

Ultimately it’s YoYoGame’s job to persuade you that their product is worth your time and money. But definitely, customer testimonials are strong persuasion.

Look, every product has flaws. People who are enthusiastic about products tend to talk a lot about ways they could be improved. That doesn’t mean they don’t like the thing they’re talking about. Far from it!

I used to recommend GameMaker perhaps more enthusiastically, but always conditionally. I still do, actually, but now it’s with a bit more conditions. It’s a fine tool, that doesn’t mean it’s right for everyone.

Why buy into GameMaker? Whether in terms of time or money, GameMaker is great if:

  • You want to do rapid prototyping and get something up and running quickly.
  • You want to do 2D game development of relatively small, simple games. (Sure, GM:S can handle larger projects, but there are other tools to consider when your project scales above a certain size.)
  • You want a simplified developer experience without all the headaches of more complicated tools.
  • You have no experience developing software and want to express your creativity with a tool that won’t overwhelm you with its complexity.
  • You need or want access to the features that a paid license unlocks.
  • You feel appreciation for the work YYG have done so far and want to contribute to that success financially.

I used to say that GameMaker is worth considering for game developers with professional aspirations, because since I started working with the product at version 8.1, I saw consistent, rapid releases of impressive new features that expanded the capability of the tool, year after year.

I’m not saying that now, because in the last year I can’t think of anything new that they’ve introduced since the PlayTech acquisition, and professional developers depend on their tools to continuously improve. Here’s a timeline showing what YYG have delivered during the life of GM:S so far:

Late 2010/2011:

  • GameMaker HTML5 (essentially a beta of GM:S that built only to HTML5)

2012:

  • GameMaker Studio launches.
  • Windows 8, OS X, iOS, and Android build target
  • GM:S available through Steam
  • Publish games to Steam Workshop

2013

  • Tizen build target
  • Ubuntu build target
  • YoYo Compiler
  • Networking
  • Shaders

2014

  • Physics
  • GameMaker: Marketplace
  • GameMaker: Player

2015:

  • PlayTech acquisition (February)
  • Then-CEO Sandy Duncan says they expect to release GM:S 2.0 “sometime in 2015”
  • Universal Windows Platform (UWP) build target (November)
  • Roadmap goes dark.

GM:S 2.0: originally planned a release sometime in 2015; as of August 2016 it’s still in closed beta. Delays happen, and often for good reason. It’s plausible that the delay in this case has to do with the acquisition by PlayTech, as being acquired is often disruptive to operations, but I don’t know what the reason is.

2016:

  • New forum software goes live (after nearly 3 months delay while old forum in read-only archive state).

So, unless I’m missing something, apart from UWP, basically nothing new/major in the last 2 years, coinciding with their acquisition by PlayTech. Just bugfixes. That’s not nothing, but that’s not major, either.

That could be a coincidence, I suppose. It could be that not much was delivered in 2015 due in part to the transition of ownership, but also due to so many new features being part of the new codebase that makes up 2.0, and 2.0 being delayed. But it does seem like their velocity of delivering major new features has slowed, especially compared with 2012-13.

My point in saying all that is not to be negative, but to present evidence. If YYG were delivering with the same velocity they were in 2012-13, I’d be very happy and recommend them without reservation. They don’t seem to be, and that’s a concern. They’re no longer talking about what their future plans for the product are, and that’s a concern. They had a very visible failure to deliver the new forums, and didn’t handle the community relations around that well, and that’s a concern.

The product is as good as it’s ever been, and it’s never been better. Can I use it now? Absolutely. Do I like using it now? Apart from My Library, yes.

But does it have a bright future? Is it going to be what I’m going to want in three or five years? I have no idea. They stopped publishing their Roadmap, so I literally have no idea. I presume they’ll continue to be around, but I don’t know what new features they’re planning, or approximately when to expect them. I don’t know that they’ll continue maintaining what they’ve built so far, or if they’ll neglect features as they’ve neglected the My Library feature. It does raise cause for concern.

Let me be clear: I fully expect that GameMaker will still exist 5 years from now. But I don’t know how much better it will be from today. And I think there’s some reason to be concerned that it won’t be as improved from 2015 in 2020 as it was from 2010 to 2015.

So, bottom line, if you have GM:S now, and use it, and like it, there’s no reason not to spend a small amount of money on extensions or other assets that look like they’d be interesting or useful to you. Just watch how many assets you keep active if you own a lot of assets.

If you’re new to Game Development and considering purchasing GM:S, or one of its competing alternatives, I don’t know what to tell you. GM:S is still great for beginners, and the Free edition is a great tool to start learning with. The free edition certainly is worth checking out. But as far as purchasing, you’ll have to decide for yourself based on how well you like it, and what your own impression is of the product’s future.

I like GM:S for a lot of reasons, but there’s good reasons to consider other tools: Unity3D, or Construct2, or Godot Engine, or something else. As for spending money on the Professional edition, it’s a maybe, downgraded from a recommended.

What could turn that recommendation downgrade around?

Well, right now it’s a wait and see game to see what happens with 2.0. If you haven’t paid for 1.x yet, it may be smart to hold off until we find out whether 2.0 delivers the greatly improved experience with the IDE, or if the IDE rewrite turns out to be a bust. I have high hopes, and I’m eager to find out.

On the other hand, there are plenty of risks? Will 2.0 drastically change GML, such that Marketplace assets all break and need to be rewritten? Will the improved room editor be a dream to work with, or minimally improved? What new features will be coming with 2.0? It’s worth waiting and seeing.

On the other hand, if you’re already invested in 1.x, and are using it, then sure, you know what you have and that it’s good enough for you right now. Go ahead and spend some money on extensions that other GM:S users have developed.

Follow Up to GameMaker: Exodus

development, games
1 Comment

My earlier post airing my dissatisfaction with GameMaker since YoYoGames was acquired by PlayTech has been unexpectedly popular. Shortly after the post went live, prominent indie game developer and owner of the ersatz gamemakerblog website, TrueValhalla, retweeted the article, bringing a great deal of traffic to this site, and many other retweets, likes, and comments.

This evening, the article received some attention from Shaun Spalding, of YoYoGames, and I had a brief exchange with him on Twitter, although due to the time zone difference it was late for him and we weren’t able to go in depth. Shaun’s a recent hire at the company, and has been in charge of the community forums since joining. Previously, his YouTube channel has provided a great series of GML tutorials. He’s an all around good guy, and I have nothing against him personally. In fact, I’d like to be clear, I have nothing against any of the other prominent YYG personalities such as Mike Dailly or Russell Kay, or GMC forums administrator Mark “Nocturne” Alexander, or former YYG CEO Sandy Duncan. All of them have been friendly and accessible, and have always responded to questions, suggestions, and even the occasional complaint professionally. It’s great to have such accessible and visible people standing behind the product. I’m not looking to make enemies or get into a fight with anyone. I’m interested in frank dialog.

TrueValhalla characterized my post as detailing the “decline of GameMaker” since the PlayTech acquisition. I didn’t use those words myself, but it seems like a reasonable way to characterize my position, given the numerous disappointments and failings I had outlined in my post. I would say that my confidence in YoYo and in the future of GameMaker is at a low point. In my opinion, GameMaker hasn’t declined, exactly — it’s improved over what it was a year ago — but the rate of improvements has slowed noticeably over the last year. With the failed migration of the GMC Forums n the last couple months, I’m very concerned.

Absent insider knowledge of what’s going on, I am left to speculate that it’s due to the way PlayTech have managed them. A large part of the problem has been YYG’s failure at maintaining community relations to let concerned users know what’s going on with the product.

The minute the new GMC Forums release was late, or better still, the moment they knew it would be late, YYG should have communicated to the community to let them know what was going on, why, and what to expect, and when.

I’m not slamming YYG by saying this; I’m trying to help them by calling attention to problems, so that they can make improvements. My dissatisfaction with GameMaker doesn’t mean that I want to see GameMaker fail, or even that I don’t like GameMaker. Quite the contrary, I love it and want to see it thriving. But, the fact is, I don’t see GameMaker thriving right now, and I see numerous reasons for concern as I outlined in my previous post. There should be no controversy: a company must listen to its customers and be responsive to their needs.

But, given their track record over the last year since the PlayTech acquisition, I don’t have much hope for improvement. And so I’m looking at alternatives, and I’m currently very interested in the Godot engine, which seems to be delivering improvements with great velocity and doing all the right things to attract my attention as a developer. It’s good to have alternatives, and anyone who’s passionate about game development is constantly looking for better tools anyway. However good GameMaker is, they have to improve continuously in order to remain competitive in the marketplace. Slowing down or stagnating is death in this business climate. I really don’t want to see that happen.

Let’s look at Shaun’s responses in detail.

First, he responded by tweeting that he disagreed with “basically everything” in my post, but couldn’t articulate why in 140 char. So, ok. That’s fair. This blog post is an invitation for Shaun or anyone else at YoYo or PlayTech to respond in depth to my points.

Next, he tweeted a link to reddit, where on May 26 he responded to someone asking about why the new GMC Forums were so late. The explanation offered there is that PlayTech does gambling software, and so has much more stringent regulatory requirements for security, and because of these requirements, their IT security hasn’t cleared the new forum for release yet due to unforseen issues with the security of the new forums.

This is really sub-adequate, for at least four major reasons:

  1. This explanation happened on May 26 — the GMC forums went offline on April 8, with a promise to return in about two weeks, which would have been April 22. So this explanation is over a month late.
  2. The explanation is buried on a subreddit, not on the front page of yoyogames.com, or even on the front page of gmc.yoyogames.com, where it belongs.
  3. Someone had to ask what was going on. Didn’t it occur to anyone at YYG that the community would want to know what was going on with its forum, and that they should proactively communicate what’s been going on? YYG seem to have completely disregarded the importance of the community of active users who support their business.
  4. The explanation reveals that they weren’t prepared to perform the transition, and did not plan adequately. Good IT practice says that:
    • There should have been a rollback plan in case the deployment couldn’t happen as planned.
    • The gap between the old forum going readonly to the new forum going live should have been minimal. Even the planned two weeks of no GMC forum was far from optimal. There really isn’t any good reason why the old forums should have gone readonly until after the new forum was up and running.
    • You should understand your security posture and ensure requirements are met before you start deploying a new system. During deployment is not the time to start testing the security of your new system!

It sounds like YYG went about the transition thinking that it wouldn’t be a big deal to make changes live on the production server, and midway through PlayTech caught wind of what was going on, at which point their IT Security department said, “Hold up, just what are you doing? Oh, hell no.” And since then, they’ve been stuck trying to comply with whatever PlayTech IT Security’s requirements are. And this has been going on for two months now, with no announcement or explanation in the most obvious place to make announcements, and no end in sight, and no rollback. GMC forum users are without a forum that they can post discussion on.

There’s no way you can convince me that “it’s all for the best” or “this was the way it had to be” or “this was the best we could do under the circumstances.” It’s a disaster born of mismanagement, poor planning, and poor communication. It harms the community of customers, and it harms YoYo’s reputation.

I highly, highly doubt that since the PlayTech acquisition that the YoYoGames web servers were integrated into PlayTech’s infrastructure in such a way that a security compromise in the GMC would have any impact to PlayTech’s compliance with any gambling regulatory concerns.

Absolutely, YYG should be implementing a secure web forum to replace the old GMC. But they should have had an acceptably secure solution ready before they went to deploy it.

You can bet if the GMC forums were directly generating revenue for YYG, this would never have been allowed to happen. But YYG seem oblivious to the fact that the community of GameMaker users is the lifeblood of their company, and that trust in YYG is essential. Users do not become customers without faith in the vendor.

Next, in response to my question of why YYG haven’t fixed the performance issues in My Library for over a year, Shaun’s response was that they have a small team and struggle with prioritizing fixing existing stuff and delivering new stuff.

I don’t doubt that. However, nothing about that admission inspires confidence. It generates a little sympathy, perhaps, but I can’t build video games with sympathy.

Here’s what’s wrong with Shaun’s response:

  1. Having been acquired by a larger company, YYG should have resources to hire additional staff to get to these tasks.
  2. YYG project managers need to assess the capability of their team and release only what they can maintain.
  3. The Marketplace is a major new feature. Releasing a beta, and then not continuing to develop it is not the right way to do a beta. Beta releases should be actively developed, and given priority. The purpose of doing a beta release is to allow the users an opportunity to use the solution, and provide feedback that can be used to improve it prior to the official release. Failing to act on feedback about the beta defeats the entire purpose of releasing it. Labeling something “beta” is not an excuse for poor quality.
  4. The workaround solution offered by YYG limits the number of assets a user can effectively own. Any defect that limits or discourages users from purchasing assets in the Marketplace should be considered a critical bug and given top priority. The whole purpose of the Marketplace is to generate sales of the assets sold there.  Anything that discourages or limits the number of assets a user of the Marketplace can own is a top priority problem. Imagine if Amazon had a bug whereby every time you buy something from them, it makes the amazon user experience slow down, eventually preventing people from using anything they bought from them. What priority do you think Amazon would give to fixing that problem? Do you think the fix would be to advise customers to not buy so many things that it hurts performance, where “so many” is a number that can be represented in 7 bits?
  5. The performance problem of My Library is embarrassing. YYG should prioritize fixing it out of pride. Or shame. Either way. There’s no way a computer built after 1977 should have a problem managing a list of 100 items! Even an Apple ][ should be able to generate the list in under a second. Whatever is wrong with the code in My Library that causes this performance degradation, it is very, very wrong. No matter how bad Delphi is, surely it was always capable of managing a list of 100 items in a few milliseconds. It shouldn’t take a 2.0 GHz Core 2 Duo with 8 GB of RAM 11 minutes to populate the list! It shouldn’t take another 11 minutes each and every time the list needs to be refreshed!
  6. If your team is hard pressed to balance fixing current issues vs. building future solutions, your team needs to stop working on building future solutions immediately, and start fixing problems until you’re free enough of technical debt that you can advance while maintaining what you’ve released. Ideally, fixing problems can be accomplished by releasing the future solution. Get off the Delphi codebase and work on releasing a clean, maintainable rewrite. But don’t introduce more new features that you can’t support until you’ve gotten a handle on supporting what you’ve already released. If Delphi makes development difficult, stop using it.

My conversation with Shaun ended before we could get very deep into these points, so I don’t mean to bury him before he’s had a chance to address things, and I hope to hear more from him or others at YYG about how they intend to address these problems. But the response that I’ve seen so far haven’t been what I’d hope to hear, and do not inspire confidence.

I sincerely hope that YYG can turn things around and give its customers the GameMaker they deserve. But how they can accomplish this, given what they’ve shown lately, I don’t know. Getting the new GMC Forums up and running as soon as possible has got to be a top priority for them. Addressing the performance problems with My Library for “large” manifests has got to be a top priority for them. Releasing GM:S 1.5 or GM:Next, and getting off of the Delphi codebase that has given them so much technical debt has got to be a top priority for them. YYG need to understand what’s important to their users, and act to deliver the most important things. They used to do pretty good at this, prior to being bought by PlayTech. They need to get back to that, right away.

GameMaker: Exodus

business, development, games, programming, reviews
Comments

I’ve been doing game dev programming in GameMaker since 2010, and lately I’ve been feeling rather frustrated by the pace with which they’ve been improving the tool. Since being bought by PlayTech in February 2015, YoYoGames seem to have hit a brick wall.

Languishing, poor quality betas of (potentially) exciting new features

The GameMaker Marketplace debuted almost two years ago. Today, it is still in Beta. Much worse than that, there has not been any substantial development in the Marketplace website, or the integration with the GM:S IDE, in about the last year-plus.

There’s been a long-standing bug with their marketplace integration, when you have purchased a “large” number of assets from the Marketplace, the interface for managing them bogs down and becomes nearly unusable. I reported this defect, a year ago, and YoYo have acknowledged the problem, but done nothing to address it in a meaningful way, other than to warn users not to buy too many marketplace assets. That’s right: YoYoGames built a store for its users to sell assets they’ve made to each other, and then told them not to buy too many assets.

The interface for My Library is terrible — very basic, and lacking in features to allow you to organize the assets you’ve purchased. The performance problem especially is infuriating, and makes the My Library feature basically useless. I offered some ideas for improving the My Library interface on the GMC Suggestions sub-forum, which is now unavailable — apparently YYG have done more in “archiving” the old forums than simply setting them to readonly. [Internet Archive snapshot of the forum thread.]

YoYo acknowledged the problem, but rather than fixing the performance problem, they recommend a workaround of disabling assets from your purchase manifest, until the number of purchased assets is at a number that GM:S can manage without choking. That is, YoYo recommend that you disable assets that you’ve purchased through the Marketplace store, until you’ve disabled however many assets you may need to get below a number that their terrible interface can manage. We’re talking modern computers with billions of bytes of memory and multi-core gigahertz processors, choking on a list of perhaps 75-125 assets. It’s an embarrassment, and the worst part of it is that it discourages users from purchasing more assets from the marketplace, or using them.

None of this has stopped YYG from taking 30% of sellers’ revenue from Marketplace sales. In many cases, sellers are building assets which provide features and functionality that YYG should have developed themselves. For example, GameMaker 8.x used to have something called Room Transitions, which gave a neat visual transition when switching between one room and other. These were implemented in a way that took advantage of native Windows system calls, and couldn’t be supported on other build targets easily, so rather than re-implementing them in a cross-platform way so that all build platforms could make use of them, the room transition functions were deprecated and removed from GM:S.

Developers were told to write their own room transition code, and not expect the built-in transitions to return in any future updates. A few enterprising GM:S users have done so, and now sell room transitions asset packs through the Marketplace. The result of this is that a feature once included in GM:S now a separate add-on that you have to pay for. Except YYG don’t have to pay the developer anything for the work, and instead take a 30% cut of the developer’s income. This makes the Marketplace a very cheap way to outsource development that should be happening in the core product, not as aftermarket add-ons.

Of course there’s also a lot of assets for sale in the Marketplace that are free, and/or do things that are useful but should not be core engine features. The Marketplace was a great idea, and has a lot of promise, but has languished since the PlayTech acquisition.

Hamstrung by legacy cruft

YYG have been stuck with an old, crufty codebase written in Delphi C for the main IDE, and haven’t gotten off of it in 4 years. They always blame the old codebase for why they can’t deliver new features to the IDE, and promise to consider ideas for new features in “GM: Next”. They had made excellent progress in the first 2-3 years, focusing first on improving the performance of games built with GameMaker by introducing the YoYo compiler and runtime, porting those to modern C++, and incorporating exciting new features like Box2D Physics and Shaders into the old IDE. But since then, we haven’t seen much. GM:S 1.4 was released in late 2014. The PlayTech acquisition was announced a few months later in early 2015. Before the acquisition, we had a major update about once a year: Since the acquisition, YoYo have only released minor bugfix updates to 1.4. The biggest missing deliverable by far is the replacement of the old IDE with something modern and coded in a more maintainable way. The old Delphi codebase has left them hobbled, unable to deliver new features, and having to work harder than they should have to to add simple enhancements and fix bugs in the old.

In the meantime, a third-party IDE for GameMaker has been offered by at least two different groups. Parakeet and Enigma are the effort of frustrated GameMaker users who got sick of waiting for an official rewrite of the GM:S IDE, and took matters into their own hands and built their own. While it’s good to have alternatives, these are precariously positioned as GameMaker is closed source and any third party efforts such as these are prone to breaking if YYG change the way GameMaker works.

Promises undelivered and unfulfilled

“GM: Next” feels more and more like vaporware as time goes on. There’s no timetable for its release any longer; YYG have actually withdrawn their old roadmap that charted out their plans for the future so you could know what features might be coming and when.

The last straw has been this failure of the migration from the old GameMaker Community Forum software to a replacement running something with better security and features. They put the old forums in readonly mode in early April and promised the new forum in a couple weeks, which was itself a pretty headdesk move on their part, since there’s no reason why there should have been any downtime — archive the old forum only once the new forum is up and running, ready to launch.

But, almost 2 months later, they still have yet to deliver the promised replacement forum. Inexcusably, they’ve been all but silent on the matter. No apology for taking so long, no explanation of why it’s been taking way longer than expected, no revised ETA on the new forums. I’ve seen one tweet from a YYG source saying that they don’t know when it will happen, and they’re sorry but their “hands are tied” — presumably by PlayTech.

Shaun Spalding of YoYoGames commenting on the delinquent GMC forum upgrade.

Acquisition: What is it good for? Absolutely Nothing!

Say it again!

When the PlayTech acquisition happened, I expressed some concern but optimistically said I’d take a wait and see approach before judging whether it was a good thing or not. It’s pretty clear by now that it’s been a very bad thing.

It’s been my experience from watching small companies get gobbled up by large companies again and again that it’s almost always a bad thing for the small company and those who care about what it does. A small, successful company has drive, passion, and vision. A large company wants to secure its position and diversify its risk, and cares more about maintaining the status quo and staying on top than it does about disruption and shaking things up. When a large company buys out a small company, they say the same thing every time: “We’re not going to change a thing. We’re not going to risk disrupting what’s been working so well. We want to get on board and help them succeed to even greater heights.” It’s almost always a bunch of happytalk to put customers at ease and give investors a warm fuzzy feeling.

But what really happens is the small company totally gets disrupted. There’s usually a round of rebranding that happens, and the small company is paralyzed by Find/Replacing $OLDNAME to $NEWNAME, to no actual productive gain. Then there’s another round of aligning the small company’s goals to the greater strategic vision of the big company, at which point anything interesting or cool that the small company was working on gets squashed or distorted. Oftentimes the best people who made the small company great leave, pockets flush with money from the boost in the stock price from the buyout, in order to pursue other opportunities, where they can remain nimble and free to innovate without all the dead weight overhead from the large company. Products and services shift in ways that alienate former customers, the operation hemorrhages money, customers, and employees for a time, and eventually the burning dirigible crashes to the ground. Oh, the humanity.

That’s what usually — almost always — happens. I don’t know that that’s what’s happened with YoYoGames, but I’ve seen it happen time and again with countless small companies in all kinds of fields.

There’s still a lot of things I like about GameMaker: its simplicity, it’s easy learning curve, the speed with which an demo can be built. I still think it has a great deal of potential for a bright future, but I fear that PlayTech have squandered it for much of the last year. The acquisition has caused YoYo to fumble badly, and from what I’ve seen so far, I have little hope for a turnaround.

Unfortunately, for a proprietary tool a fumble like this is generally fatal. Around the time I got into GameMaker, there was another popular tool, called Torque, that was a bit more sophisticated, and went through a similar ownership transition and died shortly thereafter, to be reborn as a MIT licensed open source project. I guess it’s technically still around, but exist today largely as an afterthought. This situation is starting to feel eerily similar. Although… if GameMaker were to be open-sourced, that would be one of the best possible outcomes of the current situation. YoYoGames have stated on many occasions that this will never, ever happen, though.

Another door opens

For the last two years, I have also been watching an open-source project, called Godot. Godot is a 2D and 3D game engine with many features comparable to GameMaker, but is all modern and open source, and as of this writing is now at version 2.0. The development environment for Godot runs not only on Windows, but on Mac OS X and Linux as well. It looks really good, and I am planning to use it for my next project.

I’m very excited by this. If it works well, and I like it, I will be able to say goodbye to Microsoft, finally, and after the debacle of Windows UpdateRape, forcing users to upgrade to Windows 10 without their affirmative and informed consent, the timing couldn’t be better for me. GameMaker: Studio was the last proprietary Windows-only application that was keeping me on the Windows desktop platform, and I had been hoping that GM:Next might allow me to run GameMaker on Linux, but with Godot I may not have to wait to see if that day ever comes anymore.

I won’t be surprised in a few weeks time if I am kicking myself for not making the transition sooner.

[Update: be sure to read the follow-up post]

YoYoGames’ GameMaker Community Forums seemingly in limbo; promised upgrade overdue more than 2 weeks

development, games
5 Comments

Back in April, I posted about an upcoming transition with the GameMaker Community Forums. YoYoGames had announced that they were going to start a new forum, move off of IPBoard as its forum software, and give the community something fresh and modern that would be better. The old forums were to briefly become unavailable, and then would be restored in a read-only format, to preserve the history and knowledge they contain.

This was to have taken about two weeks. It’s over a month later now, and we still haven’t seen a new GMC forum. The old forums have been archived, and are available now at gmc.yoyogames.com, after being completely offline for over two weeks. YYG have not spoken much about the new forums since they announced their original plan, which has left me wondering what’s going on.

At this point, it’s difficult to characterize the transition as anything but a failure. But as to why the failure, and when things will be coming back, we’re left to speculate. I will, however, offer a few criticisms:

Archiving the old forums should have taken place instantly, not taken more than two weeks

I don’t have any insider information to justify why the transition from an active state to a read-only, logins disabled state took more than two weeks to accomplish, and I’ve never managed an IP board site before, but for this to require the site be completely offline for more than two weeks, it must have been quite a broken implementation design. It should have been very simple, and possible to achieve nearly instantaneously: disable login for non-administrator accounts. Demote non-essential administrator accounts, such that only YYG Staff directly involved in the forum migration can still log in and manage things.

Boom. Done. No one can post anymore; the site is in a read-only state for all users but the administrators. No downtime need be incurred.

So why did this take more than two weeks? I’d love to know.

Taking the old forum down should not have been done until the new forum was ready to go

Again, I don’t know why YYG did things the way they did, and it’s possible there’s reasonable explanations for it, but I just can’t imagine any. Normally, web development is done by having a production environment, which is the live web site exposed to the world, and a development environment, which is accessible to developers and operations folks. Development takes place in the development environment until all systems are go, at which point the site is migrated to the production server. Normally this migration is something that can be accomplished within minutes, or seconds. It might well take weeks or months to get to the point where the migration is ready to happen, but the actual migration doesn’t have to take longer than a few minutes if planned properly, unless the migration is truly massive, which I cannot imagine the GMC forums new software qualifying, since they had announced that the new forums would start off empty. I understand they need time to test and configure the new forum software, test it for security vulnerabilities, and so forth but all of that could have been — and should have — been done in a test environment well before the old forums were taken down.

Remaining quiet when previously-announced deadlines slipped disrespects GM:S users

When it became apparent that the transition was not happening according to plan, and this impacted the publicly announced timetable, someone at YYG should have handled communicating the news to the user community. To date, I have not seen any announcements explaining what’s going on. No explanation of why the release date has slipped, no announcement of a new date. Even if they have no idea how long it will be, there should have been some kind of communication. Without this, it creates an impression that YYG does not value the forums or the community that uses it. This is surely not true, but the lack of transparency here is inexplicable and harms YYG’s reputation. Considering the huge efforts they had made over the last 5 years with branding GameMaker: Studio as a professional-caliber development tool, and making numerous improvements to give that branding credibility, this is a serious stumble on their part.

Because of these failures, GameMaker users have been left without an official community for over a month, and have had to make do with alternatives such as gamedev.net, Reddit and Facebook. This can’t be good for YoYoGames’ reputation or the GameMaker brand. The community’s self-support for GameMaker has long been one of it’s greatest assets, and YoYoGames seems to be acting as though they do not understand this. I only hope that they can fix whatever problems have been preventing them from moving forward and complete the release of the new forums.

Ludum Dare 35

development, games
Comments

Ludum Dare 35 happened a weekend ago, and although I published a postmortem on my LD48 blog, I haven’t posted here about it.

The theme for this one was Shapeshift. The first idea I had was to do a game that played like the arcade classic Asteroids, but where your ship’s shape would shift according to its state. I did a quick proof of concept Friday night, where the ship stretched under acceleration, and while it was a pretty cool effect, it wasn’t really something that made the game better or more interesting than the original. By late Friday I was convinced I was on the wrong track, and should start over with something else, but wasn’t sure what.

Saturday morning, I woke up and briefly considered just giving up my efforts for the weekend, and working on other stuff with my weekend time. In the afternoon I attended a Cleveland Game Developers “Excuse to Create” event, and started over with a new project. In the morning, I’d thought about another arcade classic, Robotron 2084, and I started getting interested in making a twin-stick arena shooter. In part I was spurred by the discovery that the keyboard for my new Lenovo ThinkPad P50 laptop has poor rollover characteristics, which make playing games on it all but impossible. I started building it at Excuse to Create and by the end of the 3 hour session I knew that I was on the right track. What I ended up with was much closer to a Geometry Wars clone than I had originally wanted, but it plays pretty well and I had fun making it.

I would have preferred to come up with a more original concept than that, but oh well. It’s not an attempt at a straight up clone of Geometry Wars, but more of a knock-off. The shape-shift theme comes into play with the target shapes, which “lose a side” when shot and shift into the (N-1)th sided polygon. This gives the larger shapes a kind of “hit points” which makes them take several hits to completely destroy. I thought that would be a novel enough twist, but in practice it plays feels about the same as the original Geometry Wars.

Along the way I learned a few things, all of which are game design rather than programming lessons.

  1. At one point in my development, I had the power-up items be vulnerable to the player’s shots, and also if the player shot a power-up item, they would lose one level of that power-up. This would have made the game a lot different from Geometry Wars, where it’s safe to shoot indiscriminately because your shot has no bad effects in that game. I had hoped that this change would make my game more about aiming and looking where you are shooting, and being careful. But in testing, it just made the game too difficult. As the difficulty of the game ramps up, it becomes a frenetic twitch game where you mostly dodge and run away from a swarm of shapes that are following you, and there’s not really any opportunity to be selective about when you’re shooting or where you’re aiming, and if you do lose a level of power-up, it’s pretty much instantly lethal.
  2. Spawn location matters. I knew that I needed to spawn enemies far enough away from the player that they would not be prone to crashing into a newly spawned instance that appeared directly in their path, leading to unfair death. But I also learned that spawning near the edge of the view makes the game seem more active, and puts more instances in view especially in the opening seconds of the game, when there are few objects and the pace of the game is slow. The compo release has enemies spawning randomly anywhere in the room, and as a result feels much more sparse and too slow during the opening.
  3. Code mistakes can be fun! My original code for spawning a swarm of enemies accidentally placed them all in the exact same location. Since the movement of the enemies is purely deterministic, this resulted in a “stack” of enemies all piled up on top of each other, looking like a single instance. When shot, instead of destroying the entire stack, the bullet would only destroy the first instance in the stack, and the rest of the stack would continue to advance, looking to the player as though a early-invincible “super shape” that took a great many shots to destroy was inexorably running the player down, and the player’s shots merely chipped off lesser shapes, which then joined in the attack. I liked the effect so much that after fixing the swarm spawn code in the compo release, re-added a toned-down version of this to the post-compo branch.

In looking back over my Ludum Dare games, I’ve come to realize that I’ve felt overly negative about my performance in LD48. I do have high standards for what I think makes a good game, and so naturally I feel disappointed if my efforts fall short of that mark. In my first few events, I was happy just to have proven to myself that I could build something playable in under 48 hours. In later events, I became disappointed that my abilities didn’t improve as fast as I wished they would. And, really, unless I take game development as a full-time occupation, it’d be hard to improve as fast as I would like. But perhaps an even greater sense of frustration has come from my inability to come up with a good idea for a game — or rather, a good idea that I could complete with my abilities in 48 hours that fit the announced theme. Particularly after the submission deadline, when I’d see so many good games produced by others. But if I focus on the 8 games that I did complete, rather than the 6 LD48 events I didn’t submit for, I’m able to view my work more positively. In the immediate aftermath of the event, I would always feel a certain amount of frustration and disappointment in some aspect of the game I’d made — some feature I struggled too much with implementing, some stupid bug that I got stuck on that took too much time to fix, some feature I had to drop for lack of time, something that was missing, but I couldn’t figure out what it was that the game needed, or something that just wasn’t quite right. But looking at what I have produced, there are some good ideas in six of the projects, and I’m happy about that.

>>> Play Shape Struggle <<<