OFFICIAL [DONE] GameMaker Studio 2 Roadmap Survey - NOV 2018

Status
Not open for further replies.

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Hey! Following our last GMC survey (which was great and we will have results and actions to share soon) we have put together another survey, this time focused on GameMaker Studio 2 and your feedback for the product roadmap going into 2019 and beyond. Once again, this survey is anonymous and we ask for an honest response from you.

[DONE]

Thanks!
 
Last edited:

JeffJ

Member
Yes, please do. This is great.

I would love to see this data shared at some point, so we can actually get a glimpse into what the general GMS user seems to prioritize. Would make for a great discussion for the future of GMS.
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Mostly as Jeff said, we don't want this to be too in-depth, as we want to get a wide pool of results. Sorting 50+ items would be rather tedious for most, but we're likely to dig into all of the items eventually :)
 

gnysek

Member
Mostly as Jeff said, we don't want this to be too in-depth, as we want to get a wide pool of results. Sorting 50+ items would be rather tedious for most, but we're likely to dig into all of the items eventually :)
Sorting not, but "select 5 most important" would be great. That would give priorities.
 

sylvain_l

Member
voted!

A bit surprised how short and very generic it was. Ok making a full list of all the feature in the roadmap could be tedious, but like those very generic; I was not sure what some were relyed to (like better teamwork ... does it mean multi user edit symultaneously, slack integration, or what ?!?)
 
G

Guest

Guest
It makes sense that the options are so high level, given GMS2's long (looooong) running identity crisis---its lack of focus on either hobbyists or professional users. This suggests that YYG has at least accepted that they need to pick, and this is the kind of big picture data that they seem to need internally to decide on a general direction.

The decisionmakers sitting down at a meeting probably wouldn't understand what git means, you know?
 

JeffJ

Member
It makes sense that the options are so high level, given GMS2's long (looooong) running identity crisis---its lack of focus on either hobbyists or professional users. This suggests that YYG has at least accepted that they need to pick, and this is the kind of big picture data that they unfortunately seem to need internally to decide on a general direction.

The decisionmakers sitting down at a meeting probably wouldn't understand what git means, you know?
I think (at least really hope) that you're right about this.

This is actually something I used the "anything else you want us to consider" field to tell - that they should consider choosing who their main audience is out of those two polar opposites.
 

gnysek

Member
I think that YYG is aware of most issues, and even have an own idea about what to do, but as they are owned by Playtech, it's Playtech which decides on next steps. So this survey may be more for Playtech than YYG.
 

FrostyCat

Redemption Seeker
I just sent in my vote. This survey does seem to be a good first step compared to the radio silence in mid-2018, but I have reservations about its ability to really hit the pain points.

One major omission in my opinion is IDE and runner stability. GMS 2 is almost 2 years old now, and it STILL has issues with people losing their sessions and projects, and obvious omissions in certain exports (e.g. HTML5) have reached a breaking point. No piece of software can be perfect, but some of these problems are way out of line for a paid product.

Though I recognize the importance of monetization and API integration plugins for professional users, I no longer want YoYo being the one developing it. YoYo has been playing tortoise-and-hare with API vendors for half a decade, and in every case it ends up almost half a year late AND stealing effort away from engine-level work. Take Spine for instance: The current runtime is one major version behind, and it held the libpng security bulletin patch release hostage until the last minute. It's really time to delegate to vendors and developers who have an immediate-mode stake in the integrations, and only a re-focus on extensibility can enable that. As a result, I ranked Extensibility at 1, and Social Media and Game Monetization at 5 and 6 respectively. I could understand if someone would rate Social Media and Game Monetization higher because they need it right away, but the numbers don't tell all the facts.

And for disclosure, here is my response for "anything else we should consider":
- More focus on IDE and runner stability
- Open-source the internal test suite (with optionally a bounty system)
- Outsource the monetization, social media and API integration plugins
- Allow the helpdesk to re-post tickets to the GMC (with user consent and optionally a bounty system)
I strongly believe that the developer community is under-leveraged in general support, and this takes away from priority tasks that only YoYo can do.

Also, putting the survey on the GMC only is likely to carry a strong pro-rookie, pro-hobbyist slant. With professional needs being chronically neglected, the results may egg on YoYo to neglect it even more. I would be much more satisfied if this survey was also sent to developers in the showcase, for instance.
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
We are aware of the target and wanted this specifically aimed at the GMC. We have plans for this/other surveys aimed at wider groups.
 

dadio

Potato Overlord
GMC Elder
"Creative funtionality for designers and artists"

Survey needs more clarity on what things mean.
See this option here for example...
I read it as "more stuff like Sequences, improvements to "Rooms", level editors, maybe some procedural level design support etc." stuff that basically allows designers to effectively create / implement large parts of how the game works by themselves (without code support) - which is a great thing.
But some might read that as "image editor and sound editor stuff - asset creation tools" - which is completely different and a waste of YoYo's time (I think, as most people use external apps for that.)
 
T

TimEdits

Guest
Would love to see a more complex audio system within GMS:2. One that can be used to add effects like reverb, chorus, EQ, lowpass, and highpass filters, along with the ability to manipulate their parameters.
 
G

GVmG

Guest
Done.

In general I'm very happy with GMStudio2's current state, even moving from 1.4 to 2 wasn't that painful of an impact. As for suggestions, it'd be mostly large scale stuff (like more external support for, say, other kinds of extensions or languages, or IDEs, or whatever), or specific details (like the current camera system, what in the name of god happened to it lmao).
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
"Creative funtionality for designers and artists"

Survey needs more clarity on what things mean.
See this option here for example...
I read it as "more stuff like Sequences, improvements to "Rooms", level editors, maybe some procedural level design support etc." stuff that basically allows designers to effectively create / implement large parts of how the game works by themselves (without code support) - which is a great thing.
But some might read that as "image editor and sound editor stuff - asset creation tools" - which is completely different and a waste of YoYo's time (I think, as most people use external apps for that.)
Definitely moreso the first option!
 

gnysek

Member
Ha, I gave nearly lowest priority for artists tools, as I thought it's for making graphical assets (but image editor still lacks several things that 1.x have). Designers and level designers are two different things :D
 
K

Kios

Guest
I suggested something at the end I wanted to share here.

In my analysis GMS could be a contender for messenger games et all, If it slight remodeled it's HTML5 export.

My suggestion was that for this platform specifically, GMS should offer the choice of bundling in the engine export only the "modules" or functionality that you choose.
So, say I'm only using the rendering bits, no physics or pathing or whatever functions, i could only bundle the rendering side of the engine, and use it as a multimedia library. I think the potential is there for a much smaller html5.js export, but YoYo Games has to want to do it.

Also a big +1 to everything everyone else said, specially FrostyCat, as usual.
On a side note, I hope the creative/artist tool gets the lowest priority. Really hoping for the day YoYo games will drop all of the "beginner friendly" tools, or whatever, like the image editor, and focus on actual developer tooling, like better support for coding(JeffJ has commented on that extensively before), etc.
Personally I think coding should be done through visual studio, and YYG should just support that, but never mind.

I hope this survey helps GMS in anyway, good luck to you guys!
 
N

NWC1990

Guest
In the additional comments section, why did I draw a blank??? o_O I always have something to add. lol
 

Mert

Member
Just submitted, but I'll also write it here.

Please extend the Game Maker to be operated with external sources easily. Just imagine that we can create java files on GMS IDE, and do stuff there. Same goes for Cpp. Extension system is too tiring.
 

FrostyCat

Redemption Seeker
Just submitted, but I'll also write it here.

Please extend the Game Maker to be operated with external sources easily. Just imagine that we can create java files on GMS IDE, and do stuff there. Same goes for Cpp. Extension system is too tiring.
I for one would NOT want YoYo to spend time reinventing the wheel for a Java or C++ editor. YoYo won't have time to do as good a job as established players, and any time spent trying to compete with them would be stolen from more important upkeep, support and engine-level development. It's the same reason why I oppose further investment in the sprite editor and new work on the roadmap's sound/tone editors.

YoYo's efforts are better spent integrating with existing products (e.g. Eclipse or Visual Studio in Java and C++'s case), rather than trying to wear their hats.
 
S

Steevo

Guest
Extension system is too tiring.
The extension system is great. Add the DLL, put in the name of the function, and you are done. What is tiring about that?

I even have VS running a post build batch file that overwrites the DLL in the GMS project every time you hit compile.

It would be hard for the extension system to be any better in my opinion.
 

FrostyCat

Redemption Seeker
The extension system is great. Add the DLL, put in the name of the function, and you are done. What is tiring about that?

I even have VS running a post build batch file that overwrites the DLL in the GMS project every time you hit compile.

It would be hard for the extension system to be any better in my opinion.
The GMS 2 extension system is a huge regression from GMS 1.x, and that's not to say the one in GMS 1.x is that much better.

For one, the biggest omission in GMS 2's extension system was dropping the ability to create local asset packages. They aren't just for selling to or sharing with the public, they are instrumental to private resource sharing and project merging workflows. Even for those containing only code, objects are sometimes needed to mediate in-game background actions, and sharing them properly requires the asset packaging workflow. Instead of porting the UI faithfully, some smart-alec at YoYo thought it's a good idea to force everyone to upload asset packages to the Marketplace and commit to a permanent ID, even those not intended for reuse outside the studio where they came from.

As is also the case with GMS 1.x, again there is NO documentation on anything at the native level but how to accept parameters and return simple values, and for only a few exports, how to trigger asynchronous events. Hooks to the drawing surface, audio stream, data structures, internal resources and other native-level resources remain largely undocumented, if they exist at all. Attempts to reverse-engineer these hooks come apart the instant something in the runner gets optimized. As a result, I don't think there is a single engine out there that struggles as much as GMS does with implementing video, audio and new forms of graphics rendering.

For GMS 2 specifically, YoYo designed the IDE ground-up to be extensible (so much so that EVERYTHING on the current IDE is actually a plugin), but to date the API docs are still on the cards. That defeats its purpose from the roots up and wastes the effort spent in its design. It also synthetically limits IDE work to only a small minority that knew the architecture's unwritten rules, thus the slow response to IDE problems for much of GMS 2's lifetime.

In my opinion, it would be hard to say that the extension system can be signed off in good conscience.
 
S

Steevo

Guest
The GMS 2 extension system is a huge regression from GMS 1.x, and that's not to say the one in GMS 1.x is that much better.

For one, the biggest omission in GMS 2's extension system was dropping the ability to create local asset packages. They aren't just for selling to or sharing with the public, they are instrumental to private resource sharing and project merging workflows. Even for those containing only code, objects are sometimes needed to mediate in-game background actions, and sharing them properly requires the asset packaging workflow. Instead of porting the UI faithfully, some smart-alec at YoYo thought it's a good idea to force everyone to upload asset packages to the Marketplace and commit to a permanent ID, even those not intended for reuse outside the studio where they came from.

As is also the case with GMS 1.x, again there is NO documentation on anything at the native level but how to accept parameters and return simple values, and for only a few exports, how to trigger asynchronous events. Hooks to the drawing surface, audio stream, data structures, internal resources and other native-level resources remain largely undocumented, if they exist at all. Attempts to reverse-engineer these hooks come apart the instant something in the runner gets optimized. As a result, I don't think there is a single engine out there that struggles as much as GMS does with implementing video, audio and new forms of graphics rendering.

For GMS 2 specifically, YoYo designed the IDE ground-up to be extensible (so much so that EVERYTHING on the current IDE is actually a plugin), but to date the API docs are still on the cards. That defeats its purpose from the roots up and wastes the effort spent in its design. It also synthetically limits IDE work to only a small minority that knew the architecture's unwritten rules, thus the slow response to IDE problems for much of GMS 2's lifetime.

In my opinion, it would be hard to say that the extension system can be signed off in good conscience.
Yes, I agree with everything you have said there.

I was talking from the point of view of creating and using an extension.

But that said 're-using' is a tedious task, that's for sure. Probably done on purpose in an attempt to cut out other marketplaces like itch.io.
 

csanyk

Member
Responded. Thanks for giving us the opportunity to provide feedback on the future of the product. <3
 
Status
Not open for further replies.
Top