Implementing Quests and Dialogs

I've been wanting to write up something about how quests and data work in Dawn -- a slice through the engine from top to bottom -- but I haven't had a good hook to do so yet.  I think, though, since I'm in the process of porting Dawn's dialogs over to Moai, its conversation system could provide a good example.

I'm motivated to write about quests because there seems to be little to none in the way of books, articles, and blog posts on the subject -- and yet quests -- or quest like systems -- are an essential component of many games. Finding a way to talk about them, and finding ways to compare and contrast solutions, would be valuable (and interesting!). Dawn's implementation is just one possible way. Other games I've worked on have done radically different things. Ultimately, I'd love to learn more about what others have done.

First, a quick update to provide context. I finally have the first piece of the dialog GUI working the way I want. It's not graphically pretty, but the point really for me is the underlying UI framework supporting it. It means it's possible to build (some small, pre-measured) nested ui components using an html/flex+css like syntax. For town menus, which can have variable numbers of elements, I'll need to finish measurement and sizing - but from there I'll have a good foundation for much more complex UI like combat and shops.

Mori, not to be confused with Moai.
They get angry about that.

From the game's perspective, all dialogs are launched from quests, so let's start at the top....


See full post...

Testing Moai's Positioning

Today a bit of clarification about the way Moai handles the positions of objects. My motivation is two fold. First, I'm working on the UI for character conversation in Dawn, and so I wanted to test my assumptions about the way MOAI works. Second, I wanted to follow up on a misleading statement I made in my first post about connected objects and their joints.


See full post...

Extending Moai in C++

Moai's technique of enabling C++ class instances to have arbitrary Lua data tacked onto them is great. The fact their framework also allows objects to live until both Lua and C++ agree the object memory is no longer needed is even better.

What's not so good about Moai's system is that its bulky. For every class you want to expose, you have to write a helper class inheriting from MOAILuaObject. If you want to see an example, take a look at MOAIFoo included as part of the moaicore source. It's fairly straightforward ( a couple of magic macros worth exploring ), but it doesn't directly solve the question of what to do when you already have your own hierarchy of classes.

To solve the impedance mismatch between an existing class hierarchy and theirs, at least one of their docs recommends using multiple inheritance to merge the two hierarchies together. From an architectural point of view, I believe the game's code should be able to treat Moai as a separable library that helps "get stuff done". Moai's classes should be seen and used by the rest of the code base only when absolutely needed. Multiple inheritance, unfortunately, tends to lead exactly the opposite direction.

All I really want^(tm) is to take an arbitrary class, and expose it in Lua with all the goodness Moai classes have.

Rocking. Let's do it.


See full post...

Don't repeat yourself.

I'm pretty sure the first time I saw DRY -- "Don't Repeat Yourself" -- used as an acronym, I was working with Rails. As far as acronyms go, I like it. And, while it's certainly not the only aspect of good code design worth having a shorthand for, it does serve as a useful reminder from time to time. ( Not to mention, lede for this post. )

When you find yourself typing the same code -- or reenacting the same pattern of code -- over and over again, DRY asks: how can I automate this? How can I abstract away the details? How can I program my programming? 

Enter here the dark side of Lua, because implementing C++ interfaces for Lua code is a lot more RY than D.  Declare your class and its member methods. Yes, in both your .h and .cpp. Then, declare static function versions of those methods, again probably in both your .h and .cpp. Now, use those functions to map the Lua calls to the methods ( isn't this the only part we really care about? ). Then, implement a registration function containing pairs of string names for your functions, and oh yeah, those same functions again. Okay, not the end of the world, but surely we can do better....

See full post...

baby steps

I'ven't had a whole lot of time this week to program, but finally have something decently visual ( and even somewhat functional ) on screen via Moai.

A somewhat functional main menu:

And a scrolling clickable world:

The background map is made of 256x256 textured tiles, and the towns are their own sprites floating above. Both the menu and the world map are using a UI system which allows for a full set of DOM-like mouse events, and some very naive vbox,hbox code ( there's no measure pass, so the boxes have to be told how big they are. )

The data for the towns ( their names, descriptions, etc. ) are getting pulled from the same protobuffer data files the flash version used, and the code uses the Lua protobuffer reflection lib I wrote so that the C++ side and the Lua side can share the same in-memory game data structures.

The most painful part was...

See full post...

another lua curiosity: multiple return values

The previous curiosity was an example of something that didn't work, but one might argue should. This one is something that does work, and at first might be surprising. It revolves around the way Lua handles return values....

See full post...

Moai: First Impressions

I’ve been working with Moai for about a week now, and I wanted to share my impressions of it, and what I’ve learned so far.  I first heard about Moai from the folks at DoubleFine. They are using it on their new 2D adventure game, and what they said made me want to check it out.

So far, I’ve been decently impressed.  It’s not a complete game authoring solution, and it's not supposed to be. It tries to do one thing well, and I think it succeeds.

See full post...

like a rock.

hsm-statechart is now available as a lua rock!
See full post...

not that this works...

Two lexical curiosities for you: one that doesn't work at all, and one that works... sometimes. I'm not claiming that either should work mind you... okay, maybe the second one, but, then, I have ulterior motives.

See full post...