[In this in-depth postmortem, longtime independent developer WayForward (Contra 4) discusses the creation of Wii remake A Boy And His Blob for Majesco, looking at what went right and wrong in updating the classic NES title for today's gamers.]

WayForward is an independent game developer based in Valencia, California. We turn 20 years old in March, and have shipped over 100 retail products for systems ranging from plug-and-play to Nintendo Wii. We're best known for games like Contra 4 (DS, 2007), the Game Boy Color Classic Shantae (2003) and the WiiWare horror puzzler LIT (2009).

We recently found a focus bringing retro gaming sensibilities kicking and screaming into modern times. Lunchtime conversations focus on things like Castlevania jump heights, for example. We are unified in our reverence for the games we grew up with and love. As a result, our games build on the classics using lush art, fluid animation, and innovative applications of new technologies. While we have developed great games in all genres, we have a special affinity for side-scrolling platform games.

We got the idea to pitch a new A Boy and His Blob game after spending some time playing the original NES game. I was getting frustrated with the mechanics of David Crane's quirky puzzle platformer, mostly because they were so brilliant! However, the implementation leaves a lot to be desired.

We began to brainstorm new transformations and mechanics, and a seed for a pretty cool Blob game was planted. This sort of thing happens all the time at WayForward -- but this time, we knew the owners of the IP.

Majesco acquired the rights to A Boy and His Blob when the original owners, Absolute, went out of business. WayForward and Majesco had been talking about working together for a while, so we simply put together an awesome pitch and sent it their way. We met to discuss in person at E3 2008, and the rest is history.

Originally pitched as a small WiiWare title, we instead turned the idea into a full-blown boxed Wii game. Pleased with our fortunes, we were quite excited as the realization struck... how were we going to pull this off?

A Boy and His Blob meant a lot of firsts for WayForward. It was our first boxed Wii title and a new foray into our ancient history of full-blown traditional animation.. Attempting something this unique created both excitement and confusion. Our verve for the project kept us going, but there were considerable hurdles along the way.

What Went Right

1. Small Team, Focused Vision

Blob had a very small team, all leads, consisting of only six members. These key players were involved in all aspects of the game, from art generation to level design to gameplay tweaks. With a small group, everyone wears a lot of hats and cross-pollination of ideas is built in.

Another benefit of this setup is that each team member is guaranteed to be strong; a lackluster developer would not survive in a team structure like this; everyone had to carry his own weight. Accountability was perfect; there were no layers of bureaucracy to obscure who was responsible for an issue. Lastly, communication was as easy as talking to a single point person; any slack in development could be identified early and picked up by another team member.

In addition to a small and agile team, Blob benefitted from a shared vision of the final product. We wanted to do something different than a normal platform game -- to make something cerebral, where the player would have to stop and think occasionally.

We wanted to integrate the tutorials and interface into the game; to remain text free and HUD-free. The Blob would be a lovable and realistic character that made you care not because of cutscenes, but because of the experience the player shared with him and the dependence of the characters on one another. Artistically, we would attempt to create a Disney (or Miyazaki) film in a game, but with total interactivity.

The treehouse acted as a title screen and menu

These choices were made early on and informed the design of the entire game, giving us the treehouse interface, the "sleeping boy" title screen, and laid the groundwork for the Blob's AI, and the types of puzzles the player encounters. Because we had such a good idea of what we were making, feature creep was not a problem. New or radical ideas were also easy to dismiss or integrate; when someone would say "I don't understand, maybe you need a tutorial", we could say "no, this game doesn't have tutorials. Maybe we should make it more intuitive."

2. Designing to Our Strengths

WayForward has a long history of making 2D platform games. We also have a long history of excellent art and animation. We are situated next to Cal Arts, a premiere animation college originally founded by Disney.

Much of our art talent comes from Cal Arts, so what better game for WayForward to make than a beautifully classically-drawn 2D platformer? This type of game matched very well with our sensibilities and gave us the freedom to concentrate on more important areas of game play.

Our development philosophy was also aligned to our strengths and weaknesses. We didn't have a lot of separate menu screens, because reusing the in-game engine for menus was more efficient, and this ultimately resulted in a really cool and immersive treehouse interface.

We didn't make a lot of cutscenes, because at the time we didn't have a timeline-based scripting tool to allow for such a thing, so we tried to compensate by making the gameplay itself convey emotion. Leveraging these challenges into strong points helped to create what we felt was a truly unique experience.

3. Publisher Cooperation

Majesco was with us every step of the way in developing the game. Early on, as one could imagine, there were good questions from the publisher. Why weren't we using the Wii Remote's capabilities? Why are we making this game cutesy instead of edgy? What sort of marketing tie-ins could we exploit with this product?

To communicate more effectively, we laid out our approach in a series of documents aimed at selling our vision to the publisher. Our game was to be sincere and heartwarming, with serious artistic integrity. Majesco's understanding of this direction and their support became very important.

Once they caught the vision, Majesco was with us every step of the way in the implementation of it. Many publishers would not be willing to let a developer take the lead in such matters, but Majesco was very respectful and supportive of the team's direction.

As a result, they received a game that was a truly a labor of love. We went the extra mile because they laid out the track for us.

4. Weekly Reviews, Kid Testers, and Iteration

It seems obvious, but the more people you observe playing your game, the better it gets, provided you pay attention to their feedback. Every Friday, we brought the whole team together to watch the game being played by someone new.

This may seem like a misallocation of valuable resources, but the benefit of having everyone gathered to discuss the goings-on was incalculable. Communication is key, and nothing gets the team talking more than someone playing through your game and getting frustrated.

In addition to having adults and friends play, we brought in kids from ages seven through 11 to test. They provided the best feedback of all. Watching them get excited or bored helped to shape what we added or cut from the game. After play tests, we asked some questions concerning the gameplay, their favorite transformations, and favorite levels. After every test, we had pages and pages of revision notes, which everyone feverishly began to work on.

Near the end of production, we had a TV set up next to a workstation full time. One player played all day, and a level designer had the level tools open right next to him. We changed the levels as we played through them, then rebuilt and did it again, and again, and again. This made the levels, especially the first 10 forest levels, feel perfectly polished and balanced. Unfortunately, we ran short on time to tweak the rest of the levels to this quality bar. We compromised by focusing more on the first 10 levels and the final 10, because those would stick in the player's mind after playing.

Sign posts lead kids and angered hardcore gamers.

This process is not without some caveats. The much-maligned painted helper signs that are all over the place in the early levels are a direct result of these play tests. Kids wouldn't know what to do early on, so we tossed in signs where they were getting confused. I also have the feeling that many adults wouldn't know what to do without these signs either. Nevertheless, they got slammed in reviews for being too leading. We would certainly have a "remove signs" option for Blob 2!

5. 2D Power!

Since WayForward has been doing great animation for years, making a 2D hand-drawn console game was an obvious step. Going with the 2D art style was one of the biggest reasons that Blob stood out from the crowd. We made it adorable and cuddly in an industry full of of grime-soaked post-apocalyptic hellscapes!

Detailed study guides were made for the characters

Our 2D "style", the high concept of a playable cartoon, helped get us a lot of press; everyone fell in love with the game as soon as they saw it. The early buzz helped get the team psyched and convinced all parties that we were on the right track.

What Went Wrong

1. Developing on the Fly

This was WayForward's first boxed Wii game. Everything was new; the 2D engine, the collision system, and the art pipelines were all untested. In an effort to get the game working, we built levels and Blob transformations on incomplete foundations. We jumped into development without these crucial elements finished and in place, and it gave us a ton of headaches.

First of all, the tech was not quite ready. Things as basic as the collision engine were being tweaked until late in production, causing dreaded cascades of problems throughout the whole game. We had jellybeans flying through walls and Blobs popping out of the world halfway through production.

Many flaws in the collision system were hacked out, but these house-of-cards solutions made the game rigid and resistant to change. Long hours had to be spent reworking the gameplay.

Our tools, carried over from our DS pipeline, proved unable to handle the huge environments and file sizes of Blob. This required tool rewrites, purchases of better computer equipment, and slowed our level design process down. Eventually, these problems were all worked out, but they ate into development time.

Our animation pipeline was also untested for this type of game. We began by drawing everything on paper, then scanning in, coloring in Photoshop, and batch-resizing the animation frames to fit in the game.

Dust and blemishes, not to mention half-erased pencil lines, had to be manually scrubbed out by cleanup artists. The huge amount of artwork made this task larger than anticipated.

It's funny to think back on it now because it seems so labor-intensive and there were much better solutions available. By the end of development, we had an army of artists armed with computer tablets and animation software. Once again, the newness of the pipeline cost us time, but we are now firing on all cylinders with an amazingly efficient and skilled animation department. Subsequent games using these animation techniques are going much more smoothly.

Level design was also an issue. The huge number of levels (80 in total) required that everything be designed and iterated on numerous times to get our desired level of quality. Unfortunately, the Blob's transformations and enemy patterns were not always finished (in part due to the slow art pipeline), and the collision system was not done.

Levels were being built around gameplay that was not finalized, and then the gameplay was tweaked further, leaving the elaborately-constructed puzzles in ruins. Programmers and level designers had to compromise on who was going to fix what.

Overall, creating everything concurrently was painful, but the process provided us with a stable base for future projects.

2. Outsourcing

WayForward has been able to keep agile by using outsourcing for many of our needs, including sound effects, music, and art. The tradeoff is that you sometimes end up with communication problems. One of my favorite stories is from the development of Contra 4.

We needed art for a big winged alien boss (who never made it into the game) that was supposed to have a big eye you shot to damage him. The foreign outsource house delivered a cool-looking alien, but the eye was way too small and inconspicuous to hit. We sent it back, explaining that you were supposed to shoot it in its big giant eye. We got back an alien with a huge eye -- right on its pelvis, instead of its head!

Anyway, we faced similar challenges on Blob. Our art outsourcing groups delivered wonderful background art, but they didn't understand platform games. Our templates were not always turned into usable tilesets. This meant that our artists had to rework the art, which took time and delayed level design. Frame counts for animations sometimes turned out wrong, and the quality varied between animations that were obviously done by different people. With our in-house specialists, issues like this were much easier to communicate and iron out.

What we gave them.

What we got.

Outsourcing sound effects was also problematic, as our SFX person was unable to spend a lot of time at the studio observing the game she was making effects for. Lead gameplay programmer Larry Holdaway, stepped in and pulled double-duty as a SFX fixer-upper, putting the effects through filters, fiddling with the volumes, and sometimes making or finding all-new effects.

Lastly, some outsourced programming we tried ended up not working out as well, and we had to pull the development internal to get the results we needed.

With the added problem of time zone differences, outsourcing for Blob was a hurdle. There is a silver lining; much more of our work is being done in-house now and we have a brand new internal audio department. WayForward has grown to over 80 full time people!

3. QA Schedule

Blob is a platform-puzzle game using a new engine, with an AI companion and 80 levels. It's complicated! We really should have gotten the game into testing earlier. We continued to have bugs crop up later than we would have liked.

For future efforts we will most likely try to start two months earlier in production. This will mean that the game will be more stable as we get closer to the finish, and we will be able to focus more on that ever-so-important polish.

4. Boss Battles

The boss battles were a source of strife throughout development, and the team was not satisfied with the end results. We realized too late that the methodical gameplay of Blob really doesn't support actiony bosses of this nature.

The beast boss in particular comes to mind. The idea behind the beast boss was that you would be dodging him while rolling around the arena in a desperate struggle to lure him into some floating mines.

It ended up an exercise in frustration. First off, the boy is not agile enough to throw the beans quickly and get into the sphere before the beast would inevitably come crashing down on him.

Second, the Blob's AI is not predictable enough to ensure the boy's survival. The chaotic Blob can be cute in the regular gameplay, but becomes frustrating during the boss battle.

Lastly, the boy only takes one hit before going down, forcing the player to start the whole thing over for one tiny mistake. We attempted to minimize the problem by making the boy invincible in the sphere and by slowing the beast down, but it wasn't enough.

The peril of the boss battles looms...

The later bosses took the slower gameplay into account. The emperor boss, in which you must slowly work a rock over his head until you knock it onto him, is more in line with the gameplay and works much better. In future games like Blob, boss battles would be better as methodical puzzles that play to the strengths of the gameplay.

5. Scheduling Woes

The schedule for Blob, like many schedules in the game industry, was created without detailed knowledge of how long everything was going to take. The result: we had a bunch of dates to hit based on our best guesses, which ended up less-than-perfectly accurate.

Still, we were committed to these dates, and there never seemed to be time to catch up for the next delivery. Focus sometimes shifted to "just get the content in!" in order to meet the milestones.

Because we had to rush through the implementation to meet the milestones, we ended up with less-than-desirable foundations for some of our levels and transformations. New implementations and levels were designed to conform to the broken structures, and resulted in a cascade effect when we finally went in to fix some of the early problems. Some problems were simply too ingrained to fix.

If we had allocated the time to do everything correctly in the first place, we would have probably ended up with a more solid game. This problem will be circumvented in the future by keeping milestone definitions flexible initially, then solidifying them once the team has a better idea of time required.

In conclusion

A Boy and His Blob was a labor of love. The pitch and the big ideas were all generated at WayForward, and it was wonderful to keep the concept pure. The team's freedom to follow a shared vision was a big help. All of this was possible because the publisher was willing to trust WayForward to develop the game.

The resourcefulness and agility of WayForward as a company was a big strength; rigid companies with more bureaucracy would not have been able to execute on this game within the resources allowed. The resulting mad dash resulted in a few stumbles, but Blob became a heartwarming and fun adventure. It's one of those titles that everyone on the team truly enjoyed creating; as a game that's special to us, hopefully it will open doors to even greater adventures in game development.

A Boy and His Blob Facts

Developer: WayForward

Publisher: Majesco

Release date: October 13, 2009

Platform: Nintendo Wii

Development time: 11 months

Number of developers: 35