Project
SaaS Game Engine - B2C/B2B
Timeline
2022 - 2024
Team
Senior Product Designer, One Developer
Industry
Gaming & Technology
Overview
I led the design of the new code editor which was part of a large overhaul of the workflow of GameMaker.
GameMaker is an award-winning 2D game engine with over ten million downloads and almost 300,000 active monthly users, seen all over the world as one of the most accessible tools for developing games.
After a huge update release, the team took a step back to assess the current state of the product. It was decided that after six years of steady development and user feedback, it was time to change things up.
The design team were tasked with treating the next iteration of GameMaker as a completely new software and to experiment, research and create new solutions to make it the best tool for our users.
"Making Games is for everyone" is GameMakers main company goal, it's reflected in the brand, the product, the staff and the community and we want to make sure that anybody no matter the skill or background should be able to make a game.
Rather than user personas I created a "user scale" to reference when making design decisions. Different parts of GameMaker can be targeted at different users meaning during the project I would reflect back on this and pinpoint a feature to a region.
We have three main users, beginners (people who are still learning game dev), Intermediates (people who make games as a hobby) and professionals (users who use the product to make money from). We also have to consider the different backgrounds these users may have and what biases they may already have from other experiences they have had.
Limited Space
The IDE (integrated development environment) was too cluttered.
Bespoke Enforced Workflow
Workspaces, the default workflow, were not being used as intended. People were closing editors and starting from scratch.
Too Rigid
Not enough customisability and users were feeling restricted in their workflow.
Required Coding
Some key features involved too much complex code and had no UI.
Full-screen Editors
We wanted to expand the UI so that users had the most space possible when developing and navigating the editors.
Redesign The Fundamental Workflow
Experimenting without workspaces and creating an inspector window flow we reduced the user's need to pan around or jump between places.
Improve Customisability
Giving the user ways to customise their workflow we made it feel like a personal tool that works best for any type of developer.
Provide Front End Editors for Complex Features
Full-screen editors were provided for complex features only available in code, such as the particle editor.
Design Lead Approach
This meant we handled the feature research, we would set the direction and investigate as many solutions as possible. By doing so, we had all stakeholders on board before it had started development. Communication is key
Incremental Changes
Instead of doing one or two huge releases a year, we changed to smaller monthly releases. Allowing us to gradually release larger, more complex features over time through phased development
As people use the product to make money we absolutely could not make any design changes that would break or ruin their projects, resulting in a user potentially losing money. I created these methods of categorising design decisions I made and how they might affect a user's project.
Large changes, such as workflow redesigns, would be placed behind a setting to allow the user to test the feature and get used to the workflow. Each feature designed would move to a beta build to allow for rigorous testing and iteration on user feedback.
01
Large Impact
Large-scale redesigns of current systems.
Touches parts of the tool that are fundamental to workflow.
Will affect all users, mostly existing, loyal ones.
02
Medium Impact
New editors or features.
All users will need to learn functionality.
Won't affect what already exists.
03
Small Impact
Smaller/discrete changes to existing features.
Improvements that current users won't be thrown off by.
GameMaker's old user workflow was based on opening assets in node chain windows on a workspace. A workspace is an infinite panning space where all editors can be opened and worked on at the same time. Each game asset type had a specific editor open in a workspace. Each editor was bespoke to the asset. Each editor is made up of cascading, expanding node chain windows.
After Observations
The results showed users found this frustrating and only opened one or two editors before getting lost or panning through irrelevant editors, leading them to close everything and start again while only opening the one asset they wanted to edit
We began by exploring how we could potentially rework the workflow. This meant exploring full-screen editors and how they could fit into the software. We tried out versions that would utilise full-screen editors.
There were a handful of directions:
1. Inspector window based
2. Full dialogue box windows
3. Four-way split screens
4. Expansion of existing node chain editors
Forces the user to handle floating windows resulting in overlapping editors and frustration while editing multiple assets
Each editor is extremely spacious and it's clear what users are editing. This allows for full-screen and multi-monitor editing
An industry standard and can suffer from "tab overload" if a user has too many assets open
An industry standard that allows for spacious and clean workflow with excellent customisation potential
These are unlike any other creative software meaning users will have to learn specifics of functionality. It's quirky.
Its unique and can help stand out against competitors. It allows for shortcuts to create an interesting workflow. It's quirky.
Ultimately, as a team we settled on full-screen tabbed editors with an inspector window, letting users select an asset from anywhere and be able to edit in one formatted place.
The theory with this option was to reduce the learning needed for each bespoke editor, open up space for full-screen editors to address the issue of cluttered workspaces, and limit throwing the users around different parts of the tool.
This solution is also scalable for future features and offers more standardisation of design to work upon.
I did three versions of the inspector window all after iterations on feedback we gathered after testing our prototype.
Version One
This version was aimed at replicating the editors in vertical form, however, every element was bespoke and would cause problems when developing
Version Two
I tried giving this version a vertical split to allow for expanding the properties however it felt awkward and often information was being hidden, forcing the user to resize the window
Version Three
I created a design system made up of reusable elements that would work across all editors, with only a few bespoke widgets for vital features, keeping it clean and consistent
Utilising the inspector window, we were able to fully expand the code editor into its new full-screen window. Not only did this open up the space for our users, but it also meant that we could combine other editors to work within the space.
This meant that instead of four editors for code, notes, scripts, and shaders, all could be opened in one space and work in the same way. So if we improve the UX of one, we improve them all.
To improve on the code editor I designed an in-depth navigation system to allow for quick and powerful workflow.
Asset
Allows the user to switch out the asset visible in the code editor. This can be any type with code available. It also means the user can close their asset browser and use this as a primary workflow.
Event
This allows the user to jump to certain code files within the same file, reducing the need for tabs.
Function
For the more advanced users this allows the user to jump to a specific part of the code for rapid file navigation.
Version One
Before testing, I designed a version of the navigation to work as a drop-down bar that reflected the asset browser. This worked well however due to technical limitations and development time we pivoted to another solution.
Version Two
The implemented version ended up using the already existing asset finder used elsewhere in the IDE. This helped speed up development time and used a feature that users would be used to, with larger thumbnails for easier visibility.
An event in GameMaker is essentially a code file, which was handled by separate tabs previously. I suggested we combine all these into one file to allow for quick and easy editing.
There would be a preference provided for a certain few users that would want to keep these files separate.
Redesigning the code editor also gave the team a chance to improve the coding functionality by adding smart tooltips to help learners understand the code more. A mini-map of the code was also designed to make navigating large files easier.
A light-themed version has to be done for everything we do to help with accessibility.
There are three stages of development we deal with in terms of testing and iteration. The first stage is an internal build in the early stages (this is when we designers freak out a little at the state of things), after feedback and bashing things into shape we release a beta build. This is where we get most of our initial public feedback before moving to full release. These stages take as long as the feature needs to get done right.
When gathering feedback we turn to multiple different platforms. We have the GameMaker forums to observe user discussions, a huge discord chat where we can directly talk with users, a public Github where users can vote and like posts and requests, and finally social media.
This is a streamlined version of what was a huge task and is just one of many ongoing projects I've worked on during my time at GameMaker.
As the designer responsible for changing the way over 300000 monthly users use the tool it was a daunting task and required a lot of detailed design work and communication with the team.
Big workflow changes to creative tools are very hard and scary, however, with the right process and iteration via feedback, it can work with positive results
Technical limitations exist and should be seen as part of the process, not a source of frustration
People are more open to change if they have the power to opt in. Give them a setting to try out changes to get them on board. Ease them in.
Explore as many options as you can from the obvious to the weird, it is not wasted work it's fine-tuning the final solution
The design process is never linear and rolling with problems is a skill
Design systems are key for building complex creative tools quickly and consistently
A large project I worked on designing animation tools to fit into the current game engine ecosystem at GameMaker. I was primarily responsible for handling the canvas tools, animation curve library and consulting on the timeline.
