The Gaming Den

Absolutely do not do it by stopping the game clock. You can use FindGameObjectsWithTag to get all your tactical-layer game objects and BroadcastMessage to trigger a freeze.

Note that things like GameObject.Find and BroadcastMessage are slow. Not so slow that doing it at the start of the map, as suggested, would be a problem, but don't put them inside an Update loop.

Also, in a lot of cases, there are better ways to accomplish the same thing.

Thanks again for the info.

I think what I'll do is find all gameobjects with the tags PlayerUnit and PlayerTwoUnit and add them to a list, then use broadcast message to everything in the list to have them resume movement upon battle entry and battle finish.

Once I've got character placement based on facing finished it's on to the battle script. I'll share my BattleStart script and relevant functions once I've got them wrapped up so you can all make fun of how much my code sucks. Part of why I'm doing this is just to get better at programming in general since I've only ever done simple web programming and this is a fun way to practice.

In the interim, I have a couple of questions based on the battle script. My battle script will compare the combatSpeed value of each character to determine attack order, and use broadcast message to make characters run an "Attack" function in order. Is that the most reasonable way to run something like that? Is there a good way to break ties in combatSpeed (I don't mind randomizing it, but I can't think of a great way to keep it consistently random [ex: two characters have combatSpeed == 200, character 1 attacks first, but in the next round I want character 2 to be able to attack first] when I'm using a For loop to send the message)?

Edit: Comment about Broadcast was incorrect.

Re: Turn order, you could do something like:

No, BroadcastMessage sends to an object and all of its children. Which is only every object if you've got everything as children of a single object which you message.

Ah, I was thinking of something else. Often you'd want to send the message more directly, but that would be fine for some purposes.

The units are now stopping correctly and I've switched my triggers so they happen based off of OnTriggerEnter instead of OnCollisionEnter. This is leading to the problem of determining the following when a player unit bumps into an enemy (or when an enemy bumps into a player unit):

1. Which unit was moving towards the other one at the time?
2. Which side each unit was hit on?
3. What type of terrain are the units on?

My units have kinematic rigidbodies attached to them.

1. Get their velocities and positions in world coordinates. Then do vector math to figure it out
2. Unfortunately, OnTriggerEnter does not send this info for you. Generate a vector pointing from the unit to the contacting unit and find the angle between it and forward. If you want to treat left differently from right, you'll also want to check the signs of the vector coordinates. It would also be possible to attach multiple triggers to each unit and have them pass messages up, but that would be rather fiddly to assemble and you'd need to do it for each unit type.
3. OnTriggerEnter for the terrain to set a variable in the unit would do it, albeit with somewhat unpredictable behavior if a unit is on the boundary between two at once. You could fiddle with other trigger interaction messages to get finer control, though it might come with a small performance hit.

Pseudo Stupidity wrote:Does anybody use Unity at all? I've been working on a game for a little while and wanted to see if we have some people that are familiar with it on the boards. That way I can ask you questions when I run into roadblocks instead of actually having to get better at programming.

Let's talk about making video games.

My team's programmer made me a level editor program for the game I'm working on, www.corgirun.com

Unity is da bomb

Oh, you also mentioned not wanting to start multiple battles at once, which is either trivial or stupidly complicated and I'm not sure which. I'm almost certain Unity's main logic is single threaded, so units don't actually fire Update and OnTriggerEnter simultaneously but instead in some order, though I don't think the order is predictable. So you don't have to worry about two fights triggering actually simultaneously. However, I think the other battles will have their trigger events in line to be started and happen before the fight ends. So you want to stick them in some datastructure (I don't think you care about the exact order, so either a stack or queue should work and be convenient to work with) in your battle controller and have an isFighting boolean. Then when isFighting is false and the datastructure isn't empty, remove a battle from the structure, set isFighting to true, and start the fight, then set it to false at the end.

Now, because life can never be easy, it is possible a unit will touch two things at once then get wiped out in the first fight. That needs to be handled more gracefully than crashing. Do whatever it is you do in JavaScript when you might have a null value returned.

If you want to block multiple fights with one unit close together, have a mercy invincibility variable that causes fights involving the unit to just re-add themselves to the datastructure, which you would want to be a queue so it doesn't clog the top. You will also need to cull fights if they aren't actually touching. Unfortunately OnTriggerEnter is only called once until they separate so you can't just cull the fight and count on it getting re-added.

If you're serious about working in Unity, getting your hands on a CGpeers.com account is a good way to get access to tutorials and project guides.

As well as actual Unity packages to cobble together projects of your own.

name_here wrote:1. Get their velocities and positions in world coordinates. Then do vector math to figure it out
2. Unfortunately, OnTriggerEnter does not send this info for you. Generate a vector pointing from the unit to the contacting unit and find the angle between it and forward. If you want to treat left differently from right, you'll also want to check the signs of the vector coordinates. It would also be possible to attach multiple triggers to each unit and have them pass messages up, but that would be rather fiddly to assemble and you'd need to do it for each unit type.
3. OnTriggerEnter for the terrain to set a variable in the unit would do it, albeit with somewhat unpredictable behavior if a unit is on the boundary between two at once. You could fiddle with other trigger interaction messages to get finer control, though it might come with a small performance hit.

1. I might have set attacker and defender based on whether one unit is standing still or not. I figure a unit in retreat, while technically defending, is not actually setting itself up for an attack. Characters that benefit from either attacking or defending are only going to get those bonuses if they are unmoving (had time to prepare) or attacking someone who is unmoving (they have more momentum or something?).

Do kinematic rigidbodies actually have velocities, though?

Maybe this isn't a great mechanic after all and I should scrap it. Movement speed, movement type, endurance (how long your character can march without getting tired and needing to nap [and once fatigue gets to 75% they lose combat effectiveness]) and all the other shit should lead to character diversity within units.

2. When you say generate a vector, do you mean use a raycast to the other unit? I'm just trying to figure out what this looks like.

3. That sounds reasonable, terrain should be on the easier things. Facing is turning out to be surprisingly hard for me.

On preventing multiple battles: I do have a BattleManager script and object. I have not done a stack or queue of things before, I'm going to try and ram my head against this a bit today.

If a fight starts all units get the command to stop moving and (soon to add...) the camera will move to the battle area so the fight can happen. Then on the battle's close all units will begin moving again, with the losing unit automatically moving backwards a bit (and being immune to battle starts for a bit, so I'll disable and enable isTrigger for it).

1. Yeah, they've got velocities. The velocity just doesn't get changed by outside forces.

2. Well, I was thinking get their coordinates and calculate the vector between them, but a raycast is probably a better idea.

Stacks and Queues are pretty simple. They've canonically got three operations: push, pop, and peek. Peek lets you look at the object on the top without removing it, pop removes and returns the object on the top, and push adds an object. For a queue, push adds the object to the bottom, while for a stack push adds the object to the top.

Alright, here's what I've got for facing.

function DetermineFacing (origin : Transform, target : Transform)
{
var targetDir = target.position - origin.position;
var forward = origin.forward;
var angle = Vector3.Angle(targetDir, forward);
Debug.Log (angle);
}

So determining left or right is...hard. I guess I could compare it to transform.right as well as that should let me figure out which side is which.