Fine & Dandy Games是个小型独立游戏工作室，开发了新款iOS游戏《Goop》。在这款解谜游戏中，玩家帮助一群小生物避开上方掉下的危险黏性物闯过游戏的各个阶段。Fine & Dandy Games的成员有两名，我是开发者，Ashli Norton是运营主管并且负责其他所有事宜。
我们不希望在项目进行过程中因频繁更换技术而浪费宝贵的开发时间。我们要找到不仅现在易于使用而且在不久的将来也不会改变的技术。我花了数周时间来决定项目所使用的技术，在此期间没有编写任何代码。《Goop》的开发本可以选择使用诸如Game Salad、Unity 3D和主流iOS语言Objective C等工具，但是我认为应该使用那些广泛运用于其他平台上的非专有标准技术。因为我们需要考虑的不只是《Goop》，还包括将来的项目和更新版本，我们希望能够确保不浪费时间。如果需要在随后开发其他项目时学习新机会，这会增加开发时间并延期将来的更新和游戏，我们不认为需要将时间花在这个方面上。
iOS也提供了许多处理游戏图像的不同选择，包括Core Animation、Quartz 2D、Core Graphics和OpenGL ES。我选择使用OpenGL ES的理由和选择C++的理由相同：可移植性。OpenGL ES让我可以完全控制图像逻辑，如果利用上述提及的其他技术，可能较难实现这个目标。使用OpenGL的一大优势在于其是非专有且被广泛支持的标准，不仅可以在当代的智能手机上使用，而且还可以在Mac OSX、Linux和Windows上使用，这又简化了《Goop》将来的移植过程。
对于润色的重要性以及游戏中每个细节的关注，再怎么强调也不为过。App Store中竞争激烈，坦诚地说，用户习惯使用那些控制简单且视觉效果丰富的游戏。所有熟悉App Store的人都能够理解设计的重要性。这意味着你既要有创造性，也要能够决定添加哪些细节、进行哪些润色。
开发商：Fine & Dandy Games
发行商：Fine & Dandy Games
开发工具：XCode 4, Macbook Pro, iPhone 4, Instruments, Cornerstone, Zwoptex, Glyph Designer, Audacity, Garage Band, Adobe Illustrator 其他花絮：开发时期平均每天睡觉时长为4小时。
Postmortem: Fine & Dandy Games’ iOS Debut Goop
Fine & Dandy Games is the small indie game shop behind the new iOS game title Goop, a puzzle game in which players help a group of small creatures navigate the game’s stages while avoiding dangerous goo dripping from above. Fine & Dandy Games is made up of one developer, myself, and one business manager and “everything-elser,” Ashli Norton.
Sharing years of experience in operating small software shops, we are both complete newbies to the exciting world of game development. My experience as a self-taught software developer goes back to age 12, and I have always had the desire to get my foot in the indie game door. That finally happened in late 2010 when I made the decision to tap into the creative side of my brain and shift away from traditional mobile and desktop applications.
From day one, it was a truly exciting experience to begin building a game company. Everything from choosing the company name to writing and sketching out numerous game title ideas was simply exhilarating. As I’ve worked with Ashli before on numerous projects including our current software company, it was almost a no-brainer to team up again to deliver our high quality game concepts. My more analytical way of thinking matched perfectly with her more out-of-the-box, consumer angled focus and this helped shape Goop into what it is today.
Being fans of most things Apple and understanding the Mac and iOS ecosystem made it easier to narrow down a platform for our first title. We also knew we wanted to target a large segment on the iOS platform and create a game in a category we typically played.
Our partnership highlighted our strengths as I was the sole developer and typically made the final creative decisions. Ashli focused on bringing this game title to the masses while inputting her creative ideas from a perspective I typically didn’t recognize. We went with outside help for music and art, since we knew these were skills that weren’t present in our DNA.
What Went Right:
1) We narrowed down design and concept early and stuck to it
We had dozens of ideas for possible games as our first release, from fully documented and sketched ideas to “wouldn’t it be cool if…” ideas that were never put on paper. Ultimately, we chose a game concept that we felt could utilize some of the common traits of other popular casual games in the App Store while also allowing us to implement our own ideas, such as the usage of unique characters that possessed personalities of their own, a very low learning curve for most users, and attractive graphics that would lure curious browsers. One thing that we’re proud of is that we didn’t let feature creep get the best of the project and the final result is very much similar and to the initial idea.
Nailing down the concept early was key to a timely completion. We were able to communicate and share ideas with the designer early, although not as soon as we would have hoped, which allowed her to give us important feedback. Sticking to concept gave me the chance to fully plan the direction of development, such as how collision and touch would be handled. A very welcomed bonus to staying on course was the ability to begin polishing the game without waiting until the end, the time when you’re just ready to see your app live in the store. Although we didn’t have a hard deadline set, narrowing the specific design and concept ahead of time led to a project that was able to launch in a reasonable timeframe.
2) Thorough market research on the game we wanted to release
Market research is the first thing most companies do before developing a product in any industry to lessen the chance of failure, and we were no different. We needed to learn about our demographic and determine if it was viable to pursue our game concept. As a small shop it’s very easy to let your imagination and ideas run the company, and while you may have all the best intentions, you risk the chance of completely abandoning the very market you were trying to serve with your “what if” and “it would be cool” ideas. Market research helped us determine how our game could be different from the thousands of games currently available. Being unique and identifiable was very important to us, so lots of time was spent determining if there were titles too similar in the App Store.
We made sure to evaluate other games currently available on the App Store, looking at which games were popular, which games received media coverage, which aspects of popular games users seemed to like most, and why some games couldn’t get traction. Using these findings really strengthened our ideas by reducing weak points in our game concepts and marketing.
Although we did gather a lot from existing games, we were adamant about our game being unique, which is easy to do with the game’s name. Believe it or not, this took months. We went beyond a typical App Store search and looked around the net to make sure there were no other similarly named titles. We wanted the game’s name to be unique, easy to pronounce, identifiable, and effortless to remember.
The same applied to naming the characters. First, we needed to name our characters as a group, which led us to something that was likable and easy to remember ‘Eeeps’. Giving each character a name was a bit more challenging. We had to ensure each name not only matched each Eeep’s personality, but that the names weren’t human-like. In addition to ensuring the names didn’t sound human, we had to come up with Goop’s character types and names which were unique to our game alone. The character names also had to be non-offensive and translate well in the future to localized versions of the game. For instance, our Plumpy character type could have been named a lot of other things, but we had to choose a name that was cute, ensured that the player liked and wanted to save Plumpy, and users didn’t find the name offensive.
3) Settled on the technology that was going to be used before programming began
We didn’t want to waste valuable development time changing technologies in the middle of the project. We wanted to focus on technologies that were not only going to be easy to use now, but were actually going to be relevant in the near future. I spent weeks deciding which technology to use for the project, even before writing a single a line of code. There were easier options for Goop development including using tools such as Game Salad and Unity 3D or even the option of using the primary iOS language of Objective C, but I considered it wise to utilize non-propriety, standard technologies that are widely used on other platforms. Because we weren’t only thinking about Goop, but our future projects and updates, we wanted to make sure we avoided wasting time. Learning additional technologies later on other projects would increase development time and planning in our future updates and titles, time we didn’t feel we had to spend.
Although the game was planned to be initially available on the only on the iOS platform, I chose the C++ route for the ease of portability to non-iOS platforms. I also understood that C++ is a widely used and accepted programming language in the gaming community, ensuring that if I ever needed support, it would be readily available. One benefit of the iOS platform is that C++ as well as C and Objective C can be used interchangeably within source files, which makes switching between necessary platform specific logic and game logic a breeze.
iOS also provided a number of different options to handle the graphics of our game including: Core Animation, Quartz 2D, Core Graphics, and also OpenGL ES. I chose to go with OpenGL ES for the same reasons I went with C++: portability. OpenGL ES gave me complete control over the graphics logic, which may have been more difficult to achieve utilizing the other technologies mentioned. A huge benefit to using OpenGL is that it is a non-propriety, widely supported standard that not only works on most of today’s smartphones, but also Mac OSX, Linux, and Windows, again making Goop’s future portability much easier.
4) Chose a game that was a challenge, yet in the skill set of a new team
Although both our game designer and music composer were no strangers to game creation, I was. Not only was outsourcing to freelancers new to me, it took much more time than we actually planned. Creating a title within our skillset made it simpler to communicate our ideas to our designer, as we felt more confident when determining the assets that were needed for the game.
I had two distinct goals: one was that the project had to be challenging yet something I could accomplish within my technical capabilities and two, it was mandatory that the project didn’t actually come off as my first game. That being said, I knew it had to be a game that displayed an immense amount of graphical polish and highlighted pinpoint mechanics. Luckily, choosing Goop allowed me to forgo the use of a physics engine in my first title, which could be daunting for a first time game developer.
A game title with wide commercial appeal was goal number one for us. The App Store has a vast market of users, with varying technical proficiencies, and the game had to appeal to even the most novice gamers. Our goal was to make Goop simple and enjoyable enough to be played by children, adults, and first-time smartphone users alike. This eliminated the need to cater toward a specific niche that we may not have been knowledgeable enough to provide a pleasing and satisfying end product. It was also important to pick a title in a genre we played ourselves on the iOS platform. This ensured we would be able to critique our own work and have the opportunity to tweak the game, adding things that could make the overall gaming experience better for the end user.
5) Paid extensive attention to detail and polish
I can’t emphasize enough the importance of polish and paying attention to every detail in the game. The App Store is highly competitive and quite frankly, the users are used to awesome looking titles with simple and predictable controls. Anyone that is familiar with the App Store understands how vital it is to have the very best design. This means you have to be both creative and determine where polish will be added.
The polish of games goes beyond graphics. Attention to the game mechanics was a must. We had to make sure the Eeeps responded appropriately toward the users’ actions, as well as collisions and other happenings in the game. Polishing our mechanics meant considering how the user was going to hold the device, how they would touch the screen while using their device. We wanted to make sure a person who has never used a touch screen device could play Goop. The user had to be able to play Goop without any previous knowledge of the game functions and without reading any guides or directions.
The polish of Goop continued until the last seconds before submitting the game for Apple’s approval. At first, we had the concept of swiping the Eeeps to tumble them backwards and forwards in the game. Although this made complete sense to us as the developers of the game, when we handed over the game to our parents, who didn’t own touch screen mobile devices, it was quite painful to watch them not know what to do because of the complicated controls. After switching to a more expected tap interaction appropriate to the device, I was pleased to see that even my five year old nephew had the ability to tumble dozens of Eeeps to safety.
From a graphical perspective, I personally hold 2D games to a higher standard when it comes to art versus their 3D counterparts, and I assume users do the same. This is because of the very nature of how 2D graphics are implemented. These graphics are typically implemented into simpler, casual, more user-friendly games, giving users the idea that the game in whole was simpler to create. Since the users feel the game was simpler to make, they expect more of an investment into better graphics. This is why we wanted to emphasize to our designer the use of bright and colorful artwork. Our designer, Christina-Antoinette Neofotistou, is simply talented and had the idea of adding animations in the background of each scene to make the game feel more alive, more fun, and realistic. On the development side, it was vital to us take advantage of the technology at hand by making sure we added retina-display supported graphics, which enhanced the bright feel and vividness of our characters, scenes, and menus. We wanted to avoid having someone dislike Goop because the graphics weren’t as bright or as crisp as in another title.
What Went Wrong:
1) Lack of planning and detailing the number of assets truly needed
Near the completion of the game, it became painfully obvious we didn’t plan every screen as completely as we had hoped. Graphically, there were items that I believe no first-time game developer could have planned for, such as the icons that would represent the achievements earned in the game or the appropriate font sizes for each screen.
We also realized we didn’t plan the proper amount of audio assets required for Goop. Initially, we just had a high level idea that the game needed game music and character sounds, but we didn’t prepare for exactly how many different character sounds were needed. We forgot sounds were required for the tumble of each Eeep, the sounds of the Eeeps getting gooped, the sounds for button interactions and menus, and other sounds necessary to add depth to the game.
2) Bringing in outsourced talent too late in the project
I cannot emphasize how important it is to include the talent you will be working with in the initial concept and game design. We had the idea that we would be able to finish 80 percent of the game logic before involving any third parties in the concept and design. This was a complete mistake, and luckily we only completed about 30 to 40 percent of the game before including talent.
Getting feedback early in the development process from our game designer helped shape Goop into what it is today, including the usage of animated objects in each environment as well as the integrated audio toggle with the play button. However, some suggestions required coding changes on my part that added unnecessary time to the entire project. One such change was using a stationary animated drop sprite versus the initial implementation of a drop sprite that changed positioning as it fell toward the ground. This change allowed for an easier implementation of a more realistic drip by showing drop residue on the ground while another drop was beginning to ooze from the pipe above. This would have required multiple sprites in synchronization to accomplish using my initial method.
We also unfortunately waited too long to make sound and music selections for the game, which caused an unnecessary rush on the behalf of our music composer Sean Beeson and ourselves. Although we are thoroughly satisfied with the music selection for Goop, we can only imagine how much better the overall audio could have been if Sean was included in the project earlier on.
3) Not marketing and building connections soon enough
Marketing as soon as possible in any project, particularly game development is crucial. We made the big mistake of keeping our ideas and our project to ourselves when the development community would have been more than supportive and would helped spread the word about our upcoming game title. Not asking experienced developers for guidance was a mistake. We could have taken the opportunity to build connections to ensure these influencers were aware of our game the entire development cycle. I’ve found the developer community to be hugely supportive and I am now aware of lots of publishers, game developers, and game designers that would have been excited to share their experience and knowledge earlier on, while also spreading the word about Goop as the project developed.
4) Incomplete prototyping, too late.
Knowing just how fun, appealing, and easy to play a game can be is a crucial part of development. I think this allows you to know which direction your game should go or even if you should continue to develop the game in the first place.
Unfortunately, early prototyping was left out during the development process. We could have greatly reduced the number of code changes when key aspects of the game needed to be changed such as the user touch interaction with the characters. Early prototyping would have made us aware of how easy or complex the game concept and controls would be for the average user. Receiving early feedback internally from our small team from first stage alpha testers would have helped tremendously in gauging how to further progress with the game’s development. Luckily, I think this project ended well, but we missed the opportunity to have a more streamlined development cycle resulting in added time to the overall project.
The art development could have gone a lot smoother with the use of a working prototype. The ability to show our artist a playable demo would have eliminated long, confusing back and forth emails. This also would have sparked the imagination of the designer much more compared to the low quality photos of my lackluster whiteboard drawings. A working prototype would have introduced game screens to my designer, reducing the number of overlooked and underestimated assets in the project.
5) Not enough phases of beta testing
It’s hilarious to us in hindsight how complete we thought the game was when it was sent out for beta testing the first time. We were so confident that the game was “perfect” that we boldly sent out the test version with a 0.9 version number, expecting only simple bug fixes here and there to get us to the final 1.0 version that would be submitted to Apple.
We were absolutely wrong. Beta testing is where we not only realized the game controls weren’t as simple as we thought, but our adorable family of Eeeps weren’t set to the accurate frame rate, and looked as if they were hobbling across the stage instead of working through their complete walk cycles. What would have been an obvious misstep to a non-partial party like a beta tester, was “perfection” in our eyes. We were so mesmerized by the simple fact that we completed the game and that it looked great, that we couldn’t objectively test the game to make a perfect end product.
Although our internal beta testing was helpful and truly eliminated a lot of bugs that external beta testers would have needlessly experienced, our internal testing was more about bug fixes and leaks, versus the bigger and more important component of the game: the gameplay.
We honestly believe Goop couldn’t have turned out better. We put a lot of work into the game and even through all the late nights of yelling at my Mac or simply cursing my code for the glitchy surprises it threw my way, the end result to us is phenomenal. Regardless of whether Goop is a commercial success, we will remain pleased with simply realizing our dreams of creating a game company with a first title that doesn’t scream “our first game.” Even after months of development and hours of testing, I am still in shock that not only is the game complete, but we made a project that we could be proud of for years to come.
Goop’s future is honestly more organized than the development process was. One of the first updates for Goop beyond typical bug fixes is localization. To us, this will be fundamental in the growth of Goop, especially with Apple’s ever-growing focus on expansion into new countries. After localization comes the iPad version. We want to provide those who enjoy Goop on their iPad a unique experience and want to be able to take advantage of the additional screen real estate the iPad has to offer.
All we know for sure is that after the initial challenge of getting Goop out the door, we are now one tougher bunch. We feel prepared for almost anything the gaming market has to throw our way. We feel inspired and can longer imagine our futures without somehow being a part of the gaming world. (Source: Game Career Guide)