» HTML zero0.org

Tag Archives: HTML

Controlling HTML Without A Keyboard or Mouse

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.

Tool Time – Interactive Wave Editor and Lessons Learned

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.

Tool Time – GDC and New Editor Features

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.

Tool Time – Particles, UI, and Resources

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.

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.