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…

extracting the town graphics from the original flash art.

The symbols in the SWF actually had labels for their town names baked in, as well as frames for their highlights, and I could not for the life of me figure out a way to extract the correct placement offsets for just the town graphics – even via swftools. I wound up going back to the psds, using Gimp and export layers to regenerate the individual towns, and – for now, at least – have altered Moai so to read and expose the PNG oFFs data(*).

Using the oFFs data turns out to be a fairly nice solution, because it gives pixel perfect positioning of the towns on the map without very much work. But, it does mean you have to use PNGs.

Here’s what it looks like on the Moai side:

// add a new method to the MOAIImage lua interface
int MOAIImage::\_getOffset( lua\_State\* L ) {
  MOAI\_LUA\_SETUP ( MOAIImage, "U" )
  // mXOffset, and mYOffset are new s32 members:
  lua\_pushnumber ( state, self->mXOffset );
  lua\_pushnumber ( state, self->mYOffset );
  return 2;
}

// add the method to the existing registration function
void MOAIImage::RegisterLuaFuncs ( MOAILuaState& state ) {
   luaL\_Reg regTable \[\] = {
   // ...
     "getOffset", \_getOffset },
   // ...
   }
   luaL\_register ( state, 0, regTable );
}

// extend the png loader to extract the offsets
void MOAIImage::LoadPng() {
  // ....
  if (png\_get\_oFFs( png, pngInfo, &offset\_x, &offset\_y, &unit\_type)) {
    this->mXOffset= offset\_x;
    this->mYOffset= offset\_y;
  }
  else {
     this->mXOffset= 0;
     this->mYOffset= 0;
  }
  // ... 
}

One of the main interactivity improvements would be adding some highlights, possibly via blur/tint shaders. I’m actually not sure of the status of shaders in Moai, looks like there’s some contradictory comments in the code and on the website, but think it may still be fixed function rendering right now. I’m may just live without the highlights for now.

This game port started off with the plan that the logic would all be in C++, and the UI would be written all in objective-C ( and/or something like cocos2d ). I finished most of the C++ side a month or so ago, but now that I’m using Moai for UI ( and probably will port across the statemachine game-flow logic to Lua as well ), there are going to be a few challenges to get all existing C++ bits ( quests, combat logic, player save/load, etc. ) exposed without having to re-implement *everything* in Lua.

I think for now I’m going to focus on the visual bits up and running: get the paths between towns visible, get the character sprites in and moving, maybe town popup menus and simple dialogs, and then – given some actual code to work with – can start to see how to join the two sides together.

………..
* Easier said then done: to get the script to work in Gimp I learned I had to install Python2.6 ( as opposed to my current installs of python2.5 and python2.7 ) as well as GTK+, and then download and reinstall Gimp. The latest version of the Gimp on sourceforge, however, doesn’t install on my machine for some reason so I also had to hunt down a working version. The joy of software. *sigh* Scripting Gimp with Python though, that’s pretty grand.