[Former Florida Interactive Entertainment Academy student Blake Battle takes a moment to reflect on Battle Fortress Tortoise, a complex, and very ambitious project for its upstart team.]
What do a giant tortoise, a gnome culture that lives on its back, cannons, and hungry humanoid hyenas have in common? They are all completely badass individually, and when you put them together, they combine to be the pinnacle of human achievement. Well not quite, but at least they make one really cool video game.
Battle Fortress Tortoise is a tower defense shooter that is set on the back of a giant moving tortoise. The game started as just a name. If you look at my name, Blake Battle, you might be surprised to find that I had nothing to do with the naming of this game. Our lead designer, Gabriel Gonzalez, dropped it one day in conversation with some friends during our first semester at the Florida Interactive Entertainment Academy (FIEA) as a great title for a game. He would walk around the cohort and ask people what they thought of when they heard the title. Each person had something awesome and different to add. In a strange way, almost everyone in the cohort touched this game design in some way. And the faculty and students loved it, proven by the fact that it was chosen for development as one of our capstone games.
Your goal in the game is simple: get to the Promised Land. Why? Because it is free of the massive hordes of aggressive humanoid hyenas that rule the world of Tortuga. They forced the gnomes into the trees, denying them the joys of living on the ground. They viciously hunt gnomes and tortoises alike. They want to eat you. Also, all of the female tortoises live in the Promised Land. I am sure you can connect the dots on that one.
During our capstone process, I pitched a game called Plushy Knight, an emotionally epic tale about a little girl and her teddy bear trying to wake her from a grief-stricken coma in a fear-ridden dream world. At FIEA, typically students are not allowed to be project leads on their own pitches. This is to ensure objectivity because we have executive authority on all decisions involving the game. I still to this day do not agree with that logic.
But what I can say is I have learned a ton from decisions that were made that I do not agree with. Game development is not about everything falling perfectly into place and turning out awesome, although I think most of us believed this when we entered FIEA as starry-eyed new developers. It is about constantly traversing the grey, adapting to change, making hard decisions, doing the best you can to produce a solid experience, and most importantly, getting up when you get knocked down.
Here are just a few of the things that went right and wrong while working on Battle Fortress Tortoise:
What Went Right
1. Embracing the Ridiculous (Endless Creativity)
It was clear from the beginning we were creating something both unique and slightly absurd. Rather than maintain a serious tone which would have been difficult to pull off we embraced the ridiculous nature of the concept and turned the epic-ness up to 11.
BFT had a rare theme where almost anything could be added to it, and it would fit in some strange way. Something about our combination of characters and world made it so you could drop anything in and you would just accept it. A crew that consisted of a pirate, a Scottish guy and a coward? Of course. A trailer filled with nothing but shouting and explosions? You got it. An ending which contains the T-Rex roar from Jurassic Park? Makes sense. Pulling quotes from famous films and novels and adding our own BFT twist? Yessir. Solar beam? Well, almost. All of these things and more helped to make a chaotic, epic and most importantly enjoyable experience that proved successful for all who played or watched the game.
Given this unique situation, it would have been extremely easy to give into scope creep. But our team stayed focused and delivered a focused, awesome game.
2. Facing the Technical Challenges
If working on BFT was a commercially marketed drug, it would definitely come with a warning on the label that this product is not for anyone with a history of stroke or heart attack. It is important to keep in mind that the technical challenges of our project did not present themselves once and then were solved. They caused every little change or addition we made to be a catastrophe. The issues we had to address constantly were not only issues of "will we be able to add this feature" but also "is our game even going to be possible to do?"
For example, we couldn't build lighting for over a month because our map was too big. Our frame rate was always bad. We had hundreds of hyena crowd agents on the ground while we had as many as 10 to 15 hyenas fighting the Gnomeander on Argo's back who are pathing on a moving environment. The list goes on and on. We could have cut back, but those cuts would have been a severe blow to the experience we were trying to create. Our cuts would not have been in a feature that could just be replaced, but one of several features that had to function together to build the basis for the experience we were trying to create.
We never let this stop us. We knew going into this that the game we were trying to make had never been done before. We would eventually reach a point (and we did sooner than later) where there would be no one to help us make our game. We would have to write the book on how to make it.
The biggest hurdle we had to jump came 3 days before we had our vertical slice presentations. Vertical Slice is a presentation of our progress in front of the faculty and industry professionals where it is decided which out of our 5 games would be green-lit for production and which would be cut, dividing the remaining team members amongst the surviving teams. We could not get hyenas to path properly on the back of Argo (the tortoise). This literally caused 50% of our gameplay to not function. We had our entire programming and production teams dedicated to solving this problem. We posted in several threads and scoured the internet for help. The only response we got was in Epic's very own forums. This was the response:
"Well, I would probably suggest making a navmesh manually. You can make a simplified mesh in 3d application, then convert it to a navmesh once placed in UDK. Also, movement and pathfinding do not go hand in hand. So unless it is too late to turn back, I would suggest to move the environment instead of the level, to simulate movement."
No, we will not turn back. The easy way out would have sacrificed the core of the game we were trying to make. Although there were many times that it almost came to this, we stuck with it and solved our problems. I am glad we did.
3. Project Management
We constantly measured, scheduled, prioritized, and recorded. Project management was not in short supply on BFT. People do not love to be in meetings. Most people seem to hate them. However, they are the linchpin of facilitating successful communication on a team. We stuck to our guns on daily scrums. We would enforce weekly art reviews. We made sure to do our sprint reviews and sprint retrospectives. We planned out each sprint in Hansoft and followed up on our plans.
We did not cut corners, but we were always willing to embrace agility in terms of convenience for our team. We did our best to keep meetings short and to the point. We took team feedback seriously and would do our best to improve our processes.
Project management goes a little further than just the process of assigning tasks and tracking their progress. We also put in great effort into having the team look at our game critically. Every week we would have a meeting we called "BFT BFT" which stood for "Battle Fortress Tortoise Big F......use your imagination...Team Meeting." We would start by having a quick summary from the team on what we had accomplished each week. Sometimes we would have a theme for bringing snacks to the meeting etc. We even had some team members that would perform cultural dances at the conclusion of the meetings. Yeah, it was like that.
Most importantly, in the second half of the meeting we would a play through the game in front of everyone. The big question asked at the start was "If we had to show this tomorrow, would you be proud of it?" We would then go around the room and discuss things that were missing, things that needed to be implemented, bugs we saw, and the team's suggestions for how we can improve the game.
I feel this ritual was crucial to the game's success. It really allowed us to look at our game in a critical and real way, and made the team feel like they were involved and tuned-in to its construction. When you are on a large project, not everyone touches all aspects of the game. It can be easy to lose sight of what you are making, and well, you can only see by seeing.