 |
 |
 |
 |
 |
 |
|
Spell Dancer Key Details
Team
Samples & Documentation
Project Overview Spell Dancer, as envisioned, is a complete 40-60 hour long 3D strategy RPG in a somewhat similar style to Final Fantasy Tactics and Disgaea, with some very unique gameplay twists to make it stand out from the pack. The most notable unique feature is the use of a Dance Dance Revolution style dance pad for casting spells and using special attacks (though players have the option to ignore the pad and use their controller instead if preferred). Other key features include a diverse and highly customizable job system, earning grades and merit badges based on in battle performance, and the elemental terrain effect system (where spells have a chance of modifying the terrain of the battlefield in different ways based on their elements). The story is primarily humorous and follows the adventurers of Talie and her friends over five years as they learn to become master Spell Dancers, Weapon Masters, and/or Tinkerers at The Academy of Magic, Weapons, and...Stuff and then set out to save the world as their final project. Naturally, the entire game as envisioned is far too massive for a student project, so we focused our efforts on creating a small playable demo to showcase the concept. The final version of the demo we were able to complete within the time frame is in an early Alpha build and contains a fully playable one-on-one battle, although it lacks any features beyond movement and physical attacks. A separate demo program was also created to monitor and record dance pad input based on the player's reaction on screen prompts. It was completed but, due to time constraints, was not integrated into the battle demo. In addition, extensive documentation was created with the full game in mind and, though currently incomplete, it spans over 100 pages and covers a wide variety of jobs, items, and game play functions that did not make it into the demo. Project History After finishing our work on The Frequent World Savers Club mod at the end of summer 2005, David, Patrick, and I wanted to start a new project that wasn't a mod. Being the primary designer of the group, I pitched a couple of ideas, Spell Dancer being one of them. I was, and still am, a fairly serious Dance Dance Revolution player. I love the games but I always wanted to see what DDR would be like with plot. Another inspiration was a hidden feature in the game Growlanzer 2 (released in the US as part of Working Designs' Growlanzer Generations collection), which allowed the player to boost the power of their spells by use of a dance pad plugged into the second controller port (though it worked in a much different manner than the implementation planned for Spell Dancer). David and Patrick liked the idea, so we got to work. The first few months were spent planning out the game (including the basics of the game's 30+ job classes, how the job and character progression systems would work, how the dance system would work, how said system would vary by job class, and what other things we could do to make the game more fun and unique) and working on several initial tasks. David began working on the number crunching needed for a Strategy RPG type battle system and character progression, Patrick did some research on game engines, and I worked on the basic documentation. By the end of the semester we had a working pen and paper version of the battle system, along a few Visual Basic programs created by David to aid in the necessary calculations. In the beginning of 2006, we decided it was time to expand the team. We recruited Brad Waropay as concept artist and he quickly set to work creating the visual designs for various characters and weapons. Meanwhile, David worked to refine the battle system, Patrick began to experiment with Renderware (our chosen engine), and I continued to expand the documentation and began to work on the level design for the demo. As the end of the semester neared, we settled on exactly what elements we wanted to appear in the demo and began to prepare for the summer semester, when Spell Dancer would become a special topics class at UAT (with Michael Eilers as our advisor) and development would begin in earnest. To that end, we recruited two more team members: Jon Wray, as an additional programmer, and Travis Bolek, to handle the modeling, rigging, and animation for the characters. When the new semester started in May, we quickly got Jon and Travis up to speed on the project. Jon joined Patrick in learning Renderware, and Travis set out to model and rig the first character, based off of Brad's artwork. Meanwhile, David began to work on coding the entire battle system into Visual Basic (which he then planned to convert to C), Brad continued to do more concept art, and I worked on the look and layout of the GUI and began to model the demo level (while continuing to add to the documentation). By the end of the semester the VBasic version of the battle system was complete, the GUI design was finished, the demo level was modeled and textured, more concept art had been completed, and Jon and Patrick were ready to start coding for Renderware. Travis finished modeling and rigging the first model early into the semester, completed two of the necessary animations not long after, and said he was working on the other models and animations. As the semester ended, we recruited one final team member, Alex Bates, to handle the simpler modeling jobs (the weapons and items). Moving on to the Fall 2006 semester, we planned to finish the demo in time to present it at UAT's Tech Forum in November. However, we had two major setbacks. First, Travis suddenly and unexpectedly dropped out of the project about a month into the semester. He turned all his files over to me and I discovered that, despite what he had led us to believe, he had done virtually no work for the past several months and, aside from the single model and two animations he had finished early in the previous semester, there was nothing usable. Unable to find another available modeler skilled enough to create human models, we reluctantly settled on using only the one model (with some pallet swapped textures) in the demo. We weren't able to find a replacement animator either, so I was forced step in and create the rest of the animations myself (previously, I had never animated rigged models or done animation of any kind in Maya (Travis's preferred program)). The second problem came shortly after when we discovered that the installation of Renderware on the school computers appeared to be missing the files necessary to import our 3D models. After some time spent rechecking the documentation, program files, and the like, we petitioned UAT's IT department to provide us with the original installation discs. They first promised to fix the problem themselves but, as time passed and nothing changed, we were finally able to get the discs. However, it turned out that the discs themselves were at fault and they didn't contain all the normal installation files. And, as we were the first team at UAT to do any serious work in Renderware, no one had noticed it until now. At this point, there were only about two weeks left before our scheduled presentation. Fortunately, while waiting for the Renderware discs, we researched some other engines, just in case, and decided on Panda 3D. However, as Renderware used C as its primary programming language and Panda used Python, this left our programmers with a very tall order. They had only two weeks to learn a new engine, new programming language, and redo all their past work, plus additional coding, in Python. Jon and Patrick did an excellent job getting things up and running. David tried to convert his already coded battle system into Python but there were some problems and, in order to meet the deadline, Jon and Patrick were forced to create a new (though rather scaled back) version on their own. While they worked on that, Alex finished the item models, Brad created some high quality artwork for the Tech Forum presentation, and I textured the character and items models. By the time our Tech Forum presentation came, we had two programs running in Panda. The first was a pre-alpha build of the main demo. It was a one on one battle in which the characters (both controlled by the player) took turns based on their speed and were able to move around the battlefield, switch weapons, use physical attacks, take damage, and eventually become knocked out when their HP was depleted. The second program randomly displayed an endless series of four different prompts (corresponding to the four main buttons on a dance pad) and measured the time it took the player to step on the correct buttons on the dance pad. We refined the programs slightly during the final month of the semester but, with finals coming up, none of us had much time to spend on it. At the end of the semester, with various team members planning to graduate, move away, and/or start new jobs, we ended the project (although I've continued to work on the documentation from time to time). What I Learned Spell Dancer was a far larger project than anything I'd previously worked on, both in project length and scale. I believe my team management skills improved since my work on The Frequent World Savers Club, although, had I required more thorough reports from the team members at our weekly meetings, Travis's lack of work and sudden departure may not have come as such a surprise. Although, as Spell Dancer was just a school project, I had little to no leverage I could have used to force him to work harder. Better motivational tactics might have helped, although he always excused himself from all non-mandatory team meetings (game nights, some group work/brainstorming sessions, etc.), so maybe not. I also learned that I should plan for things to go wrong and create the development schedule with that in mind. Although Jon and Patrick did an excellent job on the demo program despite our last minute engine swap, better planning could have given us more time to add in all the features we'd originally planned for. Management issues aside, I also gained a much more practical grasp of exactly what goes into a larger game and the amount of documentation required. While I technically knew before, working on the design doc for such a large project, combined with overseeing the art and programming for only a small part of it, gave me a much firmer grasp than mere book knowledge. Considering the setbacks we faced late in the project, I'm pleased with what we were able to accomplish, although I'm still a bit disappointed that we weren't able to add all the planned features to the main demo program. Despite that, Spell Dancer was a lot of fun to work on and I hope to return to it someday. |
