Red Brick Games

I’ve started working on the game results screen, which shows player scores and other statistics.

One idea I had for this screen was to include a chat window.  That way players can discuss game results after the game is over.  I’m surprised so few RTSs have a chat feature here.  After all, nearly every first-person shooter game allows chat when a game/round ends.  Torque, included.  And since Torque already has this feature, including it into my results screen is easy.

One thing I’m finding not-so-easy though is programmatically creating the results screen from C++ code.  Torque’s GUI controls are really designed to be instantiated from TorqueScript - and from TorqueScript only.  I haven’t seen a single GUI control class that has a convenient C++ constructor.  I.e., a constructor that takes traditional arguments like position, text, parent window, etc.  In fact, most control classes don’t even have C++ accessor and mutator methods!  You have to set all control attributes TorqueScript-style.  What a nuisance.

That’s one of the problems in general I’ve found with Torque; some functionality is accessible from TorqueScript only, while other functionality is accessible from C++ only.

In other news: do you recognize these two fugitives?

Catch them in action in a re-release of this gaming classic.

I live in Texas, and the regional phone company around here is SBC (or if you prefer, AT&T, after the merger). My last phone bill gave me quite a shock. I had called a friend in Australia, and SBC is charging me $2.51 / minute for the call. Yes, that’s 2.51 dollars a minute, not 2.51 cents. The call was 32 minutes so they are billing me $80.32 for that single call.

In comparison, the market rate (if I can call it that) for calls to Australia ranges from 1.7 cents down to 1.3 cents (actually, 1.29 to be exact). That’s cents, not dollars. Here’s a website comparing various calling cards, and their rates to Aussie-land.

Link http://speedypin.com/phone/cards/Australia/USA%20-%20Continental/20

Needless to say, I am pretty miffed at SBC. Prior to this, I’ve had a generally positive impression of SBC, and I’ve actually worked for them twice (in TRI - their R&D division). But this…is really something. It seems like they’re preying on the trust of their customers. “I’m sure they’ll charge me in the general ballpark of market rates…” one might think, before placing a call to a location one hasn’t called before. But think like that, and you’ll end up with a $80 charge on your next bill.

Incidentally, this call was from an ordinary residental land line, to an ordinary residential land line. No cell phones, or anything out-of-the-ordinary involved.

Well, what can one do.

I now have fog-of-war updating in the minimap, in real-time.

One of the remaining problems, though, is FOW and water in the 3-D view.  Currently, FOW does not correctly obscure water in the 3-D view.  You can see this in the 2nd screenshot above, by comparing the water in the minimap (obscured correctly) vs. in the 3-D view.

The problem is that the way I implement FOW, by darkening the terrain, has no effect on water.  Terrain and water are modeled differently in Torque.

Another problem is that the player can still kind of see the profile of the terrain, even if it is darkened, in the 3-D view.  The shape of the terrain is still there, it’s just black.  So if he tilts the camera to view the terrain against a backdrop of sky or water, he can see ridgelines, cliffs, hills, etc.

I think these problems aren’t *too* terribly important, and I could probably ship with them.  But!  I also think there’s a really cool solution to both of them.  Torque has the ability to dynamically alter its terrain height-map at run-time.  What if, at the start of the game, all darkened terrain was set to be 1 meter above the water table?  Then, as the player explored, and new terrain came into view, the game would incrementally restore the terrain to its correct height.  That would cause all initially-hidden water to be invisible, since it would be covered over by land.  It would also make FOW-covered terrain be flat, so no ridgelines or hills could be seen.  Seems like a perfect solution and very feasible.

That’s probably going to be one of my lower priorities, but I hope I have time to implement it, it would certainly be cool.

More fog of war screenshots:

Besides doing fog of war, in the last several weeks I’ve completed a big networking rearchitecture of the game.  That, I’m glad to get done.  It seems I’ve spent of a lot of time building infrastructure and learning more about Torque, which doesn’t necessarily translate into progress that I can show.  But, that’s the nature of software I suppose.  Internals can take a lot of work.  Fortunately, I think the infrastructure tasks are finally winding down (at least there’s fewer of them on my to-do list), which means I may be getting to more gameplay work soon.  I’m looking forward to it!

My apologies to anyone who’s tried to post comments to the blog; I’ve been getting spammed with tons of junk posts for online gambling.  I’ve turned off posting until I can figure out a better way to deal with it.