Development blog activate.
I posted the following on the Card Kingdom development blog.
One neat concept I learned about while researching deferred rendering was the PBuffer. The PBuffer is used for post-process effects and contains at least two screen-sized render targets that are swapped between each other while rendering each post-process effect sequentially. The final image from one effect is used as input for the next, creating a daisy chain of accumulating effects. To expand the number of possible effects the PBuffer can support, half and quarter-sized buffers can be used to scale down the previously rendered effect and used to support other effects (e.g. bloom).
I posted the following on the Card Kingdom development blog.
Since the beginning of the Card Kingdom, we’ve been using XBox controllers as the main sources of input for the game. The controllers afford us preexisting control schemes, analog movement, and support for multiple players at once. What it does not support is a way to interact with HTML in a standard, keyboard and mouse way. To support this, I’ve been working on a UI Paneling System, written in jQuery, that does not rely on a keyboard or mouse for interaction, while still providing a robust framework on which a user interface can be built.
I posted the following on the Card Kingdom development blog.
Interactive Wave Editor
As the project nears completion, this will be the last Tool Time post, but I’m ending with a bang. A large part of Card Kingdom is its waves and their design. They are our main mechanic to convey progression and are used to teach the player how to play the game. Therefore, the design of these waves are incredibly important. Before how we were designing waves was on a whiteboard. We used different symbols representing each object type, labels for when and where objects would spawn, and tried to convey how the wave should flow through hand-waving and notes. We would then convert all that to fit in the XML Serialization of the wave, not really knowing exactly if the wave would work or the placement of objects were correct. This took time and a lot of guessing on the part of the designers, and was just an unpleasant experience all around.
I posted the following on the Card Kingdom development blog.
More Lightning
In a somewhat recent post, I showed off the initial stages of the lightning effect that I’ve been working on. One of the major hurtles that was tripping me up, and the reason why in the old video it is hard to actually see the lightning, was the blend states in DirectX 11. There is a flag in the blend state descriptor called IndependentBlendEnable. If this is set the false, all render targets that are bound only use the first render target blend descriptor. For many applications this works perfectly fine. For others, this breaks everything. Well, not break per-se, but gives unintended, unwanted, and incorrect results. So, the issue that I was running into was when rendering the depth render target, the blend mode was set to additive. It was trying to additively blend the depth with an already existing depth value or zero from the depth render target. The fix was to specify IndependentBlendEnable = true and define the depth render target to use an alpha blend to overwrite any value that was previously rendered.
I posted the following on the Card Kingdom development blog.
The research topic I am working on as part of the graduate program is adding transparency into a deferred rendering pipeline. If you haven’t noticed, I’ve been posting a lot about deferred rendering. The main reason I wanted to redo our old forward rendering pipeline as a deferred one is because it’s a new and interesting rendering technique. Learning and experiencing new techniques to keep up to date with the latest technology and practices is essential in the software field, let alone the highly volatile games industry.
I posted the following on the Card Kingdom development blog.
Deferred Particles
As with other parts of the engine, the entire particle system was updated to use a similar deferred rendering method as the regular geometry. This really improves the look of the particles, in particular smoke and dust, as it gives them a more “volumetric” look. All the particles now interact with the lights in the scene just as the regular geometry does.
I posted the following on the Card Kingdom development blog.
The Card Kingdom team was lucky enough to attend GDC, Game Developers Conference, in San Francisco a few weeks ago. We showed the game to a new audience that spanned the spectrum of students to industry veterans. The overall feedback we got on the game was incredibly positive. This was a huge boost to our confidence and cemented that our design choices were correct. Any negative feedback we took and plan on addressing in the upcoming build. The most frequently asked questions were “when is this going to be released?” and “what platform is it going to be released on?” We answered that we’re going to try and submit it to some competitions and see how far it gets. Beyond that, we have to decide what the next step for Card Kingdom will be after we finish our capstone.
I posted the following on the Card Kingdom development blog.
What I did
For this version of Card Kingdom, I worked on updating core engine components with some optimizations and cleaner code, refactored the serialization pipeline to be more robust with prefabricated objects, or prefabs as we called them, added an “editor mode” that supports in-engine particle editor and run-time resource reloading, and replaced the old forward rendering system with a new, more advanced deferred rendering pipeline that supports multiple post-process effects.
Awesomium is a fantastic tool that I’ve been using for the past few months on the Card Kingdom project. I posted a brief description and reason for switching to use Awesomium here, so I won’t go too much into how awesome Awesomium is. It just is, trust me. One thing that is not so awesome about Awesomium is how they handle strings. To fix this, I wrote some utilities to make dealing with the Awesomium strings much easier.
I posted the following on the Card Kingdom development blog.
Particle Editor and UI Communication
One of the newest features I’ve been working on was the in-engine particle editor. This was a great test for the communication from the UI to the engine, and back again. In developing, this was the “worst case” scenario for communication as there are many parameters that can be set for the particles. Designing a system that could handle this case, as well as simpler ones was vital in making the UI flexible and extensible.
The solution I came up with an event listener and caller system. Using our internal messaging system, components register themselves as event listeners to one or multiple events and can retrieve the event caller for the UI.