Don't miss
  • 1,898
  • 5,500
  • 5,758
  • 107

Crunch-free, commute-free, child-friendly: making games the Lady Shotgun way

By on November 20, 2012

This is a guest post from Anna Marsh of Lady Shotgun, which recently launched its first game, Buddha Finger, on iOS.


Almost a year ago I set up Lady Shotgun, a game dev company with a core objective to have our entire workforce working flexible hours from home. A huge factor behind this rather unconventional approach to development was that fact that myself and other two founders were mothers of small children.

Without having specifically polled major game studios, I reckon practically every one of them would tell you flat out that it is either impossible to make a game like this, or that they wouldn’t do it. Conventional wisdom dictates that games are only possible to make when your entire team are sitting physically together working full time.

Yet there are many benefits to our style of work:

  • Time saved on commute – this is no small matter. I save at least 2 hours a day, 10 hours a week, 40 hours a month – that’s a full working week every month.
  • More efficient Work Patterns – working intensively for 8 consecutive hours – bar a small break for eating – does not suit some people, and I would go as far as to say it doesn’t suit most people. How many colleagues do you know who “just aren’t morning people” or have an “afternoon slump”? Personally I run out of steam after about 5 hours so by splitting my working day into the morning when my daughter is at the childminders and then putting in a few hours in the evening whilst her dad takes over increases my daily output of actual work (as opposed to browsing the internet, gassing round the coffee machine or sitting in a meeting room doing no productive work)
  • Ultra low overheads – Probably the most tangible business benefit is the slashing of overheads – We don’t pay rent on an office, we don’t pay for the team’s hard or software, we don’t pay full time salaries.

I would also list another great benefit for us:

  • Untapped Talent: Our team are very talented and most of them very experienced. They can’t, or don’t want, for whatever reasons, to work full time in an office. So by relaxing our requirements on when and where the team must work, we get access to large pool of talent without having to offer enormous up front paycheques.

Exploring all issues around home working would result in an enormous article. With such clear benefits, certainly for smaller companies, I wanted to concentrate here on 3 key elements of our processes that make it work for us:

  • Pre-Production
  • Focus on Tasks, not hours worked
  • Communication

On-paper Pre-Production

Establish clear vision, sound game structure and definite goals.

We did a lot of work on paper before committing to production. For a casual action iOS mobile title we had a design document and supporting documents of in excess of 100 pages, which is getting close to what you might get for a large console title. Frequently when working on console titles I’ve felt that the design team are obligated to start putting work up on screen before they’ve fully dotted the I’s and crossed the T’s of the design, and this is generally excused as there being no point working out on paper as “stuff will change” (perhaps a bigger reason is that the decision makers in a big company often have not come from development and don’t have the experience to visualise a game from the paper documents, therefore needing to see stuff running to make decisions on it).

Without a really clear working document however we’d find it next to impossible to start portioning up tasks and co-ordinating the group effort.

The key thing is that documentation produced needs to focus on being a practical manual for the team to work on, minus any marketing gloss. To make a comparison with architecture: During the planning phases of a building an architect might prepare Photoshop visualisations with happy pedestrians and sunny skies to show the public and financiers what the final building will look like. But they’ll also prepare far more precise blue prints, plans and technical documents for the actual builders. It’s essential if you want to actually work from the design document l to avoid the common trap of making the design document do double duty as a marketing document and to concentrate on the “blue print” aspect.

The pre-production phase allows the designer to really focus their vision for the game, and prove to themselves that the game has both depth and progression in its challenges. If a designer CAN’T clearly define these elements in writing, then it’s possible they don’t have it clear in their own minds and therefore will be leading the rest of the team into difficulties further into development.

Here’s a check list of some of the things I make sure I’ve covered with my design (which could fill an article all on its own – I’m sure game designers have their own lists).

  • A low level or “pre attentive” challenge – something the player is going to do without consciously thinking about it.
  • Some analogue element – for Buddha Finger this is the score system.
  • An area where skilled players can excel but beginners will not fail
  • A “seed” from which the aesthetic of the game can grow – in our case “70’s 80’s martial arts flicks”.
  • How the mechanic/s of the game will evolve over the course of the game this was

Two provisos here –

The more experienced the designer writing the documentation, (probably) the less changes you’ll need to make in development. Talent and enthusiasm are brilliant, but the value of having made plenty of mistakes in the past and being able to head your own missteps off at the pass is invaluable.

Design documentation of this ilk is pretty dry and boring. It’s going to contain things like equations needed to work out multipliers earned on a score, lists of data fields needed to tweak various mechanics and other such nuts and bolts. If you need a sexy marketing document to sell the game, you might have to write a separate document to do it.

Once you have your design pre-production done, you can then portioned it up into very clear, unambiguous tasks. We did this by creating:

  • Asset List – all the individual graphic and audio elements required
  • Code Backlog – each element of the game the code needed to implement.
  • Storyboard – every line of narrative and any accompanying illustration.

A good rule of thumb for tasks is to clearly define the end result required (given that you’ve broken the tasks into small enough chunks) rather than the method of getting there. For example, the artist’s task for our “Afro” character was “Enemy based on Jim Kelly from Enter the Dragon using tongfers”, not a dictation of the graphic style. This allows the team to have fun creatively with the tasks whilst being confident what they need to finally deliver. Emotive or objective words “awesome” of “fun” are also best left out of task descriptions.

Focus on results, not hours worked

Companies with full time employees are essentially paying those employees for their time. Its then up to the company to make sure that they fill that time as effectively as possible with tasks, something that can be like production Tetris. Overruns tend to get passed on to the employee in the form of “crunch” whilst under runs result in employees twiddling their thumbs between jobs.

Instead, we focus on tasks being completed as a measure of the work done by a team member. Initially we worked to weekly “milestones” using Team Lab (www.teamlab.com) , and later migrated tasks to the Assembla (www.assembla.com) “ticket” system. Because the core team have so much experience we’re pretty good at estimating roughly what a task would take and assigning tasks to team members based on how much time they had available for the upcoming weeks. Tasks were accepted and verified by the team members themselves. It didn’t really matter then if those tasks took the team member half or double the time we had estimated, or if the work was done during the day or the middle of the night as long as the task got done.

Admittedly, our low overheads mean that an overrun isn’t the end of the world – and overrun we did. The main cause of the overrun however was not bad planning but small funds meaning that various team members needed to take time out from the project to do contract work to keep their own funds up. Fortunately the flexible task based system meant we were able to keep going with whichever team members were available at the time, without holding people up with dependencies.

Communication

It goes without saying that communication is vitally important to this method of working, and that team members working together need to comfortable with contacting each other whenever necessary. I almost didn’t include this in the article because this isn’t so different from being based in a physical location – I’ve frequently been in long studio meetings in my previous jobs where we’ve walked out realising that no one was taking minutes and most of what was discussed has already been forgotten.

However, I thought it was worth summing up our experience here as it seems to be an issue that concerns studios who are reluctant to allow home work.

What we found was that team members with prior freelance experience are very good at knowing what and when to email or message their co-workers, and who to cc on those mails. In these cases we found a formal system such as a daily or weekly update to the project lead isn’t necessary and can even be a hindrance to their daily workload, so we let those team members get on with it.

Members without freelance experience however can need a bit more support– they can be worried about “bothering” other co-workers with mails or cc’ing the wrong people. Finding a way which best facilitates communication for them is very important. For producing the story artwork, which involved two more junior artists – once drawing and one colouring – and the writer, producer Sarah created an Excel sheet which broke down the work to each individual story screen required, and kept this in the project Dropbox where everyone had access to it. Each screen was then colour coded to denote what stage it was at, and clear feedback and updates from the team members when changes were made were recorded on the sheet. She then tracked the sheet each day and kept backups when necessary, whilst ensuring that the most up to date version was the live version in the Dropbox. This worked extremely well for us – especially since each team member working on the story was actually located in a different time zone.

When we moved to Assembla’s ticket system we also found its tools to assign tasks & bugs, add comments, and get support from other team member by adding them as followers to specific tasks, was an extremely efficient way of keeping communication clear during the final bug fixing and balancing phases of the game. Although I haven’t had experience of competitive products to make a comparison I was very pleased with Assembla and would encourage other home teams to check it out.

Finally, for signing off tasks we split things roughly in two – as project manager I was largely dealing with the game side of things whilst Sarah as producer was dealing with the Story side of things. This was possible due to the structure of the game, which had discreet cut scenes, and may not be suitable for everyone, but it avoided any one person becoming the bottle neck to the game and also played to our strengths. Sarah is very strong on narrative issues whilst I’m really a gameplay person.

About Anna Marsh

  • http://www.facebook.com/guillaume.bouchervidal Guillaume Boucher-Vidal

    A refreshing take on game development to say the least. I personally prefer working in the same physical space as my colleagues, but I can see the advantages of doing it from home. It must require a crazy amount of discipline to pull off from the entire team though.

    I also agree a lot with the statement on good game designers being able to limit the amount of changes done to the mechanics during development if the pre-production stage was better planned out. The marketing/blueprint dichotomy is also an issue I’ve observed ever since my game design classes, where we were actually encouraged to put less substance and more eye candy and hyping it up with buzz words. In the end, to me it always seemed like a clear sign of the lack of maturity in the industry.

    Congrats to you gals for finding a game development process that suits you and which help you reconcile career and family. I share this goal and I’m happy to see different paths being explored to reach it.

  • http://twitter.com/Matt_Falcus Matt Falcus

    Very interesting piece, and lots of great ideas. I’d be interested in knowing how you go about ensuring you’re hiring the right people to do the work, and where you find them – especially since it sounds like they’re scattered around the world. Do you meet them in person first, or do you use sites like Elance to find the workers?

  • http://twitter.com/LadyShotgunGame Lady Shotgun Games

    Good question! With the exception of our junior coder Lauren everyone on the team is someone that myself or producer Sarah has worked with in the past. We both had periods working freelance for big mobile developers which is where we worked with very talented other freelancers and when we decided to go ahead and do this we contacted those people. Fortunately everyone we approached was well up for it :) We found Lauren by contacting universities who did games programming courses and the course leaders put interested students they rated in touch with us, Lauren was one of the applicants and had a very strong portfolio of programming languages.

    If the people that we contacted had not wanted to work with us, we may have gone the Elance route – I have sucessfully used People per Hour for getting work done on our Video and Website – but obviously working with people who you know are good and have the freelance skills really reduces the stress and risk!

  • http://twitter.com/LadyShotgunGame Lady Shotgun Games

    Heh, yeah, I remember when working for one big studio people – even on the dev team – got really quite angry with me for removing the “fluff” from two concepts so I could compare their relative strengths, to see which had the best “bone structure” without all the slap as it were. It can be very damaging for the process if the designer isn’t allowed the freedom to do that! Its unfortunate that the only solution may be creating two documents, the “show” GDD and the working “design specs” – that increases the workload for the designer who has to keep the two up to date :(

    I think it works because the team actually really prefer working this way, if we were all hankering to be in the same physical space I think it wouldn’t be as successful as it has been. The other reason is to have a game that everyone believes in and no feels they’re doing it “just for the money”. The great thing about the Buddha Finger concept was that people got it exactly straight away and thought it would be a great game. If I’d had to spend any more than 5 minutes explaining the concept to the team I think we wouldn’t all stayed so focused. Admittedly, that means its probably easier to do with a smaller scope game – like a mobile game – but I’d sure like to get the opportunity to test this out on larger and more ambitious project! Thanks for the best wishes :)