Games
Client
The Games Company
William Hill
Betfair
Loto-Québec
Year
2013 - 2017
Role
Design Lead
Our goals
Pushing the technical limitations and delivering high quality games.
A lot of the existing in-browser games were done in Flash; not full screen (with a "boxed-in" fixed ratio, or zoomed in, blurry assets); and only worked on some devices.
We wanted ours to stand out for their technical quality:
HTML5 and full screen, working on all devices and resolutions, and with absolutely no loading screens mid-game. We also needed to account for multiple languagues, including Arabic and Traditional Chinese.
So, they had to be extremely optimised.
My role in the process
A lot of the optimisation happens during planning.
This meant, from my part, a big involvement from beginning to end, working closely with Product and Development, while shaping the Product and Creative specifications.
I managed not only everything related to the Visual and Sound assets, but also created the Product specifications, and other specs for Development. I'd then work with the developers on the correct implementation of all these elements - reviewing, giving feedback, and adjusting assets, as we tweaked all the details in the final game.
From a practical point of view, this included:
- Writing the games' functional specifications
- Managing creative work, and timelines
- Asset lists and guidelines for Creative
- Moodboards, storyboards, wireframes, flows
- Creating assets, screens, and animations
- Managing sound process and asset delivery
- Preparing final assets (or managing the process)
- Assets specifications and handover to Development
I also created a lot of buttons.
And symbols, backgrounds, animations...
Some case studies
Two Tribes
The challenges
Character
animation sets
With 18 characters, several actions each, and plenty of special effects, there was potential for the game weight to quickly become huge.
To run smoothly, it needed to
be light.
Animations
triggered simultaneously
At several points during the game, lots of animations would be triggered at the same time. Characters moving, arrows flying, symbols exploding...
This could cause the game to stutter or freeze, which could not happen, as these animations happened at crucial moments.
Colossal
Symbols
This game features Colossal Symbols (larger than usual, filling big sections of the reels), meaning larger files and more game weight.
Potentially chaotic screen
Even on idle, the game was filled with action and elements.
Still, it needed to remain readable, usable, and pleasant to interact with.
How we did it
Collaboration from the start
I worked closely with Product and Development, to define tight wireframes, storyboards, asset and game specs. This ensured minimal game weight without compromising creative quality.
Smart storyboards
Good storyboards were crucial for this game, ensuring not only the final weight would be doable, but also that the game wouldn't break during any in-game event.
Logical components
The animations were carefully split into logical categories.
This allowed the animation team to create within technical specs, and also made the developers' work easier, by using logical shared components to animate.
Bill and Ted's
Excellent Adventure
The challenges
Old footage
Metro-Goldwyn-Mayer provided us with the best possible source materials, however the movie is from 1989, so the quality was inevitably lower than ideal for a 2014 game.
Embedded video
This game featured lots of video clips from the movie, which was our biggest technical challenge, considering the game was in HTML5, and that the videos would be embedded.
This could easily mean too much game weight, or difficulties playing the videos in some devices and browsers.
Lots of screens
This game had more full screen features than usual, meaning, of course, more backgrounds and assets, and more game weight.
Crowded screens
Some screens required lots of elements (characters, buttons, text...). We needed to be careful to not let them become confusing, unreadable, or unclickable, especially on mobile.
How we did it
Insane rewatch amount
I've lost count of how many times I've watched the movie. Replaying the same bits over and over, meticulously taking notes, screenshots, and writing down video and audio time stamps, looking for the best clips, but also the most economic weight-wise. This was tiring, but still kind of fun.
Meticulous planning
& smart assets
Because we had so many assets (the videos alone took so much space), we had to really invest in planning them well. For example, we had to be very smart about backgrounds, spliting and planning assets carefully, and using code over images wherever possible.
Hours of retouches
We worked with a great creative team, who spent many hours working on the screenshots supplied, chopping them up, and doing retouches, to bring them to the required specifications.
Cash Cowboy
The challenges
Animations triggered simultaneously
Similarly to Two Tribes, this game often had many animations triggered simultaneously, which could cause the game to stutter, or freeze.
This was not an option, as these animations happened at crucial points in the game.
Colossal Symbols
Colossal Symbols are larger than normal, filling big sections of the reels. In this case, not only all symbols could be colossal, but they also took the entire reel size when expanded. The amount of symbols was also higher than usual, meaning a huge amount of file size for symbols alone.
Neverending features
We knew from the start this would be one of the hardest games we had to create. And then, the features and screens kept coming in. This was a big challenge both technical, and planning wise.
Agressive timelines
Despite being especially technically complicated, this game had a similar (already tight) timeline to others games, until release.
How we did it. (We did it!)
Storyboards, wireframes,
and asset lists
These are crucial for any game, but were especially so for this one, as it would not have been technically doable without some incredibly strict planning. Every on-screen pixel had an impact, as did every stage of a storyboard.
Technical creative decisions
Our creative decisions had very technical reasons to be. Assets were, whenever possible, split into small repeatable portions, or used code, with creative colaborating closely with development throughout.
Cel-shading was the chosen art style, to reduce file weight.