• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Please change the roadmap's "rough order"

DukeSoft

Member
While the roadmap ( https://help.yoyogames.com/hc/en-us/articles/231719448-RoadMap ) is in "rough" order, I still feel like a lot of people (including me) would prefer GML additions - like exception support, foreach statements, inline / anonymous functions / lightweight objects - OVER "Image Editor Effects" for example.

I don't want to whine, but I think the biggest part of the community would simply benefit most from extending GML's capabilities over PSD importers / image editor effects / audio emitters in rooms. I'd just like to tell you this open, public way so that others that agree can strengthen my point, and people that don't agree can voice their opinion as well.
 
Last edited:

nihiven

Member
I agree, these GML changes would make the most difference day to day.

  • GML: method data type to allow calling scripts through variables (i.e. foo=myscript; foo( 0, 1, 2); )
  • GML: exception support - try… catch… finally… and throw
  • GML: data structures as a true datatype (not just an index)
  • GML: Chained arrays and accessors - allow foo[a][c] (and accessor equivalents)
  • GML: Inline functions - allow var a = function( a, b ) { ….. }
  • GML: Accessor literals - allow data structure literals - var a = {| 1, 2, 3 };
  • GML: foreach statement to iterate over arrays and data structures
 
M

MoFaShi

Guest
I think these features are more important than others as well.
 
G

Guest

Guest
Just give us a stable release. Stop. Fix all the **** the new release broke. Bring the non-desktop ports up to current, full compatibility with those platforms' features, e.g., monetization. Proceed when GMS2 doesn't feel like a half-baked beta in a constant broken state.

Stability should be #1 on the roadmap.
 

FrostyCat

Member
On an added note, I want to give the IDE plugin API another nudge. It's way overdue at this point.

One of the most distressing things about Roadmap is how many of the IDE-side tasks are for things that existing programs already do well. It's almost like they are reinventing the wheel just to preserve theme branding and the idea of workspaces. Here are some examples:
  • sox can already generate tones and do basic audio processing.
  • Audacity can already do basic audio editing in a GUI.
  • svg2swf can already convert certain SVGs to GMS-usable SWFs.
  • ImageMagick can convert most image formats and extract PSD layers.
  • Geon FX, TMC Particle Lab and PixelCandy can already generate GMS-friendly particle systems.
If YoYo were to build these into GMS 2 themselves, the proprietary nature of GMS 2 would preclude the reuse of many existing solutions (especially open-source ones), or at least add a lot of red tape to it. This means duplicating a lot of work and reducing the amount of effort going into support.

Simply by releasing the IDE plugin API, end users and vendors can work on these independently and potentially release the plugins under the viral license free-and-clear. With simple program-to-program pipelines alone (i.e. minimal code within the IDE plugin, most work done by dependencies), you can easily take care of at least a dozen IDE-side items on the Roadmap this way. The time that YoYo developers don't have to spend on these features can be better spent fixing bugs and keeping extensions and runners up to date.

If only whoever is currently in charge of the IDE would understand that end users would rather have some autonomy over resource pipelines ourselves, instead of waiting for YoYo to juggle supporting GMS 2 AND pre-building pipelines in ways that may not best suit our needs.
 

kburkhart84

Firehammer Games
I think the GML additions are important, but I agree with @FrostyCat that the IDE plugin stuff is much more important. GML as it is, though lacking some features, still gets the job done. On the other hand, there are plenty of things we can't do that we could with IDE plugins. For example, my FHInput configuration program currently has to run external to the IDE, but it would make perfect sense to run it in the IDE. Even the above-mentioned particle system editors could also be integrated into the IDE, but instead have to be external. If they did things right, we could make a particle system editor directly make files, within the IDE resource structure(external resources for now), and then have code that easily loads those. But no IDE plugins means none of this happens. This is one of the biggest things that would jump GMS2 to the next level(right up there with how shaders changed things for the better). GML additions would just be a convenience feature...IDE plugins would be a whole 'nother ball game.
 

HW.

Member
I prefer having these (of GMS2 Mobile esp. Android module) if i become a respondent of a roadmap survey:

1. stable,fast,efficient IDE and runtimes.

2. stable,fast,efficient and up-to-date mobile modules runners such as APIs,JDKs,NDKs, Android 64bit support (64bit is already on Q2 of 2018 roadmap list, that's a great move YoYo team! we appreciate it, keep it up! because in 2019 it will be already mandatory to be published on the platform)

3. lightweight processing for GML,objs,functions,CPU,memory,hardware related processing,etc.

4. well working and up-to-date official extensions for essential features for published games such as monetization features: ads, iap, package expansions, and social networking features e.g. social shares, leaderboards, etc. Those features are things related to the needs of game publishers~players' end to survive the market industry (I believe many of us investing on hundreds~$ GMS2 mobile modules license don't spend the relatively-pricey budget just for a personal hobby to make games to be played by just the creator and few friends only? and not want to publish it to compete the market industry, (success or not is another case), but it is so ordinary that our dream is to make our games accessible and be played by as many as possible players, so it must survive to compete on market with must-have essential features, imho).

5. Extensions and marketplace update, easier process to make extensions for anyone including non-expert users (newbies) with official guides (steps by steps to do, templates, samples), personal library things update. This number 5. is significant if number 4. isn't well provided so that there's alternative for solutions.

6. Any Optimizations of existing functions/features especially on the mobile runtimes (e.g. YoYo's internal java codes on the runner engine that have errors on lint report unfixed for years, those so-called deprecated "regular warnings")
(please fix and optimize those deprecated java runner codes on android runner lint errors report, it is growing on every new release! amount of warnings increasing from time to time from 30ish...40+..50+..until 90+.. of warnings if using obsolete yoyo's extensions or even not). Yeah some people will say to disable the report. But, Disabling lint report just "hide" the problem, not solve it, but it is still there un-fixed( or un-optimized yet). Most of them are on yoyo's end (runtime) to fix/optimize it)

I agree with others saying that for "graphics/sprites and audio/sounds", we can keep using the already existing softwares by the market leader of graphics/sound editor softwares such as photoshop,aseprite,audacity,blender,etc. And not all of those are paid apps, so you can also use the open source software alternatives to save budget which are also great softwares indeed (competitively full advanced already to the paid software, not just a lite product).

In my opinion GMS2 just needs to support the importing multiple formats of those assets (graphics/sounds) used by devs to create games such as vector,skeletal,etc.

Perhaps it would be more efficient if GMS2 just supports the importing of the already full-baked assets of sprites/sounds, no need to create advanced raw tools to process assets from scratch to full baked if they are graphics/sounds -related. Looking at recently releases, it is already about fixing bugs of non-image-editor which should keep going on. Because the currently existing image editor is more than enough already i think, just for making placeholders or simple ones are already more than okay. To make production-ready, to be frank, if we are serious on our game, we need to use those better external graphic/sound editor softwares (for polished graphics/sounds) so we can spend time more efficient because those leading softwares are already mature and proven years by the industry. By doing that, GMS can focus on its strength: make GML language to the next level on a GM engine that supports multi-platform with the final target of product (.exe or .apk, or html5, or .etc of games) to publish on the market.

Thanks for reading my feedback :)
Happy GMS2 Mobile user.
 

Hyomoto

Member
I do agree the IDE extensions could be a powerful way to branch out the program. There are lots of asset creator's champing at the bit to provide non-native functionality, but even from a user perspective it could be useful to set up your IDE to handle data in a way you want.

I empathize with trying to produce an all in one solution that caters to absolute newbies while being flexible enough to also dig into the nuts and bolts, GM is pretty awesome for that. I think @FrostyCat makes a compelling case there, as leveraging external platforms by providing IDE hooks could be the lowest effort, highest gain for the most users. It also seems several items on the list could be checked off this way.

Look towards to the advanced GML stuff too :D
 
Top