Progress update…

A Complete Game

Over the last several months, I’ve been working primarily with web-related technologies (basic HTML, CSS, PHP, some CMS customization, etc.). In my spare time, I’ve been playing around with the more graphical / game-aspects HTML5. I’ve written a couple “draft” quality JQuery plug-ins: one for basic image effects (saturation effects, etc.), a seamless image tiler / previewer, a seamless image generator, a fire effect, and one more thing: a complete game.

I’m interested in graphics, engine architecture, and games, but often find myself exploring a specific technology rather than trying to create something “complete.” In other words, I tend to take a deep and narrow approach to coding rather than a broad, shallow approach.

My goal this time is to produce a small, maybe-not-that-impressive, but complete game. I realize I’ve never really done this before…

Gravity Tide

I’ve decided to code name it Gravity Tide. So far:

• 2D Graphics via an HTML Canvas element
• Music via the HTML5 Audio element (and via opengameart.org since I’m not a musician!)
• A main menu and credits screen
• 1 Level currently…

Once I add a splashscreen, load/save functionality, a couple more levels, a few power-ups, a few new enemies, end-of-level “bosses”, and a generic minimal game story, I think it – again, may not be epic quality – but it will be a complete game.

For various reasons, one of them being to test LxEngine with “real” data, I’ve been experimenting with loading and displaying the game data from Bethesda Softwork’s 2002 game, The Elder Scrolls III: Morrowind (buy it here on Steam). There’s a fair amount of information out there about the Morrowind file formats – as it is a highly moddable game.  I’ve been using NifTools to parse the actual models and been using custom code for the ESM/BSA parsing (neither are very complicated formats).

The primary purpose of the project has been to test out LxEngine with dated, but production-quality data and data formats.  The experiment thus far has been serving it’s purpose.  It has raised questions like, “Hey, what should the engine do when the current cell has 17 lights and the current shader only supports 8 at a time?”  The LxEngine project has hardly been lacking in TODOs, but in any case, this is helping identify the necessities versus the niceties.

A secondary purpose of the project is to learn a bit more about how Morrowind works, so that potentially as a side-effect of working on my own goals produce some useful contribution to the OpenMW project.  (This project certainly isn’t meant to compete with OpenMW – the goals here are to demo some basic rendering, physics, sound, etc. from Morrowind to test out LxEngine’s capabilities.  The goal of the OpenMW project is to produce a fully playable game with full fidelity to the original.)

As for the current progress, here are some screenshots:

Morrowind data game rendered (with obvious limitations!) with LxEngine

An actual, in-game screenshot from Bethesda Softworks' Morrowind of that same scene

Update: Texture Mapping

Adding texture mapping involved a couple core changes:

• Adding UVs and texture samplers to the LxEngine GLSL shader builder. This is less complex than some of the existing features of the shader builder, but hadn’t yet been added.  The support is somewhat minimal and will require revisiting for multi-texturing.
• Adding DDS texture format support to the GL Rasterizer.  DDS stands for DirectDraw Surface, i.e. a Microsoft DirectX format, that furthermore has some strange patent issues, which seems to bode poorly but video cards usually handle this format natively. There’s a EXT_texture_compression_s3tc OpenGL extension that allows DDS format data to be passed more or less directly to the card.  There’s a simple nVidia tutorial showing how to do this.
• Passing DDS streams from within a BSA understood by the TES3 loader to the LxEngine Rasterizer which knows nothing about Morrowind format data.  This was the fun one – which actually still requires a bit of work – abstracting the LxEngine rasterizer from the texture data source in a flexible, general way that both (a) allows the Rasterizer to know nothing about BSA files while the BSA loader knows nothing about OpenGL and (b) still streams the data directly from a disk-based std::istream to OpenGL without any superfluous copies.    The Rasterizer now allows textures to be created with a “type” and “acquire callback”.  In this case, the type is a stream and the callback is over in the TES3 loader: the only shared concept necessary is the std::istream.

Ever wonder what the Morrowind UV mapping looked like?

And after a couple bug fixes (like, ehem, remembering to open the binary DDS stream in std::ios::binary mode)…

Morrowind cell rendered with LxEngine

Next, I need to add multisampling support to the renderer: these screenshots would look so much better with it enabled!

Update: Multisampling

Multisampling…

16x Multisampling

A video with, as the title suggests, clips from 111 games in 11 minutes of YouTube footage. Worth watching for game design inspiration, if nothing else.

(Thanks to the Glest Blog for the initial link.)