An Epic EA Sports Trip

Heading to the Great White North today: Charlottetown, Prince Edward Island, Canada. That is where they make the EA mobile game The Simpson’s Tapped Out. Going to talk to their Dev Director about mobile development. A bit of irony on my McDonald’s bag at the airport this morning. It said I could win an “epic” EA Sports trip. I hope it is.

WiFi Enabled Hockey Goal Light

It went off automatically with the Canada score. Gets updates from the Internet.

USA v Canada

With a lot of Canadian transplants, the USA v Canada hockey game all of a sudden becomes a studio event with a mountain of pizza and beer.

NCAA Football 13 Cinematic Launch Trailer

NCAA Football 13 is out! Go out and buy it now. Here’s a new cinematic trailer:

NCAA Football 13 Kickoff Banner

Banner walking into work today

Yet Another Steve Jobs Blog Post

There’s been a lot of reflection this week on the Internet about Steve Job’s passing. It’s funny, I’ve never been a big Apple fan until recently and yet I see the influence that Steve had on my life.

It all started in 1983 when a friend of mine received an Apple II computer and also bought Ultima III. That was my first big exposure to computer video games. We had all played the Atari 2600 back then, but Ultima was different. It was more complex. It was more interesting than the twitch experience you got with the Atari. This was the spark that lead me down the video game path that eventually I made my career.

Recently, Steve’s ability to have a vision and have his team or company execute on that vision is what I paid attention to more. His carisma. His presentation style. His presence.

One of my favorite stories about Steve was told on the Triumph of the Nerds documentary. One of the engineers on the original Macintosh team said that Steve came to the team demanding that the Macintosh boot five seconds faster. “Do you know how many people are going to buy this computer? Millions. If you can get it to boot five seconds faster times a million people. That’s 50 lives. If you can get it booting five seconds faster that’s like saving 50 lives.” It was something that stuck with me over the years and I ended up using it several times on the load times for our games. I would always attribute it back to Steve Jobs and the original Macintosh, but it was always a great story to tell.

Steve Jobs was an amazing visionary. I was amazed how much his death affected me this week. Maybe it was that his passing reminds us all that our time on this Earth is limited and we need to live each day to our fullest.

At the Controls on TWiT

On July 15th, I appeared on TWiT’s new video game podcast “At the Controls”. It was one of their “alpha” test run episodes, so it wasn’t actually put out as a podcast, but is available on YouTube (see below).

This was a personal accomplishment for me. I have been a fan of Leo Laporte and the TWiT network since the very first podcast. Not to mention a daily viewer of The Screen Savers back in the day. Another thing that made it special was it was one of the last shows to appear in the old TWiT Cottage before they moved to their new studio, the TWiT Brick House.

Going Alpha

Wow. I didn’t realize it had been a month since I wrote on here. While this Alpha has been the best one, as far as hours, I guess it still has preoccupied me. Our scheduled Alpha date was March 7 and the team did a great job pulling all their tasks together in the last sprint. The goal was to hit Alpha on time or at the very least come in better than last year, which was 7 days late.

In order to hit this goal, the idea was to leave the last sprint (3 weeks) as a “contingency” sprint. While this sounded good on paper, it was hard to know when to use the “contingency”. It seems like we used it for anything and everything and in the end, it appeared that we were scheduled right up to the end of the last sprint. The reason it got this way, was there was always “one more thing” that needed to get in or that was half done and it would be a shame to release a feature that wasn’t 100% complete. In the end we have to ship a good game with awesome features. I don’t think the concept of a “contingency” sprint works very well because you end up using it like a sprint, scheduling right up to the Alpha date. Next year I think what I’m going to do is have a two week period before Alpha which is completely unscheduled. It will only be used for finishing something that didn’t get completed in the last sprint and fixing any issues with the game which might be hindering QA’s ability to test the whole game.

Despite having that last sprint completely scheduled, the team did a great job leaving that last week of the sprint available to verify all the features were in a good state. We ended up being 4 days late for Alpha, being declared on March 11th. There were a few crashes in one of the game modes which would hold up QA from testing. EA has a checklist of things that need to be complete before a game is declared Alpha. Stability of all game modes is one of those. Even though we had done a great job on the stability of our game, there were a few timing specific bugs that held it up. Friday the last fix went in QA declared us Alpha.

FIEA Team Presentations 2011

Today I had the pleasure to sit in on the Team Presentations at the Florida Interactive Entertainment Academy (FIEA). FIEA is a masters degree program from the University of Central Florida in game development. Several former-EA employees left just over five years now in order to form the school. Each year the students break off into teams and pitch a game project, then build it to what we call at EA a “First Playable Demo”. This is very similar to the Green Light Process we use for games. At the end of the presentation, a few people from the game industry and the faculty go off in a room and decide which games will continue on and get made and which ones will stop there.

First off, I have to say all the games were impressive. The level by which the games were built was great for the six weeks they took building them. The tools and engines that students have now in order to get started is great. I wish they had these types of schools back when I was trying to break into the game industry.

Two of the games, I thought had good presentations and first-playables. For me, they were a shoe in. The other three I thought had good concepts, but their presentation or the execution of their demo, just didn’t get across to me that they were going to be able to make what they wanted to make. I was instructed to treat this as if they were coming to me and wanted money to make the game. Did I have enough confidence that they would end up making money on their concept?

In the end, we chose 3 games to move forward. The two I thought were good and one that I thought wasn’t quite ready, but the other members of the panel thought it was. I had a great time and think it’s a great program that they have down at FIEA. It is really getting the students that “real world” feel to the game industry.

Estimates

I attended an IGDA meeting this past Thursday where the speaker tried to give estimates on how cheap it is to implement usability features. Her premise was that there’s no excuse why you aren’t implementing these usability features since they are so cheap. I’m not going to talk about that specifically, but how off her estimates were and how dangerous as a manager or producer it is to do these types of estimates without consulting an engineer.

First off, there are different ways to approach a problem. There’s the quick and “hacky” way and then there’s thinking through the problem. The best way is to think about the whole process and make it data driven. If, for example, we were going to implement a system for subtitles in our game. A series of questions you might think of are: how are the subtitles going to be entered by a producer? How are the subtitles going to triggered in-game? Are these subtitles going to need to be localized? Thinking about all these problems and leading towards a data-driven solution, will allow you to create a system which will stand the test of time. If you hack it in, the amount of maintenance you are going to have to do as this feature is used on several games, will be more cost then to implement it “the right way”. Now if you are going to be using the engine once, then hack away. However, in my 13 years in the game industry, I’ve never made a game where the engine was only used once.

Another variable are existing workflows and pipelines. Every studio has different ones and talking about an estimate for one studio doesn’t usually translate to another. Saving the button mappings for a controller is probably different for each engine. Having implemented this system before, it’s not that simple. Another factor is the engine itself. Madden and NCAA’s online play is deterministic. Meaning, the random number seeds are synchronized and only controller input is passed. What happens if you allow users to remap inputs? That now has to be taken into account and that original 3 day estimate you wanted to place on this feature is now double or triple that.

Another factor in this is motivation. I have never had any luck with estimates that were not made by the engineer who is doing the work. I have even had trouble when estimates are done by another engineer. That’s one of the things I like about iterative development. Estimates for the immediate milestone or sprint are done right at the beginning. This gives you a chance to adjust your schedule based on how accurate your original estimates were (velocity) and it gives a chance for the person who is actually doing the work to get their estimate into the mix.

The best way to attack this problem is through better designers who take usability into account when they are designing a feature. If you spent more time educating designers who know how to design these system, then this could be attacked in the design phase a feature. And what ever you do, don’t hand down estimates for an engineer to implement. That can lead to a project management nightmare.