UI-fer Madness

I have a new UI for TR2 now. Graphically, it’s based on Popgirl’s design for the TR web site (the current TR web site, not the new Joomla one the team is working on). Internally, it’s based on a UI sketch Joemac (from TW) let me crib from. And let me just say that I love steal… err, recycling, other people’s code. Especially when it’s in a language I don’t have a lot of experience with. Nothing like debugging code you didn’t write to teach you new things! Anyway, I got a handle on the code, made the modifications I needed to make, and figured out the texture mapping functions Sick programmed for the GUI, and it’s all good. The only thing I didn’t bother to do was make a TR-specific UI Theme, I just used one of Raff’s old themes. Looks pretty good to me, but I think the TR Dev Team may want to go a different direction visually. And that’s fine: all we need is a new texture drawn, and a theme to control how the widgets are drawn. Here are a couple screenshots, one English, one Japanese (slightly different buttons, Japanese version is 1 day newer):

In case it’s not obvious, I should point out that there are no elements of this UI that involve text “frozen” in images. Those buttons are all dynamically generated, with the graphical appearance controlled by Raff’s UI theme, and the text being inserted on top of that by the lua UI. The advantage of that is that you can change text whenever you want, you don’t need to go to a graphics program, save a new image, etc. Localization also becomes dead simple, as you can see from the snapshots. 

Lua Tidbit of the Day: GUI Event Handlers

I’d like to start a new segment that introduces a little bit of lua. The concept I introduce will probably always been related, if not specific to, Targetware 2. Please feel free to post suggestions for topics you’d like to see covered. I don’t have time to cover anything in depth, as every minute I spent on the blog is another I don’t spend on TR2 development!

Probably because I’ve been working on UI stuff for the last few days, I’m going to talk about event handlers. In the TW2 UI system, every control (“widget” in TW parlance) on the screen needs to have an event handler if you want it to do anything. An event handler is nothing more than a function that is called when something happens to the widget. Every UI is going to have a “logoff” or “quit” button of some kind, so let’s use that as an example. Let’s say you have created a widget, and it’s a button, and it’s named “myquitbutton”:

-- event handler for quit/logoff button
function logoff( w, e )
  if e == gui.action then
    client.quit()
  end
end

There is only one line in this code that actually does something: the 4th line, client.quit(). “client” in this case is the TW2 “client application”, running against a server. Executing this command would return you to the TW startup screen. 

So what are “w” and “e”, you ask? In TW2, gui event handlers must be able to handle w and e. The game passes these automatically to the handler. w is the widget that was acted on, and e is the event that occurred. So in line 3, we’re testing to see if the event was a gui action. Most of the time, that’s what you’re going to be wanting to handle. In other words, if this function is set as the event handler for a button, in plain English, it means: “If somebody clicks my button, then log off the server ASAP. If some other event happens, don’t do anything.”

So you’ve written the event handler for your button. The only thing left to do is to teach TW you want the event handler associated with your widget. All you need is a line like this:

myquitbutton:eventhandler():add( logoff )

That’s it for today. 

Grinding On (and On)

Today and yesterday, I worked more on the localization code. The actual code that makes a different language appear has been done for a while, I used something very similar to what I use in other programming languages. What I’ve been doing the last 2-3 days is writing some utility code that a mod developer would run whenever they added new strings to their UI or campaign. What it does is go through all your lua files looking for calls to the “localize this text” routine, and extracts anything it finds into XLIFF files, one for each language you want to localize to. Then you send those off to your army of translators, they translate the new strings, and send back the xliffs. Done. Next time you run the program, your UI and campaign will take advantage of the new translations. So one of the nice things about TW2.0 (and your 2.0-compatible mod, if you choose to use this localization lib) is that you can have a totally localized UI, for basically no pain at all. Which, if you’ve ever done software localization before, you’ll know is a rare thing.

Mod Developers and Players Want to Know: What the @#&( is an XLIFF File?

Ah, glad you should ask, brave translator. XLIFF is nothing more than an xml file that contains paired translations for (usually) 2 languages. It is an open standard (I’m using the newest 1.2, but because I’m only using a very little bit of the format, it should load in editors that only support 1.1 as well), which means that any tool that wants to, could understand it. Basically, it is, in my opinion, the best format to use for software translations (no surprise, since that was probably the main driver in the standard’s creation).

Fine, you say, that’s about as interesting as watching mud flow. Well, in practical terms, it will let anyone working on your project translate it with translation memory tools such as Trados, SDLX, Swordfish, etc., without any prep work. And that means better, faster, easier translations. If any enterprising mod team could get a pootle server setup, all the mod teams could share it, and we’d really be cooking with gas then! Pootle is, as I understand it, a server that you can feed xliffs, and have people translate them through a web interface. But it looks like you have to be a *nix ubergeek to set it up, so I haven’t tried. I’m only a fledgling *nix geek.

Do I Need Lots of Money to Translate this XLIFF Thing?

No! Just send whatever spare cash you have to me (break your piggy bank, go check mom and dad’s dresser), and I’ll tell you how you, too, can participate in the wonder of translation memory. Oh, fine, here are a couple ways to do it for little/no money:

• Sun’s Open Language Tools XLIFF Editor. This is a free tool, open source, released a couple years back by Sun. I believe it supports 1.1. Works on all platforms.
• LocFactory Editor: This is a Mac OS X tool, free “lite” version, or I think $30 for one that actually does TM. I’ll probably pick up a copy of the full version one of these days, and let everyone know if it’s useful.

Or if you’re really crazy, you can just edit the xliff file with a good text editor. It’s pretty straight forward. Of course, you don’t get the advantages of translation memory, but that probably is ok because you’re stark raving mad.

Show Me the 現金!

This screenshot is a few days old, and it shows off the truly ugly test UI I’m using for TR right now. Oh, and it’s localized for Japanese. Japanese for drooling idiots, because *I* translated it myself, and that is never a good thing!

The date in the corner, by the way, is not the RW date, but the date I had the time set to in TR when I took the snap.
What you are looking at is my TR test menu, which has only 2 options: “Start next gen TR campaign test”, and “exit the server”. The other window is a chat window, with a sentence from the server informing me that an unnamed player has logged in. The localization system lets you translate a sentence with placeholders for names and other things you will want to substitute in on the fly. So in this example, the player name is substituted into a string already translated into Japanese. Don’t worry, you’ll thank me for it later. (Or Else)

Holy Crap That’s Ugly

Yeah, well, Yak don’t do no art baby. If will be my pleasure to continue to show you ugly stuff I work on, so please DO complain. If you want to see some real UI examples, check out Raff’s blog from last summer on some ideas he was working on. He’s planning on getting together with Sick a little later this summer in London to get his UI work updated to the latest TW build. And remember, in 2.0, there’s one TW UI, and then once you select a server, you get the UI specified by that server. So if you have a Space War mod, well, your UI could look completely different from a WWI mod’s UI.
On the font: I’m not crazy about the way it shows Japanese, but as far as I can tell, this is the only freely available (and hence distributable) true type font that supports (basically) all of unicode. If anyone knows of a better one (a gothic/serif one would be nice), please let me know.

Terrain Update

Haven’t been able to get online at the same time as AU for the past few days, so no progress on getting tool to run on my Mac. There’s an interesting comment in from GH in the post a couple day’s back, for anyone interested in terrain.

What’s Next?

Unfortunately, I still have more boring localization code to write, but I can see light at the end of the tunnel. Tonight was actually a bit of a breakthrough, so I’m feeling good about my chances to start next week working on something more interesting. Not going to be doing anything over the weekend (unless someone wants to buy me a macbook or macbook pro so I can work on the road? No? Bastiges.).