“Make your game easy to play, but hard to master”, explained Mike Swanson during his session at Casual Connect Europe 2015. He shared his experiences with the audience in managing game production and designs while striving to appeal to different player types on Age of Empires Online and the upcoming Game of Thrones from Bigpoint Entertainment. Ease of entry (also known as the funnel) is intrinsic in hooking a player. He states, “Keeping this funnel really crisp coming in is key. It doesn’t matter how big the game is”.
In Dejan Omasta’s session at Casual Connect Europe 2015, Dejan explains what you should know when starting an indie studio, including project management and client communication. He says. “We really try to give 100% of ourselves because this is basically who we are. When you are a small indie studio, you really have to use your strengths”. He further explains, “Splitting between client and indie project is key”.
At Casual Connect Europe 2015, business partners Alina Constantin and Michael Rosel, spoke about what happens after a successful Kickstarter. Their focus is on their game Shrug Island and the way it captures nature and the imagination. To this, Alina said, “The goal from the start of a project that has been built for years, from an animation film, to a story, to interactive media is to connect to the imagination of people in the way that when you were a child, you see the world around you as alive. You go out in nature and it is alive and you can imagine things. The game that we are making right now is based on that feeling and trying to make it into a digital experience”.
During Casual Connect Europe, Andrej Golovkov and Ivan Krechňák spoke about montetization and optimization using data analysis. In reflection of how monetization worked when he first started, Ivan stated, “Companies had their business model based on advertising which was the main income”. It was thought that charging for online games was impossible. Now, there are many possibilities. Andrej gives this advice to companies: “Don’t be afraid to try various programs (of data analysis) in your game”.
At Casual Connect Europe 2015, Brjann Sigurgeirsson spoke about how to be successful in self-publishing. Among the many golden nuggets of advice was this: “If you are very small and you’ve decided to do it yourself, one of the best things you can do is . . . cooperate with companies that are close to you”. He further explains that if you are geographically close, you can meet a lot in order to exchange ideas.
When MegaZebra started in 2008, they were pioneers. Along with making games, the company also had to create the market in Europe from the ground up. To top it off, the company’s founders came from Internet and mobile backgrounds as opposed to a more traditional gaming background. This ended up proving fortunate for the company as it helped them tackle problems in a unique way as the gaming industry evolved.
They could have spent $30 on some posters for the Indie Prize Showcase; but instead they spent 30 plus hours hand-painting cardboard cutouts to replicate the game background. They could have sought funding for the game; instead, they worked late into the night to find time between work and school. They could have said “Eh, screw it!” after realizing there was no way it would pay for the hundreds of hours put into the project.
“But to be honest, none of that stuff even crossed our minds”, says Kurt Waldowski, the founder of devsAnomalous, as he shares the story of Zaboodles. “Budget, time, and a bulletproof business model are not a concern to us. Our only concern is making Zaboodles the best game it can be, and getting it into as many hands as possible. Zaboodles isn’t being created by a company. We are just two pals that met in the dorms in the beginning of the freshman year, and decided to pour our energy, love, and dedication into making the best game possible.”
A Neighbor Who Loves Games
Throughout my four years in high school, finding time to make games was easy. But during the freshman year of college, the University of Michigan seemed to steal all my time and motivation. I would often sketch characters in class, or babble to my friends about various game ideas. But at the end of the day, no real action was taken. Hell, I barely had enough time to meet my dorm room neighbor, Daniel. However, I did know one thing about him: he loved to play games.
On December 1st, 2011, I stumbled across a competition hosted by The Experimental Gameplay Project. The week-long contest called for games that would be played with five pads lying linearly across the floor. Not being able to keep my mouth shut about anything, I ran into Daniel’s room and started rambling about the contest. To my surprise, he took extreme interest. He had no real experience making games or programming, but that didn’t stop him. We grabbed a whiteboard and began sketching stuff. Due to a misinterpretation of Daniel’s ideas, we stumbled upon a solid concept: jump around dodging enemies while utilizing various power-ups to clear them and earn points. This was not only the birth of Zaboodles, but also of a long-lasting friendship.
1 Week, 1 Developer, 5 Buttons
It took an interesting opportunity and a motivated friend to help me discover what could be accomplished in the late hours of the night. Every evening at 10 o’clock sharp I would wander into Dan’s room, plop down on his couch, and start programming. Despite the competition requirements of only one developer being allowed to work on the game, Dan was essential to the process. Not only did he contribute great ideas, but his enthusiasm and interest kept me motivated. Many times we would stay up until four in the morning crunching the game out. Sometimes, I even fell asleep sitting up!
After one week, we had a submission we were both proud of. It went on to be selected as a finalist, was shipped off to Germany, and was played in an empty swimming pool on a giant projector screen. Man, do I wish I could have been there!
Zaboodles for More Players
We fell in love with Zaboodles. After the contest ended, we wanted to push the game to its highest potential and release it on the PC for everyone to enjoy, not just the people over there in Berlin! Sure, playing Zaboodles by physically jumping from space to space was awesome, but I didn’t have the technology to play it that way. To test the game, I had to jump around on five pieces of paper taped to the floor, while Dan simulated the input with an Xbox controller. So, it was time to optimize the game to be played on the computer.
After our freshmen year ended and the competition was over, we started adding more to the game. Different boss battles and updated graphics, among other things. Notice how I said “we”. Once the single-developer restriction was lifted from the contest, Daniel joined the team full force. Despite having little to no programming experience, he jumped right into the fire. He learned at phenomenal speed, dug through my spaghetti-code mess from the contest, and produced the entire achievement system with little trouble.
Throughout the summer, Zaboodles were being created everywhere. I remember working on the first boss while partying at my older brother’s house. I created various art assets during group work sessions at my friend’s house while he was producing music. I even worked outside at parks with my twin brother. Zaboodles got inspiration from tons of people, resulting in a wacky game with a unique personality. My computer and trusty card table moved with me wherever I went.
Mobile? Challenge accepted!
It was Halloween 2012, but we weren’t out partying across campus. We were putting the final touches on Zaboodles and preparing for launch. After programming the website in an overnight coding spree, we released the game. I was a zombie in class the next morning.
Despite not reaching the largest audience, Zaboodles received fantastic reviews. People really liked our quirky game! However, one thing was consistent throughout every review: this game would be amazing on a touch screen. The computer controls were clunky. We had no experience developing mobile games, so we knew we had a challenge ahead. After a long hiatus, we decided to go for it.
User Testing Shows the Potential
I had been crashing on Dan’s couch for three days a week, and we crunched out the game. The development cycle of Zaboodles was always in sprints; we would work casually on and off, and then suddenly, boom! We would work from sun up to sun down for a week non-stop. These waves of development really kept the game going.
As we were porting the game to mobile, we noticed things that needed to be tweaked or added. However, our biggest concern arose while showing the game to friends. Those who had played six or seven rounds were in love, but more often than not, after a few tries, they would set the game down. They couldn’t see the potential. User testing is essential. It opened our eyes to the fact that our game was unable to entice people fast enough. We needed a solution.
From then on, there was no shortage of user testing. The game was tested on friends, family, and even random people on the bus. After tweaking the gameplay and three iterations of tutorials, we finally were able to see users catching on. Yet there was still work to be done. The importance of user testing didn’t dawn on us until the game was on our mobile devices in our pockets. It was so easy to show to people, and testing on real players revealed the disconnection between our vision and reality. This forced us to push the game’s release back, and we are still working on it today.
Zaboodles is nearing completion and is planned for release in October 2014. So much was gained from the development process! The project inspired Dan to major in Computer Science, giving him a direction at the University. We discovered the amount of discipline it takes to see a project through from start to finish the way it was envisioned. It even inspired me to start doing freelance mobile game development.
The devsAnomalous‘ plans are still up in the air, but Kurt is sure about one thing: he will be making games. They hope to bring together a community dedicated to sharing skills, knowledge, and experience, turning independent developers into interdependent developers.
Since 1999 (the founders are old or, as they say, “seasoned”), Ian Jardine, Craig Martin, Julio Carneiro, Steve Parkes and William Gibson (who provided the story and background) have wanted to get into the game-making business but lacked time, funding, and expertise. By building a successful web application consulting company over the past seven years, they were finally confident enough to start their dream company. They had an inkling of what they wanted to build: namely a multiplayer tank-based game that harkened back to Bolo from the ’80s. “We wanted to make the game hard. We felt that too many current games make it too easy for players to win. We wanted the player to explore their surroundings and get that “aha!” feeling upon discovering something new and weird inside the game. We were missing one key ingredient: Game Company Expertise”, Skunkwerk Kinetic’s CEO and founder Ian Jardine recalls.
Drive and Ambitions Above All, Experience Not Necessary
We aimed to build our team around a talented group of developers who had drive and ambition, though not necessarily game industry experience. Provided below is a brief description of three team members who we think represent a good cross-section of the overall spirit of our company.
You always remember your first hire, and we picked our lead engineer Jonas, a beaming Belgian with a passion for strategic games and a rock-solid coding background. At our first meeting, Jonas told us his story: upon graduating from an obscure university in Belgium, he and his lovely girlfriend (seriously, how did she get stuck with Jonas?) packed up all their belongings and moved to Vancouver. That showed us he was willing to take risks and take giant leaps of faith…very good qualities to have in a startup.
Jonas is also very good at asking questions…lots of questions. He forces us to really think through all of our crazy ideas, not hesitating to bring up the myriad technical difficulties associated with an ambitious new feature. It has been a real pleasure watching Jonas grow into his role as head engineer, and as a person (new dad!!).
Erik, the game/audio designer, is a good example of a team member adapting to the ebb and flow of a company’s needs as they change over time. Erik was hired as our ‘sound guy’ early on, but we were too busy making art assets and solving the technical issues of creating an online multiplayer game from scratch to spend too much time on audio. Erik’s passion for games and insight into game design were evident from the start.
He became our primary game designer and produced all the internal documentation needed for feature design in both the Art and Dev departments. He still has his hand on sound design, managing our sound consultant and offering advice on thematic audio design in the game.
Kevin, the lead engineer, is a good example of how an undergrad in Japanese Studies turns into a dev at a game company. He is fluent in French, German, and Japanese. He plays guitar. He sings. He can do Flash….oh, and he is a helluva coder. Realizing that the Arts degree was not quite enough to land for a full-time work in a game company, he went back for a second degree in computer science.
Kevin came to Skunkwerks as a co-op student, worked his way up to a key member of the team, and we never want him to leave.
Multi-talented Flexible People: A Solution for Small Teams
We refer to our team members as “Swiss army knives”. Our company is too small to have a specialist in every department. Instead, we need people who are flexible and multi-talented; it also helps if you’re a musician (our backup plan: if this whole game thing doesn’t work out, we’ll hit the road as a hair metal band called “The Skunkwerks 5″ or whatever number of members we can rope in!).
Through two years of development and working with a small team, we have felt the sting of developers leaving our team for larger companies (*cough* Amazon *cough*) with much more money to throw around than we do. Our entire server team was demolished within two months leading up to a critical release, forcing our downsized client team to pick up the slack within a number of weeks. The remaining dev team not only learned about the server-side codebase, but was also able to fix a number of longstanding issues with the server architecture. Lemonade out of lemons, baby! The good news is that the people left are in it for the duration, while all we lost is “deadwood” – like pruning a tree makes it healthier.
Before Legit Game Engines Started Suggesting Affordable Deals
When we decided to make a mobile game, it was about six months to a year out from when legit game engines began offering more affordable deals to indie developers in a meaningful way. After initial research, we decided to string together our own custom engine using a variety of open-source and licensed components. This proved to be a double-edged sword in the long run, although we learned a great deal about each part, including Scaleform for UI, FMOD for audio and Sparrow for texture rendering.
The ease-of-use and implementation took much longer than expected, compared to a more conventional approach using an all-in-one engine. Moving forward, we now know how to be able to fully utilize a commercial engine should we choose to use one and also roll our own if necessary.
Why just Apple?
“Where is the [insert any platform other than iOS] version of your game?” We get this question quite often, as our game is currently an iOS exclusive title. We chose the iPad as our primary device for a number of reasons: we liked the development pipeline and usability of the Apple mobile framework, and the lack of variability in screen size amongst the various retina and non-retina iPad models.
While we agreed that Android would be a good choice for the type of game we’re making, we were wary of the expansive device list and the necessity of making our game experience work consistently across many different screen sizes and resolutions.
Apple’s 30 percent cut of profit from App Store revenue was quite steep from a business perspective, although we did appreciate the distribution platform as a service.
The submission process proved to be frustrating during our initial release of MEG:RVO – we ended up getting rejected for minor UI issues (like where to place the “Restore InApp Purchases” button), and then felt like we got approved without any actual human verification. It felt like dealing with an amorphous gatekeeper at times, and unpredictable release and update schedules proved to be a challenge for our server-based game (we didn’t want to make updates to the server until the App Store update goes through, for fear of breaking previous versions).
After our PAX East experience this year, we have received significantly more support from Apple, and the whole process has become somewhat smoother. It seems that as our app started getting more attention and updates on a consistent basis, the review timelines have shortened substantially.
Buying/Selling Wasn’t Fun – So We Removed It
One of the many things we learned from PAX East 2014 was that our game was suffering from lack of polish and usability in terms of the HUD design. PAX attendees who came to our booth approved the concept and look of what we had going on, but by the end of the three-day expo, we were all hoarse and exhausted from having to give a detailed explanation of the game mechanics to each person who stuck around to play.
We then decided to re-design our menu and in-game UI in order to present all controls and information our game contained in a simplified and concise format. We removed some features that we felt were too complex or not fleshed out enough to belong on a release version of MEG:RVO. For example, we decided to get rid of the Marketplace for the next release, since buying/selling items didn’t seem that fun and in fact might have had a negative impact on first-time players. Instead, we built a combat training mission that we strongly recommend new players to try out before getting into a match with other players.
The incentivization process was altered as well; we ended up giving players all of the weapons upfront. It’s now a balancing practice rather than a “pay to buy better weapons” system. Players gain experience the more they play and participate. Leveling up unlocks more maps, but the gameplay remains generally the same.
We hope that these changes along with our focus on user experience will allow users to stick around a bit longer and appreciate the depth and relative complexity of our game compared to more casual mobile games.
We’d Better Have at Least Someone With a Gamedev Experience
Hiring people with no prior game knowledge had its pros and cons. It would have been nice to have at least one person with prior industry experience. This might have helped us avoid some common pitfalls in our design, and reckless ambition in terms of what we wanted to create.
Should we have hired people who were passionate about games instead of people who just wanted a job? Definitely. Did we assume that most people would “just figure out” how to play our game without any guidance? Yes. We have since realized that we need to show people how the game works first, and then let them explore. This has shifted to our primary focus over the last few months and we hope that this will be reflected in our next release around August 1st this summer.
The value of our team comes from learning from these mistakes, and we feel significantly more prepared to deal with design and implementation of features than we did at the outset. Our website tag line “Doing things the hard way” is very apropos. We’re looking forward to making more mistakes in the future and further sharpening our expertise through them!
Grants: A Framework for the Business Plan
What we did right was to apply for grants (CMF) as it forces you to think through your game-plan. We used those grant applications as a framework for our business plan which we then used to to raise money. Have a proper budget and stick to that budget! Do not assume you launch the game and get an instant cash-machine. This is not going to happen. Plan for no money, but hard work, loads of “impossible” problems, and all for a very long time.
Be adaptable to changing situations; the only constant is constant change: “We adding dragons today? – No wait, robots, yea, more robots and some sparkly stuff…”
Probably the most important thing we did was to be naive. If we knew all the pitfalls from a suspect iTunes market (bots much?), technical problems (server down again..ack), personnel problems, and day-to day operational problems (why are there plants in the bathroom? payroll is due today?), we would never have started the journey. And that would have been a shame as everybody is having a blast doing what they want to do.
GlobZ is a small French indie company of four team members: Alexandre Houdent and Laurent Fernandez, who work at an office in Paris, and Fabien Riffaud from Tours and Jérémy Damon from Vannes working from home. Alexandre talks about the challenges and lessons of the creative process for their latest game, ¡Oh My GlobZ Mucho Party!
The entire GlobZ team has been working together for more than 10 years, becoming works-for-hire for web/mobile games in order to finance our own productions. In the past, GlobZ got some recognition as an IGF finalist in 2008 and Milthon prize winner in 2009 for Globulos, released first on the web in 2003 and later on the Nintendo DSiWare in 2010, including in Japan, where the game was sold best. In 2011, we also published an iOS version. Since then, we released the arcade puzzler Twinspin on iOS and Android in 2012, but despite all the good reviews, the game did not sell well at all. The question arose: what game are we to make next!? The answer to that question turned out to be a touch party game called ¡Oh My GlobZ Mucho Party!, to be enjoyed by several players on a single iOS or Android device screen.
A Party Game: A Perfect Fit For a Work-For-Hire Studio
GlobZ is a very small studio, but the team members all have strong personalities and somewhat different tastes. And even if I am the “final boss”, I like it when decisions are collective and we reach a consensus. I like to say that we are two developers, two graphic designers, and four game designers!
So when thinking of a game, we thought about the games we like to play together. Bishi Bashi was in the top list. Thinking about it, we liked the idea of doing a touch party game with the spirit of that great Playstation game! Everything seemed a perfect match:
– Minigames were ideal for a possibly sliced (between work-for-hire) production!
– A crazy art direction would allow us to experience many funny styles at no cost!
– We did not find any game like ours in the App Store, so we had a kind of “blue ocean” strategy!
– This would qualify for a PREMIUM title! No F2P – because premium is all about “perceived value” (here we have 30 minigames) and “I don’t already have this app on my device” thinking (we hope so!).
Following All Great Advice Seen in Postmortems
We were very excited about the project. We made a huge document with 35 minigame ideas, came up with “Oh My GlobZ” as a working title, developed a prototype (Candy Match), and filed an application to a French state office (CNC), who agreed to give us some money at the end of 2012 to help develop the game.
And for once, I promised myself I would follow all the great advice that I constantly see in postmortems, like:
– Do playtests as often as possible and take the feedback into account!
– Speak about the game as soon as possible and as much as possible!
– Work with a PR company instead of doing it yourself!
What a Touch Party Game Needs
In 2013, we started working on the game. Production happened not to be sliced at all, and we had to make lots of decisions on a daily basis. In other projects, we usually have some time to think between actions, so this was new to us. We discovered quite a few more things during development as well. First, our gameplay had limitations. We had no buttons mashing up stability of the device, no swiping, and no virtual controls. Also, some games that we wrote out did not turn out as fun as we hoped.
Doing something “crazy” and “fun” might seem simple when you look at it, but it’s not like that in real life (unless you’re really crazy, maybe). The first designs were “serious” and too “well-executed”. They looked like nice Flash games, but lacked a special twist, a specific identity and style. We wanted the game to be recognizable from any screenshot, not dependent on the diversity of graphic directions.
Our original plan for the identity of the game was to rely on some black-and-white characters we called Arcarids/Blubz, but we eventually changed them to avatars, where players would put pictures of their faces instead. We had worked on a Facebook game for a client where the Facebook profile picture was used as the face of the character in the game, and it was great fun and so much easier for the players to see who they are!
During development, we realized that the party game (“stupid, but fun”) orientation was a bit frustrating for some, because we also like simple and deep puzzle/strategy games, and had some as prototypes. At a certain point, in order to help ourselves decide to completely get rid of some of those we joked we would do a “¡#OMGZ Mucho Strategy!” sequel.
The Mayonnaise Doesn’t Work
In April 2013, the production was put on pause due to some work-for-hire projects. By that time, we had lots of content for the game, but the whole thing still lacked a clear direction and identity. In French, we have a great expression that fit our situation: “the mayonnaise doesn’t work”. It means you have all the ingredients, but it does not work as great as you expect. The pause happened to be an awesome opportunity to perform many playtests and show the game to some fellow game designers. This helped us outline the “fun factor” and identity/style – the avatars were the thing! So we decided to feature them in all games, not only in the UI!
We got back to the project in mid-November. It’s terrible to say this, but it felt difficult to find the motivation to start working on the game again! I thought the way out was in making totally new games, but the team was much more reasonable, and we ended up polishing the existing games, UI, and game modes. It was a wise decision, because we really had the feeling of consolidating the grounds of the title at last. What is more, the Google documents we were using included too many comments, so we decided to clear everything and keep only the latest and relevant feedback (note: Google keeps all the modifications anyway!). We also had some communication issues due to remote locations, but solved that by simply doing some Skype conference calls!
The Remaining 10 Percent of a Project
Accounts for the Other 90 Percent
We are now super happy with the avatars; they are really fun and give a strong identity to the game. And when we do playtests, we see people enjoying the minigames, which is ultimately the goal of the whole thing!
As the “ninety-ninety” rule states: “The remaining 10 percent of a project accounts for the other 90 percent of time”. We still have to add some more mini games and music and sound (it’s the only thing we subcontract), not some random placeholders here and there. It will be great because my four-year–old son won’t complain about the lack of sounds and music anymore! We also have to localize the game in as many languages as possible, and work on real PR for great exposure at launch!
While they admit that it’s always difficult to set a date when you’re doing both your own game and some work-for-hire, the team plans to release the game by the end of Q1 or the beginning of Q2 2014. In the meantime, you can get a taste of it at the GlobZ site.
Zynga’s Chief Creative Officer Tim LeTourneau suggests that there are a few basic questions that every developer should ask before designing a free-to-play game. “Why are we doing this, who are we doing this for, and how are we going to do it?” LeTourneau asks before setting out on a new project. Meaning, what is the business opportunity, who is the audience, and how can the team accomplish its goals with the available resources.
“It’s simple,” LeTourneau said, “I’m constantly surprised that there are companies and teams that don’t answer those three questions. You might know who you’re making something for and how you’re making it, but you’ve never stepped back and said, why are we making it, what specifically do we think this addresses? And sometimes developers make a game because they think it will be awesome, but there’s little consideration for who they’re making it for.”
LeTourneau started his career in the games industry in 1990 working at Electronic Arts’ customer support department. From there, he went on to a 10-year run of producing The Sims games and eventually became VP & GM of The Sims Studio. “I came to Zynga in 2011 because I thought that social gaming was not a fad,” he said. “I watched my wife, who never played games with me, all of a sudden have a daily gaming habit. I wanted to understand how it works.” At Zynga he started learning on the FarmVille team and ended up leading the team that created FarmVille 2, Zynga’s current, biggest hit. As CCO, LeTourneau spends most of his time consulting with all of the different game teams at Zynga, helping them understand what their focus is by following his philosophy.
LeTourneau explained that the approach to the audience was a key difference between The Sims and The Sims 2. “It’s amazing how many games are taken out of the hands of the gamers they were intended for, mainly because of the people making the games. We get bored with what we’re doing and we continue to make them harder, and we have knowledge that the gamer doesn’t have. Sims 2 is a great example of that. There are so many things that I would go back and do differently. We ended up making the game for people who were still playing The Sims, but the reason The Sims ultimately worked is nobody had proven knowledge of it. It had to be a game that worked for everyone.”
This lesson guided LeTourneau and his team going into development on FarmVille 2. It’s not a game made exclusively for current FarmVille players. It’s a FarmVille game that’s targeted specifically at the players that maybe never played Farmville before. “It’s very much about understanding who the audience is, and understanding that they don’t bring any knowledge of what you’re making into the experience. You have to introduce them to it in a way that they all feel like they belong.”
While his “who, why and how” philosophy is applicable to all projects, there are issues and questions that arise specifically when designing a free-to-play game. During his lecture at Casual Connect, LeTourneau will also discuss how to build a functioning in-game economy, plan for the future of the game and create meaningful social connections between players.
Find out more about Casual Connect’s lectures and sessions here.