zero0.org

Deferred Rendering In Card Kingdom

I posted the following on the Card Kingdom development blog.

Background

One of the major updates to Card Kingdom going forward is a complete rewrite of the rendering pipeline. In the original version, the alpha version essentially, we used a”forward rendering” style for our rendering process. In a forward rendering system, all lighting information is calculated when the mesh is rendered to the screen. For scenes with multiple lights, the mesh would have to be drawn for each light and blended together to get the final image. For non-complex, low lighting count scenes, forward rendering is straight forward and works well. As the number of lights and the complexity of the geometry that is being rendered increases, the processing time drastically increases. The complexity can be modeled as O( n * m ), where n is number of triangles, meshes, objects to render, and m is the number of lights in the scene. Rendering times drastically increase when more lights and triangles are drown. This is why the number of supported lights is usually around 8.

Who Needs Flash…

I posted the following on the Card Kingdom development blog.

In a previous post of mine, I sung the praises of using straight Flash as a UI system. In theory and practice, it works in the form of Scaleform. Flash offers many nice graphical features that would be difficult to rendering normally. The implementation I used basically wrapped the Shockwave COM object and exposed many of it’s methods in an easy way. Rendering was more complex as I had to get access to a DirectX 11 Texture’s GDI context in order to render to it. This process worked, but not really.

Tool Time – Focus and the Model Viewer

I posted the following on the Card Kingdom development blog.

Along with the Combat Corner and Designer’s Den, I want these Tool Time posts to be about tool development, not just on Card Kingdom, but for general tool development. I want to discuss how to make everyone on the team’s life easier when dealing with an engine by making smart decisions about form and functionality.

December 4, 2011 – 6:36 pm
Posted in Card Kingdom

I posted the following on the Card Kingdom development blog.

What I did

My responsibilities on Card Kingdom were core engine design and development, and some general gameplay programming. As one of the other core developers, my main focus was on everything else; audio, input, physics, content importing, core classes and common data structures. I also aided in rendering, most notably by writing some DirectX 11 shaders to give Card Kingdom its distinct, cel-shaded look.

Card Kingdom

Card Kingdom is a 3D arena-style brawler where the player controls an anthropomorphized playing card that defeats overwhelming numbers of zombified cards raised by the evil Joker to conquer Card Kingdom.

Prefabs and the Future

I posted the following on the Card Kingdom development blog.

Prefabs were added into the engine quite late in the development process, but made making “waves” of enemies in the game very easy to create. Prefabs, or prefabricated objects, in our system are small chunks of XML that define a single game object with all of it’s components and any children as well. These objects can then be used multiple times throughout the XML definition of the game. Common objects such as crates, barrels, enemies, weapons, etc. are defined as prefabs. One side effect of how prefabs are realized in the engine is that a prefab can have other prefabs in their definition. For example, the Goon prefab has a link to the Poleaxe prefab. This separates out each object into their own specific file. Any updates to the Poleaxe prefab will automatically be in each enemy when created.

Lighting, Cel Shading, and Shadows

I posted the following on the Card Kingdom development blog.

Light and shadow are the two basic visual cues that give objects depth and position. Light shows off the detail of the object, giving it form. Shadow gives context to the object’s location relative to the other objects around it. These two together give great depth to an otherwise flat image.

In terms of the engine, light can be done using two types of lights: point lights and directional lights. Point lights (e.g. light bulbs, candles) give off localized light that falls off over distance. Directional lights (e.g. sun light) give off global, uniform light across all objects that it hits. Though different in there uses, the calculations are basically the same.

Content Management and Model Instancing

I posted the following on the Card Kingdom development blog.

Content management is a large part of any game. In terms of our engine, “content” is any external resource that needs to be loaded into the system. Shaders, textures, models, and sound files are all content that the system needs to load. Another aspect of content is that it only needs to be loaded once. Loading the same file multiple times is a waste of resources and load time. Creating instances of the content is more efficient in both memory and time. Multiple instances of the same content resource can be created and destroyed with no consequence in the original resource.

Serialization and Audio

I posted the following on the Card Kingdom development blog.

Object serialization and audio have both been in the new iteration of engine from the beginning, but had little to no work done on them since other systems needed more focus during the initial stages of development. Now that these systems are in a state of equilibrium, serialization and audio can be worked on.

Our serialization model is inspired by Java’s (without the automatic reflection of object variables). Objects that want to be serialized extend the ISerializable interface.

InZero

InZero is a 2D side scrolling action/platformer where the player utilizes grenades that perform various physics effects: pull, push and slow, which affect the player, enemies, projectiles and environmental objects.