Reverse "Defend the Castle" Problem

[Skye McCloud]

Before I get into this post, this is more so for me to find an approach to a problem (along with things I should look at to help me, such as classes) than it is for me to actually solve the problem. My mind, she draws a blank on how to go about coding this.

You ever played those "Defend the Castle" games? What I'm making is sort of a reverse of that. Rather than defend it, you choose one person from your army. The goal is to see if they live or die. If they live, you win. If they die, you lose.

Now, unlike Defend the Castle games, this isn't at an angled view. That is to say, you don't get a view that allows for the army to have a range of areas along the y-axis and only need to just travel from left to right. Instead, the view is directly on the side. When playing, the army has to traverse a terrain (which can go up and down) and properly follow the terrain as it travels from left to right.

This is what I'm trying to figure out: How do I make the entire army follow this terrain, and even make the army look a bit more real with forces spread out along the x-axis during the march? I already know my approach to dealing with the rest of the game, but this has me stuck.

Note: I'm not looking for a huge length of code. I'm moreso looking for ideas on how to work with it, with suggestions of what I can look at to make sure things work right.

[sphoenixee]

One way I can think of doing it to to use a hit test, with hitTestPoint/hitTestobject likely.

Say you have the terrain and a tank. The tank defaults to going horizontally straight. Every frame you can call a hit test. You always want the some points bottom of the tank to hit the terrain (that way tank is on terrain). However, you do not want the inside of the tank to hit the terrain (unless maybe the enemy mage launched a spell or something XD). If the inside does hit, then you want to change the angle of the tank to follow the terrain (I assume this is what you meant; let me know if I misunderstood).

Now the thing is that the terrain does not have uniform angles. So you could change the angles in increments of let's say 5, and then predict if the angle you changed to is good using hitTestPoint (you would predict before tank moves,).

Also, you want to make sure the bottom of tank always on terrain. If it's not, then you do the angle changing with hitTestPoint prediction.

My disclaimer: I have never done this before; I have never made graphical games (only simple old school BASIC text games on the calculator) before. I'm only guessing hopefully it's a good one

Best of luck. Let me know what you finally decide on/if this works or not.

[Skye McCloud]

This was... what I had first guessed I'd have to do. Basically, to just have the bottom of each soldier just adjust to the height of the terrain. Problem is, based on previous work I know this isn't simple. Using a simple hit test won't work, as it will always be true until they hit the highest peak of the terrain. I have to do it with bitmaps.

I wanted to avoid doing that, to hopefully try a new approach, thus this topic.

I only make the barebone games. The graphics are added by someone else, then it's sent back to me to fix code.

[neznein9]

Depending on the style, you could make your ground out of bezier curves...if you did it programmatically, you could use the same coordinates to position your guys along those curves and using the bezier formula would add natural easing that would space out your guys (bunched up in the valleys, spaced out on the hills)...you could even use Tweener or TweenMax to handle all the work for you.

[Skye McCloud]

Depending on the style, you could make your ground out of bezier curves...if you did it programmatically, you could use the same coordinates to position your guys along those curves and using the bezier formula would add natural easing that would space out your guys (bunched up in the valleys, spaced out on the hills)...you could even use Tweener or TweenMax to handle all the work for you.

Ok, I'll start with the obvious: I have no idea what bezier curves are.

My concern is more how the army moves along the ground then getting the actual physics of it right. I'm just at a loss for how to make them all move in a way that won't be heavy on processing and yet will move them as I need.

[neznein9]

Sorry, Bézier curves are when you use a point to 'pull' an otherwise straight line into a curve. This article explains it much better.

You could potentially line up a bunch of curves like that and use this formula to move your guys along each segment:

ƒ(x) = (1 - x)² • A₀ + 2x(1 - x) • C + x² • A₁

0 <= x <= 1 (ie. % of the way from A₀ to A₁).
A₀ is the x or y value of the first anchor
A₁ is the x or y value of the second anchor
C is the x or y value of the control point
This equation works for both x and y position

Or take a look at TweenMax - the demo on the page lets you add curves directly into it.

[Skye McCloud]

It really does sound a lot more complexed than what I'm looking at.

I'm not really looking for something complexed. A simple idea works good too.

[joshstrike]

Well, you're just moving them left to right, and on the y axis they just need to be at the level of the ground...right? So hitTest should work okay; you move them right first, do a hit test, and then move them up to whatever that crossover point is...no?

[Skye McCloud]

I had a similar thing for a different project, and hit test doesn't work. The reason why? A simple hit test will consider the transparent areas as a hit. This means it'll just go to the top of the terrain movieclip, even if there is nothing there. You have to do an extensive bitmap hit test. On one soldier, it might be ok, but when I hit, say, 60... it ends up being very intensive on processing. At least, that is my assumption. I'm gonna have to test it first, but the entire thing looks to be processing heavy.

The best idea I could think of that wouldn't be like this, I doubt it's possible. I was thinking of trying to use motion guides, where each soldier is placed on a different motion guide (which only has a slight variant to the other guides) and they follow the guides. I've used guides in pure animation before, but I don't know if they can be done with ActionScript.

[Skye McCloud]

I wanted to add, I tested the bitmap hittesting I mentioned in my last post. As I thought, it's far too processing intensive to be of any use. After a few of the soldiers had been entered to be checked, the SWF slowed drastically and got worse as time went on. To give an idea, I use a timer that goes every 10th of a second, used to keep track of time. Normally, it works fine. When the hit testing was applied, about three or four seconds into running the slowdown would cause it to take take an additional real-life second before the it would recognize as one second had gone by. About 10 seconds in, it took around 5 seconds for the SWF to process one.

I'm still looking into the motion guide idea, but I've not had much luck searching it up. Anyone have an idea by chance?

[joshstrike]

Well, what about this...
every pixel of the ground level has a certain height, right...and those could all be in a 1-dimensional array. You could use that array to draw the ground, and then knowing the x-position of the soldiers, you could check just that number in the array and know what their height should be. That should be really fast...

         ----
 ---   -
-   ---

var groundArray:Array = [0,1,1,1,0,0,0,1,2,2,2,2...]

If you want to freehand the ground first then you need something at the beginning of your code that'll take that drawing and fill in an array like this with the ground level pixel for pixel; once you have that array, though, it's just a hash table lookup and not a hit test at all. In other words:

soldier.y = groundArray[soldier.x];

simple as that...

Josh

[neznein9]

When the hit testing was applied, about three or four seconds into running the slowdown would cause it to take take an additional real-life second before the it would recognize as one second had gone by. About 10 seconds in, it took around 5 seconds for the SWF to process one.

That sounds like a memory leak problem...once you have code running it shouldn't slow down unless you're running up a bunch of memory.

Additionally, if you want to do hitTesting, try giving your soldiers a pixel (ie. the center of their foot or something) so you can do hitTestPixel.

[Skye McCloud]

Well, what about this...
every pixel of the ground level has a certain height, right...and those could all be in a 1-dimensional array. You could use that array to draw the ground, and then knowing the x-position of the soldiers, you could check just that number in the array and know what their height should be. That should be really fast...

         ----
 ---   -
-   ---

var groundArray:Array = [0,1,1,1,0,0,0,1,2,2,2,2...]

If you want to freehand the ground first then you need something at the beginning of your code that'll take that drawing and fill in an array like this with the ground level pixel for pixel; once you have that array, though, it's just a hash table lookup and not a hit test at all. In other words:

soldier.y = groundArray[soldier.x];

simple as that...

Josh

That could work. I'll certain have to give it a try. It'll be somewhat annoying, though, with an array having a length of... oh... 500 or so.

I'm actually looking up how to use Motion to Actionscript 3, since I hadn't even heard of it until a few hours ago and I may have a possibility of making it work. I'm trying to figure out how I can utilize it for multiple movieclips and yet retain the uniqueness of each MC.

That sounds like a memory leak problem...once you have code running it shouldn't slow down unless you're running up a bunch of memory.

Additionally, if you want to do hitTesting, try giving your soldiers a pixel (ie. the center of their foot or something) so you can do hitTestPixel.

As far as I could tell, I didn't see a memory leak. I'll make a second check. I will note, I ran this on a fairly new (Two months) laptop, with virtually all of my memory being open for use. I was surprised at the slow down. However, I believe it was you who told me using a bitmap hittest (So that transparency in a movieclip wouldn't be considered a hit) was a bit heavy in regards to processing anyway. If not you, then someone else, so I was not surprised by this.

Edit: Odd. I no longer get the slowdown, but now at some point I get an infinite loop. Not sure what the cause of it is.

[neznein9]

This helps with mem leaks:

trace('Memory: ', System.totalMemory/1024/1024.toFixed(2), 'Mb'); 

[Skye McCloud]

That is AS3, right? Odd, doesn't work. I run it and and I get:

Syntax error: expecting rightparen before toFixed.
Syntax error: expecting rightbrace before rightparen.

neznein, do you know anything regarding the new Motion to ActionScript 3 that Adobe added to CS3? I actually learned about that yesterday and I'm trying to see if I can find a use for it.

[neznein9]

Sorry, I forgot some parens...

import flash.system.System;

//  ...

    trace('Memory: ', (System.totalMemory/1024/1024).toFixed(2), 'Mb'); 

As far as the motion stuff, I've seen it demoed but I've never had a need for it myself...it strikes me as kind of gimmicky (like timeline effects in MX, or the Behaviours panel)...as I understand it, you make a bunch of motion on screen and it's captured as a huge array of transform data...I think you're better off using joshstrike's method or working out a hitTest...

Can you post a copy of your terrain? Or at least a black and white hit map of it so we can see roughly the shape you're dealing with?