Hey everyone. I've got my map a little over 50% complete, with most of the ideas and concepts taken care of. The only thing I'm running short of is the final ideas for the map and actually finding the time to put it all together.

I'm looking to ask the community a few questions about EUD's and maybe for a little feedback on whats been done already.

The link to the actual map production thread is here: http://www.staredit.net/topic/9701/

There are a few questions at the bottom of the first post for the map that I'd like answered by all you wonderful mappers out there . I'll post what I need talked about here, but there are more questions in the original post (Map Production) that you can look at if need be.


Questions to be answered:

1) Should I use a location grid system to enhance the visual appeal and overall gameplay when spells are cast (Similar to that of Temple Siege) ?

2) Should I create a visual aid to show how much damage an enemy has taken (The Damage % at the bottom of the screen during the real game) ?

3) Should I keep the map as six players, or should I reduce it to four players (like the real game) ?

4) A character knockback system based on the damage already taken by a unit (not sure how i'd do this, but it has been suggested before... still not sure..) ?

5) Should the characters pause when using a special move (similar to casting a spell) to show that they actually have to stop to cast something (to create a real effect) ?

Post has been edited 1 time(s), last time on Apr 18 2010, 5:53 pm by atto. Reason: ugh... always the grammar haha

Location grids and the application of them are no doubt the most difficult and complicated parts in mapping, the only mapper I've ever seen use them well besides me is Lethal_Illusion. For something like typical WAF-style spells you're way better off sticking with mobiles.

A knockback system similar to the original SSB would give a bad-ass effect and it is possible really, but you have to understand multiple difficult concepts, to name a few: location grids, unit coordinate detection, death counter multiplication and division, simple linear math. There is little extensive documentation on these, so if you truly want go through with it just tell me and I can attempt to teach you how it would work.

Post has been edited 2 time(s), last time on Apr 18 2010, 6:24 am by yoonkwun.

Well first off yoonkwun, thanks very much for the information needed to apply to the game itself. Secondly, I would indeed like to make knockback and a good location grid system for the "spells" (really they are just special moves, like Up + B for example) a reality because I've been working on this map passionately for around four months now. If you could guide me firstly through location grids, it would be immensely appreciated.

I just had a thought on the knockback system. Although I do agree that adding in a knockback system would be completely badass and possibly the first map to have done so, I think there are problems we should consider first.

When reading all the EUD tutorials yesterday, I came across EUDs that force players to desync from the game and essentially drop. I'm hoping that all the EUD concepts you have listed would not require any of these actions that force players to drop because I don't want this map to turn into a disaster after four months of planning and debugging already.

One thing I would like to ask you however, since you seem to be inclined with EUDs:

If I were to implement an HP detection system, would I have to create EVERY trigger for EVERY possible player and character?

I think this might need an explanation, so here it is:

- When a player starts off in the game, they choose a character.
- Only one player can have one character due to trigger and location limitations of the game.
- The map locations are already designated for a single characters use only, not multiple uses (just to keep things running smoothly without bumping into each other)
- Currently there are a total of 6 players and 12 character so choose from.

So, to reword my question:

Would I have to create an EUD HP detection system for every value of HP on every character (Currently everyone has around 1000 hp and there are twelve characters) ?? From my understanding of EUD HP detection, if I wanted a system to detect every drop in HP, I would need 1000 triggers for a unit with 1000 HP, and there are twelve units in total, so 12,000 triggers.

From a perspective of players, I'm assuming that each player would have to have EACH EUD triggered to themselves, so that adds up to 12,000 X 6 = 72,000 triggers.

Now when I actually do this math, it seems like "WHOA!!! THAT CAN'T BE RIGHT !!!", but I'm a virgin with EUD's, so I could use some explanation on this topic as well (If your fingers aren't too tired after trying to explain location grid systems haha).


To clarify some of the things I would want with an EUD HP detection system:

1) Must be able to detect EVERY drop in HP and display it (even if it drops a single integer at a time) for every character that is being used by a player.

2) Must be able to be displayed in either the leaderboard or on the map itself (similar to the DBZ RX-* games with the clock system at the bottom).

Post has been edited 1 time(s), last time on Apr 18 2010, 6:22 pm by atto.

I should have clarified when I said 'unit coordinate detection' because I meant using a non-EUD method such as http://www.staredit.net/189419/ or "unit scanning" like in Elementa. So you don't need to worry about desyncs in the knockback system.

As for the EUD HP detection, it all depends on the implementation. Remember that you're detecting a value on the unitnode structure of a particular unit index (that's what SCMDraft 2 calls it anyway), so that means the player of the unit doesn't matter. Just to clarify if you don't know the concept of the unit index, each unit in a StarCraft game is assigned a unique unit index regardless of the player. So the first unit placed on the map by StarCraft is assigned the unit index 0, the second unit placed is assigned unit index 1, etc. Your EUD HP detection trigger will detect the HP of a particular unit index, so it's not like you're detecting the HP of "Terran Marine owned by Player 4" or something like that. Here's where a problem arises though, let's say the player chooses his character and his unit is created onto the main arena. There's no trigger-efficient way to detect the unit index of this unit, because you never know if someone else already had his unit created or something else in the map created a unit so the unit index of the character is unknown, basically. Also if you want to make the character revive at some point, his unit index is even more hard to guess because chances are, the characters cast their spells which create and kill a significant amount of units. You may think that, let's say, there's a total of only 42 units on the map, and the next created unit will certainly be the unit index 42, but that is not always true due to how StarCraft works.

Here's a possible workaround. It's based on fact that as long as a unit never dies his unit index will stay the same. So, on the stage where the players select their characters, the units will be next to a beacon or something right? The idea is that when the player selects the unit, the unit is given to the player, and that unit is moved to the main arena and you know for certain which unit index it is (the latest version of SCMDraft 2 tells you this in the unit properties box dialog). Now what about if multiple players wanted to choose the same character? You can have 6 of each unit preplaced and you know their unit index (for aesthetics you can have 5 of them hidden and when a player selects that character, one is moved to the visible area). Another problem is that when that unit dies in battle you can't create another one because you don't know the unit index of the newly created one. A possible workaround is that you can make it so the unit is considered "dead" when it reaches below a certain HP (like 100), then you'd just move it offstage and you still know what the unit index is.

Now, the trigger count of this system alone would reach pretty high considering there are 6 players and 12 characters. Each character would need to be preplaced 6 times to handle all 6 players, so you need to detect the HP of (6 X 12) 72 units, and yes if you want to detect EVERY drop in HP then you need 1000 triggers for each unit if they have 1000 HP (72 X 1000 = 72000). This is considered an unmanageable amount (by my standards), so what you can do is either lower the HP for each unit, lower the amount of characters available, or make it so a character can only be selected once. Making each character selectable only once is probably the best solution in this case, as it would reduce the trigger count to 12000 which is still big, but manageable. With them activated with switches I don't think the lag would be too high, haven't tested it though.

Okay, location grids. The concept of the location grid is quite simple (though making it is not). I think the animated pictures in the wiki entry for location grids really shows the concept well if you haven't already looked at it: Location Grids. Make sure you note the difference between pure and hybrid location grids and most importantly the benefits of location shifting. When I start a map with location grids, first I usually decide what kind of location grid I want with what accuracy, then I'd place the units/locations for that location grid and set up a location placement trigger system using it (not explained in the wiki, and yes I made that term up).

I'll provide an example. I tend to have the main arena in the center of the map with the dimensions either being 20x12 tiles or 20x10 (20x12 is considered to be the size of the visible area of the StarCraft screen including the hidden corner space in the HUD. 20x10 excludes the useless hidden HUD space). I'd usually have alot more accuracy, but for example's sake I'll make the accuracy at 32px (the size of a tile), and I'll make it a hybrid location grid because it saves a ton of locations and in most cases unit count isn't a problem, and I'll utilize location shifting. Now, generally we want to be as location-conservative as possible and willing to sacrifice other things to require less locations. We need to have the unit sequence going either in the X or Y direction, in this setup which would be more logical?




Right, the second one in the X direction because there's more units to cover more space of the arena and therefore less locations required. Now, in the pictures the units are placed in the arena itself to make it simpler, but in real maps you're gonna want them all the way in the bottom of the map or all the way in the right of the map, depending on which direction the units are going in. We want to do this to make full of use location shifting, which cuts our location count in half compared to if we didn't use it.

For the units themselves, they can be any units really, but the most convenient units are considered to be burrowable units because if we were doing a location grid with 2px accuracy, you can't stack non-burrowed units 2px from each other. There are a total of 10 burrowable units including spider mine, but we are going to not use spider mine because it can displace other burrowed units in more accurate hybrid grids (can be avoided though, but for simplicity's sake we won't) and we won't use zerg lurker because it sometimes doesn't fit nicely into a row of terrain. We are left with the eight other burrowable units, and we want to place them in sequential order and I'll discuss why later in the trigger section. Anyways, let's say that we need all 8 playable players in this map, so we don't want to place the units for players 1-8. We can, though, place them for players 9-12. The order that I usually use is to have the first 8 units for player 9 in this order: Zergling, Hydralisk, Drone, Defiler, Infested Terran, Devouring One, Hunter Killer, Unclean One, then have the next 8 in the same order but for player 10, then for players 11 and 12. So in my map I'd have a strip of walkable land in the very bottom with the units that look like so:



You should make use of SCMDraft 2's custom grid and unit copy and pasting functions. Remember they are 1 tile apart because we are doing a 32px grid.

With these units the X axis is covered in terms of the location grid, we just need to cover the Y axis which we'll do with locations that vary in the Y axis. Let's say we want to have a location that places something in this area:



We need to have a really long location whose middle is in that area when centered on one of our units. Also just an observation that the intersections of the 32px grid shown in that picture is a good representation of the points that the location grid will be able to place stuff in. Anyways this is what the location would look like:



So if that location was centered on the zerg zergling for player 9, and you created a wraith at that location, it would create it in the zone I mentioned earlier, you see? Now if I wanted to create a wraith at the square directly above that, I would increase the location's height by 2 squares. If you increase it by 2 squares, the center of the location increase by 1. You would just repeat this process of making locations until you reach the middle of the arena. When you do reach the middle of the arena, you'd notice that the height of the location is the height of the map. So if you wanted to cover the top half of the arena too, you'd make use of location shifting on your previously made locations.

Now you have the hybrid grid completely set up, and it covers the entire arena. Okay, but what use does this have? It only has the potential to place stuff in the entire arena, and the trigger system is what really puts it to good use. Here's how I almost always do my location grid triggers. First off for good practice, I dedicate a switch to the system, and each trigger in the system has a condition detecting if it's Set. I usually name it "_grid". I find it's best to look at the arena like a Cartesian coordinate system, so the most bottom-left of the grid is (0,0). Anyways we're going to need to utilize two death counters, I name them "_gridX" and "_gridY". Now, this trigger system assumes that "_gridX" and "_gridY" are set to the coordinates that we want to place a location in before the trigger system is run.

Okay, I thought I would have the motivation to write all this, but I don't. I've explained the basics so far, and the rest of this can be self-taught using examples and logic. I'll attach a map that I abandoned with what I've explained so far and with the trigger system, it uses a 1px hybrid grid on a 20x10. Another source of reference is my Speed Tennis map, which I think is my best work with location grids yet. I know I haven't even touched on unit coordinate detection and heck even the linear math aspect to it, but try to think critically at how it would be done. A lot of this is better off being self-taught. Sorry if you were expecting a full explanation of the knockback system, maybe I'll write part 2 another day if I feel motivated enough.

Attachments:

Post has been edited 1 time(s), last time on Apr 19 2010, 5:05 am by yoonkwun.

Amazing. Simply Amazing. You need to be given an award, a cookie or at least a cuddle for this. Location grid system are actually very very very simple, and just use a cartesian coordinate system with what we have available on starcraft haha. I can't believe how simple this is.

Oh, and just because you put so much effort and time into this single post (which I am very grateful for), I'm going to correct you on it haha!


I'm sure you can clearly see yourself that this is wrong, but thanks for posting the location grid wiki before you said this. It helped me learn and I'm already correcting on proper terms haha! It should be unit count cut in half, not location count.



Anywho, I've already got an issue. It's a simple fix, but it deals with the map I'm going to be implementing this on. In my map, the area for the battling is not a square shape because I wanted to keep the graphics given to me by SCPM 5.1 to make the surrounding area of the field have a 3D look (on the minimap). The current battling area is a perfect geometric trapezoid shape having the dimensions:

Lower: 94 tiles
Upper: 74 tiles
Height: 11 tiles
Slope (for both sides): 1:1 tile

The shape is essentially this:

.../~~~~~~~~~~\
../-----------------\
./------------------.\
/_________________ \

The real shape is on a much wider scale as you can imagine (94 tiles).

So, I beg to ask the question.... Just simply make the area a rectangular shape? I would intend to use a hybrid grid with location shifting, but the since we only have 4 x 8 = 32 units to use up, I would have to have the locations running along the X-axis with a Y-axis single column of burrowed units. Does this seem plausable?


EUD HP Detection

And a massive LOL @ my calculation. I can't believe I actually got it correct for the most part (72,000 triggers). Doesn't 12,000 triggers seem unreasonable to you at all? I mean, I'm sitting on around 400 triggers already without any location grid system or HP detection in yet... and I'm around 4 months in to working on this. I mean, I may be slow at making maps, but I test along the way to make sure it all works before I move ahead too far.

I would actually only be using a single character to choose from (which is what I have right now) and not all 6 can choose the same character. That just makes things too complex if every player can have the same character with special moves and whatever else.

I think then, the best way to do it would be to recude everything down tenfold so that its much esier to work with. All characters have roughly 100 hp, and deal minimal damage. Another thing I was considering, is detecting the HP when it's reduced by 5, not 1. This would decrease everything by an additional 20 times, making the triggers for HP detection much more simplistic to deal with.

Question: Would the detection of HP by 5's instead of 1's still be useable? Or does the HP detection for only for a specific integer. In other words, can I detect when a unit has lost 5HP or detect its HP between two numbers instead of detecting lets say, the exact number 99? If I can't then scrap the idea of going by 5's haha.


I understand your pain. When I first saw the post... my eyes went wide O_O... But it actually wasn't that difficult to understand. I'd try to save your last post for future use somewhere. I sure as hell would not want to write that all out again. No worries about the other stuff right now, I think concentrating on location grids is a good start for a lesson for today haha.

Post has been edited 2 time(s), last time on Apr 18 2010, 11:06 pm by atto.

Any real credit should be given to Lethal_Illusion, who is as far as I know the father of location grids (much better than me) and whose maps I learned pretty much everything I know about location grids from. If you haven't already check out his maps, to name a few: FRAGS, Elementa.

Anyway, for the location shifting, I'm pretty positive in that it saves you half the amount of locations compared to if you didn't use location shifting. If you haven't already found it: Shift Locations. The idea is that you make locations for 1/2 of the dimension, then use a shift location and re-use those same locations for the other half, essentially saving you 1/2 of the locations needed.

As for your arena, you need to setup the location grid for the smallest rectangle that encompasses the trapezoid, so it'd be 94 tiles x 11 tiles. If you aren't going to implement like a 2px grid then you might as well put the units along the X axis and use the locations for the Y axis, and in that case it'd work out pretty nice location-wise.

You can detect multiple HP values in one trigger with two conditions, At Least and At Most.

Alrighty, that answers a lot of questions about EUD's for Health Detection, but I'm still confused about location grids. Wouldn't it be smarter to just implement a 32 pixel grid? That way everything goes by 1 tile and not a 1/16th of it? I mean, having a location grid system that's that immense is nice, but I don't know if it's needed for this application. Maybe it would be needed for the knockback system, in that case I would make it a 2 pixel grid system, but otherwise, why not make it larger to create less work?

I'm going to take a look at those maps you suggested to see the diferences in grid sizes for the location grid.

I thought that since we had 32 units to use... Players 9-12.. which have 8 units that can burrow (each)... we could only use exactly 32 units? Wouldn't the grid system confuse units on the map if they were placed twice?

Well yeah, for a knockback system I guess you don't really need a ton of accuracy, and you could probably get away with 32px accuracy. For other applications 32px is way too large.

As for the units, there's multiple ways to handle this that I didn't cover. The simplest way I would recommend at first is to start over back at player 9 zergling and repeat the sequence, and since there will be multiple of the same units, you put each "group" of units inside a location and that's how the system would know which one to pick. With a lot of groups this can be sort of location-inefficient, and there's another more difficult method that requires only one location no matter how many groups there are, but it's quite involved. I used this method in the Location Grid map attached above, if you're really curious, with the triggers' comments being prefixed with "skip".

I'm not sure exactly what you mean by "group". Do you mean just like the first tile has only 1 zerling stacked, the second tile has two, the third has three? Something like that?


Edit: I'm not sure I understand your map either. A massive amount of triggers are repeated. Why? It doesn't make sense to have the EXACT same trigger around 30 times. Once is good enough isn't it? lol.

I understood your movement system and the way it's set up. It's probably what I'm going to use as a "cheat sheet" for doing my location grid system, but why do you have triggers that repeat. The condictions, actions and everything are all the exact same.

Post has been edited 1 time(s), last time on Apr 19 2010, 2:14 am by atto.

I'm curious; was the wiki article I wrote for Location Grids enough or did you need yoonkwun's example to understand? I ask because I want to know if I need to make it more comprehensible.

Actually, the wiki you wrote was amazing. I'm starting to pick up on some terminology and the way that location grids are talked about now. The pictures helped the most. Large words jumbled up in bunches often confuse even the most sophisticated individuals. You broke it down nicely. Great work.

yoonkwun's example was just a nice refresher really for me. After twenty minutes of careful reading, he had a post waiting for me with the example you're talking about, but I felt as if it was the same thing repeated, just a much much shorter version. Both your and wiki and yoonkwun's examples have helped me understand a lot so far.

The only thing I'm having trouble with now is understanding yoonkwun's method of using "groups" because all of the examples that you gave in the wiki only show how location grids can be done for approximately 8 units used by 4 players (9-12) if you have all the other game's players used up (1-8).

Does this picture clarify a bit?


Which triggers/map are you talking about? In my Location Grid map, the "gridSkipX" triggers are copied alot to know which group to select; I'll explain exactly how it works another day.

Post has been edited 1 time(s), last time on Apr 19 2010, 5:04 am by yoonkwun.

Ahhhhh Yes. Now I see the pattern. Sorry, just the words "squence" and "repeat" did not register with me somehow the first time you explained it. Now that I see the actual squence, it's quite simple to use. Altho, one thing that it a bit confusing is the selection of which group? how in the F would it know that it's on group 1 or group X? I mean, I understand how locations can detect units, but locations detecting location? lol sound a bit weird to me.

Regardless of what I said earlier I decided to half-ass finish up my explanation. Hopefully I'll answer any questions you still have.

Part 2 of my location grid explanation. Okay, I'll pick up from where I left off. So we know that we need a group of triggers, that will do the following: take the two death counters _gridX and _gridY, and place a general-purpose location (I call it gen) onto the an area on the main arena as if _gridX and _gridY were coordinates on a Cartesian coordinate system. So let's say before this trigger system, _gridX was 5 and _gridY was 7. The trigger system runs and does its job, and afterwards the location gen is placed on this area:



Now we'll see what the trigger system actually contains to know how it places the location in the correct place in a hybrid location grid system. We must start with the dimension in which the units are placed, in this case it's the X dimension. Let's take a second look at our units in relation to the main arena:



A couple observations can be made. If you place a location for the Player 9 Zergling, it is placed on the X coordinate of 0. If you place a location for the Player 9 Hydralisk, it's placed on the X coordinate of 1, and it follows the pattern of our sequential order that we chose. So, the first set of triggers in this trigger system will be to detect what _gridX is, and place a location (we'll just use gen) onto the appropriate unit. Here's what the set of triggers would look like:



And so on for each unit. Once this set is complete, we know that gen is placed on the appropriate X coordinate. Do you now see where the "group" fits into this? If we needed to have more than one group, the triggers would look something like this:



Now, for the Y coordinate. It follows the same basic principle really. You'd have a set of triggers that look something like this:



If you're wondering why it's centering on a Map Revealer, it's because a map revealer can't ever be centered on, so it will certainly center ontop of the location gen no matter what. Anyways the locations gridY0, gridY1 etc should be setup so that when they center on gen, the center of that location will be on the appropriate spot on the main arena. The location gen is centered back onto the location so that gen is at the appropriate spot, and the system's purpose is served. Get it? For the dimension with the locations (Y dimension in this case) you should utilize location shifting. The wiki explains it really well so I don't think I need to explain it any further.

This next segment focuses on unit coordinate detection, which is essential for both spells and the knockback system. There's a wiki entry about it: http://www.staredit.net/wiki/Unit_Coordinate_Detection and honestly I haven't bothered to any of the systems in there except "Adjustment to Motion" from long ago and it's a bad method. We're going to focus on the method that I use because we already have a location grid setup, it is lag-free, pixel accurate, and always works regardless of if the unit was moved or not through triggers. There may or may not be betters methods, but I'm 90% sure it's what Elementa uses. It's not documented in the wiki so I'll explain how it works.

I'll cover the theory first. We are going to use pixel accuracy because it doesn't cost that much locations to do so. This is a visualization of what the trigger system would do, first we are trying to detect the X coordinate of the marine:



It would place a location like that. The system will then detect if the marine is there or not. In this case the marine is not there, so we know it cannot be in the first 32 pixels in the X dimension, you see? As a result the system adds 32 to _unitX. Next it will advance to the next area:



It doesn't detect a unit in there again, so it adds 32 pixels again to _unitX. It does so until it reaches here:



Once it detects the unit in there, it will initiate what I call micro scanning (before was macro scanning). So, it places locations of that decrease in 2 pixels as so:



I used that illustration to help convey the the concept better, each location is a different color and they're they all are smaller by each other by 2 pixels, so on the right side of each location they're 1px smaller, you see? The purple blob represents the marine. Now what the system does is first sees if the marine is in the smallest location (dark green in the picture). It's not there, so it adds 1 to _unitX. It detects if the marine is in the 2nd smallest one (which is brown) and it's not there, so it adds 1 again. It repeats this process until it reaches the blue location. After it sees that it's in the blue location it terminates and does the same exact thing in the Y dimension. Next it adds half the unit's width to _unitX, and half the unit's height to _unitX. The logic in that is that it terminates in the first pixel it sees the marine, so you have the coordinates of the sides of the marine which you don't want; by adding half of the unit's size to both coordinates you have the coordinates of the center of the marine.

The triggers themselves, once you fully understand the theory behind it should be straightforward to make.

This next segment is how you can apply having unit coordinates to spells. This part is very simple. The idea is that directly after the unit coordinate system, you alter the _unitX and _unitY coordinates so that you can create whatever effects you want. So if you wanted to have a spell that creates a wraith 16px to the left of the marine, you'd just subtract 16 from _unitX, then have that value transfered into _gridX through binary countoffs, then the grid system will place gen in 16 pixels left of the unit. Simple right?

Next is the general theory behind the knockback system, and is the only part I'll cover. How to make the actual triggers themselves is left as a challenge for the reader. Let's say you have two units whose coordinates you know in their respective death counters, and you detected that Unit 1 hit Unit 2, and you want Unit 2 to be moved in the direction that Unit 1 hit him in. The first thing you want to do get the slope of both units, which is essentially just the difference between their coordinates. So, you'd do two operations: Unit2Y - Unit1Y and Unit2X - Unit1X. Let's say in this case the slope is 4,2, 4 being the difference in the Y coordinate and 2 being the difference in the X coordinate. So you can imagine the equation of the line between the two units is y=4/2x. For example let's have the knockback distance be 64 pixels. In the slope, the dominant coordinate is Y (because 4>2). So you'd plugin 64 for y and solve for X. 64 = 2x then 32 = x. Unit 2 would be moved 64 pixels in the Y direction, and 32 pixels in the X direction.

Very good explanation. I can tell however that you are growing tired of writing and it's fine by me. The explanation for the knockback system is pretty interesting and now I know exactly what to do from here. It all sounds so easy, but I know it's going to be a lot of work because I'm a virgin (as already said) to location grids.

The only thing I would like to know, is how you detect (im assuming there is something I can read) when a unit has been attacked by another unit? The detection for the direction of attack should be simple enough using your slope and coordinate explanation, but detecting which unit was hit and which initiated the attack might be a different story. Any pointers to another post? I hope there is one, otherwise I might be replacing your fingers for you haha.

Thanks very much for the explanations, they're a lot of help. This should most indefinitely be stickied now haha. Any questions on location grids are now answered and VERY easy to understand. I hope someone sees this and actually saves it

Thanks. Good to know someone benefited from it. For detecting which unit was hit, it all depends on the implementation. Will the players be able to cast spells that spawn auxiliary units like zerglings that can attack? If so there's no practical way to detect the coordinates of those zerglings and which one attacked, etc. If only the main character attacks, then you can just detect a drop in the enemy's HP, which must mean the other character attacked him. But if there's more than two players on the arena there's no real good method other than a method which I don't think I should mention due to respect to the author who I think wants to keep it a secret.

So yeah, I haven't even thought of it but the system is has a lot of drawbacks. For it to be reliable you're going to have to keep it 1v1 and detect drops in the HP, and have no auxiliary units that can attack.

Lol, well that sucks the big one. Then there is no point in using a knockback system at all. Yes, the characters will be able to spawn spells that can attack such as zerglings, and yes there are more than just two players playing on the battle arena at a time (six can play).

Well, the knockback system is out the window, but the spell location system isn't which is nice. The only thing I'm having trouble with right now is visualizing what exactly happens and how it works. I mean, it's simple enough, but I already see a glitch with an answer I cannot yet grasp. I remember you talking about division for location grid systems and now I see why. If I'm using a tile of 32px wide by 32px tall, In order to utilize the method you gave me for the exact location of a unit (Unit Detection Method), I would need to divide the numbers I recieve for the exact location of the unit casting the spell by 32 to find the proper square it's most situated in. I know I could use the At Least and At Most triggers as division, but the method sort of seems choppy because then there is a possibility that the spell casting effects will be offset by different amounts, depending on the type of effects used.

I know that I shouldn't be worrying about perfection right now, but do you think it matters that much that a spell effect that's supposed to look symetrical is off by 31 pixels (being the most)??? (which is almost one whole square... I think it would look funny lol)

So now I'm thinking of a smaller sized tile to use even though it means more triggers.

Another question that's been giving me an itch is:

Based on the conditions I can give a trigger, do I need to create a set of triggers for each possible condition for each player when using a spell casting system? Remember, the players can be different SC units that use this location grid, AND what's stopping two users from casting a spell at approximately the exact same time, so I'm just thinking ahead to exactly how I could devise a plan of action towards these problems.

From a stand point of timing, if two players cast a spell at the EXACT same time, the trigger system for finding a unit wouldn't know what to do, would it? I mean, how fast can this Unit Detection system run? and If two players DID cast a spell at the same time, what course of action would the Unit Detection System take?

With 32px accuracy you can have it so the greatest amount of the offset being 16px. The grid triggers would be something like:
----
At Most 15 (0)
----
At Least 16 (32)
At Most 47
----
At Least 48 (64)
At Most 79

I don't know if that's clear to you or not.


I can't quite grasp what your first question is, but for your second question if they both cast a spell "at the same time" it should work fine because of how StarCraft handles trigger order. It runs all the triggers for player 1 first, then all the ones for player 2, etc. How "fast" the unit coordinate detection system is should be one trigger cycle.

Oh yeah, I guess you're right about the pixel accuracy. I was thinking in one direction and one dimension at a time, but that's not how starcraft works haha.

As for the triggers running, I didn't know that SC runs from player 1 through the players. I assumed it did what came first like every other programming language out there. I had no idea that SC labelled players as more important or "in an order".


And I do actually understand your example using the 16px offest. This example just reminded me of borders tho haha. What to do about those? Just let the units "Not create" lol?


P.S. Don't worry about the first question, it was a pr- question really, because I just asked it again in the second question, but after my little explanation.

I think now I should have worded my second question a little better. The way I'm thinking of it is that there are basically a few variables that are death counters which subsequently count the pixels where a player is located. Like you've already posted "_unitX" and "_unitY" as variable counters for the location of the unit for the player when he/she casts a spell.

I'm merely trying to ask the question that if Player 1 casts a spell, and Player 2 casts a spell, won't the variable values for the X Coordinate and Y Coordinate get overwritten by Player 2's action?

The way that I have the Unit Detection System (UDS) working (or the way im envisioning it working) is that when a player brings a unit to location "Cast Spell" (from being built and popping out below a gateway where "Cast Spell" is), the UDS finds the players character and utilizes the values of the X and Y coordinate as you have described to create an effect before units are created to make a spell look. The problem is, that even if the first triggers ran to find the X and Y coordinate, and then moved on to making the effects for the spell, once Player 2 casts its spell the variables will switch from what they currently are for Player 1 to the coordinates for Player 2. Would this not screw things up if the triggers were in action too closely together (time wise) ? If you don't understand the question, I'll clarify that I'm currently envisioning only 2 variables to use to find a unit "_UnitX" and "_UnitY", which are used by every player.

If I need 2 variables for each player, then I need 12 units I can count deaths for (which are not being used by SC) and I don't think there are more than 10 or so... are there?

Yeah, it gets a bit iffy with borders in general as ground units will be unplaceable, but you should probably include the borders into the next closest spot. Like in my previous example, instead of:

At Least 16 (32)
At Most 47

Just do:

At Most 47 (32)

To handle the borders as well. But then again it all depends on the map.


This is all based on the misconception that death counters can't be used for multiple players, which is false. A death counter "_unitX" will have unique values for Player 1's deaths of it, Player 2's deaths of it and so on, and modifying the value for Player 1's deaths won't effect the deaths for Player 2.