Nerds Make Science Fun!

As I mentioned in my previous post, I’ll be posting a little bit at a time about my ideas for an RTS.

Also mentioned in the previous post, an RTS with mobile bases would be difficult to balance. For me to explain why, I have to explain proxies.

Keep in mind that, unless otherwise noted, I’ll be discussing Starcraft: Brood War for most of my examples.
It’s an RTS with simple rules but incredible depth, and it’s the one I’m most familiar with. While games like Dawn of War have extra mechanics like cover, I plan to model my RTS after Starcraft, to a degree, because the simplicity of Starcraft’s rules has also led to that much more creativity. If you really feel unfamiliar with Starcraft, or want to find more information than the bare minimum I’m putting here, visit the Teamliquid Starcraft Wiki.

In Starcraft, you’re “expected” to place your tech buildings and your production buildings inside your base. That’s the safest place for them, and it consolidates all your stuff in one area so that whatever unit you’re using to build them won’t have to run too far out (unless you’re zerg, in which case your builder morphs into the building), and it lets you focus on one area of the map whenever you want to crank out another round of units.

The text below the page break is an enormous aside about proxies. If you want to read it really badly, click ‘more.’

Anyway, back to the main point. If you think a bunker rush is scary, imagine this. Your crawler is a colossal mobile unit with a passable attack. The current mechanic for it has it able to move, attack, and produce units at the same time. (This was not the mechanic used in C&C 4, though. There, your crawler would have to unfold into an immobile building with no attack while it pumped units.) So, you pick the faction with the units that are the fastest to produce. As you’ll see in my later posts about the available factions, this will be modeled heavily after the Starcraft Zerg. To avoid lawsuits, (Hah!) I’ll call this the Swarm. So you take your Swarm Crawler and march it toward the middle of the map, producing units all the way. As your units pop out, you send them to every part of the map to scout your opponent, who is likely teching to the next available unit (the poor sap, he’ll never see it coming!). By the time your hulking crawler makes its way to the enemy crawler, you’ll have a small but scary force of Swarm units, while your opponent has not made the best use of his production time. Your units outnumber your opponent’s, so your crawler’s HP will have a slight lead over that of your opponent’s crawler. Eventually, after a battle of attrition your crawler comes out on top. Your opponent’s only defense is to do exactly what you are doing, and that makes for a boring game.

I’ll admit, C&C 4 did a good job of preventing this sort of cheese. Since you have to turn your crawler into a building to create anything, this kind of rush is just out of the question. If your opponent tries to rush, you turn your own crawler back into its unit form to give your army the upper hand. However, this honestly feels a bit stiff to me. I want a crawler that can reinforce on-the-fly. If the crawler can move, but not attack, then you’ll run into problems when your units are produced piecemeal and lack the crawler’s support.

My favored solution is to have the crawler able to attack, but not move - or move really slowly - while it produces units, and be completely helpless when researching tech. This would force the attrition rush to be made with an inferior force, while the opponent would be able to flee if you insisted on parking your crawler nearby.

Rushing is still an option. If you gain an understanding of the timings of the game, such as when a certain unit is slated to appear, you can in theory create a large force and attack your opponent while he’s halfway through researching some powerful tech, forcing him to cancel his research to defend his crawler and delay his tech. Since time is the only resource in this game, it could be a major setback. The crawler’s function will have to be determined through extensive testing, but for now, this seems to be the option that can provide the most tactical possibilities.

(more…)

Lo, and did Blizzard get off their lazy rears after a decade of waiting and make Starcraft 2, and did they release it on July 27

So this would probably be a horrible time to discuss any other RTS. Which is why I’m doing exactly that.

The one I have in mind is Command and Conquer 4. I heard about it from a friend, who is a big fan of the C&C series but hated that game on sight. His biggest gripe with it was its MMO-like format. As you play online, you gain experience points, which you spend on an upgrade tree of sorts. He knew he hated it just for the MMO part. When I found out more recently that C&C 4 did away with resource gathering (Tiberium can now either be used as a bomb or redeemed for upgrade points), and that your main base, a mobile crawler, respawns if killed. From what I gleaned off the Wikipedia article, the win condition isn’t army annihilation, but keeping control of a number of control nodes.

While I agree with my friend that combining an MMO (Massively Multiplayer Online) with an RTS (Real Time Strategy) isn’t a good idea, and I agree with other people that respawning in an RTS just feels wrong, I think the idea of a mobile headquarters has promise.

When compared to a traditional RTS, a mobile base would bring drastically different gameplay. I’ll be using Starcraft: Brood War as a basis for comparison. A mobile base would do away with resource gathering by necessity of map design; having resource deposits everywhere would clog the map. You’ll only have one base, so there would be no point in moving it to a new location until your current resources run out.

A mobile base RTS would bring more focus on scouting, map control, and army composition. In Starcraft, once you locate an opponent’s main base, you could generally keep tabs on them by hovering an observer (cloaked scouting unit) over his base or using a comsat (radar) scan every once in a while. Of course, there are some exceptions. You’ll have to keep tabs on where your opponent is expanding by periodically running a fast unit around the map. A Protoss or Terran player can hide a tech building in some corner of the map, hoping to catch the opponent by surprise. A Zerg can put a building at a less-defended expansion, where it serves a dual purpose of hiding the tech and possibly clogging an entrance into the base.

In contrast, against a mobile base, you can’t get complacent about your scouting. After you’ve seen the opponent’s base, he can pack up and travel across the map, and you’ll be left in the dark if you just go back to the same spot.

Balance will be difficult, but that’s something that playtesters or developers can work out.
I plan to make some sort of RTS like this as a summer project, or at least once I’m done with college apps. For now, I’ll be coming on to post more concrete ideas I’ve had that I’ll probably wind up implementing.

First update it forever. Isn’t that wonderful? I’m sure you’re all dancing with joy.

Anyways, here’s what we’ve got this time:

A wonderful powerpoint made by me detailing the work I’ve done this summer! Enjoy!

Slides for SIMR

William

“To the programmer he said, ‘I will make you incompetent during the worst possible moments. It will take you hours to find and repair trivial errors.’ ”
-Programmer’s Bible: The book of Assembly Code, 3:16

Oh, how true it is.

For a few hours today and the better part of last night, I’ve been working on a program to calculate a line of best fit. It was a code exercise that took much longer than it had any right to.

It’s not that the code itself was difficult. I use Visual Studio for my C# code, so I got the window and controls set up fast. The line of best fit can also be calculated analytically. Just find the formula for the least-squares error, take the partial derivatives of A and B, and solve the system of equations. My code worked perfectly fine for solving the problem and spitting out A (the slope) and B (the y-intercept).

The problems came up when I tried graphing stuff. First, I found out that the computer counts pixels from the top left, while I want the origin at the bottom left. But when I reflected the drawing vertically about the y-axis (the transformation was NEW Y = HEIGHT OF WINDOW - OLD Y), all the points disappeared. I had the help of my dad, and we spent about two hours staring at the code and getting nowhere.

Here’s the breakdown of what I did with that chunk of code today:

5 minutes: Figuring out that HEIGHT OF WINDOW should have been HEIGHT OF THE PANEL WHERE THE GRAPH IS ACTUALLY DRAWN, WHICH IS LIKE HALF THE SIZE OF THE ENORMOUS WINDOW ITSELF. Now there’s your problem!

5 minutes: Suddenly realizing the old code only showed a fifth of the data points and that now I’ve got 100 more to deal with.

20 minutes: Wondering why the edge of the graph kept getting cut off and changing the size of the points on the graph to see why. Turns out that the data just happens to have a lot of points congregated to the right.

10 minutes: Wrestling with syntax and about a dozen sets of parentheses to draw a y-axis.

10 minutes: Figuring out a way to expand the boundaries of the data set without having to worry about signs.

10 minutes: Wondering why my attempt to draw the least-squares regression line doesn’t show up on the window.

2 minutes: Adding 0,0 to the data set to force it to be included in the graph, then seeing the outlier skews the line way off.

3 minutes: Removing 0,0 and changing the graph range manually. Oh, looks like the outlier didn’t do much for the data anyway, and the line is off entirely.

15 minutes: Trying various fixes before noticing that it’d be best to remove the flip-by-y before making changes, since the flip complicates things.

5 minutes: Rewriting the line of code that draws the graph and remaking the arguments for the function from scratch. No dice.

20 minutes: Various remedies, all of which fail miserably, before sitting down to think and realizing that expanding the graphing range messes with the scale, so I need to add a few correction terms in to shift the line back.

5 minutes: Code-wrangling, which finally gives a line that works.

5 minutes: Drawing an X-axis.

Total time elapsed: 1 hour 45 minutes on a really short piece of code, plus the 2 hours from last night, plus the half an hour I used to write up this article.

Man, where’s the Ballmer peak when you need it?

-PKTT