Yak's Target Rabaul Blog

Introducing Zones: The Foundation of the TR 2.0 Campaign

targetrabaul — Sat, 24 Apr 2010 17:26:49 +0000

Target Rabaul 2.0 is, of course, a combat flight simulator. It is also, however, a (hopefully) well-designed game of strategy. The game will be won or lost based on capturing enemy territory. Shooting down a million enemy planes will not, in and of itself, win the game for you. It might help you defend your territory. If you want to win the game, you have to destroy enemy ground targets, to enable your ground troops to capture enemy territory. I will cover the various kinds of targets in a future post.

Territory in TR 2 is divided up in land zones and water zones, as shown in this map:

Target Rabaul 2 Zones Map

The green circles and squares represent land zones. Any land zone with a line connecting it to another zone can be invaded without needing control of the adjacent water zone. Squares represent critical zones, but we have not decided exactly what that will mean yet in terms of game play.

Note: The red numbers are zone IDs used by the TR2 campaign engine, and will not be visible in the actual game.

How Zones Work

A zone can be either “contested” or not contested. Uncontested, the zone is happy and safe. Any “strategic” targets within it’s area are churning away making contributing to the war effort.

As soon a zone is captured by Side A, all neighboring zones owned by Side B become “contested”. Think of that as meaning that ground troops are actively fighting each other in that zone. Strategic resources are destroyed. Tactical resources (tanks, anti-tank guns, trucks, bridges, etc. for the side owning the zone are now available for the enemy to bomb/strafe. The number of tactical targets in a zone are relative to the hardness of the zone. Damaging the targets (100% destruction is NOT required) damages the zone. Once the zone runs out of defensive points, it is captured. Think of this as your airplanes tipping the balance of the battle in favor of your troops, by strafing enemy positions, smashing enemy tank columns, etc.

Zones will not necessarily each be the same toughness. Each zone will have a certain “hardness”, represented by points. For the sake of argument, let’s say 5000 for a weak zone, and 50000 for a super hard one like Rabaul. The numbers simply reflect how hard, historically, it was to capture that territory.

Sample Game Flow

Let’s go through a sample game:
1. Game starts with Japan owning most of the zones (our start date is Aug 7, 1942).
2. Allied forces have uncontested Rennell Islands, uncontested Henderson field (a tiny zone unto itself), and contested zones surrounding Henderson. In New Guinea, allied forces control several land based zones.
3. Allied forces attack up the Solomons, capturing Malaita, Florida, Russel Island, and Vura. This makes New Georgia contested for the Japanese, but they still have Rendova uncontested, and flying countless missions against Vura (allied, but contested). The IJN/IJA destroy Vura before allieds can complete destruction of New Georgia. As soon as Vura is captured, New Georgia resets to “uncontested”, and is safe. Now allied forces, if they want to capture Vura again, have to launch an invasion fleet. They start bombing vura again, and when it gets to 20% of maximum strength, an invasion fleet is automatically launched from a neighboring allied-controlled sea zone. IJN/IJA can destroy this invasion force to cause Strategic damage (more on that later) to allied territories.
4. While allied forces were busy in the solomons, IJA/IJN forces were concentrating on New Guinea. From Buna, they push over the Owen Stanleys along the Kokoda trail, and with heavy air support, capture the tough zones of Kokoda and Toribaiwa (Note: these will be very tough zones, even though they have low population density, to reflect historically tough nature of the battles there, and the rugged terrain). With a final push, the IJN/IJA capture Port Moresby, ending the game. (Capturing a square zone might mean the capturing side wins the campaign, or maybe 2 squares will be required to win). We are not final at all on victory conditions, so take these with a grain of salt.

More on TR 2.0 Target Sets

targetrabaul — Tue, 20 Apr 2010 02:07:41 +0000

Mossie asked me a question on the TR Dev forums about the target set sample code I posted, basically wanting to know if this was the TW way, or just something I made up. The latter. This is just how TR happens to be doing it, not a TW recommendation. These are custom files I cooked up. I will be adding/tweaking them too as I get further into testing.

To explain a bit more on how they are used:

In the TR 2.0 campaign, there are essentially 2 types of targets: strategic and tactical. The same actual object (say a flak gun) could be used as either a strat target or a tactical target. It just depends on how it is used: if guarding a factory, it would be a strategic target. If guarding a fort, it’s a tactical target.

Each zone has a certain “hardness”, represented by points. Let’s say 5000 for a weak zone, and 50000 for a super hard one like Rabaul. If a zone becomes “contested” by having one or more neighbors captured by the enemy, then the campaign engine starts generating Tactical targets in that zone. It generates an amount that corresponds to the zone’s hardness. So if a zone had 5000 points of hardness, maybe the system places 15000 points worth of tactical targets. (I have no idea what the right ratio is, btw. We’ll need to game test that.) To place those targets, the campaign engine reads through all the target sets we have stored in the .targetset files, checks some meta information (side, land vs sea (don’t want a tank in the ocean normally), etc., and starts randomly throwing them into the zone until the sum point value of all the individual targets meets the required point threshold. Tactical target sets could be anything: tank group, anti-tank defensive position, pillboxes, gun positions, etc.

If enemy pilots destroy some, it throws in new ones (again, selection and location are random).

Airfields are a little different, in that some structures (hangars, revetments, etc.) will actually be placed in a fixed location relative to the runway, but guns, for example, are going to be placed randomly. You won’t know exactly where each flak gun, quonset hut, fuel tank, etc, is, for a field unless you happen to have done some recon earlier.

Strat targets are different again, in that they are placed in UNcontested zones. Damaging them causes damage to all contested friendly zones, not to the zone the strat targets are in. If a zone with strat targets becomes contested, the strat targets are destroyed automagically. (think tanks and artillery blowing the #*&@ out of any factories before the infantry gets near them, not to mention softening up by aircraft ahead of time).

TR 2.0 Progress for April 18, 2010: Target Sets

targetrabaul — Mon, 19 Apr 2010 00:17:56 +0000

Had a chance to sit down and code for a few hours today, for the first time in a few weeks. Nothing very exciting. Essentially, TR2.0 is, at the current moment, a test script that automates a fake campaign. Instead of players doing things, the test script does them, and I watch and see what happens. Before the public alpha, all the action was actually in the log files. Once the public alpha came out, I was able to start adding more code to the TR codebase, so that instead of/in addition to simple lines in the log (“New target spawned at 123.45, 45.233: IJN tank, tactical, 10 points, blah blah blah”), an actual object shows up on the game terrain.

Today I focused on replacing some temporary code used to place targets randomly in the game. All the targets had been called out in a single lua file. Today, I went through and created separate files for each target set. This makes it easier for anyone to add more target sets, and not worry about messing up the TR code. Here is an example of a TR target set file:

name = “airfield-3000ft-h-j”

waterGround = “ground”

targetType = TARGET_TYPE_AIRFIELD

staticDynamic = SD_STATIC

sidename = “Japan”

exclusionZone = {w = -500, e = 500, n = -125, s = 125}

placementVariance = {h = 2000, v = 1000}

targets = {

{

name = “Japanese Hangar Type 1″

modelpath = “/data/tr/objects/structures/j_hanger_1.model”

points = 100

location = 0.443,0.5782

heading = 180

},

{

name = “Japanese Steel Pillbox”

modelpath = “/data/tr/objects/structures/j_pillbox_steel.model”

points = 10

location = 0.879,0.5562

heading = 135

},

etc. etc. etc.

I also added code to let the target set designer specify an “exclusion zone” for each target set. This is a rectangle onto which no target can be placed. Think of an airfield runway, for example. You wouldn’t want a flak gun to be generated in the middle of the runway.

You can also now use the placementVariance line to specify the area into which targets will be placed, relative to the center of the target set. In our example above, targets will be placed between 0 and 2000 meters from the horizontal center of our target set, and between 0 and 1000 meters from the vertical center. As long as they don’t collide with the exclusion zone of course.

The location and heading lines are not yet handled by the TR campaign engine, so I’ll cover those and some of the other parts of the file in future posts.

Targetware 2 public alpha Released

targetrabaul — Mon, 19 Apr 2010 00:00:44 +0000

So I’ve been AWOL again: busy with family and work. We’re moving, so my wife took the kids (one more since my last blog post) to their grandparents for a month. The idea being that I would de-clutter the house, clean the house, sell the house, and find a new home for us to live in. Well… noooooo problem. After the first day without wife/kids, I realized I have TONS of free time. And I don’t remember how to use free time. I eventually check out the TW forums, just to see if anything is new, and LOW AND BEHOLD: the first TW 2.0 public alpha has been released!!

Now this is the point where you figure that I probably gave up on the boring selling the house stuff, and just went back to coding TR 2.0. And you’d be right. But… only for a few days. Fast forward… 3 days before family comes back, and I’m just now starting to (hopefully, knock on wood, nudge nudge, wink wink, etc.) get over the hump on selling the house. I’m still hopeful though, because a public alpha means there really will be a TW 2.0, and so there really will be a TR 2.0. GREAT!

By the way, it’s more of a technology demo right now. You can download it, get into the TW 2.0 world, and kind of cruise around the terrain (including going to moon, saturn, and beyond). Meanwhile, the mod elves are now busily working away at converting their TW 0.64 materials to work in TW 2.0, and sick is busily working on implementing the physics API and some more terrain work. He’s on IRC #targetware channel on freenode if you want to ask him anything.

Hot Summer Action!

targetrabaul — Sat, 12 Jul 2008 14:44:27 +0000

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

targetrabaul — Fri, 13 Jun 2008 02:59:29 +0000

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(  )
table.write( ,  )

You can read more about these here.

That’s it for now, back next week.

UI-fer Madness

targetrabaul — Wed, 04 Jun 2008 05:04:53 +0000

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

targetrabaul — Mon, 02 Jun 2008 02:47:12 +0000

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

targetrabaul — Thu, 29 May 2008 04:49:38 +0000

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

targetrabaul — Wed, 28 May 2008 04:33:08 +0000

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.