The Process
The entire design and development process for Enyara spanned from January, 2008 to April, 2008. To keep things organized, the team met on a regular basis (both online and in person) to hammer out any issues the project was currently suffering from. Just like any software development project, Enyara suffered from setbacks, complications, and obstacles to overcome. Through code organization, a subversion server, and good communication, we were able to handle what was thrown at us.
Challenges and Setbacks
Art and Animation
Most teams encountered issues with getting art elements into the game, and our team was no exception. It's one thing to have your 3d objects modelled and ready to go, but it's a completely new issue to get those elements into the game and working properly. We had issues with object alignment, texturing, object scaling, and especially karma physics. Once we got everything imported into the game, we found out that dealing with karma physics required even more alteration to the basic models.
The Karma Physics Engine
Dealing with a third party engine will always present some challenges, but getting our game to cooperate with the karma physics engine (provided with Unreal) was a challenge itself. Most of the work here went into tweaking values (which seemed almost arbitrary in nature). Sometimes, karma objects would lose certain behaviors (like being able to be placed dynamically) that regular objects in the game have. Getting Enyara's levitate spell to cooperate with the physics engine was a challenge as well.
Lag and Framerate
One thing that definitely helps the framerate and reduces lag time is the reduction of what exactly is done in every actor's Tick function. The Tick function runs once for every object in the level in every frame that's generated, so the more you pack in (and especially depending on the complexity of what you pack in), the slower the end result will be. We had issues with the flying objects in the minigame as well as the patrolling AI, but in the end we were able to reduce slowdown significantly.
Camera Issues
Gimbal lock was a major issue with the flying minigame. Gimbal lock is the problem that arises when you're looking straight up (in the positive Z direction) in a video game. If you try to look left or right in this case, you're just going to rotate. Since Unreal deals with rotators (meaning you can rotate the Pitch, Yaw, and Roll of the camera), Gimbal lock was always an issue when you're looking either up 90 degrees or down 90 degrees. The problem was solved by introducing quaternions, and the camera that follows Tambo around the minigame ended up being much smoother.
The Mouse Cursor Interface
Compensating for High/Low-end Computers
When programming in Unrealscript, always pay attention to the DeltaTime variable. It's the amount of time that has passed since the previous frame was generated. The amount of time will be really small for high end computers and really large for low end computers. If you take all of this into consideration, you can make sure that someone on a high end computer will walk away with the same experience as someone on a low end computer.