Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Little Boy Games' Go! Go! Break Steady
View All     RSS
June 16, 2019
arrowPress Releases
June 16, 2019
Games Press
View All     RSS








If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Little Boy Games' Go! Go! Break Steady


September 18, 2008 Article Start Previous Page 4 of 4
 

2. The hamster development.

It was absolutely necessary for a genre-merging, original title like GGBS to have a lot of gameplay and visual iteration to become compelling. However, as engineers and neophyte game designers it played havoc on our nerves. For one thing, it gave us a deep respect for the game producers out there.

As an engineer I always found it irksome when features I worked on so hard were cut or heavily modified. The burning question would be, "Why wasn't the feature fleshed out completely before it was built?" Having put on the production hat, it became clear why something intangible like fun can never be figured out on paper.

Nonetheless, it was a psychological struggle to continue to discard or re-work game features. It was especially expensive and gut-wrenching when we had to make changes very late in the development cycle.

All in all, developing a new IP with a unique game mechanic is not for the faint of heart.




Figure 4: What Looked Cool Kept Changing

3. Call in the refactorer.

The barrage of reworking of gameplay and the visual look of the game also made managing our codebase quite an ordeal. While the build-as-you-go technique meant the code and coders had to be flexible, at some point it became overwhelming.

Although we built a rendering test-bed to try out various visual elements, like new shaders or particle systems, we still ended up refactoring our main codebase over and over again. Unfortunately, a lot of the core architecture from various prototypes still lingered in the final codebase despite our refactoring efforts.

For instance, the initial move tree code was still intact, but the tree was now a linear list. Similarly, the puzzle evolved from its hastily written initial prototype. In retrospect, we could have reduced bugs, especially the very expensive online de-synchronization bugs, if we had refactored the puzzle code once we had finalized its behavior.

4. XBLA integration is no joke.

Despite having worked on a number of major titles and having experience with online-related certification issues, we underestimated their impact on our game.

We thought that having such a small front-end, and relying on Microsoft libraries for online features, we wouldn't need to build major architecture to handle things as invites, network disconnects, memory card ejections, score reporting to leaderboards and profile changes. This turned out to be a significant mistake, as the majority of our bugs were related to the aforementioned issues.

XBLA integration is a feature unto itself and requires a lot of dedicated development. Having slogged through all those issues for GGBS, it is absolutely clear that one has to carefully architect user interfaces and respond to the Xbox HUD properly in all areas of the game.

The critically painful issues happened during pre/post-game lobbies and when the game is loading up. There are too many edge cases to enumerate here, but to summarize we learned the hard way to give the XBLA integration features their due.

5. Marketing XBLA games as an indie.

What is hype? We completely underestimated the marketing effort required for a successful XBLA title. One of the most attractive reasons for us to develop for XBLA was that we wouldn't need a publisher or major marketing, as the game would always be available online and would be able to garner enough sales for us to make up our investment.

This might have been true when we first started developing for XBLA, as there were then fewer than 10 titles available. We, on the other hand, were the 150th title on XBLA, and we were released alongside a very popular remake of a classic arcade game. Going into our release, we had next to no hype and much to our chagrin very little post-release hype.

Researching this more, we realized that this seems to be the bane of all indie developers. Although we found someone to help us with the PR work close to the release date, in retrospect it would have been prudent to show more of the game earlier so consumers would at least recognize the name when they see it on XBLA.

Conclusion

In the making of GGBS, we encountered a ton of trials and tribulations. Developing a product from scratch and releasing it successfully to the mass market brings an amazing sense of accomplishment with it.

XBLA titles now have production qualities that rival previous-gen titles, and it swells our hearts with pride that with such limited resources, we were able to create a game that is fun and provides a one-of-a-kind gaming experience. Hopefully, it will find its way into the hearts of consumers too and we will have a truly happy ending.


Article Start Previous Page 4 of 4

Related Jobs

Gear Inc.
Gear Inc. — Hanoi, Vietnam
[06.15.19]

Technical Director
Legends of Learning
Legends of Learning — Washington, DC, District of Columbia, United States
[06.14.19]

Senior Unity Engineer - $140k - Remote OK
Wargaming.net
Wargaming.net — Chicago, Illinois, United States
[06.14.19]

Server Engineer
Wargaming.net
Wargaming.net — Bellevue , Washington, United States
[06.14.19]

UI Engineer





Loading Comments

loader image