Animation, Character Rendering and Overall Progress

The animation system is now largely in place and a basic character model has been created. It’s pretty clean and well separated from actor data and game logic, and common functions like attaching additional meshes to bones can be done with a minimum of hassle.

Characters (and their equipment ) use a different shading model than the environment. The models are not normal mapped, and the diffuse texture is painted rather than composited  from photographs. A second diffuse texture is created from the first, with the colors shifted to cold colors, and these two textures are interpolated between by the diffuse lighting result, which is exaggerated.

The idea is basically similar to gooch shading, but with diffuse textures instead of solid colors.

There are a number of reasons why I decided to take this approach. Like in gooch shading, the models will not become more difficult to see when they are in shadow. Visibility will be further enhanced by the contrast in styles between the characters and architecture.

I want the game to have an otherworldly, dream like ambiance, and a rendering approach that verges away from realism, but stops short of being cartoonlike, is helpful towards achieving this.

The main impediment to realistic, normal mapped characters is the sheer time overhead. While it’s doable to an extent, it would greatly lessen the amount of overall content that could realistically be produced for the game (already a very small amount).

This expressive approach to character visuals will also help prevent the onset of grimdark.

My next target for development is to build a resource manager, and to extend the simple markup language used to define static game objects to cover the definition of characters and other asset types.

After that, I plan on implementing simple enemy behavior – A* to the player and attack. This should be enough to start testing and adding nuance to how the underlying game data interacts and to begin the process of slowly refining a tight combat system.

I’ve already created the process for adding new kinds of room to the dungeon, and specific types that are necessary or highly relevant to the core gameplay dynamic will need to be implemented.

The high level system which controls the density of specific room types will have to be created, as well as systems for populating rooms with enemies in an enjoyable manner.

While there will be some decorative cruft, such as statues or whatever, I don’t want to have meaningless detritus or crates full of nothing all over the place. Every object should have an obvious gameplay function, or obviously lack one.

Once the player can explore, fight and die, the game will have reached it’s first big milestone and will finally be at the prototype stage. After that, aggressive user testing and constant tweaking of gameplay dynamics, with the aim of reaching a simple, solid, fun gameplay dynamic, will bring the game to it’s second prototype. From there, the addition and balance of final enemy types, items, room types and gameplay dynamics, and copious amounts of polish, will get it to alpha. After that it’s just bug fixing and polish, as well as a period of larger scale testing in beta.

I hate to hang a time frame on development, because I’ve never developed anything of this magnitude before and any time estimate would be a complete guess. Things have been progressing very quickly, though. The codebase is showing no signs of blechery as of this point, the most difficult technical challenges have been solved to a decent standard and the whole things seems to comming together nicely. I would like to have the initial prototype stage reached before Christmas. At the current rate of progress it seems likely that I will.

Also, by a process so complex it verges on black magic, I’ve managed to create an ambient sound-scape  that fits the mood pretty well. I’ll write a post attempting to explain how it was made.