Red Brick Games

Archive for the ‘TorqueScript’ Category

Good things come to those that wait

Sunday, October 26th, 2008

At least, they do in my case.

Particle effects have worked out well. Here’s a particle-heavy animation of a worker building a road:

I’ve been wanting to implement those effects for a long time. The intial shovel-scrape kicks up dust, dirt flies off to the side, and when the dirt lands, it kicks up more dust. All done with particles.

All that is courtesy of a powerful “action” system that Orcs vs. Martians has. Every action, such as shoveling, can trigger a sequence of so-called micro actions. Each micro action can play an animation, play a sound, change the mounted tool, and now, trigger particle effects. Put together, actions can now consist of an elaborate sequence of audio-visual effects, as the shoveling action does in the video. The sequences are declared in Torque script for easy editing. It’s a nice, flexible system for unit animations and effects.

It all plays client-side, so all that mounting, animation, and sound happens without consuming any network bandwidth.

I’m now working on re-laying out the game setup gui, portions of the in-game gui, and portions of the results gui. It’s going well so far - things are fitting where I want them, and the in-game gui should emerge from this re-layout somewhat simpler. Some of this work is about applying some really good feedback I got from the last beta test.

Also, much of this layout work will probably be final! That’s not to say I have all the final 2-D artwork in place; I don’t. But as far as the arrangement of gui controls, their resizing behavior, etc., this will probably be a final pass for a lot of gui work. w00t.

Posted in TorqueScript, Networking, GUI, Graphics | No Comments »

Models and more

Wednesday, March 19th, 2008

I did a small favor for a fellow indie, and he in turn made some new 3-D models for OVM! OVM now sports a UFO model to serve as the Martians’ base, and a laser rifle for Martian crewmen to hold.

I felt the placeholder art I originally had for those two items really detracted from the game’s look, even as placeholders. What a nice improvement. Thanks Thak!

If you’re interested in more of Thak’s work, check out 3dmatter.com or spellcraft.biz. He works fast - he turned out those two models in no time flat.

Progress

These last few weeks I:

finished the A.I. personal-view-of-the-world feature
started to separate OVM’s pathfinding code into a stand-alone library
added new features to meta-C (my homegrown programming language, which OVM is written in)
optimized meta-C for speed

I kind of spread myself too thin these last weeks, trying to do all those things simultaneously, and several of them didn’t go as planned. Still, I got some progress done.

A.I. personal view of the world

This is done! The A.I. now makes all important decisions based on a limited, imperfect view of the world. No cheating anymore!

This is a huge milestone, and it’s been a long time coming. I remember putting this feature on my to-do list well over a year ago. At the time I thought to myself, that’s pretty ambitious, I don’t know if I’ll get that feature in. So, I’m definitely happy that it’s actually in!

I still need to do the follow-up work of increasing the A.I.’s exploration ability; without that, as predicted, the A.I. is behaving dumb as dirt.

Pathfinding library

I started pulling out OVM’s pathfinding code for packaging as a sellable product.

Here’s what the main API currently looks like:

   F32 findPath(
      Point2F          bgnPoint,
      RectF            endRect,
      IMap*            map,
      Vector<Point2F>* path,
      ICoster*         coster = NULL,
      F32              range = 0,
      F32              maxCost = FLT_MAX
      );

It’s simply a global function that outputs a vector of way points. Maybe I’ll describe the parameters in a later post. I’m still figuring out how to make the API as user-friendly and flexible as possible, by using C++ templates, etc. Naturally, it’ll also need a friendly TorqueScript interface, too.

There will also be some utility functions and data structures, for things like iterating over the tiles crossed by a ray (useful for smoothing out the final path).

One good thing is, I’ve taken a look at some other free pathfinding packages, and it looks like OVM’s pathfinding does indeed provide features beyond what’s already out there. Got to provide value, to sell a product.

Next up: Squads

I’ve started working on giving OVM a notion of sqauds, i.e. groupings of units.

The more I think about squads, the more issues I see them impacting in the game. For example:

making units march in formation
reducing the number of calls to pathfinding (and hence reducing CPU demand), via squad flocking
reducing network traffic, via squad flocking
allowing the A.I. to temporarily subdivide a force to deal with attacks from multiple directions, via a hierarchy of squads (i.e., squads of squads), and then bring those forces back together to resume the squad’s original mission
helping the AI manage multiple units sent to do a single job, e.g. when multiple workers go to build a new base
allowing units to auto-explore in two’s or three’s, in addition to individually

I thought that was kind of interesting. Originally, I thought of squads as mainly relating to marching in formation. But they seem to touch quite a few other areas, at least from a programming perspective.

Posted in C++, TorqueScript, Pathfinding, A.I., Networking, Development tools | No Comments »

Progress for June

Tuesday, July 3rd, 2007

Picturesque screenshot of Orcs vs. Martians (click to enlarge):

I’m going to try something new that will hopefully make this blog a more enjoyable read. I’m going to separate out, probably at the end of each blog entry, programming details that would be of interest only to software developers. That way, people who aren’t into such things can skip them more easily. We’ll see if that works out.

redbrickgames.com saw 60% more web traffic in June than it saw in any previous month. Wow - that’s kind of exciting. I’m actually surprised how many visitors this site gets, considering that it’s mostly a blog about an unfinished game! Don’t get me wrong, I like visits, and *I* think watching a game go through development, with the occasional wrong technical direction and humorous bug, is pretty interesting. I’m just surprised (and glad) some others think so too.

For anyone who wants to link to this site, go right ahead (and thanks). Eventually, redbrickgames.com will become a storefront to sell the software I write, so for me, any traffic is good traffic. Here’s a link-bitmap:

For June, here’s what’s been done on Orcs vs. Martians:

allowed workers to queue multiple build orders!
allowed multiple workers to work on the same building.
added many more unit animations & sound effects.
implemented a system to make animations/sound effects more network-efficient.
fixed some problems with animations not stopping.
got hand-made maps working!
implemented a “tabbed property sheet” gui control for Torque.
came to a decision on what content I want in the end-of-game screen.
…and in that vein, added many new stats & graphs to the end-of-game screen.
fixed lots of small bugs.
fixed several areas of “questionable” code, code that hadn’t exhibited any problems yet but theoretically could.

Building multiple buildings now requires considerably less micromanagement. Just select a worker (or several), hold down SHIFT, and click once each place you want a building. It’s a fire-and-forget sort of thing, so when the workers finish one building, they’ll automatically start the next. (if you don’t want multiple buildings, don’t hold down SHIFT) It works great for building a tower defense around a base or multiple windmills.

You can also see planned buildings in the 3-D view now!

I also implemented a new animation/sound system, and I’m pretty happy with it. It allows a sequence of animations and sound effects to be associated with each little “act” that a unit can do. For example, when a worker chops a tree,

a chop animation plays;
a swoosh sound plays, as the axe swings through the air;
a chop sound plays, when the tree is hit.

The new system allows the sequence to play multiple anims/sounds as a result of a single act, which wasn’t possible before. So now chopping, mining, building, paving, etc. are more interesting to watch. The system could also be extended to support particle effects too, like bits of bark flying as a worker chops a tree, or puffs of dust as a worker paves a road.

Hand-made maps now work! Orcs vs. Martians is designed to rely heavily on random-generated maps for replay value, but I figure it also needs to support a few hand-made maps too. For one thing, hand-made maps are currently the only way to get some different color schemes into the map. Here’s a hand-made map that has a nice alternative to the conventional water color:

(In the future, I hope to add more color/texture variety to random maps, too)

I’ve also implemented a generic “tabbed” control in Torque. This is like those tabbed property sheets you often see in Windows. I previously cheated with some hacks to make the Options dialog look like it had tabs, but this is the real thing now. The Options dialog now looks like:

Plus, I’m using my tabbed control two places in the end-of-game gui, and might use it once in-game too.

I’m pretty excited about the end-of-game gui; I’ve come to a decision about what content (statistics and graphs) I want in there. I want to provide a satisfying experience when the player reviews the game he just finished, and I think what I’ve got planned will do that.

Technicals

Another nice thing about the anim/sound system is it uses very low network bandwidth. Each time a unit does an act, I just send the act number (encoded in only 4 or 5 bits) over the network. The client-side then plays the sounds, animation, and in the future, particle effects - with no more network activity. w00t!

The Torque Game Engine doesn’t have a native implementation of a tabbed control, can you believe that? so I may submit mine as a code resource to GarageGames. Everybody needs a tab control! at least, you do if you have an options dialog.

I’ve found that TorqueScript makes the programming model for a tabbed control wonderfully easy, too. I just defined a single control class, GuiTabbedCtrl. GuiTabbedCtrl looks for any child controls beneath it, and automatically renders them as tabs. It’s that easy to use! To get the name that appears on each tab, GuiTabbedCtrl looks on each child for a dynamic field named “tabName”. I may do something similiar to let children specify bitmaps to appear on their tabs, too.

Posted in General, TorqueScript, RTS maps, Networking | No Comments »

Turning on DTS billboards

Saturday, June 23rd, 2007

I finished the DTS billboard resource that I mentioned earlier. This resource is a patch to Torque that allows a Torque developer to, in-game via TorqueScript, turn on billboards for any DTS shape. So if you purchase a 3rd-party art pack with DTS shapes that don’t have billboards turned on, now you can turn them on yourself.

Link is here (this is on the GarageGames website and requires a license to the Torque Game Engine).

Posted in Torque, TorqueScript | No Comments »

Hud, etc.

Tuesday, May 29th, 2007

The revised hud in Orcs vs. Martians is coming along nicely. Screenshot (click to enlarge):

There have been lots of other improvements and developments in the past month as well, both in the hud and elsewhere.

Hotkey group display

The hud now shows a summary of the hotkey groups. These are the ten groups assigned by the CTRL + number key combination. The summary shows which groups are currently assigned, and what kind of unit/building they contain.

Dynamic chat log

The chat log now appears and hides itself dynamically. When not in use, it rolls itself into the top of the hud, freeing up extra real estate.

now you see it

now you don’t

Base summary

There’s now a small base summary display in the upper-right corner of the hud.

This summary allows the player to check on the status of his bases at a glance. Normally, he’d have to select the bases or hover over over them in the 3-D view to see info about them.

Improved details display

The details display now has two modes, selection and upgrades. Selection mode shows the currently-selected units or buildings.

Upgrade mode shows each player’s upgrades.

The upgrades mode is partly new, in that it now shows enemy upgrades. It used to show only the player’s own upgrades.

One twist with the upgrades mode is that it shows only enemy upgrades that the player has actually seen. It’s quite possible for enemies to have better upgrades than the player knows about, hidden behind the fog of war. Until you actually spot a unit or building that has an upgrade, it doesn’t show up. That way you can never be quite sure what kind of advances your enemies might have, until you’ve forayed deep into their territory.

I used to try to show information from both the selection and upgrade modes on the hud at the same time. But there wasn’t enough screen real estate, and it was too visually complex. The user now switches between the two modes using the TAB key.

New unit/building portraits.

The 2-D unit/building portraits are now generated automatically from their respective 3-D shapes.

This is nice from a development standpoint, because it allows me to revise the 3-D art without worrying about updating the portraits. It also means a smaller download size, since the game won’t need to ship with portrait image files (they’re generated at run-time, in-memory).

This feature still needs some work; for example the units’ weapons don’t show up yet in the portraits.

Building fire

Buildings now catch fire when they’re damaged.

I actually had this feature in the game a long time ago. Originally, it required network bandwidth to work. I tried to remove that requirement and make the fire be client-side-only, but it stopped working. It turns out that Torque needs to be explicitly told when an object is client-side-only, otherwise the object won’t render. That was the problem in the case of my fire. I’ve fixed it now and the fire is working again.

In case it helps someone else, the fire is implemented as a standard Torque ParticleEmitter. The fix to make it client-only was to set its ScopeAlways flag, and to clear its Ghostable flag. That’s basically all there was to it.

Robot damage

Martian robots now emit oily smoke when damaged.

This uses the same client-side ParticleEmitter approach that building fire uses, so smoke also requires no network bandwidth.

Overkill limiting

Ever get annoyed while playing an RTS, because a hundred of your units fire at the same target, and don’t shoot at other targets in the same vicinity? The first target gets oblitterated, and then you have to wait for all your units to reload again. Meanwhile, your units get pelted by return fire from the other targets that are still alive. When your units do reload, the same thing may happen again.

OVM now contains A.I. code to prevent this. As soon as there’s ample firepower headed towards one doomed target, your units that haven’t fired yet will automatically select other targets. This helps spread out your units’ fire, making them more effective. This feature is especially helpful in large or lopsided battles.

By interesting coincidence, I ran across an internet discussion of this issue just after I started to implement the A.I. in OVM to prevent it.

Visible carried resources

Resources carried by workers are now visible.

Right now I’m just using a placeholder 3-D model to represent the resources (a backpack). For release I’ll use something more accurate, like logs and/or stones, which is what resources are in OVM.

Game tips

The loading screen now shows a game tip while the user waits for the game to load.

There’s also an optional tip window at the start of the game. This window allows the user to cycle through the tips, and to turn the tips off.

The user is also now able to pause the game and get to the tips, via a help sub-menu.

Tabbed options

The options dialog now sports the look of a tabbed property sheet.

Auto-groups!

Orcs vs. Martians can now automate assignment of hotkey groups! The user simply tells the game which types of units & building to assign to the different group numbers. The game will then automatically add new units / buildings to those groups, as the units / buildings are created in the game.

I really like this feature. It’s yet another way to reduce RTS micromanagement. I haven’t seen this idea tried yet in any other RTSs I’ve played.

About dialog.

The game now has an “About” dialog.

The credits window self-scrolls. Even to do something as simple as that, though, I had to add code to Torque’s C++ GuiScrollCtrl class. Torque’s gui control classes are pretty bare-bones, IMO. They implement just barely enough functionality to satisfy what a typical first-person shooters might need; do anything beyond that, and you’ll need to extend the gui classese yourself. But, I’ve found their implementations to be pretty straightforward and easy to work with, so it’s not a big deal, it’s just always a little extra work.

Demo mode

The game now has a demo mode, in addition to the full mode. The demo mode limits some features until the user purchases the game.

I also added in some simple copy protection.

Nag screen

The demo mode now shows a nag screen when the game exits. This is the notorious screen we all know and love that makes a sales pitch for buying the full version of a game. I don’t actually have the screen drawn yet, but there’s a placeholder for it and the code is implemented.

Pre-release expiration

Pre-release builds of the game now expire after a certain date. The game then gives a link to the RedBrickGames.com website, so a user can get a more recent build. These kinds of features are boring to work on, but they need to be there.

Replays

The game now supports simple replays.

Replays are available immediately at the end of the game (well, after the data is streamed down from the server, they are) without having to exit out to the main menu. Players can watch the replay while still connected with the other players, and can chat about the replay in the chat gui.

Game setup

I’m in the process of revamping the game setup screen for ease-of-use.

The ping bar-indicators on this screen now work! Torque really shines here - the ping bars turned out to be easy to implement. Torque already maintains a list on the server of all the client network connections. It’s named ClientGroup, intuitively enough. Each element in ClientGroup is a GameConnection object. Those objects have a getPing() method on them, and Torque does all the work in computing the ping. So all OVM has to do is periodically poll the GameConnections for their ping, and then draw the ping indicators.

Posted in General, Torque, TorqueScript, A.I., Networking | No Comments »

Pedernales

Tuesday, May 15th, 2007

I recently went hiking for the 2nd time in Pedernales State Park. Beautiful place.

There was water nearly everywhere. It was coming out of freshwater ground springs all over the place, which was really neat.

I’m surprised that the Perdenales area was never really settled in the frontier days. With freshwater springs that abundant, you’d think it would be an attractive place to settle.

Here’s the World’s Smallest Spring, as designated by Me. This little hole was smaller than the diameter of a dime, and was in a shallow stream bed. It was jetting up a little fountain of water that rose about 1/2 inch above the stream’s surface. It reminded me of a drinking fountain.

Wildflowers.

Back on the subject of game development, I’m finishing up the HUD improvements I mentioned in my last post. I’ll post some screenshots in a while. Another task I’m working on is a resource for the Torque game eninge. This resource will allow a Torquescript programmer to add billboard detail levels to any DTS shape that doesn’t already have them. I’m really excited about this resource, as it could be very helpful to a lot of people. Billboards are a neat feature of Torque DTS shapes, but they seem to be under-used, for various (quite legit) reasons. Hopefully this resource will make billboards much more accessible to a wide swath of Torque developers.

Posted in Torque, TorqueScript, Life | No Comments »

Game results screen

Saturday, August 26th, 2006

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.

Posted in Torque, C++, TorqueScript | No Comments »