Hot Summer Action!

Is something sadly missing in my life these days. However, as all good Minnesotans try to do, I manage to spend all weekend outdoors during the summer. Which leaves very little time for TR coding. But fear not, our summers are short, and a good chunk of the TR team is on the bottom of the world, so it’s winter for them. So theoretically, they’re all being super productive  

Some of you may have noticed that we transitioned the Target Rabaul web site to a Joomla site, from the creaky old PostNuke site we had been having hosted by Mark 9 Systems. LeadDog and the others are still working on content, but this is a good thing: we’ll be able to better control our content, and more than one of us can update it. 

Fun Terrain Coming Up

There was a neat discussion thread in the TR dev forum about how we want to do trees in TW2. Ebola posted a great series of pics of how other sims have done it, what the poly counts were, etc. Since I was actually home this morning, I had a chance to chat with Sick about it. It’s not all finalized yet, so Sick didn’t feel comfortable bragging about it yet, but I think it’s safe to say TW2 is going to allow some seriously cool terrain clutter. I will of course post more when I know more. 

All UI and No Play Makes Yak a Dull Boy

I haven’t been working on much the last week. Since it’s summer in this part of the world, and since our summer is short, I tend to spend the weekends outdoors as much as possible. Didn’t get much done this week because of work and low energy, but I did put the UI stuff in the background again, and return to campaign work. Joemac and Sick are changing a lot of stuff right now with the UI code, so I’m going to let the dust settle there before going back. Also, the TR team is still working on how they want the new web site and UI to look, so it’s a good time to pause on the UI.

Have Terrain, Will Travel

I don’t think the Mac bug with “tool” has been fixed yet, so I got a windows copy from Joemac and built a TR terrain using Parallels VM. (And no, I don’t care that you think VMware is better: I paid for Parallels early on before VMware could be bothered with Mac users, and it works just fine for my purposes). I haven’t hooked up the new terrain yet, I’ll do that next week I hope. 

Next Task: Saving/Restoring Campaign State

My next job is to start moving away from my campaign testing script, which ran a kind of accelerated campaign when you clicked a button. Pilot actions were all simulated.  What I’ve been working on this week (or meaning to work on, anyway) is adapting the code so that you can have cold starts (fresh campaign) or re-starts based on the last saved campaign data. Based on my comments in the campaign code, I see that I’m targeting a campaign length of about 3 weeks long. More than enough chances for the server to crash (probably same “Chinese hackers” that are hitting up those congressman’s pcs!), Bloo to stumble through and yank out the power cord, or the server to collapse in self-pity when faced with 300 raving TR fans shooting each other down all night long (Hey! I can dream, can’t I!?). Smooth sailing so far, thanks to these little TW lua gems: 

table.read( <filename> )
table.write( <Lua table>, <filename> )

You can read more about these here.

That’s it for now, back next week. 

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. 

No Coding… Only Game Design

I was out of internet reach for the weekend, so I worked on a TR2 game design document. It started out as a UI design document to show the troops on the TR dev forum. After I got started, I realized I had to flesh out more of the game design before I could mock up a UI. I’m still working on the document, it’s kind of fun actually. It’s an exercise in ideas, which is a nice break before going back to actual coding, which is sometimes an exercise in debugging. At least for me, at this point in my lua career. 

I’m going to post this on the TR dev forum when I’m done, collect comments, and then maybe show it to interested TR players for feedback. I can’t promise I’ll accept all comments, but I’ll certainly keep them in mind when doing implementation. And, if you don’t like how it turns out, you can always code up your mod totally differently! I’m looking to try something a little different with squads in TR, and see how it turns out. It could be a very good thing. Or it could backfire and suck! If it does, we just yank it and that’s that. 

 

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!

 

TR 2: It’s a Long Road, Getting from Here to There…

Hi All, welcome to my Target Rabaul dev blog. I’m going to use this blog to document my efforts to bring Target Rabaul into the Targetware 2.0 world. I want to warn you up front: This is my first blog, and it could suck.

What This Blog Will Cover

This blog is not an official Targetware/Mark Nine Systems blog. It’s not even a Target Rabaul official blog. It’s just a record of what I’m learning, testing, and trying to get to. I think it’s mainly going to cover:

• The next-gen Target Rabaul campaign system
• Learning Lua/Programming in Lua
• Developing for Targetware 2

I’ll be throwing in screenshots and whatnot as I come across stuff I want to relate.

For anyone stumbling over this blog: I’m not going to try and write up the history of Target Rabaul, or Targetware. Targetware is a community-based online, massively-multiplayer, combat flight sim. Target Rabaul is the oldest community-orginated “mod” for TW. 

Targetware 1 and TR 1

“Targetware 1″… what the heck is that, you ask? That’s what we call Targetware 0.1 – 0.64. “TR 1″ is what I call all TR builds designed for TW1. Targetware 1 development has been frozen for quite some time, as Sick re-writes everything to make TW2. Target Rabaul is actually still in development for TW1, thanks largely to Peril, Baders, and the rest of the TR dev team. 

Targetware 2 and TR 2

What does TW2 mean to TR and other mods? It means better graphics, sure. But to me, I think the most important thing about TW2 is that games are no longer based on scripted scenarios. TW has pulled back from supplying a framework for how games/mods should be designed. In TW2, everything is out there for the mod teams to control: their own UI. Their own everything. All this is controlled through lua scripting. It’s entirely conceivable, probably very likely, that every mod team is going to go off in a different direction from the rest. Some mods may end up being free-for-all, simple “arenas”. Some may be a TW1-esque set of historically-based, individual scenarios with logic and continuance between them. Some may be all-encompassing world war (or space war, given the new physics and terrain features in TW2), a kind of strategy game with a flight sim laid over it. 

On a practical level, to get a mod working in TW2 will require some work. I’m learning this as I go along, but here is a basic outline (in no particular order):

• Create new terrain – TW 2 employs a totally new terrain engine. It also has a built-in terrain generation functionality, through the “tool.exe”, well, tool. I haven’t gotten mine to build yet on my Mac, so I haven’t tried that out yet. I’ll report back on it. 
• Re-write plane and target .acm files – TW 2 has a new physics engine, and it also no longer recognizes the old style “config” files. You’ll probably still be using the same basic data, but it will be in a different format. When I know more, I’ll post about it. My plan is to convert a couple TR planes, then post instructions on how to do it. 
• Write or copy a mod UI – In TW1, there was one UI that controlled everything: selecting a server, game settings, input settings, and in-game menus. In TW2, Targetware (the app) comes with a UI that controls graphics/etc settings, and server selection. Once you choose a server to join, that server’s mod takes control of the UI. So each mod needs a UI. Nothing says we can’t just share them between mods, of course, but first of all, someone has to write one, and then you want to think about either customizing it for your mod, or just hacking it to pieces and making a totally unique one. You may decide that your mod has different requirements, not just visually, but functionally. The UI for an arena-based game may not work for a strat/campaign-based game, for example.
• Adapt 3D animation (.anm) files – TW2 doesn’t use the .anm files you’re used to from TW1. I’m not sure what the new format will look like, but I’ll post on it when I have a chance to learn how to convert to it. 
• Decide what kind of game you want – TW1 game play was pretty much defined by the structure provided by the scenario files (for good and bad). TW2 game play is all open… This is probably the most basic decision any mod team needs to make. For TR, initially any way, I’m working on a New Guinea/Solomons campaign that involves concepts from wargaming (Rydog and Sick supplying the brain power there). I’ll describe it more in a different post. 
• Code your game play decisions in Lua – Once you’ve decided what kind of game you want, you need to write up the rules in lua. Or steal the rules from another mod. I imagine in the beginning, all the mods will share a really similar look, until we get enough people comfortable with lua to start branching out, getting closer to the dev team’s original vision for their mod.