Discussion in 'Community Chat' started by andev, Dec 1, 2017.
New is not always better, but whatevs.
Let's say I have a foot on each canoe by now. After I finish my Framework I will move to GM2 for good! =]
Not me. I tried to learn it but it pushed me away to learning c++... i found c++ EASIER to learn and wrap my mind arround then GMS2. Its that bad.
Alright, I'm actually curious here. I get that the IDE is much worse (hell, I'm practically a meme on this subject at this point), but what else do you find so different? There's the fact that everything is based on layers now, which I understand makes it more challenging to make somewhat efficient use of the good old depth=-y, but besides that, GML and the way you work is practically the same, no?
The sprite editor is just horrendous.
I hate the workflow system, i got the hang of gms 1.4 and gm 8.1 but i just could not wrap my mind arround gms 2.
Everything just feels cluttered and clostraphobic. I cant just jump arround the different windows like you can in gms 1.4. I also cant stand either gms 2 or gms 1.4 code editor and use a 3rd party one that more resembles visual studio.
I cant stand that the idea of instance create is gone.... i know the layer system is there now but for me it feels like gms2 is trying to be too much of what its not. Even kids i used to teach in highschool feel the same.... the software feels different and alien now.
Add ontop all the technical issues... it doesnt agree with my laptop or desktop pc.
The sum of it all was to just say "duck it" ill learn c++
Well, I do know C++ (it was my first language) and actually try to create a game engine from scratch is... daunting to say the least. But, hey, whatever rocks your boat, right @James222 ? Maybe try... another engine before that, mate?
I am yet to understand what people are so angry about GM2. It seems good, some things have changed, conversion generates a lot of trash, but I was able to clean it up without too much work. I did like workspaces. And, @JeffJ, if you can, pm me on how to make the depth=-y thingy on GM2, please. I am curious. =]
The one thing that I am scared to hell is when an update breaks my current project... This I don't miss one bit. It literally drives me insane. So I plan to get the 2.3 update and disable the updates until I complete my next game.
Haha well tbh my job in real life is a programmer and my current job is to create a visual drag drop or click and click game engine for the artists at the company to use to make in house games. I know the challenges involved in writting a game engine in c++ its... even in the best cases a mess to get right.
But in all honesty... ive used gm almost dailt growing up. I still remember the first time i installed gm6 which was the current build at the time. It got me into programming and game dev and ill always be thankful for that.
Yeah, I still remmember the time in 2006 that I make Overkill in a span of 2 weeks. Still using GM with all the bad and good that it brings.
I hope you do well, @James222. May your games be ever fun, no matter the engine. =]
Ill hit you up in a pm sometime
Been on a GM:S 2 boat for a while now and I generally found it much more convenient to work with.
Things I'm not too fond of:
workspaces - maybe they have some degree of visual appeal and are easier to grasp for more visual-oriented people (?), I just found them taking too much space (will try out the non-overlapping windows, maybe it'll get better); I guess they could work better if windows could be minimised and displayed with some extra icon? (on that note, disabling the animations was one of the first things I did)
sprite editor - I feel like compared to earlier GameMaker version it makes complex things easy and easy things complex, with the most blatant example being the Paste-brush thing; it's possible to emulate, but why I have to apply the brush with pixel precision for that? >.<
layers system - caught me off guard on some occassions, especially when I found that the object I put at some ludicrous negative depth like 100000 or 1000000 won't draw; it took me a while to figure out it's because it's outside the valid layers range (not saying layers system itself is bad, but rather that it broke some existing intuitions)
default audio settings - compression/streaming option stays as "Uncompressed" default, even when I add mp3 file; it greatly increases the file size, most of the time without author's intent, and this setting is probably responsible for about half the size of the recent Jam ZIP or so
Things I like:
improved code editor (with all that variables highlighting/hinting and such)
And since it's the thing I'm using most of the time, it easily makes up for the issues I listed above and then some. Things are looking up considering the soon(ish) GML improvements; I've already found myself yearning for these changes on multiple occasions, especially during the last GMC Jam.
I never said new was better, I said it wouldn't make sense to add new features and ship them turned off by default.
In saying that, some people think the new workspaces are better, it's impossible to please everyone but when there is an option in the preferences to change the behaviour to the way each person prefers then it's not really an issue.
You could use a fully featured sprite editor like Aseprite which is free if you compile it from source, as well as other free ones like GIMP or Paint.Net etc. The built in sprite editor is never going to be (and shouldn't try to be) as good or fully featured as a tool made specifically to perform that single task.
Not sure what you mean by this, if it was gone we wouldn't be able to create instances.
You can use instance_create_layer() to create an instance on a layer, or instance_create_depth() to create an instance at any valid depth you like.
Behind the scenes it will be added to a managed layer but for all intents and purposes you don't need to worry about that if you just want to deal with depths like in 1.4. Yes it's a little less performant but it's not anything you'd notice in regular circumstances.
Just use depth = -y like you did in 1.4 and let GMS2 manage the layers in the background without worrying about them.
As I just said above it's a little less performant as GMS2 will be creating layers at each depth and destroying them when empty, but it's not something you are going to notice in the majority of circumstances.
There is no need to optimise your game before it starts having problems.
Hi @Alice! =]
Yeah, as @rIKmAN said, a better option would be a proper drawing software. I use Paint .net and I am starting to use Inkscape too. A Drawing software on top of a game engine seems too much trouble to keep them in development. Did YoYo plan to scrap it altogether?
I heard it so much bad things here about the workspaces that I was actually scared to try it the first time on GM2. Lol. I actualy like them at the end. Seems pretty neat and I usually don't left too many windows open even when I am using Eclipse, Visual Studio or even browsing the internet. Maybe that helped me like the thing. =]
This seems a thing that I think I will really need to wrap my head around and understand it fully. We were so used to the depth system on GM1.4.
Hmmm, that's a nice thing, rIKmAN. Thanks for the advice.
Well, this seems pretty sweet, isn't it? =]
I hope I do not regret using GM2, but so far so good. And I am axious like hell for GM 2.3 Update. Hope they can deliver them as planned. =]
If you want to test out a depth sorting method as well and compare performance, there are a few tutorials and methods for doing it on the forum if you do a search for "depth sort" or similar.
For example FriendlyCosmonaut made one that stores instance ids and y values in a grid:
She also has a downloadable project you could take a look at which might help you get started,
MirthCastle has a tutorial where he creates a layer per y position and stores the layer ids in a grid:
Spoiler: MirthCastles Depth Sorting Tutorial
There are probably more, but test all the methods out and see what you think as their is no reason not to give yourself time to see which works best for you. I
However if you are just making a standard game with a reasonable amount of instances then using depth = -y won't cause you any noticable problems performance wise.
Messing around with GMS2 for my latest asset project, and it's not as bad as it was last time I tried it out
Arrays are a first-order citizen now, which means you can pass as many return values as you want (and basically pretend you're sending objects around). This is amazing.
Code completion is nice, but I feel it's unreliable, randomly ignoring some global variables for no reason. Also I HATE HAVING TO WRITE ONE HELP LINE PER ARGUMENT JUST TO GET ARGUMENT HELP. It's just bloated and annoying (I almost never need more descriptiveness than the argument names, and even if you do, this is always better written as one block of text that explains the ENTIRE function instead of splitting it up explaining what every argument does). Bring back the /// syntax (or some variant thereof, since /// comments are interpreted as Javadoc now) so you can actually be bothered to document code.
I'm indifferent about the workspace thing, but I really wish the text in open code windows was antialiased so you could actually READ it when you zoom out to get an overview of multiple things at once (instead of having to zoom in again just to see what you type / copy)
The sprite editor not having clipboard support and defaulting to a sprite size I'm almost never using (and forcing a really annoying multi-click workflow to change the sprite size) makes it an utter annoyance to work with, even when just making least-viable-effort placeholders.
Overall I feel like, I mostly enjoy using GMS2 for its increased language power but the IDE is actively fighting me whenever I try to do anything in it that's not writing code.
@Yal You can change the default sprite size in File > Preferences > Sprite Editor along with all the other default values for new sprites.
Hmmmmmm, this is gold, @Yal. I didn't knew that. Thanks. =]
Good to know. I need to get better at document my code properly.
Well, that is unfortunate. I didn't knew that the srpite editor was that atrocious.
Looked into it, but there's no option for "keep aspect ratio" which is the main thing slowing me down, apart from the "width" field not being selected by default... basically I want to be able to resize sprites without having to move my mouse all over the screen and click three different small things, instead of just type - tab - type - enter - start-actually-drawing... I almost never use the default sprite size (and almost never make multiple sprites with the same size in a row)... typically I draw a character first, and then some auxilary stuff like projectiles... so I always need to change the sprite's size before I start drawing, and that got a lot slower with the new workflow.
Might get some mileage out of "default origin", though (but I still feel like the drop-down menu is just disorienting... and I think it being text is a major part of that)
Ah okay, my reply was to:
I guess me implying that there's any sprite size I use was kinda erroneous since I basically use different sizes for every sprite I make
Oh yeah, there's another thing I'm finding really nice! Inlining macros you only use in one very specific part of the code right there. For instance, in a switch-statement state machine (because you have so many small oneliner states it's excessive to make scripts for every state) it's nice to be able to make name-based labels for states you'll jump to, but you can just avoid labelling boring intermediate states.
Originally I didn't like the idea of having to write a macro script instead of some sort of editor, but it's really nice to be able to have them anywhere, making them easier to find if you only use them in one very specific part of the codebase (instead of bloating the giant macro definition file).
(Another example I'm doing a bunch: when returning an array of unrelated stuff, making macros to refer to each of the contents in human-readable way so you don't need to memorize the numbers... right above the return statement)
The thing is, I do use a specialised drawing software (Inkscape), but even then I came across UX issues - I think mostly related to copying frames between sprites? Can't remember the exact problem now. But one thing that would do improve the UX would be having all import options available from workspace Sprite window rather than accessible through sprite editor, mainly Import From Strip. Having lots of tabs with Sprites open because I happened to import many sprites at once can be somewhat annoying.
Also, as Yal mentioned, the new sprite editor - compared to the old one - takes more effort to even make simple placeholders. As I said, it makes complex things simple and simple things complex. It's kind of like it tries to be a specialised drawing software rather than simple placeholder tool, but lots of the time specialised software is preferable anyway and it ends up working worse as a simple placeholder tool from GM 1.x... >.<
(arrays are cool, though, nice to be able to define them inline)
Wee comment on this... You CAN actually import strip sprites straight into the sprite editor and it's a feature I use a LOT. Basically, make all your sprites a single long strip and then name them "sprite_name_stripXX.png", where "XX" is the number of frames in the strip. On import into the sprite editor, GM will recognise the strip suffix and split the sprite into it's individual frames. It does mean you can't do grid spritesheets, but once you get into the routine of designing your sprites along a single strip, it actually saves a load of time.
Another thing I don't like about the new sprite editor is the confusing removal of the ability to add new sprites into an existing sprite animation, like with "Add From File" and "Add From Strip".
I understand that the majority of the time this wouldn't be a problem but it just makes the sprite editor feel unfinished. I think you can get around this by copying the new sprite from another editor
on your computer and then pasting the new sprite into the animation but that is just needlessly complicated for something that should be so simple to do.
However I will give a disclaimer that I have not used Game Maker in months and that it's possible this might have been changed but for the past few years it wasn't.
II noticed that feature a couple weeks ago. It's very convenient and counter-intuitive. I had been using GMS1.4 as an image editor prior to it's discovery. On a related note: I miss colorize/colorize partial, and I love the addition of layers... but hey, that's why I have GMS2, GMS1.4, GM8.1 Pro, GM7 Pro, GM6 Pro, and GM5 installed on my computer. I can use whichever tool the job calls for.
I think it'd be interesting if GameMaker took a modular appeoach, allowing each customer to customize their installation by selecting "modules" which are important to them: This offers less bloat for customers who who don't want any bells-and-whistles, and options for customers who want/need them. IE: Additional tools for sprite editing, isometric mode for rooms, alternative image/room editors for SVG, 3D Models, etc. (perhaps the existing sprite editor could become a "Recommended" module for default installations and removed entirely for folks who don't want/need it.) DnD™ could work similarly.
I imagine that an integration such as that would be too tedious and expensive to justify... or a complete re-write. Just wanted to provide some food for thought.
The main issue with modular software is that you get issues getting every module to cooperate with every other module, easily leading to a cascade of integration issues. It could work if you go for a fully Unix philosophy of having programs that does exactly one (1) thing, and use files to transmit data between each other... i.e., most of GM doesn't care which program made a file as long as it's in the right format (you could say anything using sprites already does this, for instance, since it can't tell if you drew them in Photoshop, MS Paint, or the image editor) and in the right place. In the best of worlds, this could be extended so that objects, scripts, project structure, etc all could be hooked up to external editors whose only necessary quality is exporting to a format that's GM-friendly, with only the compiler and a resource-format sanity checker being "core" irreplaceable parts of GM.
Sadly, it probably won't really happen with GMS2, since it's really monolithic - now every resource also has a .yy file with metadata(?) so it's more difficult than ever to add in a file without passing it through an official editor first, on top of the workspaces workflow tying together assets even more closely than in the past, tilesets being based off of sprites but being unique resources, etc. And after all... why would we even want a scattered version of GM when one of its big selling points is that it's the one app to rule them all, giving you everything you need in one package?
So yes, it would be a total re-write. Thanks for 'splaining "why not" though. I'm only somewhat competent at using GMS2 (and completely ignorant about how it works.)
Welp, I think that I've done my part to de-rail this conversation. I should probably mosey off now... Have a wonderful day, everyone!
I got back into Game Maker this December (2 weeks ago) after taking 2 years off and it's then that I saw GMS2, but I was happy with 1.4 so I stayed with it. the problem is that all the 'experts' and those that I needed to help me with my project are on GMS2.
So on Christmas day I bought GMS2 and transferred all my projects across.
It took me a full 2 days to work out all that was wrong with the transfers and what functions had been depreciated, but after those 2 days I have sorted it all out, gotten used to the new workplace areas and I'm happy.