PostMortem
What went right
-
Strong start
OrBlitz began as a simple idea in the spring of 04'. While attending GAT300 class, both Marc and Josh discussed game ideas for their following year. Somewhat inspired by the resources in Max, particularly the textures, their first ideas involved simple ball mazes and challenges with different textures representing materials. The focus was always on creating a game that could be artistic, but one that would not necessitate an artist to create a polished product.
During the summer, Jason and Jesse both joined in on the team and weekly meetings were established to refine the game design. With everyone's contributions, OrBlitz was fully shaped and the task of translating every idea to paper was left to Marc, the team's game designer. The GDD for OrBlitz described every feature in the game with strong detail. Unlike most teams that rarely look at their GDD's after completion; the Yakuza have continuously indexed the pages of their GDD to resolve design conflicts. And with a strong start in design, little time was wasted beginning the technical implementation at the start of class in fall.
-
Unique graphics
OrBlitz owes much of its success to its unique style of graphics, a blending of non-photorealism and simplicity. Many games have shipped from DigiPen, but unfortunately many are overlooked purely for their lack of strong visual presentation. But unlike those titles, OrBlitz catches everyone's eye.
Specific techniques involved:
- Cel-shading (a.k.a. Toon-Shading)
- Projective hatching
- Shadow volumes
- Paint volumes (an original creation of Marc)
-
Pseudo-realistic physics
To meet submission guidelines, Jason crafted a strong 3D physics engine. But to create a compelling game-play experience, unrealism had to be injected into the product. Jason and Marc quickly added this unrealism after Beta by determining what direction an orb would travel in after a collision assuming a completely fake and 2D physics system and then interpolated the actual 3D results back to the 2D estimation. The result is much more playable physics, and as it tends to act the way players expect the orbs to behave, few actually notice that any special interpolation code is being performed.
-
Content creation tools
Marc and Josh knew from the start of the project that they wanted to explore the realm of scripting languages. After some debate as to which language could best express their ideas, the team decided on Lua. By using Lua, many game-play features of OrBlitz can be defined on a per-level basis. For example, the game architecture has no concept of a level timer, but this can easily be added to a level in script at the cost of writing a minimal amount of script.
And as the game revolves around the placement and destruction of blocks, a level editor was created entirely in the game engine with only small adjustments to the existing code base. Anything that cannot be done in-game can simply be hacked in the actual level data files (stored as text). A true testament to the power of scripting and the level editor combined is that Marc created a series of over 20 single-player levels in less than 2 days time (and they're good levels too).
What went wrong
-
Linux version
From the start of the project, a Linux version was planned. Little needs to be said here besides one simple warning: Do not attempt to make your game run on alternative platforms if you don't have at least more than one team member with a machine running that platform.
One major side affect of the possible Linux port was that all supporting technologies chosen were cross-platform (i.e. SDL, OpenGL, etc).
-
Technical planning
OrBlitz is a rather large software project, and unlike the game-play design, the technical design required a lot more planning. Unfortunately many of the game's features were not adequately planned for and detailed in the TDD, leaving the developers adding in features without the support from existing code. An example of this failure was the game's multi-blocks. They were in the GDD, but little thought was placed into their implementation as the early code base was constructed. To remedy the problem, Marc and Josh spent many hours while at GDC coding and debugging the multi-block feature.
-
Scheduling of physics and networking
Both physics and networking failed to stay on track at full pace. To combat slipping too far behind, Josh worked with Jesse on networking and Marc worked with Jason on physics (fortunately with a stronger background due to PHY300 and PHY350). And as there is only so much time that one person can spend on the project, A.I. and graphics began to fall behind as well. Stronger leadership and more thorough planning would have helped.
-
Little time for content
As many features were behind leading up the Gold, very little time was devoted to content. Fortunately, good tools existed for the creation of content, but that couldn't change the fact little time was left to add in, test, and refine the game's levels. From our understanding, this is a common trap of many teams at DigiPen.
What we would do differently
-
Larger team
By having only one additional person, many of the team's woes would have been avoided. An extra person could have been assigned to general game-play tasks and never removed to help or do anything else. This would have given everyone more time to work on their specialty and increate the development time for content drastically. Also a more robust and cohesive game architecture would likely be established.
-
Team scheduling (1st semester)
Although the team worked hard together during the summer to prepare the game's design, class scheduling conflicts prevented the team from working closely with each other. Time on the weekend should have been devoted to team work to build the team's closeness.
Although the group lacked a strong team relationship during the 1st semester, the problem was quickly resolved by mandatory Saturday classes as a result of Prof. Ellinger getting hired at Microsoft.