I'm just toying with this idea for now. Let's assume we're talking a potentially arbitrary number of physical objects (represented as units) here. There'd need to be a per-unit data storage for angle and velocity: Two numbers for angle, one for velocity. And that's not even going into fancy crap like spin, z axis, and shit like that. Lots of that pixel-precise detection stuff and trigonometry maths and shit, too.

I figure a stack of burrowed markers under physical units of sufficient size (they'd have to be fairly large I'm going to think) could store some data, assuming game rules prevented them from moving too close to each other. More creatively, a single marker offset from the center of the physically-simulated unit in the direction it's traveling could be used to store its angle (or two markers on either side for a longer, more precise line), though that'd take some extra work to grab angles for each unit. Velocity could either be the length of the offset marker from the center of the unit, or a stack of markers under the unit to store the number. Or both together, more likely. I can't see DCs being suitable for storing this data on a per-unit basis, though.


However, with a way to uniquely address specific units on the map for physical simulation, angle and velocity data could be stored externally (not physically with the unit itself, I mean... like as a stack or configuration of burrowed markers somewhere outside of the main play area), which'd make things a tad easier, more flexible, and less error prone. I don't fancy consuming unique burrowed unit types or individual locations per unit, though. Though I doubt I'd see any reasonable gameplay applications using more than a dozen physical objects, so it probably wouldn't be a disaster. If each unit could externally track its grid location, too, I could work around a few more limits perhaps and squeeze off a few more units to be simulated, but I don't think it ought to matter after a certain point. Simulating more than a few concurrent objects with collision detection and all that would probably bring Starcrap to a crawl, anyway.


I dread that collision detection part, by the way. Let alone the actual physical interactions thereafter. It'd probably take two whole game ticks at minimum just to render one frame of physically simulated movement, or else tens of thousands of triggers to squeeze it into one.



Anyway. Does this sound about right?

Post has been edited 5 time(s), last time on Jan 9 2010, 7:07 pm by Tuxedo-Templar.

I've actually been throwing around the idea of a physics engine for some time now (but I'd never be crazy enough to make one ).

I thought about it a number of different ways, but the idea that seemed most plausible to me was doing everything virtually and then projecting that virtual world as accurately as possible on the screen. I think the easiest way to do the velocity itself would be through extremely precise parametric equations (probably even more precise than a pixel). Acceleration equations would be much trickier. You'd need to get the slope from point A to point B, find the force of the interaction, and add/subtract that value to the parametric x and y (AND Z?!) equations. Since everything would be virtual, it wouldn't lag the map as much (not all that many physical things going on, just raw numbers).

I basically have no idea how you'd do angular velocity, force, and acceleration, though.

Well, MacroTriggers or something similar will pretty much be a MUST if you plan on pulling this off

Virtual everything? Argh.


Yeah. Fuck this idea. It's fun to think about, though. And definitely not impossible.

It would pretty much need to be. Replacing and using burrowed units for storing information would be the primary contributor to lag if it was done that way. There are 10 unique burrowable units types (including spider mine), assuming you devote only neutral player (P9-12) units for it, that gives you 40 bits. A single deathcounter is ~31 bits, per player and is far more accessible.

Even without bringing friction, slopes, and range/parabolic motion equations into this, you're dealing with some gnarly death count work. That's not to say it couldn't be done - in fact, a 20x12 test map that allows you to set the initial height and velocity for a bouncing or rolling object might be a good undertaking, just to see if it's possible.

Table hockey in SC would probably be the simplest game to start with.

Yep. Ping-pong would be the logical second step.
...yes, that was sarcasm...

One could make a pong game without bothering with vector math at all

You could also create some simple Ai for a 1 player option, where the enemy pong paddle just moves towards the y position of the ball.

What gets more complicated is movement that simulates parabolic pathing, which is probably what you mean when you say ping-pong. A just plain pong game would be pretty interesting to see made though.

You could even create, for a pong game, Ai the detects where the ball is going to pass the enemy lines assuming that the math is done virtually, and there are limited angles of direction in which the ball could travel.

There was a map that drew parabolas out of mutalisks or something like that.

I thought about pong, but decided it wouldn't be as fun as table hockey.

One could use the markers, however, to associate physics with an arbitrary unit. A kind of "Hey, grab any unit you want to, drag it onto the Beacon, and give it physics!"

As for collision detection, if you decide to do something more advanced than a hitbox, then you'll want to use the Separating Axis Theorem. Wikipedia and Metanet (the creators of N) do a decent job of explaining it, but I think that this explanation is simpler... (It took a WHILE for the Metanet explanation to finally "click" for me, but that could just be because I suck at math...)

When you check non-rotating bounding boxes for collisions, you check for overlap on the x-axis, and then on the y-axis.

Well, when using SAT, you work with each surface of the two polygons you're checking, one at a time. For each surface, you

• Think of the surface as an axis.
  
• "Flatten" the objects along that axis.
  
• Check for overlap on that axis.
  

If there is even one axis that doesn't have overlap, then you've found a non-collision -- stop the comparison, and start checking the next two objects.

'Course, this leads to the problem of keeping track of polygons for each physics-possessing object. One could simplify this by using the same non-rotating bounding polygon for every single object. (E.x. a non-rotating regular octagon.) There's also the problem of having to do this in StarCraft triggers with death counters. I mean, you'll need entire binary countoffs just for basic arithmetic! I can't even imagine that in MT (though that could just be because I suck at MT)!

And as for responding to collisions (realistic ricochet, accounting for differing velocities and trajectories at the time of collision)... I have no idea. But from a programming standpoint, if you can get SAT working in SC, you can probably get this working. (Assuming that you either know how already, or can find a guide that's written in English -- rather than the overcomplicated and bastardized dialect that a typical textbook is guaranteed to use.)

Cool.



Oh please. MacroTriggers or TriggerScript or any other trigger abstraction tool could make short work of DCs. To an extent, of course.

In fact, seeing how easily I've managed to import and modularize some of my old updated math functions already...

Yeah, then you end up with an ungodly number of triggers if we're still trying to fit this into a single trigger tick. That wouldn't even be a speed bump with something like MacroTriggers (probably easier, in fact), but I don't think there'd be enough counters available for more than a few dozen physical objects.

But I guess with burrowed shit the lag probably would preclude too many objects anyway, but I'd have to actually attempt it to know for sure...


Naw.

Post has been edited 5 time(s), last time on Jan 10 2010, 6:52 am by Tuxedo-Templar.

The map that stickynote was talking about, is called Projectile Plotter. I haven't looked at the triggers too much, but it can graph parabolas on starcraft and it only has 57 triggers (Thanks be to MapStats). It detects velocity and angle. If anyone wants this map PM me, I don't wanna host it here and have it say 0 hits for the next 3 years.

just incase anyone is still reading this, and sorry for double post, you could find unit acceleration using Inverted locations and use that to simulate gravity or velocity or w/e.

Pyro682's idea, not mine.