Subtext

Quick, computer. Do something useful.

I've been doing research for a new post on scripting with data, and my favorite find today was this picture lifted from a presentation on subtext.

On one side of the image: a programmer working hard to figure out what the heck all that code does. On the other side: a computer sitting idle, doing nothing but displaying text.
So. True.

See full post...

Lua Protocol Buffers

Since I've been posting about Protocol Buffers lately, I thought I'd post a quick note about a small project of mine over on Google Code.

lua-pb-reflect provides access to protocol buffers in the Lua scripting language without having to generate Lua specific protocol buffer code.  If you're already embedding Lua in your games, it's probably the simplest binding out there. It has no C++ dependencies other than Lua and Google's standard protocol buffer library.


See full post...

Playing Zelda as Zelda: Do we make what we are?

While I've been off writing about arcane aspects of game development, my awesome girlfriend, Kenna, has been busy hacking up the original Legend of Zelda so you can actually play *as Zelda*.  ( She also documents how she did it so other people can try some hacking themselves. )

There's a truly impressive ROM hacking community out there who keep bringing new life to these classics. What makes Kenna's particular hack special is, of course, the gender-bending...

See full post...

Scripting with Data - Part 2

Jake Simpson, the author of the Sims scripting system, has said, "Good scripting is less about which language you use, and more about which features you expose." He asserts, for example, that functions determining if an NPC is in a range of another object are more valuable than raw trigonometry functions. A "range function" written in C++ will be faster than the script based math, and the code will be less error prone because it's been written just once. He calls these "Relative Scripts", but what he's really talking about are Domain Specific Languages.

Domain Specific Languages (DSLs) of any sort can make developing games quicker and easier. DSLs are more constrained than general purpose languages, but it's those very constraints which them so useful.

My goal with this series of posts is to introduce a relatively simple way to make your own domain specific scripting languages using a data compiler. With this method, if you already have a mechanism to save and load data for your game, then you already have a compiler for your scripts. In addition, there is no need to write a specialized interpreter ( like QuakeC, or Unreal Script ) because C++ is, itself, the interpreter. 

For the purposes of this post, let’s assume you don’t have a data build system lying around, and let’s see how to use an off the shelf solution to create a simple scripting language. If you have a data build system though, I hope this helps you read between the lines, and see how you might adapt your system to support scripting with data.

See full post...

Scripting with Data

Inspired by Niklas Frykholm’s series on a data-driven system for vector fields, I wanted to share a technique I use for scripting which I call "data-build scripting". It’s an admittedly poor term because it's not about scripting your art pipeline or data-build system, it’s about leveraging your build system to create your own powerful scripting languages.

I’ll tell you a bit about Nikas’ system, then introduce data-build scripting, and wrap up with some source code using Google’s protocol buffers to create a custom scripting language.

The advantage of data-build scripting is that you can create highly-targeted domain-specific languages that are an integral part of the very same data your scripts act on. The disadvantages are the same as any custom scripting language: no script level debugger, no general purpose tools for writing your scripts, and a new class of possible bugs related to script processing and memory management.

See full post...

Controlling Moai Rendering Order - Part 2

This is the second of two posts looking at ways to control object rendering order in Moai. That is, managing which objects appear on top of which other objects in your game.

The first post looked at the more straight-forward techniques of using insertProp() ordering and pushRenderPass() layering. This post looks at two more techniques: Partition priority and render tables. It requires digging a little bit under the hood to see first: what the code is doing when you insertProp, and, second: what happens when you pushRenderPass. Both techniques are very handy, so without further ado...

See full post...

Controlling Moai Rendering Order - Part 1

Using Moai, how can you ensure one object appears over top of another? Maybe you need a starfield to appear under your ships, perhaps you want to see through a translucent window to objects behind a building, or maybe you just need a dialog button to appear over its background.

Most 3d games use a z-buffer to record the depth of each pixel rendered, and rely on a z-test so that pixels closer to the viewer can take precedence over pixels further away. Many 2d games, on the other hand, rely on rendering order to control which objects display over what. Every new object rendered simply overdraws ( or blends on top of ) whatever is currently on the screen.

In Moai, by default, it's rendering order that controls appearance. How, then, do you control the rendering order of objects? In what follows, I'll explain four techniques you can use to get your scenes rendering how you want...


See full post...