Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Trials and tribulations of being an off-site designer. Communication and management.
Background
Several months ago I started working with EnsenaSoft who wanted some design work done to improve their overall quality of games. They had done plenty of games in the mobile field, many of which were adaptations of non-digital games into the digital realm, such as Mahjong, hangman, and backgammon. In addition, they had some games in the style of older or more popular games, but very little that seemed "new."
Their original game designs were interesting, but suffered from either a lack of complexity or tight control schemes to help keep the player interested in improving their skills.
The client is based in Mexico, so in person meetings are nigh impossible. Phone calls were a primary source of information passing early on in the project.
The Project
In the initial call with the client, he described wanting to do something in the vein of another game classic, Boulder Dash. For research, I scoured the internet for forums, fan games, comments on the originals, what worked, what was disliked, and its overall mechanics.
As it turns out an official successor to the Boulder Dash title was recently released, the 30th anniversary edition. While its mechanics and features stayed very true to the original, and I had designed several new challenges that would give ours a definite edge, we decided to venture in a new direction and expand our horizon a bit.
There has been a minor resurgence in 2D puzzle/action games lately, Unmechanical, Stealth Inc 2, Beatbuddy, to name a few. The client added in stealth action features, moving lasers, laser grids, cameras, buttons and doors, etc. This happened several more times, the client adding new features while I had little control over how they functioned, and how they interacted with each other and the features already implemented.
Issues and resolution:
This is where we ran into an issue with communication. I was still in a core design phase, attempting differentiate between bugs and intended features, clarify mechanics, and see how it all fit together, but the client was expecting level production, and we would make changes to the already created levels with new corrected mechanics. Eventually it was expressed to me that level production was of primary concern, and systems would have to follow and be fixed as time allowed. With the clarification we were on the same page once again.
The communication vastly improved; bug finds were clearly shown and resolved. New feature requests were handled more seriously as the client could better see how they fit into the levels being created. The gears were finally interlocking on their own. We were both able to work in tandem with clarification calls required less as email communication with clear instruction and examples were made more precise. Everything was documented in a location where both parties could see and comment and it made it very easy to make sure that both myself and the client were on the same page.
Reflection
Now as the project reaches its end I see what would have worked better at the start and how the client could have gotten more out of me earlier on.
Goals - Design is not very sexy until implemented. Especially systems and mechanics. Seeing measurable progress takes experience with design itself. Days could be spent on simply making sure that systems work and don't need to be changed. Having personal checklists of what is being checked or documentation on these features can avoid the "what is the designer doing over there" feelings.
Communication - The best method of communicating with a remote client/employee is tons of documentation. Clarity is of utmost importance when you can't just walk in and talk to someone. Keeping the information in an area where both the designer and client can see it, edit, and add information keeps design choices clear, allows you to give direct examples in real time, and lets both the client and the designer read/deal with the information in their own respective time. Occasional scheduled calls/facetime allows for more complicated ideas to be hashed out quickly, but the core of your communication will be text. Make it clear, and make it count.
Scheduling - Creativity can wax and wane as ideas come freely or you have a stint of writer's block. We eventually settled on a weekly review. This became one of my favorite parts of the changes to the interaction, as suddenly I was not as stressed if I was behind one day as I could catch up another when my mind was more cooperative. The weekly review kept me on task with a reasonable goal, while allowing for flexibility within that.
As we are close in on the end of the project, and EnsenaSoft decided that they wanted to move it to a more core audience than mobile allows. Level difficulty has been adjusted for the more precise control schemes of keyboard and controller; Visuals and sounds are being modified and finalized, and we have a greenlight page up.
Given the mid-stream switch to a more action/stealth game from a core action/puzzle, there are some rough edges, but it's a stepping stone for a client that is going from translations to writing his own story with unique characters and challenges. See more of the project on the Miko Mole greenlight page: http://steamcommunity.com/sharedfiles/filedetails/?id=512173872
Read more about:
Featured BlogsYou May Also Like
