Anito: Defend a Land Enraged Wrap Report

Development Timeline Niel Dagondon: Production started October of 2001, with development wrapping up after two years and a week of development. We originally targeted a 12-month development cycle - imagine an RPG at only one year. :-) Four months or so into development, we had to re-assess our goals and the scope of work involved, and decided we had to scale up the features and content if we were to compete internationally. We added another six months to the schedule, making it 1.5 years. The additional six-months were due mainly to rookie mistakes, such as having to scrap four months of story work, redoing the first town five times, and my original co-programmer leaving very early on so we had to learn his code. This delay, although unwanted, did provide for a lot of improvements to the game.

Changes and Enhancements Niel Dagondon: The biggest change we made to move the graphics from pure 2D to a hybrid of 2D and 3D. The original plan was to have graphics similar to Baldur's Gate and Divine Divinity, with structures painted on the ground. However as the graphics engine was already in Direct 3D, we prototyped structures raised as billboards from a tilted terrain, then eventually tried making them in 3D. It looked really good, and even though we estimated a delay of three months from redoing many of the structures, we decided to push through with it (although we had the artists whining for days).

Some enhancements also came out from scrapped features. In the original plan, one goal was to have most of the items interactive so you could go around clicking everything. After the initial demo though, we found it got too annoying and even tiresome, as many items had no real effects. We had to make many items non-interactive, and then put a button to highlight all the interactive ones. This resulted in tighter gameplay over-all.

Such a change can also be seen in the skill system, whereas the initial design was to have skills based on combo movements using the mouse and keyboard, giving a more action feel to the game. We wanted players to feel they were actually performing a skill by doing something themselves. An example was for the player to hold a chakra (keyboard) button then click a skill ingredient (item), then click the ingredient on the enemy. Testing however, proved this was more difficult than we'd thought, and memorizing skill combinations was more bothersome than fun. Thus, we opted for more traditional skill button.

Major Challenges Niel Dagondon: The team's biggest challenge was completing such a massive project with a skeleton-sized staff. Making an RPG is no small task, as it commonly takes a lot of manpower to do both the content and gameplay. This was especially hard for our rookie team of seven. We were, however, aware of this situation from the very start and did what we could to cut back features from what we thought was the ideal game and mold it into a very solid, smaller-scoped yet still excellent game. As you may have noticed, multiplayer was the first to go. Then, we went for sprite-based animation rather than boned models. Of course, a lot of content also had to be cut, including an entire chapter and a few villages.

As with any team, replacing key members was a big challenge. With only two programmers, one leaving meant half the code needed to be re-learned. As I was the other half in programming, this task was up to me. This did cause a few delays in development, but we were fortunate such a change happened early in the cycle.

Also, a lot of areas in both programming and art were still new territory to us. We were fortunate, however, to have other people help us. Mark Currie of Inhuman Games, whom I met at a convention, helped us out in the pathfinding area, even to the extent of mailing us sample code from their own programs. Also, thank goodness for books like Game Programming Gems.

Best Decisions Niel Dagondon: One feature I personally had to fight to preserve the games score. Many testers and even a few team members were questioning the logic of having this, as it is a feature seen only in arcades nowadays. Flash forward to today, however. Looking at our forums, the final score has been a hot topic for discussion as well as a possible reason for some players to replay the game.

Some decisions were especially hard to make at the time when we were developing the game. This included scrapping almost all the story, dialogue and cutscenes we did for the initial demo. It was approximately one year into development when we decided to redo the story from scratch, using the same characters and towns. This decision was due to player dissatisfaction with the story. Simply put, many players did not enjoy playing the female character because of her attitude. This caused the longest delay since content was the last part to finish. We could probably have launched a few months earlier if not for this, but I doubt a lot of people would have enjoyed the game as much.

The decision to keep two stories in one was a very daunting task for the story / content guys. After all, half the story probably means you finish development of the story in only half the time. It also means, however, that it takes half the time to finish the game. With two stories, we were able to double the playing time without necessarily doubling the number of maps and characters we had to make. And this also became one of the more successful and appreciated features of the game, providing a unique selling point.