Tag: YoYoGames

Thoughts on the GameMaker Marketplace experience so far

business, games
2 Comments

GameMaker Marketplace has been available to Early Access users for a little over a month now. I think it’s a good time to talk about the experience.

I first heard about the Marketplace in July 2nd, and was very excited by the prospect.

I got to work on putting an account together and developing my first product. I put my first store asset, mmap mini maps, up on 7/20, priced at $4.99. I wasn’t sure what to price it at, but considering the amount of hours that I put into it, for someone needing a mini map for their game this would save them dozens of hours, and time is money so it seems like a very good value. So far it has sold only one copy, but I’m still happy to have made my first dollar.

It’d be easy to feel disappointed, but I’m not surprised, really. I’ll download anything that looks interesting for free, but the moment you put a price tag on something I hesitate. Unless I have an immediate need, and unless I know for a fact that this asset will work for my need, and I don’t feel like I can build it myself easily, I’m unlikely to pay for something. And I don’t think other developers are too different in that regard.

Winds of change

With the announcement of the Marketplace, one worry I had is that it could have a chilling effect on the GameMaker Community, in that people won’t be as open with sharing their code as they were prior to the Marketplace launch. So far I don’t see that happening, but it’s still early.

It does take quite a bit of effort to take something from a quick example on a forum post to a full-blown product, so I expect the forums will continue to be a place where people share code with each other, and perhaps the best things from the community forums will get developed further into commercial-quality assets for the marketplace. That would be good.

On the other hand, if everyone thinks that their code is valuable and that they can make money from it, maybe they won’t want to share it in the community forums, lest someone else “steal” the code and turn it into an asset before them, and try to make money off of it. Money/greed serves as a disincentive to community cohesion. So rather than put the idea out there at all, and get vital feedback from the community that it’s desired, or how to improve it, the greedy dev builds it in secret, and uploads a product to the marketplace that is inferior to what it could have been had the community collaborated on it openly. That would be bad.

People are very giving and friendly when they see the value of helping each other by sharing what they know, and I generally find this value to be greater than that of money. The $3.50 that I’ve earned by my one sale so far of mmap mini maps isn’t going to make a great difference in my life. But if I think about all the code that has been shared on the GMC forums that I’ve learned from, that has made an amazing difference. The knowledge I’ve gained from hundreds of hours I’ve spent on the forums is a treasure. The $3.50 I gained from perhaps a hundred hours of developing mmap is a pint of beer. The experience I gained from writing it is worth far more than the money I’ve earned from it. Putting a price on some things devalues them.

Nickeled and Dimed

The other worry that I have had about the Marketplace is that these assets will end up costing more and more in the long run. Not in terms of prices going up for individual downloads, but from the aggregate total of all the little things that cost $1-2. The cost of a GameMaker license has always been a good value. GM:S provides a very good basic framework for game development, but now in addition to that cost, there’s all these asset packs that we might “need” to buy in order to have features that a game developer “must have” in order to make a pro-quality game. Don’t such features belong in the core product? Some of them, at least?

And, if YYG does decide to incorporate features that were first implemented in some very popular marketplace asset, what then? I imagine the asset’s developer will feel as though they were effectively working for YYG for very, very cheap, and may not appreciate their revenue maker becoming redundant. YYG will have to take care not to alienate developers, perhaps by licensing/buying the the rights to well-developed assets that they wish to incorporate into the core product.

I really want to see the core GM:S product contain all the features that I need to build a high quality game easily — not to have to buy the core product, and then accessorize it with endless add-ons that individually cost $1-2, but in aggregate end up costing as much or more than Studio itself.

Healthy ecosystems should support a healthy core

Another problem I foresee is that all of these “accessory” assets will be of varying levels of quality, will not be maintained by their developers forever, will not be designed to work with each other, will not offer as fast performance due to being programmed in GML rather than C++, etc. What the marketplace does is multiply the number of developers who are developing (extending) GM:S. By doing so, what we collectively risk is that our efforts will be chaotic, and unmanaged, resulting in a lot of waste, poorer overall quality, and all the other things a lack of good management causes.

I’ve seen this with the WordPress ecosystem, as well. Themes and Plug-ins become abandoned, whether due to unpopularity, developer disinterest, or whatever, and the sites that use them end up stuck on some old, outdated version, looking for a suitable replacement. The WordPress ecosystem overall is healthy, vibrant, successful, due to its large userbase, but there are an awful lot of plug-ins that I’ve had to stop using because the developer quit supporting it. Fortunately, I’ve always been able to find a replacement when I’ve needed to, but it does become a pain to have to select from among a number of popular plugins, which is the best fit for me, and then make sure that it integrates well with everything else on my site.

This makes me think that a better way to have a large scale community of developers contribute to a code ecosystem is the open source model. It’s a very different business model from the one YYG currently develops GM:S under, and YYG has stated many times that they will never open-source GameMaker, but be that as it may, imagine if the IDE, the runner, and the GML language itself were open-sourced so that the community of developers could commit code to the core product, rather than be limited to extending it and creating reusable assets for projects. Granted, the vast majority of GameMaker users probably aren’t competent C++ programmers. So the idea isn’t particularly workable.

But the idea that the best Marketplace assets should somehow make it into the core product is one that has great appeal to me. Perhaps “best of Marketplace” value bundles could be converted to native code, merged and integrated into the core GM:S product, and sold as +$99 add-ons for Professional, or part of the Master Collection suite, the revenue from which would be shared among the contributors. I’d love to see a “Best of Social Media”, “Best of IAP”, “Best of Advertising”, “Best of Analytics”, “Best of Physics”, “Best of 2D Platforming” collection arise in a few months or years. That could be really cool.

The value proposition: saved time vs. lost expertise

You don’t have to buy Marketplace assets, of course, since you can still develop your own projects, but now we have a dilemma to consider: develop from scratch at the cost of your own time, or save time by spending money to buy a ready-made asset? Most of the time, the time saved by buying a reasonably-priced asset from the Marketplace will be more valuable than the money spent for the asset.

But which is truly the more costly option? Buying the asset pack gets you the feature now, so you’re buying time. You can also buy things that are beyond your capability or understanding, which is a great value since it enables you to do things you couldn’t otherwise figure out how to do. And you’re probably buying quality, assuming that the developer of the asset pack has been at it longer than you, and is doing it better than you would have, although this is not guaranteed.

But then you have to spend time to integrate the asset pack into your product, and learn how it works, possibly modify or extend it in order to work how you need it to for your game, maybe even debug it… does it really save you as much time? Maybe not as much as it seems at first.

And on the other hand, by rolling your own features, you gain valuable experience and expertise, you understand the problem and the solution much better than you would if you simply bolted on an asset pack that does it for you without having to engage mentally and solve the problem. In a way, buying an asset from the Marketplace is like paying someone else to go to the gym and work out for you. The weight still gets lifted, and you save the time so you can spend it on other things, but at the end of the workout you don’t have the muscles. And, lacking those muscles, it leaves you less able to lift more weight that you need to lift. This value that is lost from buying assets is the most important value of all.

On the other hand, you may be able to make gains by studying that code that you purchased, particularly code that solves a problem that you had no idea how to solve yourself, or does so in such a way that you might never have thought of yourself.

Above all, you gain unique flavor and style from doing things your way. If everyone uses the same sprites, or tiles, or code, everyone’s games will end up feeling more generic, standardized, commoditized. For works of art, this is not desirable. Hand crafted resources give a project personality, quirks, and uniqueness.

In any case, the Marketplace is come, and with it, whatever consequences will come with it. It’s a new era for GameMaker: Studio users, and one filled with opportunities limited only by what we can imagine.

Latest Google Chrome changes break HTML5 applications built with GameMaker: Studio

development, games
Comments

Users who browse this site with Google Chrome will have noticed that the HTML5 demos and games that I have built in GameMaker no longer work in the latest version of Chrome. I became aware of this fairly recently, but until yesterday I had hoped that it was just a problem with the configuration of my primary computer, as the problem did not seem to be evident on my other computer that I do testing with. Unfortunately, after updating that computer to the latest build of Chrome, I found that the problem is more widespread.

This thread on the GMC forums explains what to do if you’re a programmer who has an HTML5 game that needs to be patched in order to fix it with the latest Chrome. I have yet to try this on my own games, but will be experimenting in the near future. Presumably, YoYoGames will be updating the GameMaker: Studio build for HTML5 to rectify the problem in an upcoming release, and once done, re-building the game will also fix the issue.

Mmap 1.0 released

games
Comments

Mmap is a GameMaker asset pack that provides powerful, flexible, easy to use mini map functionality.

MMapIcon200x200

Features:

  • Easy to use, Beautifully coded! Source code thoroughly documented, very easy to understand, modifiable.
  • Great performance.
    • 2000-4000 mappable instances in HTML5
    • 10000+ mappable instances in Windows (YYC).
  • oMmap object
  • oMappable parent object
  • Four types of mmap:
    • Basic
    • Radar
    • Sonar
    • Static
  • Identify Friend-or-Foe (IFF) color code system
  • Fully customizable!
    • colors
    • alpha transparency
    • screen size
    • detection range
    • zoomable
    • refresh rate
    • blip tracking
  • Tested on Windows, Windows (YYC), and HTML5 builds

Live Demo in HTML5

Documentation

Buy it at the GameMaker Marketplace

YoYoGames launches Marketplace (early access)

business, development, games
Comments

YoYoGames has opened its new marketplace to early adopters. Now is the best time to get a product up, as there’s not much competition right now.

It seems the going price for most things is $.99-1.99. Some things are free, and larger products cost more. It seems that the marketplace is currently geared toward selling singular assets a la carte, rather than larger bundles and collections. I’d like to see the sellers create bundles for certain types of assets, rather than try to nickel and dime their way to maximized revenue. I’m also curious to see if the marketplace will allow sellers to use a “choose your price” model a la the Humble Store.

All sorts of assets are available, from graphics, sounds, and fonts, to shaders, scripts, and extensions. Not every category offers something yet, but I expect this to blow up quickly as developers rush to market.

I have some mixed feelings about this, but overall it’s a positive development. On the positive side, it enables GameMaker developers to see their work to each other, which should encourage the aspiring professional by providing a way to make money and an incentive to produce. On the negative side, I’m not sure that the community needs such an incentive — there’s a huge amount of freely available stuff that has been openly shared in the GameMaker Community. Creating a marketplace will tend to introduce greed and cause developers to guard their secrets, or at least want to be compensated for sharing them. In the long run, this could prove more detrimental than beneficial.

Could a build farm be coming to GameMaker Studio?

business, development, games
2 Comments

Interesting.

Earlier today, I posted an idea I had to the GameMaker Community Forums Suggestions board: for YoYo Games to provide a Build Farm service to GameMaker: Studio users who would like to build their games for platforms that they do not own.

Currently, while GameMaker: Studio enables users to build to multiple platforms, certain of those platforms have fairly steep requirements in terms of a physical device to connect to in order to build, and even membership in developer programs. Maintaining all these devices and memberships is prohibitively expensive for anyone who isn’t making a living by doing it.

Providing a Software as a Service model for building to remote cloud-hosted virtual devices that are configured and maintained by YYG themselves would greatly simplify the effort required to build to non-Win32 platforms, making it far easier for GameMaker Studio users to reach all of the platforms that GM:S allows them to reach. Suddenly, it becomes feasible for a solo developer studio to release a game on all platforms without having to own a Mac, an iPad, an Android device, etc.

Further, I suggested that once the build farm was up and running, the next logical step would be to allow developers to submit their newly-built games to various App Stores for whatever target they have built to, enabling GM:S users to bring their games to market far more easily. YoYo Games could have their own store, and GM:S users who have accounts with other app stores could connect their accounts to their YYG Store account, which would enable them to submit their games to the other stores very easily.

Shortly after posting my idea, YYG CTO Russell Kay commented “Squirrel!” — which, apparently, means that I’ve suggested something that YYG has plans to do.

I’m not sure how much of the above ideas they are working on, or how closely what they are working on will resemble what I’ve outlined above, but it’s extremely exciting to think that this may be coming at some point in the indefinite future.

Anything that makes it easier and cheaper for a game developer to bring their products to market — without having to handle all the other aspects of running a business — makes it possible for small studios to compete and do business and make money without having to grow and support a full staff in order to handle these functions internally.

GameMaker Studio Standard now Free

development, games
Comments

Today YoYoGames announced that they are discontinuing the much-derided free edition of GameMaker Studio, GM:S Lite. In its place, GameMaker Studio Standard is now free. Previously, Standard was $49, but often discounted to free for special promotions. The Lite edition was not favored by users for being too limited in features and resource constraints.

This is a good move for YYG, as it serves to strengthen their position among neophyte developers who want a first tool they can use for free. GameMaker has long been a “gateway drug” for many indie game developers and programmers, and making a free version that is actually useful will continue to ensure that new users will have little reason not to give it a try.

Their official announcement is copied below:

YoYo Games Ltd.

Today, YoYo Games announces that a powerful version of GameMaker: Studio is now available to developers for FREE. We’ve taken the resource-limited “Free” version of GameMaker: Studio and replaced it with a feature-rich version of GameMaker: Studio called “Standard.” The newly launched GameMaker: Studio Standard puts the full power of GameMaker: Studio at the fingertips of games developers everywhere!

If the cost of GameMaker: Studio was holding you back before, there isn’t anything holding you back now.

For more info, visit https://www.yoyogames.com/studio.

Game on!

New GML variable scope rules will break old code

development, programming, reviews
9 Comments

[Update: Please read the comments from YoYoGames CTO Russell Kay, at the bottom of this article. As it turns out, the implications of the changes that I expressed concerns about in this article were overblown. The YoYoGames tech blog article that caused my concerns wasn’t clear enough in describing them, resulting in my misunderstanding of the severity of the changes.]

Today’s YoYoGames tech blog deals with GML variable scope rules. I was dismayed to read that they are changing the scoping rules, which will result in old code breaking.

I’m normally very supportive of the decisions YYG has made with the development of GameMaker, particularly in the GM:S era, but this is probably the single worst thing that I’ve read about the development of GameMaker since I started using it in 2010.

I have a lot to say about this. First, I’d like to address the specific changes. Then I’ll talk a bit on the philosophy of how I would like YYG to treat me as a developer who relies on their tools.

(more…)

Looking forward to GameMaker Studio 1.3

development
Comments

There’s been a lot of news coming out of YoYoGames lately about the upcoming release of GameMaker Studio 1.3. They’re delivering a lot of new features that have me excited.

From the official roadmap:

Version 1.3

Debugger

Rewrite of the GameMaker debugger to include full source level debugging, break points and watch windows. Will also target cross platform support, allowing remote debugging of Mac, Android and iOS devices.

I really like that they’re delivering an improved debugger with breakpoints and watched variables. This is something that is frankly long overdue, the functionality that was provided in the current debugger would be considered barely adequate compared to what’s been offered in other IDEs for at least the last 10-15 years.

On the other hand, I credit the lack of a decent debugger in GameMaker for making me a better programmer by teaching me not to over-rely on a step-through debugger to understand my code.

Because I lacked a proper debugger, I learned to build myself a logging system. Because I lacked watch variables, I learned to draw the values of variables I wanted to read to the screen, next to the instance.

It turns out, when you have a game with a lot of objects, all of which are updated in a loop that runs at 30 iterations per second, stepping through your code to see what’s going on must be extremely slow and tedious. I am not sure how much use I’ll get out of a debugger — I’m sure there’s times where it’ll still come in handy for me, but for me, logging and drawing variable state to the screen so I can continue to run the game at realtime and see what’s going on faster will likely be more valuable to me.

One highly valuable programmer’s tool that I’d love to see added to GameMaker Studio in the future is unit testing. Programming benefits from unit testing by proving that existing functionality still works as intended when new code is added or existing code is modified. It can accelerate development by reducing the time it takes to find bugs, immediately identify when they are introduced, understand the scope of their effect, and so on. I don’t believe that unit testing can help prove whether a game design is fun, but it is very valuable to proving that code is correct. I’d rather spend my time in GameMaker playing with design experiments, not trying to figure out why something I coded doesn’t quite work like I thought it should, and if I could write unit tests for my GML code and use them, that would be a huge win.

Extensions

Windows and HTML5 already allow custom extensions, so this will add them to iOS and Android.

As I understand it from what I’ve read elsewhere, this means native code extensions. So far, I’ve done a little bit of work in creating extensions for my projects, and all of that has been done in GML, at first because that was the only thing I was comfortable writing them in, and then later because I wanted my extensions to be usable no matter what platform I was targeting. Being able to write extensions in other platforms that are native to the platform will mean substantial performance boosts, and the capability of leveraging existing code libraries, and potentially even entire engines or frameworks. This is great because it means a lot of existing functions are soon to become available to GM:S projects, and won’t require a lot of re-invention of the wheel. Instead, developers can just glue existing wheels written in other languages onto their GM:S projects.

The only downside to this is that I fear this will turn into an excuse not to implement language features in GML, when it comes to future development of the GML language and the GameMaker framework. “Why bother implementing [requested feature], it already exists in [other language], so just go install [some extension] or learn [other language] and implement the extension yourself!” may become a frequent response to feature requests and criticism of GM:S.

One of the really nice things about GameMaker was that it was a small, simple, self-contained language. As well, non-GML extensions have not historically had full access to the GameMaker runtime engine, meaning that in essence when you made a call to a native-code .dll extension, you were passing some data values out of GameMaker into the .dll, which would only know of those values, and it would do whatever it did, and return a value back to GameMaker, which you could then do something with. This scope boundary made native extensions a bit more difficult to work with, and a bit more clunky as well, and as such I tend not to use them.

As we’ve seen with the newly-added features such as source control, Box2D physics, and shaders, GM:S has for some time now been bolting on more and more stuff in order to quickly deliver features it has historically lacked, which are already familiar to experienced programmers and really don’t need to be re-invented. But this means that non-programmer game designers will have to stretch themselves increasingly further in order to gain mastery over these new features.

Much as web development in the mid-90’s was all about learning HTML, which was dead simple and easy to learn in no time, and then later along came CSS and Javascript, and SQL, and backend scripting languages like Perl, PHP, and ASP, which made things increasingly complex and difficult to learn, and then specialized Javascript libraries and frameworks like Rails, I see the same thing happening with GM:S — a tool that was once very simple to pick up and learn is growing more capable at the cost of increasing complexity, sacrificing ease of use.

True Type Fonts

The ability to add True Type Fonts to your game from an external file and support for non-roman alphabet languages.

This is a nice thing to see. It’s a little bit hard to feel truly excited about fonts, but TrueType support is another one of those things that is long overdue and will make GM:S feel no-longer antiquated in its typeface options.

Simple Flash Asset Importer

Allow importing of certain Flash assets directly, including things like vector images, and PSD files.

I never did get into Flash, so this isn’t especially important to me, but it will allow vector sprites and therefore resolution independence, which is pretty awesome.

Spine Animation Importer

Allow importing of animations created using Spine.

2D Animation runtime

Visualize in GameMaker any assets imported from Flash or Spine.

I haven’t used Spine, but it sounds a lot like the Spriter project, which I helped fund the kickstarter project for. So, hopefully this doesn’t mean that GameMaker won’t support Spriter in favor of Spine — one of the Spriter project’s stretch goals was support for GameMaker, and I still would like to see that delivered.

Push Notifications

Will permit you to use push notifications to inform the user of things on iOS and Android.

Mobage

Integration of the Mobage SDK will permit you to use their social gaming network in your games.

These last two are of special interest to developers targeting mobile platforms and social networks, which is pretty much everyone these days who wants to make money doing independent game development.

Early Access Builds

This is a very big deal for me. To date, GM:S has offered two update channels: Beta (for the latest builds), and Stable (for more well-tested builds) — but only one installation. So you had to decide whether you wanted to get the latest release and risk bugs, or the stable channel with its slower delivery of cool new features. Now, however, they’ve changed the way this works, so that the “Early Access Build” can be installed adjacent to a stable release, allowing the developer to play and experiment and learn the newest features before they’re ready for official integration, and not have to give up having a stable IDE for serious work. I’ve been burned at times by trying to use features that weren’t ready yet, and now I feel like I can safely do that without being punished by project-breaking bugs from the beta channel.

A few quick updates

administrivia, games, programming
Comments

Did not complete Ludum Dare 28

I even liked the theme this time: You Only Get One. I came up with an idea pretty quickly: a platformer in which you are given the choice of several power-ups, but you only get to have one. Once you made your choice, you have to get through the level using that ability.

Alas, I did not get very far and did not complete the game. I started out trying to build a platforming engine from scratch, ran into bugs, and a few hours later concluded that without declaring a pre-existing base code for a working, tested platform engine, I just wasn’t going to have any hope of completing a game in 48 hrs.

I really needed to do this in order to free me up to do things like come up with the various power up items, and devise level designs that would be solvable with each of them, just in some different, uniquely challenging way. That’s a rather tall order, really — level design in platformers takes a lot of talent and testing.

Once I realized that I wasn’t going to be able to finish that project idea, I could have scrapped it and started something else, but I opted not to — mainly because I was very frustrated by that point by a couple of technical problems.

This culminates a year of mostly failed projects for me: I was sick the weekend of Global Game Jam 2013 and didn’t partake, then the wheels fell off my computer just in time for our local Cleveland Game Developers Summer Jam event, when a dying hard drive put me out of commission for the weekend as I struggled (mightily, and successfully) to move my OS to a SSD. I blew off LD26 because I hated the theme “Minimalism”, and then skipped LD27 entirely because I hated the theme “10 Seconds”.

Of course on the plus side, I helped put out a book on GameMaker, and am currently working on another, but in terms of releasing finished products, this has been a bust year. Nothing to do about it but pick myself up and get back into it, though.

Site has been down a lot lately, hasn’t it?

Since I went and registered this domain name in 2010, I’ve been hosting on a server that a friend of mine generously provided me some space on for free. At first I had no idea what I was going to do with my domain, at all — I just wanted a web server of my own to play with in my spare time, and learn from. I dabbled briefly with trying to build a native HTML website before realizing how not-fun that really is, and switched to using WordPress, and have been blogging with it ever since.

This year, the server started having issues with downtime. I’ve been in contact with the server administrator, who at various points has explained that the outages have been caused by all sorts of things: database server disk storage full, upgrades, DDoS attacks, aging hardware, you name it. It seems the problems have gotten worse over time rather than better, and so a few weeks ago I began shopping around for a new hosting service. I’ve got one now, and am in the process of migrating the site over to the new server. I’m hopeful that I’ll be through doing that sometime this week, and then I can cut over the DNS registration to point to the new server, and all will be well again. This weekend there was another bad outage, and the site was down for about 24 hours. Dealing with that had me distracted, anxious, and frustrated, and not at all in the right frame of mind to be focused on my LD48 project.

Despite the ease of setting up WordPress initially, I’ve found it fairly difficult to migrate the site over to the new host, mainly due to differences between the hosts, but also due to my relative lack of experience in doing this sort of thing. So I’d like to say I’m learning a lot from this, but really at the moment I’m just learning that it sucks to do something when you don’t really know how, and the documentation and tools that you have available to you are not all pertinent to what you want to do, and it’s up to you to figure it out. I’m muddling through, and perhaps by the time I’m done I’ll understand how stuff works a lot more than I did before I started, but I haven’t seen that payoff just yet. I haven’t yet resorted to the tech support at the new host, but I plan to this week when I can get to it. Getting the current host to be up at the same time when I have a large block of time to throw at migrating seems to be an issue, and I don’t want to waste my time talking to tech support when the old host is down and something that I may need to pull off of there isn’t accessible.

So that sucks.

YoYoGames Support rocks

On top of that, I also had a bit of frustration with GameMaker Studio this weekend while I was still trying to work on my LD48 project.

Somehow or other, the auto-suggest feature in the GML code editor went glitch on me, drawing a super-tall suggestions box that drew off the top of the screen, and wouldn’t allow me to scroll up to see any of the suggestions.

Tl;dr: it turns out that the autosuggest box is resizable by dragging the edge with the mouse, making this quite easy to fix. However, I did not know that at the time, as there’s no UI widget that hints at this functionality, and I expected that it was like a regular “Tool Tip” widget in Windows, which are not normally resizable. I tried exiting/relaunching, and even removing/reinstalling GM:S to no avail, before resorting to tweeting my SOS. I also submitted a bug report with YYG.

Within an hour or so of my SOS tweet, xot of GMLscripts.com had offered me some suggestions which fixed my problem. I really appreciated him taking the time to do it. I don’t know who xot is in real life — if he’s connected in any way to YYG, a former employee, or just a long time GameMaker developer, but I’ve gotten a lot of use out of gmlscripts.com over the last couple years, and so I donated $25 to him for providing such a valuable resource to the community, and since then he’s been quite friendly and generous with his time — he also contributed quite a bit to the draw_text_rtf() script that I posted about earlier this year. So, three cheers for xot, wherever you are — you’re a great guy.

This morning, I woke up to find an email from YYG Support in my inbox:

Hi there,

Reading through the twitter feed you linked it looks like you managed to solve the issue.
Is this correct?

Thanks

Peter
YoYo Games Customer Support Technician

Since the bug report tool doesn’t let you upload files, I had pasted the url of the twit pic, and Peter had apparently followed up, reading the conversation, and, seeing that I’d apparently sorted things out on my own, checked in with me to make sure I was doing OK. Awesome!

I wrote back to him:

I don’t know what caused it to happen in the first place, though, so you still may want to investigate that end of it, in order to prevent a recurrence of the issue. It seems to me that while it makes sense for the height of the auto-complete suggestion box to size itself dynamically, it ought to have some “sanity checks” to make sure it’s not sizing itself larger than the display resolution, and more specifically to size itself to no larger than needed to display the suggestions.

To which, he replied:

I’ll let our coding team know about this issue so they can add some checks to prevent this sort of thing happening again.

I’m extremely pleased with this exchange.

A year or so ago, back when YYG’s Mantis bugtracker was still open to anyone to submit bugs, it often took a long time for anyone to respond to a bug report, and often that response was unsatisfying — you felt like you’d annoyed someone with a concern or question that they felt was stupid, or that you were guilty of misusing the bug reporting system to ask for help merely using the tool rather than reporting a genuine bug, bug reports would often be closed prematurely, before allowing you to engage their developers who were working on it to communicate about the issue, and if the issue did merit a fix, it could be months before someone got around to it, because there’s a zillion bugs and they have to be properly prioritized, planned, and implemented.

By contrast, this experience left me feeling that they cared about my problem, not just the bug report, that they were interested in taking care of it the right way, and that it was their pleasure to do so. Submitting issues is also simplified compared to what it used to be in the Mantis system, which is also appreciated.

I really, really can’t say enough good things about how it feels to be using GameMaker these days.

DRM signals early death knell for legacy GameMaker development

development, reviews
3 Comments

It’s generally known that GameMaker 7 and 8 use a DRM technology called SoftWrap to manage license and product activation. Today, YoYoGames released the following announcement, regarding this technology:

http://yoyogames.com/news/172

Update for GameMaker 7 and 8 Customers: Please Read

We want to inform all GameMaker 7 and 8 customers that Softwrap, our exclusive technology provider for GameMaker 7 and 8, has announced a change to its business. By August 31, it will no longer be possible for GameMaker 7 and 8 customers to install or reactivate their licenses. After August 31, if you are having issues reactivating GameMaker 7 or 8, please register a ticket that includes your Softwrap license code via the YoYo Games Support Center and our agents should be able to help you.

In reaction to this news we would like to help migrate users to GameMaker: Studio. “Studio” is the current version of GameMaker and the only version where we offer regular updates and support. We’re therefore offering customers of GameMaker 7, 8 and 8.1 an upgrade to GameMaker: Studio Standard for only $9.99., which is a $40 saving on the regular price.

To upgrade to GameMaker: Studio Standard, simply click here and enter your Softwrap license number to purchase a license for GameMaker: Studio Standard.

For more information on how to migrate games from GameMaker 7 and 8 to GameMaker: Studio Standard, please read our Wiki entry “Porting GameMaker 7 and GameMaker 8 to GameMaker: Studio.”

We apologize for this inconvenience but hope you find our offer to upgrade to GameMaker: Studio compelling enough to take advantage of it.

Thank you for your continued support of YoYo Games.

The YoYo Games Team

It’s not entirely clear from this what the help YYG plans to offer GM7 and GM8 users will consist of, or how long they’ll continue to offer this help.

A consumer friendly failsafe for the contingency of the DRM license servers going offline should be to unlock the product for all users. Not doing so can present a great inconvenience. If YYG and Softwrap goes out of business, or simply change their policy, that’s it for your GameMaker license. Short of hacking around its product activation, there’s no way you’ll ever be able to use it again.

That’s for a product that you paid for. This changes the nature of purchases into something more akin to a subscription or rental — only, your continued right to access that which you have paid for is contingent upon the continued existence and goodwill of the business entity who provided it to you.

Imagine having a tool chest filled with expensive tools that you paid for, but then finding one day that the chest has become permanently locked as a result of the manufacturer going out of business. That’s what it’s like to use DRM-encumbered tools.

Offering a discounted upgrade path to developers who haven’t yet adopted Studio is better than nothing, but it’s likely that developers who are still on these old versions have not upgraded yet not because of financial reasons, but because of legacy projects that are not easily ported to Studio due to a dependency on now-deprecated functions that are no longer supported in Studio. For any such developers, migrating their codebase from GM7 and 8 to Studio could involve substantial re-engineering.

YYG no longer use SoftWrap DRM with GM:Studio, but does continue to use a DRM solution, and YYG have stated in the past that they will likely never abandon DRM. I disagree with their stance on the matter, but I recognize that it is their decision to make. I continue to recommend that they abandon DRM in the future, and figure out a business model that allows them to do so.

I also encourage them to release a non-DRM encumbered version of GM7 and 8 for existing licensees who wish to continue supporting legacy codebases that they are unable to port to Studio. When a business elects to cease support for a product that they released, the most ethical thing to me would be to release the source code for the product, so that those who wish to continue using it can develop their own patches and updates. Failing that, at the very least they should unlock any DRM that would prevent customers from being able to use what they’ve paid for.