Get the latest Education e-news
 
  • Postmortem: FIEA's Penned

    [12.06.12]
    - Alexis De Girolami
  • [FIEA student and Zynga intern Alexis De Girolami details the missteps and difficult decisions involved in producing her student-run team's thesis project, Penned.] 

    There are definitely times when going to FIEA (the Florida Interactive Entertainment Academy) can feel like living inside a bubble. Though the 65 or so students in our class are technically Master's students at the University of Central Florida, we exclusively work (ahem, live) in a building off-campus and rarely see anyone outside our program. In a way we're like a student-run studio, and that allows us to assess our 7-month capstone projects -- and the big thesis project that this postmortem is about -- as legitimate, published games. Three games were made in our class: Battle Fortress Tortoise, Plushy Knight, and Penned.

    Lucky for you, this postmortem is about Penned.

    Penned is a 3D action-adventure game where the player uses vocabulary words to change the game world and gameplay. We didn't want this game, even from the start, to be your typical educational game -- it's pretty established that that genre isn't terribly popular and has a bit of a bad reputation. We wanted to create something that was, first and foremost, fun and the learning would follow because you were enjoying yourself.

    Prior to writing this, I made a long list of good and bad things that happened during the project and spoke with a number of people from different disciplines on our 22-member team to establish the common denominators. So here we go!  


    What Went Wrong

    1. Communication

    Everyone on any student project in the history of the universe (and undoubtedly many in the industry) can list this as a primary problem that held a team's progress back, and we were no exception. Our problems with communication stemmed largely from an early onset of personality-clashing that never fully dissipated as the project progressed.

    The lack of communication of features completed, features with improper design specs, finished assets, assets that we didn't even know needed to be made, and a whole slew of other things made for a difficult time for parts of the project. This affected morale and created problems not only with the game, but with the team's dynamic on a larger level.

    I would like to say that we solved all these problems by the end of the project, but then I would be lying. What I can say that we did, however, was create a dynamic between members of the project that was, if not perfect, then functional. One method was starting cross-discipline standups, where those on similar features had to talk to each other about what they had accomplished and were working on next. We originally had our daily standups organized by discipline: programmers, artists, and designers, each keeping relatively separate.

    Don't do this. It was a terrible plan, encouraged miscommunication and generally led to many problems that should have been avoided. Changing it to feature-specific teams improved morale, made general understanding of features more organic, and overall did a lot to make the process run smoother. It kept everyone informed and allowed any problems to surface in an environment where we could do something about it.

    2. Scope

    This was easily one of the biggest failures we made as a team, and likely the biggest one I made as project lead. Our eyes were way bigger than our stomachs and it started to show early on. Largely this came down to what we thought we were capable of creating on the artistic and animation sides of things, and we simply didn't have the manpower to fill the needs we had.

    Another related problem to this was scheduling, and this problem predominantly came from inexperience and over-eagerness. The length of time it takes for one person over another to finish something was a problem we had never experienced on this scale, and it lead to us over-scoping our goals every single time.

    Towards the end of the project we recognized this wasn't our strength and attempted to undershoot to compensate, but this problem was one of our primary organizational faults throughout the duration of Penned's production. Attempting to understand the major hurdles on a feature -- and then using that as a frame of reference for scheduling later --was something that we didn't do enough of and would have helped us in the long run.

    Similarly, making a real effort to understand the priority of features allows for any giant hurdles to make themselves known earlier rather than later.


    3. Not evaluating combat early enough

    This requires a little explaining. At FIEA, a number of games start being made in January (for us it was 5 games), and they go through the motions of preproduction on teams of around 15. Then, at the end of February, we have Vertical Slice, a big event where each team formally presents their game and their plans for the future. Then the faculty decides whether projects should be cut (2 were this year) or greenlit.

    This date often leads to what amounts to two months of psychotic, frenzied game design and development. Decisions need to be made fast and implemented or it's likely your project will be cut.

    Back to Penned. Our biggest problem coming out of Vertical Slice was that we had so rushed our design process that we blew through the development of combat in the game. And the result wasn't fun. At all. It was clunky and felt terrible and no one wanted to touch it because it was the big, scary beast of a design and animation elephant in the room.

    So we ignored it. And complained about it. For 3 and a half months.

    Trust me, I'm not proud of this.

    We eventually realized that putting our heads in the sand wasn't an effective design technique (surprise, surprise!) and got our act together. We completely revamped our animations, reestablished our system of combos, and added activity into things with a more purposeful special attack. We did the same with our AI. We added a proper controller, and the end result was the product that we are quite proud of today. In the end we put more work into fixing a shoddy core element of gameplay than we ever would have had we just done it the right way the first time.

    We learned our lesson: ignoring a shoddy feature or building cool stuff around the feature will not make it better. Ever. It will only make it more obvious that you're trying to hide a really ugly elephant.

Comments

comments powered by Disqus

UBM Tech