iMprOVE_WRAP 2.1 has been released. Get it at GameMaker Marketplace or itch.io.
| 1.0 | Initial release |
| 1.0.1 | Updated iw_draw_self_wrap() to use image_blend rather than c_white for the color argument. |
| 2.0.0 | Added new functions:
Improvements:
|
| 2.0.1 | Improvements:
|
| 2.1 | New functions:
New demo room for the iw_distance_to_object() and iw_distance_to_point() functions |
In the last couple of days, YoYoGames have released some teasers that seem to be signaling the immanent release of GameMaker: Studio 2.0. This long-awaited release will overhaul the GM:S GUI, which YoYo have been rewriting in modern C++, and usher in a new era for GameMaker. Beyond that, little is known, as YoYo have been pretty secretive about their plans for the future of GameMaker since being acquired by PlayTech in 2015.
My greatest hope is that GM:S2 will have builds for Mac OS X and Linux. Out of all the software I use today, GameMaker is the last product that runs only on Windows, and I am eager to move to Linux full-time.
It remains to be seen what the release will bring.
Recent purchases of GameMaker who picked it up through the Humble Bundle have been speculating about what GM:S2 will cost. Obviously, a major release isn’t going to be free. It’s typical practice for software companies to sell upgrades to existing users at a substantial discount, so I’m expecting no less.
If YYG do extend discounted upgrade pricing to Humble buyers, most of whom paid around $15, they’ll still be getting an incredible value.
For a long time, YoYoGames used to publish a roadmap, showing their plan for the future of GameMaker: Studio. Interested parties could look and see what new features were in the works.
Since PlayTech took them over, they’ve taken this information offline.
In a recent Forum conversation, YoYoGames employees Shaun Spalding and Mike Dailly explained that while they wish they could communicate the future of the product, their hands are tied, and when they can talk about things like upcoming release dates and new features, they will.
This is very disappointing to serious GameMaker Studio users. A roadmap is an important document for developers. Software development is all about maintainability. In order to write software that is maintainable, it’s important to know how the tools you are using will be changing over time. Knowing the future plans of the tools can help developers avoid wasting time using features that will be deprecated and removed in the future, or avoid wasting time writing their own implementation of a feature that is planned in an upcoming version. A roadmap also prevents the repeated asking of the same questions, “when is [X] coming out?” or “I suggest you implement [already planned feature].” A roadmap is part of the conversation that happens between a software developer and the users, and not having one harms both the company and its customers.
Most software engineering projects intended to be consumed by other developers have a roadmap. Other game engine developers such as Unity3D and Godot Engine have public roadmaps.
It is my hope that PlayTech will change their policies surrounding information of their products, and allow their employees to engage in open conversation about their products. In the meantime, concerned GameMaker users should speak out and make their voices heard.
Today I’ve released a new asset on the YoYoGames Marketplace, called iMprOVE_WRAP.
Many video games have the feature that exiting one side of the screen will “wrap” you around to the opposite side — notable examples of this include the smash hit classics Asteroids and Pac Man. GameMaker: Studio has a GML function, move_wrap(), which is intended to provide this feature easily, but it has a few limitations. iMprOVE_WRAP addresses these limitations, resulting in a more powerful, flexible implementation.
One of the most troublesome limitations of move_wrap() is that it only works for instances that have a speed. In standard GML, the variables speed, hspeed, and vspeed are used to move instances. But you can also “move” an instance by changing it’s x and y position in the room, without setting a speed. Many GM:S users will implement their own movement systems that eschew these variables, in order to give themselves complete control over the movement engine. When they do so, they are often confused when they discover that move_wrap() doesn’t do what they expect.
iMprOVE_WRAP eliminates this dependency, so that an instance no longer need to use the GML speed variables in order to wrap; wrap behavior in iMprOVE_WRAP is based entirely on an instance’s x,y position.
Another problem with move_wrap() is that it is intended to work with the Outside Room or Intersect Boundary GML Events. This means that move_wrap() is only useful when an instance moves outside the room, or encounters the edge of a room. But in many games, the “play field” may not be synonymous with the entire room — the room might have a border, or “dashboard” or “heads up display” which ideally should be considered “out of bounds” with regard to the play field.
iMprOVE_WRAP allows you to define a “wrap region” — a rectangular area inside the room, which instances wrap around the borders of, rather than the borders of the room.
With move_wrap() the margin argument which determines the margin by which the instance must be outside of the room is the same for both horizontal and vertical travel; with iMprOVE_WRAP the horizontal and vertical margins may be set independently of each other.
With move_wrap(), an instance still draws its sprite in the default draw in only one location: at (x,y). If the instance is off the edge of the wrap boundary, but hasn’t yet crossed over, the instance draws on the “pre-wrap” side of the room; after the instance progresses by margin pixels over the border, then the instance’s position is moved over to the “post-wrap” side of the room, and the instance is drawn there. This is not a big deal if the instance crosses the wrap boundary quickly, and has a relatively small sprite; but for slower-moving instances, or instances with larger sprites, it creates a jarring “jump” effect, where suddenly the instance appears on the “post-wrap” side of the boundary, with no real warning, rather than gradually entering the room.
iMprOVE_WRAP solves this by providing a new function, iw_draw_self_wrap(). This new function augments the default draw by drawing the calling instance four additional times, at positions left, right, up, and down from the actual instance, the width or height of the wrap region away from the actual instance. Thus, when your wrapping instance is moving off the edge of the wrap region, one of these extra drawings is poking out on the opposite side, creating an illusion of continuity as the instance leaves one side and emerges from the other.
For a wrap region that is smaller than the room itself, it’s best to do your drawing on a surface that is sized to the area of the wrap region; otherwise the parts of the drawing that should be outside of the region will be visible outside of the wrap region. Alternately, if drawing to a surface is not something you want to do, you can “mask off” the portions of the room outside of the wrap region by layering objects at a higher depth around the border, like a picture frame or dashboard.
To compliment the iw_draw_self_wrap() function, I’ve added a new collision function, iw_collision_wrap(). This function checks for collisions at the four places occupied by the four drawings drawn by iw_draw_self_wrap(). There are actually two iw_collision_wrap() functions.
The more basic, iw_collision_wrap() sets five instance variables in the calling instance to store the id of any instance in collision: other_center, other_up, other_down, other_left, and other_right.
The more advanced, iw_collision_wrap_map(), returns the id of a ds_map, which holds those same five instance variables as keys, which you can access using ds_map_find_value().
Which to use is up to you, and the style of programming you prefer. iw_collision_wrap() is easier to use, and if you don’t mind the instance variable names, is probably slightly faster at runtime. iw_collision_wrap_map() is for programmers who get pedantic about “correctness” and want their functions to return something, not cause side effects in the application state. Since it’s not possible in GML to have a function return 5 separate values, we return a data structure that stores the five values. The downside of this is that you have some overhead, namely a need to clean up the ds_map when it is no longer needed. Fortunately, it’s not hard. The example project will demonstrate how to do this properly, so don’t worry.
iMprOVE_WRAP is available at the YoYoGames Marketplace for $2.99; however I am making it free for the first 10 downloads. Please rate it and review it if you give it a try!
This is a collection of scripts and macros that handle motion and action. A “control scheme” is a set of inputs and their associated actions. Add a control scheme to your player object with just two lines of code!
It is intended to handles input, motion, and action quickly and easily, while allowing you to extend to include any audio or visual effects that may be needed.
Documentation is awesome.
Currently, just two control schemes are implemented; I’ll be adding others in the future, much more is planned.
It’s currently free, as I’d like to get everyone to try it out and provide me with feedback, but when I’ve added more features I’ll be charging for it, so be sure to get it now while it’s free!
Today mmap mini maps 1.2 was released on the GameMaker Marketplace. It’s a really great asset, which ads a powerful, configurable, easy to use mini map system to your GameMaker: Studio project. I’ve spent dozens, if not over a hundred hours developing this asset to the highest quality, and am selling it for just $4.99.
I’ve re-published the mmap mini maps over at the GameMaker Marketplace. The new version, 1.1.6, fixes the bug of the missing mmap constants — this time the right way, replacing the earlier workaround that I had supplied a few days ago.
Building the asset package the way I needed it was not obvious, but with the help from some GameMaker Community Forums users, I was able to learn the correct method to get the constants added to the package.
GM:S has two ways to build an Asset.
The more visible method of the two, and the one I had used at first when building my Asset, is to use the Package Manager, located in the Marketplace Menu.
Using this method, you can only build an asset which includes “project resources” — Sprites, Sounds, Backgrounds, Paths, Scripts, Shaders, Fonts, Time Lines, Objects, Rooms, or Included Files.
NOT include-able are Extensions, Macros, Game Information, or Global Game Settings. It’s a good idea to understand the rationale for not including these, and how YYG intends for GM:S users to work around these limitations:
The other way to create an Asset for the marketplace is to build an Extension. Right click on the Extensions folder in the Resource tree of a project, and Create Extension. Then right-click the newly created extension and Add Placeholder. The purpose of a “placeholder” is vague, but what it allows you to do is define Macros which reside at the extension level,which is done one at a time, in an interface that is different from the project-level Macros editor, and even more of a pain to use.
You can also add Functions to the Extension placeholder. You can add a code file, such as exported scripts in .gml format, or a .dll, .js, .dy-lib, etc. and then define Functions which hook up to the code file.
Once the Extension is defined, you can create an Asset out of it, by logging into Marketplace, and then right-clicking the Extension, and choosing the Create Asset Package option. Creating the Asset Package this way is much the same process as creating an Asset Package from the Marketplace menu, with the exception that the Extension that you right-clicked on will be included with the Asset Package.
Why there isn’t a simple way to include an Extension in the Package Manager build process, I don’t know. I guess the answer ultimately is that this is a new feature in GameMaker, and still in beta. The UI design is rough, inconsistent and not as obvious as it could be. Hopefully this will be addressed as the features are refined. But, for now, it is what it is, and game developers who use GM:S will just need to be aware and familiarize themselves with the differences between these two methods of building an Asset Package.
I’ve been struggling with updating my mmap mini maps asset pack in order to fix a bug that I discovered with it. Since I’ve been unable to do so, I’ve elected to temporarily withdraw the product, rather than continue selling a broken asset. I’ll have it back up as soon as I can get it fixed, but I don’t know how long that may take, due to problems I’m having with the tools.
First, the bug. In the mmap mini maps package, there was supposed to have been a collection of Macros (what used to be known until recently as “Constants”), which I used to assist with programming the Mmap object. When I built the Asset Package, I failed to realize that these Macros did not get included. Without the Macros defined, the project doesn’t work.
One workaround would be to add the macros manually. They are documented completely in the user manual that I wrote. I can also furnish a .txt file that can be imported, to save the data entry. If I can’t get the tools to cooperate, that may end up being the solution I go with for the short term.
It was not obvious due to the way the package builder works, and I didn’t notice it in testing because I tested it by bringing the package into the same project that I had used to build it in the first place.
Lesson learned: Build the package in one project. Import the package into a fresh project to test.
When you build an asset package in GameMaker: Studio, you start by taking some project that you’ve been working in, and then going through the Marketplace Package Manager to build a Marketplace Asset using resources from the project. However, the interface that YoYoGames have built is still very beta. It is unstable, resulting in error messages and crashes. But the greater issue is that the design of the interface, and the workflows it supports, is also rather poor and unrefined at the moment.
When you build your Marketplace Asset Package, you are presented with a Package Builder that allows you to select resources from the project and add them to the package. But the resource selection options are not complete. You can’t select Macros. They just aren’t even there.
So how do you add Macros to a Package? By adding them to an Extension, supposedly. There’s an Extension Builder built into the GM:S IDE, as well as this new Marketplace Package builder. I’m presently unclear as to the relationship between Extension builder and Package builder, but the end result of a Package is that you get a package that is ready to be uploaded to the Marketplace as an Asset, and when you download Assets that you’ve purchased from the Marketplace, it installs itself in your Library, where you can add it to a project, where it… becomes an extension.
The Marketplace asset-extension has whatever resources you had added to the Package — sprites, scripts, objects, sound effects, fonts, included files, timelines, shaders, you name it… just no macros.
But if you build an GMEZ extension using the Extension Builder interface, things are very different. I can create an Extension, add a “placeholder” to it, where I can define Macros (one at a time, which is horrible, like each Macro is its own asset in the tree), and I can add a code file, which can be .gml, javascript, a dll, a dy-lib, or java. And I can define Functions which access the code residing in the code file, providing an interface between GM:S and the functions provided by the extension.
And the documentation shows a similar resource picker for handling both importing resources from a completed Extension into the Project, and for moving project resources into an Extension that you’re authoring. But, for some reason when I am in the Extension Builder, it’s one-way only, I can import from the Extension to the project, but not from the project to the extension.
So when I build an Extension, the only things I can put in it are Macros and Functions and Code files. And when I build a Package, the only things I can put into it are project resources other than Macros and Extensions. So I can’t add Macros to an Extension, then add the Extension to the Package. And I can’t add project resources to the Extension Builder. So there’s this impasse that I can’t figure out how to work around.
It could be the documentation is just out of sync with the version of GM:S I’m running, or it could be there’s some serious design bugs in GM:S currently, or it could be I completely misunderstand both the documentation and the user interface, and am missing something that will become apparent to me eventually.
I’m a bit frustrated now, and very tired of banging my head against a wall trying to figure out how to make it work, so I need to step away from it for a short bit.
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.
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.
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.
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.
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.
I almost didn’t submit a game this time around. For some reason, I couldn’t get my creativity going. I thought that Beneath the Surface was such an excellent theme, too, with great potential. When they announced it, I started trying to think of a game that would happen underground, or under water. But all I could think of was the setting, not what you’d do there. My brain was being an enemy to me.
So I stayed up until about 6 AM Saturday morning, and still hadn’t thought of any good ideas. My best idea of the night came to me when the Neil Young song, “The Needle and the Damage Done” popped into my head, and I briefly considered making a game about heroin use and damaging the skin beneath the surface. If I wanted to do that right, I needed to make a chiptune cover of the song, and I still can’t do music properly. One day…
So, I put that idea aside, and then nothing else came to me. I slept in until around 11:30, and spent most of the afternoon sitting around, waiting for inspiration to hit me, but nothing happened.
I dicked around on the internet, reading stuff, and started reading all these articles about the New Mexico landfill dig, where they were trying to determine if the legends of massive amounts of unsold Atari merchandise being buried in the desert were really true.
Turns out, they were true!
I found the story fascinating, because why would people still care that much that they’d dig around in a land fill trying to find that stuff. It’s not as though E.T. was a rare and valuable game. To me, the story wasn’t fascinating, it was people’s fascination with the story that was fascinating. It seemed to be getting a lot of coverage in the media.
I still didn’t have any ideas for what would be a good game, and by around 5 or 6, I had given up and resigned myself to not producing anything this time around, and felt pretty down about my failure to come up with any good ideas. I had a relaxing Saturday evening, went to bed, had a pretty normal Sunday, and then, around 7pm it occurred to me that the land fill dig was happening beneath the surface of New Mexico. Beneath the surface…
Beneath the surface…
Beneath the surface…
Beneath the surface…
neath the surface…
the surface…
surface…
urface…
face…
And I got this visual in my head of the pits in the E.T. video game, and connected that to the landfill, and immediately realized that there was a potential game in there.
Digging in the Alamogordo, New Mexico landfill, in a pit from the E.T. video game, searching for the secret stash of E.T. videogames. I knew exactly what I wanted it to be, not really a challenging game, just an idle time waster that paid homage to the legend and the events of the weekend. I had less than 2 hours before Compo deadline, and knew I’d never make it, but this would need to be a Jam entry anyway, as I wanted to use graphics and audio sampled from the E.T. video game.
Unfortunately I was already on my way to spend the evening with friends, and I didn’t get home until close to 11pm. By 11:30, I had just gotten started, and I worked through the night until 6:30am, and which I had most of the level laid out and working. Movement and collisions were very buggy, but the game was basically playable by this point.
I took a power nap, worked Monday, and then cranked out bugfixes until I got everything working right. All told, the game took about 10 hours to build. My fastest development time ever. Howard Scott Warshaw took 5 weeks to make E.T., his fastest development time ever.
I used that time rather well, struggling only a little bit with the bug fixes, and all I really needed to fix those bugs was to step away from the project and return to it fresh — once I did that, it was fairly easy to redesign the code that handled movement and fix the problems I’d been having in the wee hours of the morning earlier in the day. Throughout the project there was very little re-work, almost nothing thrown away, and everything that I built was done in such a way that it doesn’t feel like a mess. The project code is actually pretty decent. Almost every LD48 that I’ve done so far, I’ve struggled with some stupid error in a feature that should be very basic and easy to do, and ends up sucking a lot of my time away from the project, but this time, I worked effectively from start to end. Only, I had just about 10 hours of work put into the project over the entire weekend.
The game itself, well there’s nothing much to it, but it does feel somewhat like one of those terrible shovelware titles that caused the Great Crash of ’83.
So, there it is, an homage to terrible games. Since that’s what it is, it somewhat excuses it from itself being a fairly terrible game. At least the programming is fairly decent, …beneath the surface.
Well, play it and see what you think.