• 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.

Question - IDE IDE too crowded?

Status
Not open for further replies.

fetito666

Member
How can I make the IDE more comfortable looking like the setup in the tutorials?

http://imgur.com/a/MJoid

The first screenshot is from my setup (1900x1024), but the screenshot of the IDE from the tutorial IDE looks way cleaner. How come?
 

GMWolf

aka fel666
Probably because it was taken on a much larger screen with higher DPI.
Notice how a lot more can be fitted onto the resource tree?

A lot of users have asked for an alternative to workspaces: it simply wastes a lot of space. But so far YYG has been adamant that we just need to get used to it. I got used to it, sure, but I still think it would be way better with a simpler system for smaller screens.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The screens were taken on a 1920x1080 monitor... so I think the issue is with the DPI settings. You should check to see that windows is set to 100% dpi and not scaling stuff for accessibility. And you can also override the DPI only for GMS in the Preferences.
 

GMWolf

aka fel666
I'm on a 15 inch 1080p laptop, with widows scaling set at 100%.
I find that since I'm only focusing on a single window at a time, I loose a lot of space having all the extra borders (window border + workspace border + wasted space in between because I don't waste time aligning my view perfectly).
 

Surgeon_

Symbian Curator
I haven't got GMS2 yet, but I dread to think what it would look like on my 1280 x 960 monitor...
 

csanyk

Member
My laptop has a 4k screen, which I down-size to 2048x1152 so I can actually read text. The IDE is very crowded, cluttered, and inefficient with its use of space.

I like the concept of workspaces, but they definitely need work. It's understandable if YYG are proud of the new interface and believe in it. It's hard to throw away work and walk away from an experiment that doesn't work as well as it needs to. But I have to say when this many customers are voicing their opinion, the problem isn't them.

I will say, YYG have done a tremendous job with the IDE, making many improvements to its UI. There are still quite a lot of rough edges, missing convenience features that, if and when they get around to implementing them, will make a big difference.

Here's what I love about the new GUI:
  1. Everything can be moved around and docked.
  2. Nothing is modal. I can have anything open and switch to any other thing without having to close the first thing.
Here's what I don't love:
  1. The IDE is too monochromatic. I have a hard time with the icons in some cases, and I think part of the reason is that they don't use any color. The white on black aesthetic is stylistically cool, but I prefer usable over cool.
  2. The IDE doesn't remember enough of the customizations I make with arranging windows, etc. to make re-arranging it to be how I want it to be worthwhile. When I close a workspace, for example, that doesn't mean that I don't ever want that workspace to be available in my project ever again. It just means that I don't want so many workspaces open right this minute.

    To fix this: Have the IDE/project remember the workspaces that you've given names to, and list them in the Windows menu, so I can re-open one when I want to. As it is, if I close one, it's gone forever, no undo. Unnamed workspaces are then able to be treated as temporary. When closing an unnamed workspace, you should be prompted "Do you want to be able to bring this workspace back after closing it? Y|N|Don't ask me again" and if the user says Y, they save the workspace by giving it a name.

    To eliminate saved workspaces from the project, right-click the name of the saved workspace in the Windows menu, and select "Delete Workspace". Just make it clear to the user that "deleting' a workspace does not delete the assets contained within the workspace, it merely removes the workspace as one of the views of the project.

    You might say, "Well, why are you closing workspaces if you don't like re-creating them, and you expect to still need it later?"

    Well, I'm trying to reduce clutter, that's why. And this IDE gets very, very cluttered when you have a lot of assets open in their editors.

    Instinctively, I want to minimize the amount of visual noise, and so I close them. Even though I know by now that closing the workspace means it's going away forever, I can't help myself. The habits ingrained from using various desktop+mouse computers for 25+ years die hard!

    Also, if I middle-click by accident, which is fairly common with my laptop's mouse pad, which has a large middle button, it closes the workspace.
  3. By far the biggest issue with workspaces is that they only fill that middle region in the IDE window. I would love workspaces tremendously more than I currently do if workspaces were a full window-sized region, each with its own left, right, and bottom dockable regions.

    Why? Because, if you think about it, it makes the most sense.

    Let's say I have three workspaces, I'll call them Sprites, Objects, and Rooms. In one, I open up all the Sprite resources, so I can quickly and easily go into them and modify them or reference their properties. In Objects, I open up my objects, so I can quickly reference properties set in Object_1 when I'm coding something in Object_2 that depends on them. In Rooms, I have my room resources open.

    With me so far? OK, now if I'm in the Rooms workspace, of course I like to have my Room Editor panels docked at the left or right side of the IDE, because of course, that's how they are intended to work. But, when I switch to my Objects workspace, I have no need of the Room Editor panels, and there they are, still docked in the left/right side slots in the IDE, wasting space, distracting and confusing me!

    To fix this: If each workspace had its own left/right dock space, where I could dock stuff that's actually relevant to that workspace, things would be so much better. There would be less irrelevant visual clutter in any given workspace, and the workspace would make full use of the screen size, instead of being cramped into an area perhaps one half or one quarter the area of my display.

    There are many ways that workspaces could be set up, and this is a strength of the IDE that it can be set up to work how YOU need it to. So there shouldn't be "one right way" to set up workspaces. So I have been experimenting with different ways of organizing mine.

    I've tried having all the resources of a single type open in one workspace (sprites, objects, rooms, etc.) but I don't like this very much. I've also tried having all the resources related to a single conceptual part of my project open in one workspace (eg, a Player workspace for my Player objects, sprites, scripts; an Enemy workspace for my Enemy objects, sprites, scripts; etc.) and no matter how I decide to organize my workspaces, I still run into the issue of unnecessary-in-the-current-workspace-context panels being docked and taking up valuable screen space and visually cluttering my work environment.
  4. The Chain view is very space inefficient. This is the second biggest usability issue with the IDE.

    At first, I really liked the concept of Chain view, as it clearly communicates the relationship of various sub-editors to the main editor window, and keeps them together so you never lose them. Screen shots of the Chain view look really cool, and I get that it's likely a point of pride on the part of the designer of the IDE.

    And for a very large display I think maybe Chain view can work. If I could read text on my 15" 4K laptop screen, I might find Chain view to be useful without issues. But even at 2048x1152, which is very large, I find that Chain view forces me to scroll excessively in order to work on a single asset, especially horizontally, and it's just not acceptable. Scrolling around the workspace, or dragging windows about and resizing them so I can fit them into my already-too-small Workspace viewpane is a big time consumer, and it's a very unproductive use of time.

    YYG suggests learning to navigate by Ctrl+T, and I'm still getting used to that, but a keyboard shortcut in no way changes the fact that the visual/mouse driven GUI has a usability issue.

    To fix this: What would be better than Chain View? For me, I don't want to get rid of Chain views, for people who like them they're fine, and YYG put a lot of work into them.

    But I would like having options and alternatives, and rather than having Workspaces with a small viewable area but that represent a potentially infinite 2D field where I can lay out numerous resources opened in their various Editors, I would prefer a tabbed approach and for workspaces to occupy the full window, not just the center dock. Each workspace should be its own tab within the main window, and each editor open in the workspace should be its own tab in the center dock. Switching between tabs is way faster than scrolling about a workspace.

    Additional thought: Make keyboard navigation for Chain view. I know that Ctrl+T and Ctrl+Tab are recommended keyboard shortcuts, and I'm not sure what else there is as far as keyboard navigation, so if I suggest something that already exists, let me know about it. I'd like to be use a combination of Tab and Arrows and PageUp|PageDown and Ctrl/Alt/Shift modifier keys to navigate around Chain View, if these shortcut keys aren't already dedicated for other purposes.

    Something like this:

    Ctrl+PageUp|Down: Switch to Previous|Next Editor form in the current Workspace
    Ctrl+Shift+PageUp|Down: Switch to Previous|Next Workspace tab
    Ctrl+Shift+Tab: Switch to next Window in the IDE, if project is open in multiple windows
    Alt+LeftArrow|RightArrow: Shift focus to the Previous|Next form in the chain of the current Editor.
    Tab: Shift focus to the next field in the current form in the current editor.
    Shift+Tab: Shift focus to the previous field in the current form in the current editor.

    Those are just some rough suggestions, so if they conflict with other keyboard shortcuts, they may need some work, but you get the idea. Anything to avoid having to scroll about with the mouse, hunting through large empty regions of a workspace, hoping to find an open Editor.
  5. My workaround for now: One of the major saving graces of the GMS2 IDE as it currently stands is the fact that I can break out anything I want to into its own window. Then I can maximize that window, and make better use of my 2048x1152 display resolution.

    Breaking one resource out into its own maximized window makes the resource editor the only set of GUI controls that I can see, which is exactly what I want. If I'm in the Object editor, I don't want to see panels from the Room editor, which make no sense in that context; I do want to have the space to be able to see my object's properties, Events, and Actions/Code Editors, without having to scroll the entire Object editor about, or pan the Workspace so I can see the part of the Object Editor that I can fit on the screen that I need to work in for the moment. When I'm in the Code Editor, I want the Code Editor window to be large enough to display, say, 120-160 characters of text per line of code, and I want the entire vertical height of the code editor window to be in view at all times.

    I do not want to have to scroll about in the workspace, and I really do not like when the bottom of the code editor window goes out of view in the workspace, making it so that I can't see the status bar portion of the Code Editor window, and see the information there, which is very valuable and helpful. I rely heavily on the function signature information in the status bar to tell me the correct ordering of the arguments I'm supplying to a function, and for this to be cut off at the bottom of the window is a major handicap for me. So I end up spending time resizing the code editor window so I can see the bottom of the Code Editor.

    And I shouldn't have to; the IDE should know better, and open up windows at a usable size, a size that makes them fully visible. As it is, I find that the best way for me to use the IDE is to break every editor out into its own window, maximized, so I can focus exclusively on that window. This is OK, but it's really a workaround for overcoming the weaknesses of workspaces. The single-window experience deserves to be as great as it can be. Currently it's turning me off, for the reasons I've outlined above.
I've typed enough here for now, I think. I could go on, into minutiae, but I don't want to get too bogged down in details. I really think that if YYG would re-think workspaces so that each Workspace has its own dockable regions, instead of having Workspaces occupy the central dockable region in the IDE window, it would make a huge difference and would likely address a good 80% or more of the complaints that I have working with them currently.
 
Last edited:

fetito666

Member
Yes, my DPI scale is 150% (otherwise everything else is too small and I cannot read anything on my screen).

Is there a way to exclude GMS 2 from that DPI settings?
 

MilesThatch

Member
I have a 1440 and a 1080 screen and I love it on both. Maybe this is a Windows scaling issue.
@Hyomoto takes little time to share his patriotic admiration of the new workspace interface, as usual.

I am waiting for that DPI setting Mike talked about that will allow you to scale the GMS2:0 icons and menus. That outta free up more space from the clutter for low res and laptop users.
 

fetito666

Member
@Hyomoto takes little time to share his patriotic admiration of the new workspace interface, as usual.

I am waiting for that DPI setting Mike talked about that will allow you to scale the GMS2:0 icons and menus. That outta free up more space from the clutter for low res and laptop users.
So Yoyo is working on a DPI fix?
 

MilesThatch

Member
So Yoyo is working on a DPI fix?
It's not a fix as they are not changing anything permanently. It's a DPI setting that will allow you to scale the ide components, like text and icon scale, window menu and bar scale etc. Like the fine tuning file explorer on Windows. I do believe that all the tabs and menus take up too much space on top of everything nested INSIDE the workspaces which is why I'm looking forward to that feature.
 

fetito666

Member
It's not a fix as they are not changing anything permanently. It's a DPI setting that will allow you to scale the ide components, like text and icon scale, window menu and bar scale etc. Like the fine tuning file explorer on Windows. I do believe that all the tabs and menus take up too much space on top of everything nested INSIDE the workspaces which is why I'm looking forward to that feature.
Thank you for the information.
 
Z

zendorf

Guest
Switching between tabs is way faster than scrolling about a workspace.
This really is the crux of problem. If there was a way of having both the workspace concept for those that love it, as well as having a more basic context sensitive tabbed UI, I guess everyone would be happy. The best UI I have ever used for a graphics program is still Cinema4D. It is irrelevant that it happens to be a 3d program, what is important is how the tabs are laid out and how the context sensitivity works. A complete beginner can pick it quickly, but it still works well for a seasoned pro....which is the hallmark of an effective UI.

There is only one property panel, and parameters of any object you select instantly show up here, with tabs where appropriate. When objects are multiselected, it is easy to see which objects have common parameters, so that you can change parameters on multiple selections simultaneously. Any window can be floated or docked/tabbed as appropriate, so you have as much flexibility as needed.

Would love to see GMS move more in this direction...
 

Llama_Code

Member
By far the biggest issue with workspaces is that they only fill that middle region in the IDE window. I would love workspaces tremendously more than I currently do if workspaces were a full window-sized region, each with its own left, right, and bottom dockable regions.

Why? Because, if you think about it, it makes the most sense.

Let's say I have three workspaces, I'll call them Sprites, Objects, and Rooms. In one, I open up all the Sprite resources, so I can quickly and easily go into them and modify them or reference their properties. In Objects, I open up my objects, so I can quickly reference properties set in Object_1 when I'm coding something in Object_2 that depends on them. In Rooms, I have my room resources open.

With me so far? OK, now if I'm in the Rooms workspace, of course I like to have my Room Editor panels docked at the left or right side of the IDE, because of course, that's how they are intended to work. But, when I switch to my Objects workspace, I have no need of the Room Editor panels, and there they are, still docked in the left/right side slots in the IDE, wasting space, distracting and confusing me!

To fix this: If each workspace had its own left/right dock space, where I could dock stuff that's actually relevant to that workspace, things would be so much better. There would be less irrelevant visual clutter in any given workspace, and the workspace would make full use of the screen size, instead of being cramped into an area perhaps one half or one quarter the area of my display.

There are many ways that workspaces could be set up, and this is a strength of the IDE that it can be set up to work how YOU need it to. So there shouldn't be "one right way" to set up workspaces. So I have been experimenting with different ways of organizing mine.

I've tried having all the resources of a single type open in one workspace (sprites, objects, rooms, etc.) but I don't like this very much. I've also tried having all the resources related to a single conceptual part of my project open in one workspace (eg, a Player workspace for my Player objects, sprites, scripts; an Enemy workspace for my Enemy objects, sprites, scripts; etc.) and no matter how I decide to organize my workspaces, I still run into the issue of unnecessary-in-the-current-workspace-context panels being docked and taking up valuable screen space and visually cluttering my work environment.
This is by far the best solution I have seen to this. I do agree its weird that the room editor panels stay there once you have clicked out of a room. For the most part I do really love the work spaces though.
 

csanyk

Member
This is by far the best solution I have seen to this. I do agree its weird that the room editor panels stay there once you have clicked out of a room. For the most part I do really love the work spaces though.
I love the idea of them, as well; it's just a slight tweak to the implementation, and they'll be much better, and most of my complaints about them will be addressed. I really hope that YYG take this advice.
 

Cpaz

Member
The screens were taken on a 1920x1080 monitor... so I think the issue is with the DPI settings. You should check to see that windows is set to 100% dpi and not scaling stuff for accessibility. And you can also override the DPI only for GMS in the Preferences.
Are we talking GMS 1.4? Or 2? If it's 2 we're talking about, where exactly in the preferences would this be? I've looked in general preferences to no avail.
 
C

Claire

Guest
I don't think the DPI override made it into the current beta build, it should be in the next one however and you'll find it under General Settings -> Workspace -> DPI Override
 

11clock

Member
I don't think the DPI override made it into the current beta build, it should be in the next one however and you'll find it under General Settings -> Workspace -> DPI Override
Would it let us go below 100%? My computer is at 100% DPI and it still feels too cluttered on my 1080P monitor. I can't even have a full object shown in my workspace unless I move it to another monitor, and even then I can't set objects to automatically open on the other monitor. Also the resource tree is too bloated. I just want everything to be smaller than what they currently are on a 100% DPI 1080P monitor.
 
F

Feronar

Guest
One way to improve it would be to auto-collapse control panels for editors that aren't currently in focus. For example, when you switch out of editing a room and, for instance, go to the image editor or main workspace, the room editor control panel should automatically close or collapse.
 

Mike

nobody important
GMC Elder
Please see (search for) previous comments as to why we don't do this...
 

Agneum

Member
One of the major saving graces of the GMS2 IDE as it currently stands is the fact that I can break out anything I want to into its own window.
Except, when you open a script or an event, you can only open it in a fullscreen tab named after the event, or in the workspace, which would have you drag it and any other tabs out. Currently I have to open an object, click on all events (for the events to get added as sub tabs) then drag the whole window externally. Which takes quite a few mouse clicks...

I have a hard time with the icons in some cases
Completely agree. The resource view is not that easy to read either.

The Chain view is very space inefficient.
Yep, I'm mostly interested in the code window, but I can't collapse the events or the object without that window going as well. So I'm stuck with at least 3 windows chained.

the biggest issue with workspaces is that they only fill that middle region in the IDE window.
Which is why you want to work with external windows, right? But you can't open stuff in external windows easily.


The thing is that a lot of SMALL additions and fixes would GREATLY improve the editor. It's just up to the devs to set the priorities straight.
 

cidwel

Member
I'm finally done with GMS2 workspaces. The editor isn't bad at all but managing these workspaces is worse than managing tabs (i'm a senior developer, so I'm pretty used to quickfinds/tabs). I tried to get used to it for a month and cannot work anyomore with that. Anyway I find REALLY good the overall of the tools that GMS2 have (paths, room editor, animations etc) but since a week or so i'm using Webstorm for coding my game and the GMS interface for managing and creating resources. I find pretty cool that I can open the events and scripts from there, and GMS2 detects and updates any change I do to a file instantly.

Here's a sample of my project in Webstorm. I'm using javascript highlighting since is quite similar to GML, some tweaks to only see gml files and some others for disabling innecesary inspections. Even I have real control of the variables used in any file.

Now I'm really comfortable developing my game. This could work in any available code editor, so it would work flawlessly with ATOM, Sublime even Visual Studio Code. Hope YoYo never obfuscates GML files so I can continue coding like that.
 

Attachments

Last edited:

Agneum

Member
Here's a sample of my project in Webstorm. I'm using javascript highlighting since is quite similar to GML, some tweaks to only see gml files and some others for disabling innecesary inspections. Even I have real control of the variables used in any file.
Any chance you could do a short tutorial on how to set this up? As much as I would like to depend on the tools provided in GMS2, for the mentioned reasons in my earlier post I cannot. I'm sure there are plenty of people who would like to know how to do this.
 

cidwel

Member
Any chance you could do a short tutorial on how to set this up? As much as I would like to depend on the tools provided in GMS2, for the mentioned reasons in my earlier post I cannot. I'm sure there are plenty of people who would like to know how to do this.
I don't have the time and the mood to create a full tutorial about how to do it but I supose I can bring some quick hints to configure it:

- Create a new Webstorm project in the root of the GameMaker project. It is better to make a copy since i can't guarantee if something could break while using Webstorm with GameMaker.
- I do prefer not to see the *.yy and xml files so I filtered them out from the project tree. This can be done in Webstorm creating a scope (Settings > Appearence and behaviour) with this pattern: !file:*.yy&&!file:*.xml&&!file:*.iml
- Also check the "Automatically reload changed files" in GameMaker. It's the first check on General Settings
- Make sure *.gml files are opened as Javascript syntax in webstorm (Editor > FileTypes. Select Javascript and add *.gml extension as a "Registered Pattern"
- In Webstorm, go to Insepections > Javascript and disable the ones that you think aren't actually wrong patterns. It is better to just put the mouse cursor on wrongly errors in the Webstorm editor to see what kind of "Inspection" is and disable it if you don't need it

- You can diff the draw and draw_gui blocks since draw_gui are using 64 as the first index for the event (draw_1 / draw_64)

BTW I do not use D&D so I have not tested how this would work.I just create a simple code block action in the object events, so this code style makes Webstorm a good tool to code GML

Even if you can manipulate the tt/xml/iml files to create/edit resources, I only use Webstorm as the Code editor. I still prefer to create/manage any kind of resource using GameMaker:Studio. So I have webstorm in the primary monitor and GMS in the other one.

Sorry bout my poor english. Hope this works for people who aren't using DnD programming style
 

rwkay

GameMaker Staff
GameMaker Dev.
@cidwel - we have no plans to obfuscate / encrypt or do anything to the project files - they will remain clear text and should support the way in which you are working for the forseeable future, for Source Control purposes it needs to stay that way and allowing modification of external resources is part of Source Control too so that should continue to work as it currently is.

So you should be good using external editors if you wish.

Russell
 

Mike

nobody important
GMC Elder
@cidwel just take care with versions. We won't flag project file changes in the release notes, so you should take care when updating.
 

GMWolf

aka fel666
Can I just point out that if users are already turning to new editors, there is clearly a problem?
The all in one IDE has always been one of GM's strong point, and already that is crumbling away.

You have mentioned many times thatany people love the new IDE workspaces.

I have only seen people say its far better then 1.4, but that isnt saying much at all.
And the feedback you take from the IDE and during the beta asked for first impressions, never asking about what its actually like using it.
Of course the chaining workflow and sprawling workspace will get good first impressions, it looks cool.
But it just isnt practical! It really isnt.
And despite asking a couple times, I still haven't had an answer to this simple question: what information are chains supposed to convey? As far as I can tell, not much at all!

I hope you are aware that I love GMS2. Really do. And that's exactly why I'm being hash on the workspace system.

@cidwel I may actually start using webstorm to edit GM projects. It makes far more sense to me. Though, its a shame you cannot add events from within webstorm. Someone ought to build a plugin that would modify the object files too.
I am tired of adjusting the view in the workspace all the time...
 
Last edited:

Mike

nobody important
GMC Elder
@Fel666 Can I then just point out that we've been through lots of feedback both from forums, social media and surveys and very people few have issues with the IDE. You have to be very careful not to take what a few users say on here as what all users think. The fact is it's a very small number - the vast majority love it, and are excited to move over to it. It is impossible to satisfy everyone - utterly impossible, and we're not going to try. We will however keep iterating on it and trying to get something even more like, but we're not about to change the fundamentals that so many have clearly taken to.

The all in one IDE has always been one of GM's strong point, and already that is crumbling away.
I have only seen people say its far better then 1.4, but that isnt saying much at all.
Also... to say the IDE has ALWAYS been one of GMs strengths in one breath and then say folk are saying its FAR better than 1.4 and that isn't saying much is contradictory in the extreme. By definition if GMs strength has always been the IDE, and everyone thinks its FAR better than the last version, then I'd say we're on a good path.

The chains show context, ownership and code flow (where appropriate). Opening an object then a parent shows which object it belongs to - especially if you have several of these open. Code flow: Opening an event then several scripts and sub scripts let you follow code flow. If you disable the open in tabs, and full screen options where each script opens in it's own window, then you're basically seeing a full flow of code laid out on the workspace, but even without that you see scripts side by side so you see the call stack down to them.

As I've said before, while we might not agree with various arguments talked about here, we do listen to them all, and discuss many of them internally. But just because you disagree doesn't make us wrong, it just means you don't agree. :)

We do have plans to allow more "preferences", so that you'll be able to tune the workflow better to what you want, but we're not looking to change the fundamentals.
 

rIKmAN

Member
@Fel666You have to be very careful not to take what a few users say on here as what all users think. The fact is it's a very small number - the vast majority love it, and are excited to move over to it.
I've seen you say this in a few different threads / posts, and just out of interest - if the "official forums" are an almost insignificant number of users (~10k members) - where are they all?

The GM subreddit has ~17k users but I don't see any discussion on there regarding feedback from the community with a view to update / tweak GMS2, it's mainly questions from devs regarding coding problems, SDK issues etc.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I've seen you say this in a few different threads / posts, and just out of interest - if the "official forums" are an almost insignificant number of users (~10k members) - where are they all?
I suspect that you are being ingenious here...You say 10,000+ users but that doesn't mean they all post to complain... I've only seen a few of those 10,000+ users saying they have issues with the chaining and I suspect that that's what Mike is saying too.
 

rIKmAN

Member
I suspect that you are being ingenious here...You say 10,000+ users but that doesn't mean they all post to complain... I've only seen a few of those 10,000+ users saying they have issues with the chaining and I suspect that that's what Mike is saying too.
Not at all, it's a genuine question - you should never assume anything, I'm sure you know how the saying goes.. :)
You are correct though, a lot of the @10k users will be lurkers, but that goes for reddit too.

As I said I've seen it posted a few times that the users on here are a small subset of the overall userbase, and I don't know the numbers as YYG would so it's a genuine question as to where all these other users that must number way more than 10k reside online.

With the nature of coding, it's hard to believe there are an enormous number of users that never go online for help, advice, feedback (good or bad) and just use the product without any issues or problems they need help with - and if they did then they are also unlikely to be giving feedback at all.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I honestly can't say what the numbers are so I won't even attempt to approximate. But I can say that we get feedback from a huge variety of sources including:

Skype groups
Twitter
Facebook
In IDE questionnaire
Reddit
GMC
Email
Helpdesk

I will also say that people are more likely to contact us when they find something they don't like than when they find something they do like. So, if a lot of the contacts with YYG are to complain about something, and very few of them are actually complaining about the chaining but rather other things (docks, shortcuts, change in paradigm, etc...) then it's fair to assume that the majority are either indifferent or like chaining. This can be extrapolated out to the number of licences that people have and a percentage calculated. It0s not perfect but it does give a fair idea of where to concentrate efforts for future iterations.
 

rIKmAN

Member
I will also say that people are more likely to contact us when they find something they don't like than when they find something they do like.
This is usually true.

So, if a lot of the contacts with YYG are to complain about something, and very few of them are actually complaining about the chaining but rather other things (docks, shortcuts, change in paradigm, etc...) then it's fair to assume that the majority are either indifferent or like chaining. This can be extrapolated out to the number of licences that people have and a percentage calculated.
So would it be fair to say there aren't an overwhelming number of positive reports and feedback (as per the first point re: contacting when they like something), but more that YYG are taking a lack of feedback at all as sign that people are happy with it / are indifferent?

There will always be more people that don't say anything at all than there will people who give an opinion, that's the case in any walk of life (just look at recent elections haha!), but I think to infer results from this could be a little dangerous.

You probably think I'm being awkward, but I'm not - I only really use this forum with regards to GM, so I just wanted to know if there is some massive community of GM users out there that I had no idea about.

I have no dog in this race btw, I haven't used GMS2 enough to have a solid opinion either way as I'm waiting for bugs to be ironed out and (hopefully) some things to be added. I just don't think it's ever a good thing when a company dismisses its users opinions and feedback out of hand and classifies them as a minority.
 
I think a lot of people haven't given GMS2 enough time yet. People are quick to complain about changes and new things. For me, it took about 20-30 hours of coding before I started to value its newfound efficiency. My first two commercial games were built with GMS1, and my upcoming game uses GMS2, and I'm absolutely flying through development this time around. It's almost ridiculous how quickly you can create a solid game now.
 

Mike

nobody important
GMC Elder
I've seen you say this in a few different threads / posts, and just out of interest - if the "official forums" are an almost insignificant number of users (~10k members) - where are they all?
As has been said....most don't join a community when they start using a program, especially if they have no issues. I use a fairly pricey video program, and I've never joined their forums - never even looked to see if they have them.

I've used C# for 15 years(?) now.... never been on a forum for them.

GameMaker is used by hundreds of thousands of developers, we have 10K registered here - and who knows how many are just spam bots, probably about 1/3 (who knows).

So while the forums are an important place to get feedback, it isn't the final say by any means.
 

DeScruff

Member
I think a lot of people haven't given GMS2 enough time yet. People are quick to complain about changes and new things. For me, it took about 20-30 hours of coding before I started to value its newfound efficiency. My first two commercial games were built with GMS1, and my upcoming game uses GMS2, and I'm absolutely flying through development this time around. It's almost ridiculous how quickly you can create a solid game now.
I genuinely want to know how its more efficient, I feel like I'm constantly fighting the IDE.
For example: If I want to compare two scripts side by side, one will be pushed off screen because I placed the other too close to an invisible border. I'm not quite sure why this invisible border is to thick, or why its invisible, or why you can't tell if your placing windows too close to each other , or why it pushes things Up/Down, when Left/Right would be the shorter path, and wouldn't be so "jarring".
I got dual 16:10 monitors because that extra 1920x120 pixels really makes a difference when coding, but I almost feel like I need a 21:9 monitor to do a simple task like view two things side by side on the same screen.

EDIT: Its not 100% invisible: there is a line on the Right side, but there is no line on the Left side, to compare to. So you just have to eyeball it, and more often then not I'm ~1 pixel off and something gets pushed off screen.
Im still not sure why this "Push other windows (or whatever they are called)" practically offscreen was a good idea vs letting them stack on top of each other.
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
If I want to compare two scripts side by side,
Then you open a new column in the script editor window. :) See the "Editing" section of the manual here: http://docs2.yoyogames.com/index.html?page=source/_build/2_interface/1_editors/scripts.html

Im still not sure why this "Push other windows (or whatever they are called)" practically offscreen was a good idea vs letting them stack on top of each other.
There is a preference to change this behaviour if you so wish. See the "Allow workspace chains to overlap" prefernce in the Workspace section of the General prefs.
 
I

icuurd12b42

Guest
We do have plans to allow more "preferences", so that you'll be able to tune the workflow better to what you want, but we're not looking to change the fundamentals.
Please have an option to disable the Workplace entirely, it's the sore spot of everyone I talk with. It's not improving my workflow and the options I have set to almost have something working is half broken, splitting script in multiple tabs over the course of a session. I am alway hunting down where the script window is... Losing opened scripts, having to re-locate them in the treeview. like we used to do in 1.4 the result is more clicks to get where we want.
 

DeScruff

Member
There is a preference to change this behaviour if you so wish. See the "Allow workspace chains to overlap" prefernce in the Workspace section of the General prefs.
Oh thank god, thank you so much. instantly 70% of my frustration is gone.
Kinda surprised I didn't see that in the preferences before. There are a lot of options so I guess I skipped over it.
 

Mike

nobody important
GMC Elder
Please have an option to disable the Workplace entirely, it's the sore spot of everyone I talk with. It's not improving my workflow and the options I have set to almost have something working is half broken, splitting script in multiple tabs over the course of a session. I am alway hunting down where the script window is... Losing opened scripts, having to re-locate them in the treeview. like we used to do in 1.4 the result is more clicks to get where we want.
This isn't going to happen. We will look to add more preferences to allow users to control where scripts go in full screen tabs etc. but we're not removing the workspaces. As I've said above, we've had very little in the way of negative feedback for them, there are a few on the forums who would like better control over things but in the wider community very little.

We are looking to allow you to restore a full screen event-script back to an object, to allow you to open all events of an object into a dedicated tab (so it gets named), and to goto the object whose script your in etc. We'll continue to add these kinds of things. But the workspace itself will stay.
 

zbox

Member
GMC Elder
:(

R.I.P nice manageable native windows from 1.4. I really can't get to grips with this new strange seemingly fully GPU rendered workspace.
 

Mike

nobody important
GMC Elder
Bleah.... windows on top of windows was quite probably the worst thing about the older versions. You could only ever have a couple of objects open max before you started to lose things. Even with multiple monitors it was just a mess. It's the one thing I truly hated about it - well, that and the old tile system.

The workspace allows you to lay them out - even if that's just in a column, then you can use the resource tree, keys, bookmarks. zoom or the mouse wheel to scroll move/scroll between them. Yes it's different an change is almost always hard, but it is much better once you're used to it.

And yes, it's a HW accelerated UI - which also makes the room editor fast for a change. This allows it to be fully cross platform, otherwise it'd be a nightmare (again)
 

zbox

Member
GMC Elder
Yeah I was thinking that you would have gone with the HW accelerated angle for the potential of easy x platform UI... smart move there. I generally stay away from structuring code with the GM objects and opt for data structure based systems so script tabs + two monitors has been a pretty good workflow for me.

Guess we'll have to see if I can get next to the new UI seeing as that's the way it's going!
 
S

Schyler

Guest
I'm not sure I see a point in the workspaces to be honest. Typically, my workspace just looks like this.

ws2.JPG

As I do more stuff, it just towers vertically. I use a laptop so I can't really easily drag the workspace around. I have tested laptop mode, but when the code editors are large finding a "free space" to drag around and access the resources you have open is just really annoying.

GMS 1.4 had a really horrible looking, but functional environment. GMS2 has touched up the UI to look clean, but I feel there has been a major usability regression. Look, if you maximize everything, the workspace disappears and it's a little better. I think that's how I'm going to use it.
 
Last edited by a moderator:

GMWolf

aka fel666
to say the IDE has ALWAYS been one of GMs strengths in one breath and then say folk are saying its FAR better than 1.4 and that isn't saying much is contradictory in the extreme.
An IDE isnt all good or all bad.
Being able to quickly edit any resource in the same IDE package is nice. Thats a + for all GM IDEs.
Having a bunch of windows was not so great. Thats a - for 1.X
Having a workspace system is (in my opinion) better than lots of windows, but not as good as a tabbes system.

So, yes, the IDE now is much better than 1.X IDE, because 1.X had many problems.
But it remains true that it was nice to have everything in a single package.
As i said, not black and white.

The chains show context, ownership and code flow (where appropriate).
I think thats the problem i have with chains: they show too many different things.
At first, i though they showed ownership. That makes a lot of sense. But then i realised i could middle click on a script in the code editor, and it would open the script with a link. Now its showing code flow, not ownership.
This is, in my opinion, poor design as it can lead to ambiguities.
Showing code flow isnt all that useful either, since we already have that information in the code...

I also dont undestand why chains would be the best way to represent the information: lets take objects as an example:
They can only ever have one, and only one, set of physics options, one set of events, etc. this infomation could be conveyed by having them be in the same panel. Having them be attached with chains seems like an excuse to use chains.

Why not have a larger object panel, with all the physics, etc. if you want to hide them, you collapse the sub panel, making the object panel smaller...

I also find that many resources do not make use of the chain workflow. Then you end up with floating windows, just like in 1.X. The difference being now you can not only loose you windows by moving them somewhere, you can also loose them by moving the view, or even by opening a new window that will push everythg around.

The solution to this has oftne been to use the quick find feature, (alt + t or ctrl + t or something), but this defeats the point of the workspace. As soon as you start using this, you are no longer navigating the workspace, you are essentially bringing up windows. Something that could have been added to 1.X.
In fact, im pretty sure someone could write a script to do that in 1.X.
In fact, looking at @Mike s streams, you only use the resource tree to find your resources. You make 0 use of the workspace.
But you constantly collapse every panel to make room for the chains and extra window borders. Loosing valuable time.
Basic Ui design teaches us every time we open a panel or window, we spend time studying it. This is why many IDEs opt to have the projects explorer constantly open, since it is someting you will need to access often.

I also want to voice my opinion on the surveys that where taken in early beta. They asked for first impressions, and seemed to fish for positive feedback. (Or at least, thats how i felt taking them).
As i stated before, the first impressions you are going to get from the workspace system are undoubtebly gonna be positive ones. Its good looking, and seems to have a lot to offer.
But once you get used to it, you see that the information provided is of very little use... but the questionairs never get that far.


I realize the whole workspace thing will probably not go away, after all, it seems like YYG have put a lot of effort into finding ways to make use of it (like the excesive chains with objects, or opening new chained code windows evrytime you want to go to a script). It shows you really care about it. I just wonder why.
 
Last edited:
I

icuurd12b42

Guest
^
It is also restrictive in its use and behaving oddly. when dropping things on the workspace sometimes it drops it where I want, sometimes it scroll all to way to another region because the item I dropped is already in the workspace, preventing me to define the workspace I want... It constantly moves, and zooms in when I don't want to. it uses single click when we'd been programmed with a double click mindset since the 90's.

I cant really put related stuff together, or place items in multiple places or workspaces, fact I mentioned day 1. it confines you, forces you to use large areas. there is a large workable area right there that I cant really use efficiently because it is STRICT in its presentation, it does not zoom far enough, so you can't move stuff from one part of the workspace to another without drag dropping and rescroling or close things when zoomed out in prder to redrop the item to the spot that needs it.

This is the workspace that resulted in me creating varying number of resources. things are so far apart. It's a GodD dessert.... and there are things not showing because it cant zoom out far enough... So I dont know where they are!!! Are we going to need a minimap to get through this!?

upload_2017-2-5_8-33-15.png

I think we can't really tell you what's right or wrong with this. I'm pretty sure we dont know in all actuality. It just feels Off. it behaves in surprising manners... And all the options you add to the preferences dont actually help us I mean YOU. it just makes every single one of us have his own idea of how the UI should act in a manner each of us find somewhat acceptable. Are you going to have so many options in there that the interface will be unrecognisable from user to user? The problem here is fluidity of use and many head scratching moments.

Fundamentally the idea is sound, heck it's stunning. It's more of a workspace thane the MS Windows OS is, but the execution is simply clumsy...

I would like to have object in there I could expand, be able to visually see the script flow, like I would in the old days, on my desk with printed code for example. explode an object to see it in it's entirety, dependencies and all.

Anyway, as I said, we cant really make recomendations on a concept that could be a paradigm shift, as it stands, it's a better windowing system in a canvas... it could be so much more.
 
Status
Not open for further replies.
Top