- ARPDAUPosted 12 years ago
- What’s an impressive conversion rate? And other stats updatesPosted 12 years ago
- Your quick guide to metricsPosted 13 years ago
Crunch-free, commute-free, child-friendly: making games the Lady Shotgun way
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.
Related Posts
