FrameGame is a game project that me and a creative peer of mine are working on that is a subtle yet significant spin on “Pictionary” or “Telestrations”. This is an idea based on a creative exersice we've done in the past inspred by exquisite corpse.
Before we made any code or assets, we started with project's base-level requirements. This would serve as a starting point that we revisit and change as the project continues. The game should flow as follows:
• A player hosts a private lobby that others can join with a code
• The game then generates different prompts for each player
• Players draw animation frames based on the prompts and send them around
• The game generates animated .gifs from player's frames and distributes them
• Players vote on their favorites and save gifs to their device
• Winner is declared and game can restart
The first sketch of the game (left) compared to the prototype (right)
The image above was essentially the visual idea for the game, though it alse served as a good starting point for how we initially could think about the general design and layout of the game. With that to work from, I could then start coding the prototype.
The aforementioned prototype I was able to quickly assemble (only spending about 1 week on a playable version) using HTML5 and Node.js running on my personal pc to function as a basic server to allow for networked multiplayer. While this served us quite well to test the viability of the concept, we then turned our sights towards working on a production quality build. Because of the logistics of designing and maintaining our own potentially large scale Node server, we decided against coding our game from scratch and instead opted to make it in Unity using Photon Realtime because both are able to scale easily.
UI changes between game versions
I do a lot of bug testing during development or in small groups, this way I can streamline my efforts, though in larger test groups I try to make builds as bug-free as I reasonably can beforehand, so as to get useful feedback on gameplay and features. In our experience, users tend to focus on the bugs and forget the suggestions they might have had.
Once we have an adequate amount of feedback we can use to identify needs, missing features, and bugs, we then update the design doc, helping to solidify the concept and plot our next course of action.
We like to kick meetings off (time permitting) with our own feature ideation to get ourselves excited. These ideas go into a backlog that we sort through (usually after but sometimes during the meetings) and categorize by priority. Next we discuss design, share the progress on our tasks, and determine the milestones before we should start the next round of user testing. Frequently we revisit discussions about our tiered goals for the game’s initial release, subsequent updates, and what the final product should look like. We then catch each other up on completed tasks and general requests.
After we conclude the meetings, I update the docs to reflect our decisions and discoveries. Some of these updates serve as an active task list for us to reference as we continue development.
One time around the merry-go-round is not enough for a quality product to emerge. These steps are designed to help us ensure that we keep developing a good game that people enjoy. Our user testing has helped us identify aspects of the project we would never have discovered on our own. For instance, we discovered in our test groups that players who don’t associate themselves as animators are reluctant to play the game at first, but end up enjoying themselves much more than they thought. This led us to consider changing how we brand and market the game for a more general audience.
We’ve concluded Agile-like workflows to be a winning strategy for ensuring that a good game comes out at the end, and that is something I’m willing to work hard for.
Nearly every project I’ve done has its own unique set of challenges as well as opportunities for growth. FrameGame is no different. In this project I’ve increased my comfort with customizing workflows and gained a greater appreciation (as well as some strategies) for user testing.
Project organization practice is typically at the core of most of the projects I work on, however this one in particular, I’ve been working with an animator by trade who has not worked on game projects in the past, and is also collaborating remotely. Because of these factors, he has been looking to me for direction and project management. This has helped me greatly in pushing me to be more organized and to be ready to delegate tasks as well as knowing how and when to request on-demand assets.
This project is not yet released (currently in a privately playable state), though we have loved working on it so far and are dedicated to seeing it through to polished completion. I for one am excited to see the reception of our finished game.
Main menu and gameplay
Gifs from play testing
