YoYoGames announced a game jam to celebrate the GMS2 Beta a couple weeks ago, and I’ve decided to try to participate. I don’t have a lot of time to work on my project, but I wanted to do something to warm up for Ludum Dare 37 anyway, so this was just the excuse I needed.
Since I’m short on time, and am very interested to see how well the GMS1.4->2.0 import feature is, I decided to work on an update to my LD35 entry, Shape Struggle.
Import and Compatibility Report
First, I made a copy of my source code. Then I imported it into GMS2, which was easy. A few seconds later, the project had been converted.
Immediately, GMS2 presented me with a Compatibility Report which details all the conversions it had to make, and the report itself appears as a file in my project resource tree under Notes.
Mostly, the conversion report details involves replacing calls to obsolete functions with compatibility scripts that do the equivalent thing. In my case, the game converted nicely, and I was able to build and run it without any problems. But, I expect that if the conversion process ran into problems, perhaps a function call that it could not convert to GMS2, the Compatibility Report would make mention of this, and I might have some additional work to do before the project would run.
YYG’s documentation says that the compatibility scripts should NOT be messed with, they are not intended to be human editable, so I haven’t tried messing around with them, but it leaves me curious about what might happen if I did. Not being able to go into these functions and make changes makes me question how maintainable an imported project is; and if it is not very maintainable, it mostly defeats the purpose of importing and converting an old project.
I haven’t done enough yet to know whether this is a legitimate concern or not, but it’s a worry for now until I know more. It seems to me that in order to have complete control over your project code, you’ll eventually need to go through and re-write any code that makes calls to compatibility scripts, to do the equivalent thing in a manner which is completely native to the way GMS2 wants things done. In many cases, this could be a simple and straightforward transliteration of the old code into new code which eliminates deprecated functions. Depending on the project size, though, this could get very tedious.
Update: Reading the Help documentation more carefully, I misread. Only compatibility scripts starting with a double underscore should be left alone. From looking at the compatibility scripts that I have reviewed so far, it seems like a fairly straightforward wrapping — the old, deprecated function call is used to create a script of the same name, and the script calls the equivalent GMS2 GML function(s) needed to achieve the equivalent results. It should (in principle) be possible to replace the call to the compatibilty script with the code inside of the compatibility script, and thereby convert the project to pure GML2. This does not apply to __compatibility scripts, however. If your project converts with these, it may be necessary to rewrite your project a different way to make it pure GML2. Or you may be able to leave it alone and hope that you don’t need to maintain that part of the project.
Collision Mask problems
Although my project would build and run, the conversion process was not 100% perfect. I noticed that some objects seemed to be colliding in a way that indicated that there was a problem with their collision masks. Sure enough, when I went into the Sprite Editor to have a look, I found that the collision masks were all wrong.
Upon further investigation, I determined that the only type of collision mask that currently works in GMS2 is a rectangle mask. Diamond, Ellipse, Precise, and Precise Per Frame masks are available options, but when I use them none of them work — collisions do not register and no event happens.
Moreover, I found that the collision mask editor does not seem to draw the mask shapes very well. When I tried to draw an ellipse mask, the right and bottom edges of the ellipse were flattened. I spent a lot of time trying to re-draw them to fix this problem, but the editor just overrides what I try to draw, and there’s no way to override it.
What’s more, if I tried to adjust the Alpha Tolerance on the mask, it would reset the mask to fill the entire sprite.
Very likely these are bugs due to the software still being in Beta status, and will not be long-term issues with the import process once GMS2 is officially released from Beta. So, clearly, the Sprite Editor has some issues and a long way to go before it is ready for release, including features which apparently have yet to be implemented.
Image Editor WTFs (Woes To Fix)
I also had a lot of problems with getting used to the new Image Editor. Most of this is a matter of UI polish, but there’s so much that is familiar, yet different, in the Image Editor UI that it’s giving me a lot of frustration. I fully understand the need for a user interface to change over time, but I do not understand many of the changes that have been made with the Image Editor. It’s tough to even know how to formulate my questions about them.
I find that Select and Copy operations don’t behave like I’d expect them to — copy creates a new Brush in m brushes palette. I can’t simply paste the pixels I’ve selected, and expect them to appear in the image at the position where I copied them from. This makes aligning static elements appearing in different frames in an animation a huge pain. Unless I’m missing something. Yes, there’s onion skinning, which is a great feature to have, but I don’t want to have to do painstaking image placement, I want to simply paste and see the content draw in where it was in the frame where I copied it from.
There’s also no replace color tool in the new Image Editor. In the GMS1.x Image Editor, there used to be a handy tool that would replace all pixels in the image matching the color you clicked on with the color set in the tool. For example, you could turn all red pixels green, with a single click. This was a useful tool, and I miss it.
I find the Text Tool in the Image Editor to be in need of a great deal of additional refinement. Currently, it is not very usable. I need to be able to reposition the text after I’ve typed it, but before committing. Most modern graphics editors allow this, but in GMS2’s Image Editor, once you click, there doesn’t appear to be any way to move the text that you’ve started typing, which makes positioning it correctly largely a matter of guesswork. There’s also no font preview, so when you select from the list of font names, unless you’re already familiar with the font in question, you won’t know what it looks like until you start using it. Currently it’s a huge pain to use the Text Toolf.
Summing up
Still, overall I’m very pleased that the code conversion process resulted in a project that could compile and run without throwing errors. There are still issues that need to be resolved, namely problems with sprite collision masks not coming through correctly in the conversion. And a lingering question about how maintainable an imported project is, if we cannot touch the compatibility scripts. I expect in time, with some more experience with converting projects, it will become apparent what the best approach to take is with modifying a game after importing it from 1.4.