5 min read

Excavating Design as an Off Site Designer

Trials and tribulations of being an off-site designer. Communication and management.


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.



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:


Latest Jobs


Playa Vista, California
Audio Engineer

Digital Extremes

London, Ontario, Canada
Communications Director

High Moon Studios

Carlsbad, California
Senior Producer

Build a Rocket Boy Games

Edinburgh, Scotland
Lead UI Programmer
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more