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. 

In the Mood

A couple of fun videos on Youtube:

• Ki-43s and P-40s and Buffalos, all footage shot by a Japanese film crew. I don’t know the origin:
  http://www.youtube.com/watch?v=18gR1Y0XMp4&feature=related
• Ki-43 (two-blade prop, so probably Ki-43-I) test flight. Note the awesome snap rolls:
  http://www.youtube.com/watch?v=EDt6jOOIkpU&NR=1

Now if that doesn’t get you in the mood for Target Rabaul 2, nothing will! 

Progress Update

Almost got tool working on my OS X box, it started to download terrain files, then curl ran into a segmentation fault. Wade is working on it. Closer, but no cigar yet. 

Codewise, I cleaned up some things, made the localization code more robust, and then started to implement a new UI, based on some code from Joemac. I realized it’s really not that hard to make a decently pretty interface. In fact, it reminds me of the old days (I won’t say good old days) of laying out web sites in HTML using tables.  I should have a screenshot to post pretty soon. Still working on making Joemac’s code my code (ie, figuring out what the hell it’s doing)… 

TR Web Site Getting an Upgrade

The TR Dev team is working on a new home for targetrabaul.com. It’s not up yet, so don’t go looking. Looks like the team has settled on Joomla, which is an open source system with a content management system in the background (as I understand it anyway). This should make it a lot easier for us to add new web content. 

 

 

Good Housekeeping

I finished up draft 1 of the TR game design doc, and passed it on to the TR Dev Team tonight. Hopefully, we’ll get a good discussion going on it, agree on the major points, then put it up for more community comments from the TR community. 

On the coding side, I didn’t get much done tonight, just re-organized the files a bit in preparation for switching to a different SVN repository. I also picked up a newer build from sick that fixed a couple UI glitches I noticed earlier. Still no luck on the “tool” build for OS X. GH sent me a couple interesting pictures showing some data glitches in the geo file repository that TW2 (also) uses, and mentioned patching the data. I’ll try to get with him once I’ve got “tool” working and can see some of these things for myself. I’ll also get some info for you all from sick on how to customize the terrain. 

Take This Localization Code and Shove It!

Yeah, that’s right. Shove it in the “done” shelf! I’m finally done with all the localization code, put the final touches on tonight. I’ll write up usage later, when it’s closer to a public release.

Mod Makers: Keep Working on TW1? Move to TW2 Immediately?

I’ve seen this question a few times now. The only real answer here is “Do what you think is best“. But if you want some unsolicited advice (the kind I specialize in), then I would suggest you can do both if you want. I can’t tell you yet what the animation (.anm) format is for TW2, and I can’t tell you what the physics files will look like, but your 2D and 3D artwork is going to work as is in TW2, so you won’t lose anything by continuing to build up artwork for planes. I wouldn’t spend any time on terrain if it was me, unless if it was to build ground clutter 3D objects. Time you spend on scenarios is not going to be easily leveraged for TW2, but we’ve got some time before TW2, and new scenarios are always appreciated by the players. But while you’re working on TW1 stuff, now is a good time to start preparing for TW2.

First Steps for Moving Your Mod to TW2

There are 2 things you can work on right now, without knowing any more about TW2 than you already know:

1. Gameplay Design – Ask yourself: what happens when a player logs into my server? What does he do? Does he get right into a plane? How many teams are there? Are there missions? Are planes limited to historical “sides”? Is it a free for all? Are there older generation planes mixed in with later generation planes? Is there a ground war? Can players affect the ground war? How? How do you win or lose the game? What happens when you die? All these questions you need to start asking your team now, if you haven’t already. Forget about what you could do in TW1. Ask yourself what you want to do, if you could make the rules. Because in TW2, you ARE going to make the rules. Or copy them from a fellow mod team (you lazy bastige).
2. UI Design – In TW 2, mods have their own UI. What your UI will look like is part art (or lack thereof, if your idea of a perfect user interface is one based on a UNIX command line), and part function. You need to decide on a theme, colors, etc etc, but beyond that, you need to know what your game design is, or you won’t be able to make a UI that meets your needs. You can make your UI 3D if you want, you can make it 1980s arcade retro, but however it looks, it needs to support your game play. It’s worth investing some time and thought here. 

Anyway, those are my recommendations for mod teams trying to decide on a course of action. Note to TR Dev Team: We really need to get started on a UI. Not graphics, but how we want players to interact with it, in relation to our Zones campaign. Will post on dev team forum.

TW2 Q & A: 1 km Long Spaceships

On a previous blog entry, Vermillion Leader (friend of Imperious Leader? Inquiring minds want to know) asked if there were any issues in making a spaceship for TW2 that was 1 km or longer in length.  I asked Sick about that, and his answer is:

no issue at all. in fact, rock the [beep!] out!!! i suggest a 100 km long space ship :)

I asked him if the code that reduces poly count of objects rendered far away would affect a ship that was basically near and far to you at the same time, and he said no, because that code is actually based on the size of the object on the screen, not it’s proximity to you. So, A) we should pitch in and buy Sick a shift key or two, and B) mega spaceships seem totally do-able, can’t wait to see them!

 

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.).

This and That

Tool Progress Update

I was able to build “tool” yesterday, but it was missing some libraries or something, Wade is going to take another look at the xcode set up. I’ll check back in on that as soon as I have a chance to play with it and make some terrain. Here’s the command I’ll be using: 

tool terrain 143.0 0 163.216 13

Being geographically challenged, I’m not sure I got that right, but I’m led to believe it’s about the same territory we use in TR in 0.64. 

Lua Update

I’ve been working on the localization code for the TW UI, and for mod UIs and servers. I’ll put this out as a library anyone can use in their mod. Nothing too sexy to report, because I did all the fun parts already. Right now I’m writing some routines to traverse a file directory, find .lua files, and vacuum up any localizable strings it finds, and add them to an xliff file so you can translate them. I’ll talk more about localization in another post. It’s one of those things you want to design in from the very beginning, because it’s painful to add it in later. I must say I’m looking forward to finishing up that module, and get on to the next thing in my project plan, “have supply targets increase for winning side”.