» Card Kingdom zero0.org

Category Archives: Card Kingdom

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.

Justin’s Post-Mortem

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.

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.

Cheating with the Character Controller and Phantom Collisions

I posted the following on the Card Kingdom development blog.

Two features of Havok Physics that we will be using for this game are the character controller and phantom collisions. The character controller is used, as the name suggests, to control a physical body as user controlled object. It handles the various states a character can be in: on the group, wanting to jump, in the air, climbing a ladder, flying, etc. It also supports custom states as well, so crouching, swimming, any state that the physical representation of the body needs act differently in, it handles.

Who Needs Scaleform…

I posted the following on the Card Kingdom development blog.

Another new feature for the engine this go-around is an enhanced UI. Our previous UI was built using objects and custom components for each type of widget. Buttons, text labels, sliders, and other such controls could be placed in the game interface with a few custom animations, such as sliding in and out of the frame and rollover/highlight states. These controls functioned well and were pretty simple to use and extend, but it took a lot of initial work developing the widgets that could have been used in other areas of the engine.

Havok Physics, Tools, and the Visual Debugger

I posted the following on the Card Kingdom development blog.

Integrating Havok into our engine has been a slow, arduous, yet rewarding experience. The main feature that makes Havok such an ideal solution are the tools. Exporters for common 3D modeling programs, preview tools and visual debuggers make the development process a much more pleasant experience. Without these tools, we would have to rely on our engine, which is still a work in progress.

New models, animations, physics interactions and property tweaks would have to be tested in the engine with massive amounts of debug information displayed. The process for testing would be: model or code, export, import into the engine, maybe recompile the engine, run the application, test, find errors, make adjustments, repeat. That process is time consuming and unproductive.