Daily news, dev blogs, and stories from Game Developer straight to your inbox
Going Games: From Web Development To Game Studio In One Project
Flash developer Tim Cooper explains how he transitioned from building web content for clients into a full-fledged game development studio, revealing hard data and hard truths about the change from working in one environment to striking out with his own games.
February 2, 2011
18 Min Read
[Flash developer Tim Cooper explains how he transitioned from building web content for clients into a full-fledged game development studio, revealing hard data and hard truths about the change from working in one environment to striking out with his own games.]
Team Cooper is a digital studio that specializes in the development of Flash games and interactive micro-sites. Whilst the majority of our business is work for hire under NDA, we also build our own games under the name of Robot / Lizard Productions.
Before the summer of 2008 Team Cooper was effectively a one man operation (Just myself, with my wife Emma as company secretary), but in the time since then we have grown to six full-time employees making browser-based games for a variety of clients.
It's been just over a year now since we released our first "proper" Flash game (Beastie Burgers) and while some may not consider it to be particularly remarkable, it has been pivotal in the growth and direction of our company.
Over the past years I have read a lot on other people's blogs (and Gamasutra articles of course) about their successes (and occasionally failures) in the Flash game development world, so I thought it only fair that I share our experiences too.
I have struggled somewhat with how much I should reveal in terms of numbers (building Beasties was not a directly profitable experience, after all.) But the game profits do not tell the whole story.
I'll start with a bit of background as to my motivations for wanting the company to move into game development, and then go on to talk about the development process and where it has led us.
Why Game Development?
I've always loved making games. As a child I spent a lot of my time on my Sinclair Spectrum writing my own games in BASIC and I have even earlier memories of coloring in board games I had devised and drawn up on the insides of old cereal boxes.
Unfortunately, at some point over my teenage years, I lost sight of that, and by the time I had been through secondary school and university I had almost forgotten about it. My first real job was at a company called ACT e-learning. It was there that I was first introduced to the Flash platform, and my passion for making games was re-ignited.
I was hired as a multimedia developer, which meant building all sorts of web-based content, but every now and then we would get to build a minigame in Flash. I loved that part of the job; I loved programming in Flash and working with other creative people, although I didn't realize at the time how much of a good thing that was.
Unfortunately, ACT went out of business, I was made redundant, and I ended up taking a job doing PHP development. I only have one good thing to say about that job: it taught me just how much you can really hate a job, and I learned the value of doing something you genuinely enjoy. For that reason I left and became a freelance Flash developer.
Getting Our Game On
After spending two years as a freelance developer, I had worked on a variety of projects and business had picked up enough for me to hire a junior developer, Kyle. Despite going for a variety of game-based contracts, the type of work we were actually getting was all very similar to the jobs we had already done.
Some of it was quite interesting and technically challenging, but it wasn't really where we wanted to be. I realized that if we really wanted to get hired to make games, we'd need to make (and finish) a decent game as a portfolio piece to give potential clients a taste of what we were capable of.
Back then, we usually had some spare time between each client job, time which we could afford to spend experimenting and trying things out. At the beginning of the project, we had no real commercial aspirations for the game; I just wanted to build something fun, so we got stuck in.
Deciding What to Build
So many genres of game to choose from, and I decided to build a cooking game. I don't really know why, and I think everybody thought I had gone completely mad. I'd had the idea for a burger-building game back when I used to work at ACT, but I'd never got past the prototype phase. As it was the "best" idea we had at the time, we decided to run with that.
We could have made a shoot 'em up, or a tower defense game, but these are just so common. I wanted to make something a little out of the ordinary, but keep it a mouse only affair to appeal to the online casual player. Sure, there are plenty of burger flipping Flash games out there -- just not as many.
Because we had no real development plan, we blasted ahead with development -- blindly. I had drawn up some quick sketches to give an idea of the kind of functionality I wanted, but that was about it.
We would build a little bit at a time around our client work, which in some ways was quite good because it meant that we had a break from it and could take a step back to assess how things were going. But in other ways this was bad, as maintaining momentum is difficult when you keep starting and stopping on a project.
Deciding on a Style
After we had spent some time on the initial development work, I started to think about graphics and applying a style to the game, so I hired my friend Phil to do the artwork. The initial idea was that the game was going to be based around serving people; they were going to have dynamically generated faces to give it a bit of variety, but after some initial sketches I felt it would still have looked a bit plain.
I wanted it to look a little out of the ordinary, and take advantage of Phil's illustration style, so at some point (I can't remember where the idea came from) the decision was made to replace the people with monsters and the "regular" ingredients with the kinds of things I would expect those monsters to eat. The name Beastie Burgers followed shortly afterwards.
Writing a Design Document (Better Late than Never!)
After trying to explain the game to Phil, it was also clear that we needed to define the game in a bit more detail, so I wrote out our first game design document.
This was an invaluable exercise as it meant we always had something to refer back to with our stop/start development, and it meant that we could actually assess what was still left to do, rather than guessing.
Once we had the graphics in and the main gameplay in place, we did some user testing using the First Impressions service from Flash Game License.
When I read the initial feedback, I was very disappointed. I wasn't expecting amazing feedback because at that time, the version we submitted had no audio and no tutorial. I just wasn't expecting the feedback to be as bad as it was.
At that stage it also didn't have the story mode; it was just you in the kitchen, cooking burgers for monsters. People loved the graphics, but hated the game. The problem was, nobody could figure out what was going on, got frustrated and dismissed it as rubbish. With hindsight, I am not surprised people didn't like it, but at the time I was a little gutted.
However, I went through the various reviews we had received and reading between the lines realized that the reason people didn't like it was not only that they couldn't figure out what to do, but they had no sense of purpose as to why they were doing it. It was clear to me that as well as adding the missing audio and tutorial, we would need to add a back story to tie everything together.
Rewriting the Game Design Document
With my newfound, enlightenment I went through everything and rewrote the game design document from start to finish. I thought up a back story for the main character Raoul and got to work devising the tutorial steps to teach people how to play the game.
When I sat down and really thought the story through, it became obvious what should be in the game and what wasn't relevant. However, I did get a bit carried away and in the process of writing down all of my thoughts. When I was done writing what the game should be, I'd managed to triple the scope of the whole game.
After discussing all my "amazing new plans" with Emma and Phil, they were a little skeptical. Emma thought we should keep the game down to a minimum, whereas I wanted to add all the features I thought it needed to be "complete".
In the end, I realized if we built everything I had thought of, it would actually take forever. So I compromised, removed some features and settled on adding the tutorial, the intro animation (so players knew why they were cooking the burgers), the story mode (with a map to navigate to each of the locations) and the achievements system.
So on that basis, we continued with development and eventually got the game to where it is today. I submitted the game back to the First Impressions service for more feedback and this time round the results were much better. The reviews that came back were very positive overall and I felt much better about having gone through the whole process.
All in all, because we had developed the game in small chunks (a little here and there when we had the time) the total build time was 18 months from start to finish. If we had built it in one chunk (and planned it properly), it would have been much, much less.
As I mentioned previously, when we began building the game it was intended as a portfolio piece. At the time I didn't realize that there were Flash game developers out there making real money by building games and getting them sponsored, but as development progressed I realized that the prospect of selling a Flash game was a very real one. I got quite excited about the thought that maybe we could operate as a company, just building our own Flash games -- how awesome would that be?
When we finally submitted it to Flash Game License for sponsorship at the beginning of October 2008, it had had good reviews from the community there. As that was backed up by the recent First Impressions ratings, I was hopeful for a good deal.
In the end, when we did agree to a deal, I was a bit disappointed by the process. I was told by one of the FGL team that they had expected the game to sell for more than it did, but I guess sponsors just weren't that into it. Maybe the timing was wrong, maybe sponsors were nervous about us being a "new" developer, maybe they just thought it was crap. Now all we had to do was release it, and see if they were right.
Rather suitably, the license deal and payment all went through just before Halloween, so we launched a couple of days before. Our primary sponsor even changed its homepage header bar to feature the monsters from the game (which was quite nice).
Our sponsor also handled most of the game distribution, so it spread pretty quickly around the various game portals around the world. For the first few weeks it was fun watching our game spread through the internet and seeing the play count rack up (We had Mochibot and Google Alerts set up so we could track who was hosting it and who was talking about it).
During development of the main game, we had also started a "dress-up" style game where you could build your own monster. Originally, we had planned to have this save to a database, and then pull the user-created monsters into the main game.
However, later on I decided to axe that functionality as it would involve a lot more than simply being able to distribute a single standalone SWF. I still liked the idea of the dress-up game though, so we put together Beastie Builder and put in on Facebook just for fun, hoping it would drive some more traffic to the main game.
Once the main rush for the web version was over, I also thought we should have a go at putting a version of that on Facebook too to test the water and see if it could spread as well as it did online. I also wanted to see if we could make any further revenue using microtransactions (We decided to give Mochi Coins a go).
I wasn't hopeful, to be honest, as I had read repeatedly that regular games can't be just dropped into Facebook, as they need to be designed around the platform.
Nevertheless, it wasn't a big job, so we added various Facebook hooks throughout the game and plonked it on there. We also put some Mochi ads in at the beginning to see how that would work out. Again, the results were a little disappointing.
If you've read this far, I guess you're itching to know how well it actually did and how much it cost.
Number of plays. Well, over the past year, the daily play counts have got smaller and smaller since launch but there are still about 5000 plays a day worldwide. At the time or writing this total number of plays is just over 4 million, which I am told is not too bad for a cooking game. I am pretty chuffed with this number although I realize it is quite small in comparison to Flash games like Desktop Tower Defense or Bloons.
Development costs. I cringe a little when anybody asks me this. Perhaps I'm a little embarrassed? (Although I shouldn't be, for reasons I will discuss later.) I should also say that this isn't a "real" cost in that it was calculated based purely on the overall time spent on it, plus the external costs of hiring Phil and other people for the bits we needed to outsource.
Our time spent on it was our down time, in between client work, so if we hadn't been working on this, it would have been spent on some other internal activity (Like hoovering or organizing paper clips).
Anyway, in total it was around £11,500, which breaks down approximately as £9,000 for internal staff time (The cost of paying our salaries for time spent), and £2,500 on outsourcing the external assets (If this had been client job, we would obviously have needed to charge more than this because I haven't included any other operating costs, rent, profit margin, etc).
Revenues. Between our two sponsors, we made about £1,800. Our Mochi advertising on Facebook has made us a blistering £3.54, and we did manage get some revenue through Mochi Coins (one person paid us £1.85 to unlock all the levels and content, although I suspect that was my mum). We also had some Google adverts in the Facebook app and on our Robot / Lizard website which have made us a stonking £55.
Something to bear in mind here is that the Mochi ad revenue for the Facebook version was from only 10,000 plays. If we had not gone with a sponsor for the web version and used Mochi distribution with Mochi ads and coins, we could have expected to make around £2100 (Based on the CPM we received with 4 million plays).
We also would have received more traffic back to our own site, which would undoubtedly have generated more revenue from the Google Ads there, although how much that may have been is anyone's guess (Maybe if 5 percent of people clicked back to the site it would have been another £1000?)
So, Was It Worth It?
Absolutely! On a personal level, it was a very rewarding experience. Producing something that was ours meant our own vision and our own rules. We also learnt a lot in the process, for Kyle as a new developer at the time, it was an excellent coding exercise, and for me it was a good lesson in planning, game design, and time management.
Of course, on paper it looks like a financial disaster, but that isn't the point. If you ignore the cost of our own time (our downtime otherwise spent twiddling our thumbs and eating biscuits) the money we made from sponsorships just about covers the money we had to spend on getting the assets produced.
Besides that, the whole reason for developing the game in the first place was as a means to show off what we were capable of and inspire the kind of client work we wanted to do. From that point of view, it has done us nothing but good. It has been an excellent portfolio piece and has been a contributing factor in winning us lots more game development work.
While it is hard to say if it has been directly responsible or just partly, it has led on to a variety of things such as being invited to join the BBC's @North scheme, and talks with some major game development companies about potential future projects.
We currently have six separate game projects either in development or booked in to start in the coming months, so in that respect alone I can honestly say it was worth the time and expense it took to get it built. My main regret is that we didn't start and complete it sooner.
Some Lessons Learned / Confirmed
You get hired based on the quality of work you have done in the past, not on the quality of the work you "know" you can do. If you want to get game development work, make a game!
Planning is your friend, but don't let planning get in the way of prototyping an idea. The quickest way to get a game started is to just start building it, but the best way to finish is to have decided (and written down) what it is you are actually building.
Do user testing! With anyone! Use a service like First Impressions or get a random person off the street. Sit them in front of the game and watch them, don't tell them what to do, just ask for their thoughts. Getting feedback how other people interact with your creation can be a revelation sometimes.
Don't expect to get it right first time and don't be afraid to iterate. Prototype, Plan, Build, Test, Amend, Repeat as necessary. Making a game is about trying to teach the player to do something, then testing them and pushing them to get better at it. You need to check that the process is working properly.
If you're making your own game, make sure you get your priorities clear from the start. This can be hard if you haven't planned what you are building though. In our case we knew why we were making the game, but lost sight of that slightly during development while we experimented with various things (Mochi ads, Facebook, Flash Game License, etc).
Build your game around a story. It's my personal feeling that a game needs to have a story behind it. That story doesn't necessarily need to be revealed to the player, but it does help you as a developer to dictate what is and is not within scope.
Write down all your random ideas. Since working on Beasties I have learned the importance of writing down random game ideas. Whenever I have one (usually while walking to work) I add it to a list I keep.
Earlier this year we pitched one of those ideas to a client, they loved it, and we begin development on a project for them in January. For our next Robot / Lizard project we also have a dedicated space on the wall for these random "post-it note" ideas, they may not get done anytime soon, but at least they won't be forgotten.
Work on projects you enjoy, with people you like. It really doesn't feel like work that way and you get a lot more personal satisfaction out of it.
2011 is looking pretty exciting for us as we continue down the path we started on.
Primarily we'll continue our work-for-hire Flash development as we have been fortunate enough to build some good relationships with larger entertainment companies over the past year.
We are also still setting aside time to work on our own projects. One of which is a Facebook game and the others are smaller personal projects, currently at various stages of development.
Building Beastie Burgers has helped to bring us some excellent clients, the game work that we wanted to do and the experience and confidence in ourselves to continue working on our own projects. With each new project we complete, we are honing our design skills, becoming better game developers, raising the bar in terms of our own game portfolio and with the upcoming additions to Flash Player (The Molehill API for 3D) we hope to ramp things up even further.
Read more about:Features
About the Author(s)
Tim is the Managing Director of Team Cooper, a small digital development studio specializing in the Adobe Flash Platform. He's been a professional Flash developer for almost 10 years and loves working with the Flash platform to build enjoyable, interactive experiences like games, Facebook applications and micro-sites. In his home life, he is currently training his two very small children in the ways of video games. Consequently his eldest won't leave the park now unless he's 'completed' it.
You May Also Like
Accessibility and fancy footwork with GLYDR's John Warren - Game Developer Podcast ep. 40Feb 28, 2024
Exploring the 2024 State of the Game Industry report - Game Developer Podcast ep. 39Feb 2, 2024
Phantom inspiration and the ethical auteur with Xalavier Nelson Jr.Dec 8, 2023
Designing Killer Queen: from playground experiment to modern arcade sensationOct 18, 2023
Get daily news, dev blogs, and stories from Game Developer straight to your inbox
Subscribe to Game Developer Newsletters to stay caught up with the latest news, design insights, marketing tips, and more