Cracking the Code... Editor

GameMaker

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.

Time to Reinvent the Engine

The Problem

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.

The Solution

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.

Results

The results were great and most of our users, particularly power users who use the tool to release games were on board with the large changes to the product.

97%

Activation in Beta build

10/10

Power users approved direction

94%

Agreed solution improved workflow

Breaking the Workflow

Out With the Old

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

Experiment With the New

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

Floating Window Editors

Forces the user to handle floating windows resulting in overlapping editors and frustration while editing multiple assets

"Wildcard" Options - Quad Split Windows & Workspace Windows

These are unlike any other creative software meaning users will have to learn specifics of functionality. It's quirky.

Tabbed Editors

An industry standard that allows for spacious and clean workflow with excellent customisation potential

User Flow

Inspector Window

Keep it Consistent

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.

Variations

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

Full-screen Editors

Go Full-screen or Go Home

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.

Navigation

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.

Single Code Document

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.

Improving the UX

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.

Feedback

Roll Out

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.

And the Crowd Goes ...

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.

Takeaways

Summary and Thoughts

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

Next Project

GameMaker Sequence Editor

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.

Coming soon

Fancy a chat?

Get in touch