Category: Game Development

It’s Madden Season 6

Today is the sixth relaunch of Madden NFL Mobile. I can’t believe I’ve been involved with this mobile game since 2013. I’ve been seeing it come together for several months and have been excited for it’s release. This has to be the largest update since our initial release back in 2014. I’m most excited about the new Season Mode. It’s the most in depth single player mode we’ve done in Madden Mobile yet. Hope everyone enjoys it. If you haven’t played in a while, come back and try it again. The UI has been revamped and looks wonderful. It’s available today on iOS and Android.

NBA LIVE Mobile – Season 3

Today we are kicking off the 3rd season of another game I work on: NBA LIVE Mobile. This game is so much fun and I’ve been playing it all weekend. It has really come together nicely. The new campaign system that we put in for this release looks awesome and is excellent in guiding you through what to play. If you’re a basketball fan, you should check it out. It’s available today in the Apple App Store and the Google Play Store.

Madden NFL Overdrive

It’s that time again. We’re kicking off the 5th Season of Madden Mobile, now called Madden Overdrive. I’ve been working on this game for 5 years now and I’m so excited about the launch today. The graphics and gameplay engine has been updated to the PS3 version of the game and a new head-to-head mode called Overdrive has been added. If you’re a football fan, you should check it out. It’s available today in the Apple App Store and the Google Play Store.

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. IMAG0140

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.

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.

Next Gen?

I participated in the transition from the PS2/Xbox generation of consoles to the PS3/Xbox 360 generation we are in right now. It was a very tough transition for us. We pretty much threw out the old Madden engine and created a new one from scratch. There were some systems that stayed, but the whole art pipeline was completely changed, which included the animation system. The game play for modern 3D games are pretty much animation driven.

It is now 5 years since Xbox 360 debuted and there is no next generation of consoles in sight. However, there has been a lot of movement in mobile gaming. I remember when the nGage came out and everyone laughed. Now it seems they were just a little ahead of its time. The amount of games that are coming to the iPhone is staggering.

Now I’ve read this rumor on Gamespot that Apple might be planning TV-based gaming through their Apple TV product. Could Apple try and force their way into the space that has been pretty much dominated by Nintendo, Sony, and Microsoft? We’ll see, but it’s an intriguing thought.

Of coarse, our philosophy at EA is to build games for any platform. However, it does make it very difficult when the hardware is vastly different from one another.

Road to Alpha

I came back to the NCAA team at an interesting point in our development cycle. It’s the tail end of Production and we are only 6 weeks away from declaring the product Alpha. For Electronic Arts, Alpha is Feature Complete: all new features that have been implemented and a certain level of stability exists with the game.

Throughout Production we are writing requirements that we call Tests for Completion (TFCs). It is the expectation that the developers who are creating the feature, whether they are artists, designer, or programmer, make sure that they feature they are working on fulfills these TFCs. At the end of our sprints, all the TFCs we commit to at the beginning of the sprint need to pass a review by our QA department. Invariably not all of them get complete and if any of them miss, we try and get them complete as soon as possible right after the end of the sprint. However, sometimes there’s a few that slip even more beyond that sprint and can start hitting up against Alpha. In order for our QA department to declare the game Alpha, all TFCs must be 100% complete.

In order to give us some buffer room, we designate two sprints as “contingency”. Those two sprints are not included in the scope of the project. The two sprints are: one right before the Holiday break (late December) and the other one right before Alpha. We choose late December because there are a lot of developers that like to take extra time off around the break. Overall, these two sprints give us some time in order to iterate on features and hit Alpha on time.

NCAA Football is divided into four sub-teams, we call Pods. Coming onto the team three weeks ago, I’m pretty much taking up the charge to Alpha. My first thought was, “Will each Pod make it to Alpha?” The team had what they called a Master Burndown, which combined the points and velocity of all the Pods. This is great, but all it only takes one feature to hold up Alpha. So, I used some of the techniques I talk about in my Hansoft Basics presentation, to calculate a per-Pod velocity based on data in Hansoft. That ended up giving me data that we were probably going to be booked around a week and a half into the final contingency sprint. Good, but not great.

From this point going to Alpha, we have to keep a very close eye on things that are changing on the backlog. Figure out what is being added and what is being removed. It’s delicate balancing act of wanting to get as many features into the product as possible, quality of the product, and the number of hours we are going to have to crunch during Alpha. I’m hoping we come out completely balanced.

FIEA – Hansoft Basics

On Friday, I gave a talk about Hansoft and some examples how you could use Hansoft to track a project using iterative development. Below is the slides from the talk. The emphasis was put on scoring each sprint, calculating a velocity, and then using that velocity to predict if you can finish on time. If you have any questions, contact me or leave a comment.