Designing a HTML5 Game
2017 | Goodgame Studios
The project started out as a tech pilot started from our Research and Development department to explore the scalability of browser games based on HTML5 and JavaScript.
After the "proof of concept" we turned the demo into a shippable product. The initial game concept was based on a previously released mobile version. Goodgame Empire: Millennium Wars is a complex MMO empire building game in which the player conquers and explores Mars. (Empire: Millennium Wars).
Goal
Build a next generation HTML5 browser game.
Pilot project to test native technology and performance.
Challenges
React.js was a new framework for the development team.
Mobile and browser development took place at the same time with different teams.
Keeping design changes to a minimum in order to align mobile and web platforms.
What I've achieved
-
Successfully lead the design for this project from ideation to launch
-
Introduction of the concept of a design system (Sketch + Storybook)
-
A smart UI allowed us to build a pseudo responsive interface that scaled down to 800x600px
-
I build an interface evaluation tool that helped artists to define colors of the game world in conjunction with different UI styles
What I've learned
-
I was very happy to work with such a skilled team on this project
-
UX design is an active part of the game design in games
-
Scrum works best with small groups that are highly proactive and collaborative
-
Sitting next to actual developers is the best constellation I could imagine for that project (and in general)
-
Atomic / component-based design for games is not a myth - it works better than expected
Setting Up Pipelines and Tools
During the project initialization, we defined a couple of goals:
-
Vision alignment
-
Change catalog (features)
-
Product goals and milestones
-
Communication documents
-
Deliverables & Design System
Design Pipeline
We put a high focus on re-usability, clear and agile documentation for design proposals and features, as well as an agile collaboration when exploring new patterns for the web version.
Utilizing a communication document for aligning project related naming conventions was a valuable tool as the project evolved.
Atomic Design Foundation
Going with Atomic Design was a perfect choice for the chosen tech stack and the design pipeline. We set up two additional systems:
-
Design System (sticker sheet)
-
Sketch master files as as single source of truth
-
Abstract as a versioning system
-
Zeplin for the front-end synchronisation
-
-
Living Style Guide
-
Component storage and live preview for all components
-
Synced with development and production environment
-
 Atomic design in a nutshell - this is part of a pitch document for the team |  UX design and game design go hand in hand when evaluating mechanics that will have an impact on the interface / ux |
|---|
Architecture
Defining the information architecture included:
-
Responsive behavior
-
HUD mapping
-
Cross-platform experience
-
User Flow & Behavioral patterns
-
Content distribution
Responsiveness
One major business requirement was the partner portal integration (e.g. gaming portals) and therefore a minimum playable resolution of 800x600px.
I solved this with anchored HUD zones that were populated with corresponding components. The interface heavy interactions were handled by a centered panel with two flexible content spaces.
At the lowest resolution, only the main panel is visible and provides a good playability throughout all screen sizes. Additional breakpoints were added for future responsive improvement sprints to maximize the usability on 4K screens.
Extending the mobile game design
Free-to-play games often restrict certain parts of the the UI design due to a complex economy balancing system that lies underneath. Certain interface elements are are designed to be cumbersome and clunky as part of the game experience. More important is a connected monetization aspect behind exhaustive interface flows. Players are willing to pay for shortcuts...
One hard requirement gave me a hard time to solve and test properly: 800x600px playable resolution. This small resolution came as a requirements of a partner site integration that allows players to play in small iFrames.
I came up with a main/secondary dual panel concept what worked well on all screens. It also reduced the amount of development work to make everything responsive / scalable. Only HUD elements needed additional breakpoints while the main interface floats in the center.
 We agreed on a list of ui vocabulary as a part of our communication documentation. This enabled the team to use a shared set of definitions. |  The chosen interface approach scaled nicely from 800px up to 4K. For high resolutions we planned to implement a "UI-double scale break point". |  We agreed on a list of ui vocabulary as a part of our communication documentation. This enabled the team to use a shared set of definitions. |
|---|
Wireframes and Components
A crucial factor for the success of a free to play browser game is the accessibility. Loading time is one of the pillars. The whole interface design of this game was based on code whenever possible. Only illustrations and banner graphics were added as images. All monochromatic icons were vectorized and embedded in an icon font.
I imported all images from the mobile version into Sketch and linked it with appropriate components. The symbol-override feature allowed me to create real-data wireframes which are the best way to determine whether the design is working properly.
 The UI color exploration happened in several workshops along with the art director and internal preference tests. |  New wireframes were fast and consistent thanks to an elaborate component sheet. |  I had to create all dialog windows within the context of the background and all possible environmental dependencies. |
|---|---|---|
 The image library was a great solution to work close with the artists. New art was pushed into this library and I only had to connect it with the corresponding components. |  Some ui elements became pretty complex due to some deep game mechanics. I started building up nested components to make it easier for the later development. |  Another example of nested components / modules. |
Rapid Prototyping
Prototyping was a constant layer from the very beginning. I started with simple paper prototypes to determine UI flows and the distribution of HUD components.
Later I used more complex tools that allowed UI Designers and stakeholders to rotate several interface designs in a game-like environment. All interaction patterns were tested and approved before implementation via prototyping.
Framer’s code-based interactions were perfect for the handover to developers. All UI animations were also embedded in the style guide to provide consistency throughout the patterns
 Interface study of the inventory system |  Building simulation via rapid prototyping in Framer. |
|---|
Play the game (new theme/title since 2020)
Conclusion
The pilot turned into a success and we got green light for a public game launch. It was the first native game based on HTML instead of a game engine or framework. We delivered within 9 months which included a learning process for development to move to REACT.JS from Unity / C#.
I am proud of the technical result and how smooth the development went.