Category: Projects

World Series of Poker: Full House Pro (WSOP:FHP) was a free-to-play online poker game, developed by Pipeworks Studio and published on the Xbox 360 by Microsoft Games Studios on September 4th 2013. On this project, I was Lead Engineer during pre-production and Gamplay/UI Engineer through the rest of production to the soft launch. This was also my last project at Pipeworks Studio and, as of this writing, my last professionally developed game.

This was a troubled project. The intention was to take a previous Xbox poker game, Full House Poker, port it to the Unity engine, make it free-to-play with micro-transactions, and incorporate the WSOP license, and do all that in 6 months. The launch was a year after development started. A lot went wrong, and as lead engineer, I bare a fair amount of responsibility. It is said that we learn more from our failures than our successes, and I learned a lot on this project.

The first lesson is to push back against unrealistic deadlines. My inexperience as a lead and history of inexpensive licensed games where the schedule was unmovable gave me tunnel vision, focusing on an overly optimistic schedule that would have relied on everything going right to succeed. I don’t know if the schedule could have been changed, but I definitely should have given voice to my reservations.

Next, we should have planned more around our risks. Early in pre-production, we identified several risk factors, including 3rd party support, code and asset reuse, licensee approval and internal technology development. But even though we identified these risks early, we didn’t have contingencies planned incase of a delay or other issue. And many of these risks became issue. As lead in charge of scheduling and planning, this was a regrettable oversight.

One aspect that did seem to go right, at least initially, was we had a working gameplay prototype early, reusing AI and game logic from the previous FHP. The issue is these were the only modules we were able to reuse. Changing engines meant much of the codebase had to be rewritten from scratch and the switch from a Peer-to-Peer to a Client-Server network architecture meant the game logic had to be substantially modified. The major problem with this is the prototype gave us false hope of an easy development and served as the basis for much of the gameplay code logic, which made the eventual shift to the client/server model more difficult and time consuming than if we had scrapped much of the prototype code after the concept had been proven. As the person who wrote the prototype and much of the gameplay code, this was my blunder and my lesson.

Now the lessons are less organizational and more personal. As a still inexperienced lead, I was eager to prove myself and took on a lot more coding responsibility than I should have. I know that management would be a major part of my time, and I viewed the coding tasks I gave myself at the end of the day as a reward for completing the rest of my duties. But as the coding tasks became more integral as production ramped up, with the core gameplay code being my sole domain, these initial couple hours of coding became late nights of coding, as I was crunching evenings almost from the beginning. As development dragged and the schedule was pushed back, it was evident that I was struggling, floundering. In a move that was both devastating and a relief, I was removed as lead engineer so I could focus gameplay and UI exclusively.

The lessons I take from this are numerous. Manage my time better. Don’t take on core responsibilities as lead. If you are crunching early, it is a sign of poor scheduling, especially if you wrote the schedule. Don’t be afraid to ask for help, especially if you are struggling.

The most personal lesson of all: Don’t put your life on hold for a project. During development, my wife, then fiancée, and I bought a house together. But before I could move her and her kids, who lived two hours away, crunch hit big time. It was several months before I felt I could take the time off work to handle the move, which was a great source of tension and concern, even after we were together under one roof. While before, crunch meant I had to skip playing games in the evenings, now it meant being away from my family and not fulfilling my duties as a husband and father.

After a year of hard, frustrating struggle, World Series of Poker: Full House Pro launched. Unfortunately, there wasn’t enough work for everyone. I was laid off once WSOP went into maintenance mode. I don’t blame anyone at Pipeworks. Both the studio and myself were in a state of transition, and thus far, we have both managed to stay on our feet.

Pipeworks Studio, as mid-sized work-for-hire game company, often had multiple projects running at a time and, since schedules rarely align seamlessly, there was frequent downtime for individuals between projects. Because of this, I was able to contribute to several projects for a month or two each. Here I list the most prominent and the connection they share in my personal growth, as well as changes at Pipeworks and the games industry.

First was “Dancing with the Stars: Keep Dancing” a social dancing browser game based on the popular reality competition show, developed by Pipeworks and released in North America on April 30th, 2012. With the rise of social/mobile games and the fall of licensed titles on consoles/handhelds, Pipeworks began shifting gears, focusing on a “games as a service” model. This meant developing technology and talent to make, support and maintain connected, persistent online games. DWTS was the first big push into this area. It also represented our first project in Unity, rather than our internally developed engine. With a greater focus on web and mobile going forward, the flexibly and platform independence of this 3rd party engine was indicative of this shift.

My part on this project was rather small, doing UI for character customization and missions early in development, when design and interface elements changed frequently and a clear vision had yet to crystallize. The opportunity to learn Unity and C# was highly valuable, but with how volatile the design was, I would be surprised if any of my work remained in the final project.

The next project I want to mention was an internally developed prototype for mobile, utilizing Vuforia Augmented Reality technology in Unity to bring elements to life inside the app. The goal for this project was ambitious, seeking to combine AR, GPS awareness and location specific content in a way that would exceed the capabilities of Pokemon GO. For spring of 2012, this was gutsy. As far a I know, the project never got off the ground, but my AR powered prototype became a highlight of corporate demonstrations and helped drive business for the studio.

The last project for this post was AXE-MAN, a mobile puzzle game developed by ImaginEngine, a sister studio of Pipeworks, and released for iOS/Android in June 2012 as part of an advertisement campaign for AXE Body Spray. Unlike DWTS, where I helped early in development, here I was brought on for late bug-fixing and maintenance around the launch. This was my biggest mobile project and let me dip my toes into the native languages of Java and Objective-C. This was also yet another Unity project with an online component, this time being leaderboards associated with a sweepstakes; continuing the “games as service” thread that will also be present in a big way in the next project. 

This project, being developed by Pipeworks Studio and to be published by THQ on the Wii U, was never formally announced. It was going to be a casual family drawing/guessing game using the branded license synonymous with that type of game, before it was cancelled mid-development. I was promoted to Lead Engineer for this project, creating schedules and technical documents, managing engineers below me and updating the drawing systems from uDraw for the new design.

This was a fantastic project, while it lasted. This was our third drawing game in a row as a studio, so the tech was well tested and understood. This lead to confidence in the budget and schedule that was uncommon in any of my projects. As lead, I collaborated with production, design and art on our shared vision for the end product. I endeavored to communicate this vision, and the immediate tasks to achieve it, to the junior engineer under me and keep him focused on what was needed. The pre-production and prototype phase went very smoothly and just as we were getting ready to start full production, the project was cancelled.

The fate of this game was seal by two larger failures: the weak launch of the Wii U and THQ’s  turbulent fall. When THQ axed their casual and family division follonw the failure of the uDraw, our family board/party game was left in limbo. The game was so tailored to the Wii U’s strengths that would likely would have found a different publisher, had the Wii U not failed to met even the most pessimistic sales projections for its launch year. With a publisher disintegrating, a platform struggling and a license holder eager to jump to the tablet market, we had no chance. We delivered a fully playable build of the core game with our last pre-production milestone, archived our work and moved on to other projects. This remains my only professional project to not see release.

uDraw Studio: Instant Artist is a fun and educational art program, developed by Pipeworks Studio and released by THQ on November 15th, 2011 for the Nintendo Wii, Xbox 360 and PlayStation 3 as the pack-in game for their second iteration of the uDraw game tablet peripheral. On this project, I was responsible for updating the toolbox UI for new tools and HD  resolutions and scripting support for tutorials.

This was a period of transition for me. I moved from Seattle, WA to Eugene, OR. I was working for an established game studio with multiple teams, large and small, operating at once. And yet, the type of work I was doing and the type of people I was working with stayed the same. By this point, I had 3 years making video games, with multiple projects seen over the finish line on a variety of platforms; in this industry, this made me a seasoned veteran. So everything at Pipeworks was quite familiar and I easily slipped into the groove again.

And like Cory in the House DS, uDraw is another project I worked on that has an interesting footnote in gaming history. After the surprise success of the uDraw Tablet on the Nintento Wii the year before, THQ launched it on all 3 major platforms the next year, to disastrous results. The kids and family audience, THQ’s bread and butter for licensed products, had been moving to mobile and tablets and were no longer covering THQ’s risky bets in AAA game development. Once the second wave of uDraw flopped, THQ shuttered the casual kids and family division to focus on AAA, using uDraw as the scapegoat for the year’s worth of losses. It would not save them, as the publisher went bankrupt a year later. This also won’t be the last time I talk about THQ imploding on this site.

Greg Hastings’ Paintball 2 was a competitive paintball first-persons shooter developed by Super X Studios and released by Majesco on September 21th, 2010 for the Xbox 360, PlayStation 3 and Nintendo Wii. As a programmer, I was responsible for the player level creator, controls and motion controls, special weapons, achievements, and, of course, menus, HUD and general UI, with the modules I was responsible for maintaining growing as the project neared completion.

This was a fun project to work on. A small team (4 engineers, 3 artists, 4-5 QA) meant low to no barriers of communication between teammates. With the large scope and few engineers, we each a great deal of ownership over the modules we were responsible for. And with a generous schedule, we were able to relax and work without crunching ever few weeks. James, the owner, producer, lead programmer, engine programmer, scrum master and sole full-time employee of Super X, maintained a fun and focused environment throughout the projects and we were all proud of the work we did.

In addition to the intimate atmosphere, this project saw a great deal of growth for me as a game developer. This was my first chance to work on modern consoles, gaining valuable experience for future positions. The freedom and collaboration let me discover what I truly enjoy about game development (Gameplay and UI) and why (the immediate feedback and sense that I am interacting directly with the audience). Plus, I finally got to use floater point math!

Imagine: Music Fest is an adventure/rhythm game developed by Handheld Games and released by Ubisoft on May 9th, 2009. I was responsible for much of the UI, including dialog and the character customization and light show modules. I don’t have a lot to talk about on this project. I had worked with this engine and this team before, doing similar tasks that I was confident in my ability to achieve on time.

Though the biggest reason specifics are hard to talk about is how development was completely overshadowed by the downward spiral of Handheld Games. Licensed projects, our bread’n’butter for years, were fewer and father between. The iPhone promised a sea change to the market and while our leadership was able to see the rise of the mobile market, they were completely unable to capitalize on it, despite heavy investment. My team was pushed to do more, for longer, with fewer people and shorter schedules. As a result, the entire project felt like a long grind to an inevitable conclusion.

I kept working hard to not disappoint my fellows in the trenches and due to my pride in my work, but it was only a matter of time before the waves of layoffs hit me again. I still have good memories of the project and the team, but I was unsurprised when Handheld Games closed shop a few months later.

U-Turn was a digital camera developed by Handheld Games and released by Digital Blue. On this project, I was responsible for the built in image filters, their implementation, optimization and occasional conceptualization as well as the UI needed to select them.

Another project on inexpensive embedded chips, so once again, limited break points and no floating point math. That last one actually made many of the filters impractical, since the effect had to be achievable in real-time. Mostly this involved a simple remapping of source pixels, but we needed to implement in assembly to keep the performance up.

Cory in the House was an adventure game, developed by Handheld Games and released by Disney Interactive on April 15th, 2008 for the Nintendo DS, based on the popular Disney Channel sitcom. My responsibilities were focused on gameplay and UI, including weapons, enemy behavior, scripted events, pop-up dialogs and the main menu.

This was a fun project to work on, even if the quality of the end product was exactly what one expects from licensed title on the DS. Development was more relaxed overall, largely due to being properly scoped, with a functional legacy code base to build upon. This was my first game that I could find on the shelves of GameStop, so it will always hold a special place in my heart.

After this, I did some additional programming for Cheetah Girls: Passport to Stardom, taking the pop-up menu from Cory and making it work for the dialog system in Cheetah Girls. This was only a month, so I am not giving it a full entry. But I did enjoy the opportunity to iterate over code I had worked on before, polishing, expanding and generalizing it so it could be a utility for multiple projects. With the tight schedule of most of the titles I worked on, this was a luxury I savored.

On a bizarre side note, in late 2013/early 2014, Cory in the House DS went viral as users and 4Chan and Reddit made it the most requested game on GameFaqs and gave it “universal acclaim” on MetaCritic user scores. Internet culture will never fully make sense to me, but it is nice that something I made was the source of some harmless fun. Could have been a lot worse.