Unity (game creation)

Discussions and debates about video games

Moderator: Moderators

Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Unity (game creation)

Post by Pseudo Stupidity »

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.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

I have used it for a course. I'm not exactly what you'd call an expert, though.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

That works for me.

Question: Is there a way to use OnCollisionEnter without having a RigidBody component on one of the objects? I'd like to let friendly units be able to pass through each other, and having a rigidbody on all of them prevents this.

If you know of a workaround that doesn't involve OnCollisionEnter, or a way to let objects with the same tag pass through each other even though they have rigidbodies, that would work too.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

You can set layer interactions in the physics manager and make things on the same layer not collide. Since I'm betting you want to let them pass through each other but not stay overlapped forever, you probably want them to have associated triggers that do interact. Make sure that units don't react to their own triggers.

There's also ways to disable or override the physics system when colliding, but those would almost certainly cause weird behavior.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

This page has a lot of helpful information, especially the chart at the bottom. But you'll run into plenty of other problems along the way this page totally glosses over, so fucking hell. But let me give you the gist.

There are two important things to consider to understand how your object's collision detection will behave:
1) Is your object a rigidbody, a kinematic rigidbody, or static?
2) Is your object's collider a non-trigger collider or a trigger collider?

Second point first, because it's easier. Non-trigger colliders are meant to resolve physics engine collisions, and they only generate an event when it makes sense for one of the two overlapping objects to apply a force to the other (which the physics engine then applies automatically in addition to generating the event for you to do with as you please). Trigger colliders are much less restrictive and are meant to detect simple overlaps, and they generate an event whenever two non-static (i.e. not non-moving) colliders overlap.

Now for the first point. Let me explain what each of those three things is:
1) Yes, you can add a collider to an object without a rigidbody, a collider is just another component like any other. A collider on an object without a rigidbody is called a static collider. Static in this case means non-moving, and Unity assumes that you intend to use these static colliders for shit like walls or script triggers or whatever. Static colliders don't trigger when they hit other static colliders, because that would be like telling Unity to constantly generate collisions between two walls at their intersection. Also, moving an object with a static collider has some expensive overhead (redrawing the scenegraph) and you really shouldn't do it. So while you technically can do this, it won't do what you want at all.

2) If you look at a rigidbody, you'll notice there's a checkbox for kinematic. Kinematic rigidbodies are rigidbodies which cannot have forces applied to them by the physics engine, not even gravity. Their motion is controlled entirely by their own logic. But they can apply forces just fine. So if a kinematic rigidbody hits an ordinary rigidbody, only the ordinary rigidbody is affected. When a kinematic rigidbody hits another kinematic rigidbody or a static rigidbody, neither of the two objects can have forces applied to them so no collision event happens. But if you're using trigger colliders, you'll still get the "these two things overlapped" event and you can LOGIC at it yourself without using the physics engine. So this can kind-of-sort-of do what you want it to do.

3) An ordinary rigidbody is... incredibly ordinary. I don't know what else to say about it. It gets forced applied to it by all the things. It's an ordinary physics object.

The ideal solution for what you're trying to do is to add non-kinematic rigidbodies to everything, and then follow name_here's advice and limit collisions using layers. But some people have talked about using kinematic rigidbodies and triggers and having some success, but it seems to come with its own host of problems.

One thing to look out for is that for certain combinations of the six posibilities the event generated by a collision is only sent to one of the two objects involved, which is exactly as fucking annoying as it sounds and isn't really documented anywhere I can find. Which is a problem you will probably run into if you try the kinematic + trigger approach. Which is another very good reason to try the thing name_here said first.
Last edited by DSMatticus on Fri Jan 30, 2015 10:24 pm, edited 1 time in total.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

Note that if you use kinematic triggers you're not going to be able to use most of the built-in physics stuff. That might not be a problem if you're doing a top-down RTS or something, but you'll have to program in gravity and not falling through the ground manually if you want those.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

Thanks for all the info! Some details on my game:

I'm making an Ogre Battle style game (the world needs more of these), so I don't need the physics. I was using rigidbodies for the ability to have collisions get detected in the first place and get all the relevant bits set up for the combat portions.

I'm going to have to read through all the collider info this weekend. I was so excited that all my JS knowledge wasn't going out the window that I underestimated how hard it would be to actually program a game. There's still a fuckton to do just to get the basic combat system running.

If anyone had an idea for how to script the actual combat that would be great. I have vague ideas (a combatController script that just has units run through Attack scripts based on their stats and the chosen strategy, and those scripts activate takeDamage and other shit on whoever they're affecting), but am so new that I'm literally winging all the code as I go. I design websites, so programming a game is a whole new thing.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

Yeah, that combat scripting looks like a sensible idea.

If you're not using the actual physics stuff, I think just kinematic trigger rigidbodies should work fine, assuming there isn't some weird undocumented behavior.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

I'm not actually all that familiar with the original Ogre Battle, just the turn-based tactical RPG one similar to Final Fantasy Tactics. But if you're trying to handle "there's a map that a bunch of different things run around on in real-time; when those things get too close, you get a screen transition and snazzy battle music" then kinematic rigidbodies with trigger colliders sounds like the way to go. A simple check during OnTriggerEnter to determine if the two objects are enemies of one another is all you need to decide if there will be a battle, and because they're kinematic they can pass right through eachother if you decide there won't be one.

As for handling the battles, I do not know how Ogre Battle's battles work, so I am at a loss there.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

DSMatticus wrote:I'm not actually all that familiar with the original Ogre Battle, just the turn-based tactical RPG one similar to Final Fantasy Tactics. But if you're trying to handle "there's a map that a bunch of different things run around on in real-time; when those things get too close, you get a screen transition and snazzy battle music" then kinematic rigidbodies with trigger colliders sounds like the way to go. A simple check during OnTriggerEnter to determine if the two objects are enemies of one another is all you need to decide if there will be a battle, and because they're kinematic they can pass right through eachother if you decide there won't be one.

As for handling the battles, I do not know how Ogre Battle's battles work, so I am at a loss there.
That describes what the functionality of the primary part of the game is. You order units around the map to achieve whatever your objective is (typically capture the enemy HQ or escort an NPC unit somewhere), and if a unit of yours runs into an enemy unit you get a screen transition and have a battle.

Kinematic rigidbodies with trigger colliders it is then!
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

I assume there are also terrain features you can't move through. Static colliders for those should cover it.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Not sure if I'm correcting or clarifying, but I have to expand on that; in this case, a static collider would not stop your units from walking through terrain objects for two separate reasons, but you will need them as part of the solution you'll use to stop your units from doing so.

The first reason is that when you set a collider's isTrigger to true, you are telling the physics engine "this collider is not a physical object, it's a logical object, and other than telling the objects involved that they're touching one another you shouldn't do anything to them." A trigger collider is a ghost. It gives zero fucks about passing through your walls.

The second reason is that when you set a rigidbody's isKinematic to true, you are telling the physics engine "I take full responsibility for the position and motion of this rigidbody, and you should not do anything to it even when it touches another object (but you might do something to the other object)." Kinematic rigidbodies are an unstoppable force. They'll push non-kinematic rigidbodies (with non-trigger colliders) out of the way and punch through static colliders as though they weren't even there.

We are talking a kinematic rigidbody with a trigger collider, i.e. both of the above. That's basically the ghost of the Juggernaut. If you place a bunch of static colliders (non-trigger or trigger, doesn't matter in this case) and your ghostly Juggernaut units run into them, the physics engine will call OnTriggerEnter but it will not stop them. You'll have to stop them yourself in the OnTriggerEnter code (probably by reversing the movement that caused the overlap).

Stopping objects from passing through one another is a part of the Unity physics engine. Opting out of one is opting out of the other. So to get the former without the latter, you need to write some of your own "can't go there" code or try your best to turn off all the bits of the physics engine. The former sounds simpler (especially for a project like this where you know you don't want any physics), because the physics engine seems very tenacious to me and I wouldn't want it looking for things to do to my rigidbodies, which is why I think the way to go is kinematic rigidbodies with trigger colliders.
Last edited by DSMatticus on Sun Feb 01, 2015 4:46 am, edited 3 times in total.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

Yeah, you're looking at a three or four part switch statement for the onTriggerEnter code. One case for bumping into an enemy unit that starts a battle, one for touching a friendly unit that either does nothing or prevents them from stopping inside each other, one for bumping into terrain that makes it stop and back up a bit, and possibly one for touching the objective, though personally I'd advise putting the code for triggering it on the objective itself and have it signal the GameController.

In order to prevent this from becoming a nightmare maze of duplicate code, you probably want a Unit class that all types of units descend from and give it methods for each type of interaction that subclasses will override, and only have the switch statement itself in one place. Then give it startBattle, separateFromAlly, move, and encounterObstacle methods that do your actual logic and touch<label> methods that go in the switch statement and generate an UnimplementedOperation error however it is that Javascript does that, which your EnemyUnit and FriendlyUnit classes override to call the contextually-appropriate logic methods.
Last edited by name_here on Sun Feb 01, 2015 5:01 am, edited 1 time in total.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

I had not considered that completely ignoring physics will require a bunch of triggers (I still want gravity around! I don't want them to phase through mountains or fly over non-flat terrain). Oh well, the physics get in the way and the code shouldn't be difficult to stop units from Juggernauting their way through walls, rivers, and mountains.

Right now I've got a really simple movement script where it just sets a goal and unerringly moves towards it based on the unit's moveSpeed stat (which is gathered by checking all the children and pulling in the slowest movement speed). I wanted to make sure I could test the collisions and all that.

I'm actually OK with units being a big stack together as long as they aren't perfectly overlapping each other. I want multiple units to be able to heal and rest in the same stronghold (basically a square on the map that lets all characters in a unit recover fatigue and health), I just don't want one collision to start multiple battles.

I've been having battles start by using tags, each unit is tagged with PlayerOneUnit or PlayerTwoUnit (I'm keeping the option of multiplayer open because it's just as easy as not doing that) and is running a script with OnCollisionEnter that checks the tag and either starts a battle or does nothing. I've got to switch it over to using trigger colliders, and will do that once I wrap up the "pull in and position characters" part of my battle script.


I've been having fun trying to figure out the best way to spawn the characters in the little battle area, which is just a plane hanging out in space. So far I've got the children of my primary unit getting pulled into a list of objects owned by my "battle manager" object where I'm going to drop all my scripts. It took me a while to decide that was the best way since I'll need a list anyways to make it simple for targeting and all that jazz.

Next step: pull the children of the enemy unit that it bumps into (easy) and drop them into a list of enemy units for the battle manager. Then position units (and do so based on unit facing, so attacking an enemy from the back spawns their characters in backwards formation, same thing with from the flanks). Then a switch over to solving the movement and collision problem before what I suspect will be the most difficult part: coding the fucking battle system.


I guess my next question is how do I determine facing? All of my units are just spheres at the moment, but I'd like to give them facing and have them automatically rotate (when standing still) to face the nearest enemy. The automatically rotating thing should be easy, but I haven't got a clue as to facing yet.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Hm. You are confusing me a bit, and I'm not sure if it's because I'm misunderstanding what you're trying to do or if you're making things harder for yourself than they need to be. Let's talk about the original Ogre Battle; it has a tactical map and a battle map. Correct me if I'm wrong about any of the following.

The tactical map is a 2d plane, and on that 2d plane some areas happen to be marked with special properties like "this is a mountain, dudes should not walk here; impassable." But the level geometry is fundamentally 2d. There are no slopes or hills or any of that crap.

The battle map is another 2d plane, and I... again know nothing about it. Looking at screenshots, I get the impression that the battle map is a featureless, bounded 2d plane and units can only face one of two directions; towards their enemy's side of the plane. Was the battle map gridded, with units forced to align their movement evenly with grid spaces? I really can't tell from screenshots, but I know a bunch of other games of that era and genre did that.

Out of the two descriptions above, I'm not sure anymore what you're keeping and what you're getting rid of. Gravity on a flat 2d level geometry would be redundant, because your units would never ever need to go up or down; you'd fix their positions along that axis to begin with. But if you're updating Ogre Battle-like gameplay to a non-flat, 3d level geometry, then that changes things. Similarly, it sounds like you want to do the battle map very differently, which means that my already woefully incomplete knowledge of Ogre Battle isn't even helpful. What is your desired facing system? Four-directional? Omnidirectional? Is movement based on discrete units (i.e. locked to a grid) or continuous (i.e. measured warhammer style)?
Last edited by DSMatticus on Mon Feb 02, 2015 9:28 pm, edited 1 time in total.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

DSMatticus wrote:Hm. You are confusing me a bit, and I'm not sure if it's because I'm misunderstanding what you're trying to do or if you're making things harder for yourself than they need to be. Let's talk about the original Ogre Battle; it has a tactical map and a battle map. Correct me if I'm wrong about any of the following.

The tactical map is a 2d plane, and on that 2d plane some areas happen to be marked with special properties like "this is a mountain, dudes should not walk here; impassable." But the level geometry is fundamentally 2d. There are no slopes or hills or any of that crap.

The battle map is another 2d plane, and I... again know nothing about it. Looking at screenshots, I get the impression that the battle map is a featureless, bounded 2d plane and units can only face one of two directions; towards their enemy's side of the plane. Was the battle map gridded, with units forced to align their movement evenly with grid spaces? I really can't tell from screenshots, but I know a bunch of other games of that era and genre did that.

Out of the two descriptions above, I'm not sure anymore what you're keeping and what you're getting rid of. Gravity on a flat 2d level geometry would be redundant, because your units would never ever need to go up or down; you'd fix their positions along that axis to begin with. But if you're updating Ogre Battle-like gameplay to a non-flat, 3d level geometry, then that changes things. Similarly, it sounds like you want to do the battle map very differently, which means that my already woefully incomplete knowledge of Ogre Battle isn't even helpful. What is your desired facing system? Four-directional? Omnidirectional? Is movement based on discrete units (i.e. locked to a grid) or continuous (i.e. measured warhammer style)?
I'm going more for Ogre Battle 64, which is the same as Ogre Battle except the tactical map can have different elevations (mountains are actually tall and units walk up them slowly and have line of sight change the higher they are).

The battle map is invisibly gridded, characters statically stand where they are and trade attacks with each other. When setting characters up the battle map IS visibly gridded though, since where you put characters determines how they attack.

An ideal facing system is just four directional as far as gameplay is concerned. You are either attacked from the front, back, left, or right and that changes where your characters are on the battle map (which changes how they behave in the fight). If you have a wizard in the back row and your unit is attacked from the rear that wizard is now in the front row and is going to get killed very quickly.

tl;dr: The battle map is static and each side has a 3x3 grid they stand in (but it is invisible). Characters are unmoving and fight based on where they're standing. The tactical map is not entirely flat, and it can have terrain features like mountains and forests that can slow character movement and screw with line of sight.
Last edited by Pseudo Stupidity on Mon Feb 02, 2015 9:40 pm, edited 2 times in total.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

Transforms do have direction vectors you can calculate angles from, but if you only have four facings it might make more sense to use an enumerated type.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

That is very helpful.

@Tactical Map:
I'm not actually sure what the simpler solution is anymore. With a flat level geometry, keeping units from falling through the floor is trivial because the floor doesn't move. You set their height, never change it, and you're done. And detecting when units are moving up/down slopes in order to change their speed is a completely non-existent problem, because flat things are flat.

I think, in the end, it comes to the complexity of the level geometry. If your level geometry is mostly flat with some special regions that have special behaviors, it would probably be better to just give those regions special triggers. If your level geometry is full of gradual elevation changes (hills and valleys galore), the physics engine has a lot more to offer. So I suppose the question you should ask yourself is, "if I were playing this tabletop, could I easily represent this as a flat board with specially marked regions?" Looking at screenshots of Ogre Battle 64, I would think the answer is yes. But if you were getting anymore complicated than that, I would say the answer is no.

@Battle Map:
As name_here said, you should store a unit's facing as an enumerated type (north, south, east, west or something) in that unit's data. When you need to know a unit's facing, you look at that value. When you need to change a unit's facing, you change that value and update the graphical representation of the unit (so if you're using 2d sprites, change the sprite; if you're using 3d models, rotate the model). You shouldn't ever directly check the orientation of the physical object, you should just ask units what they think their facing is and trust that their graphics are accurate (and if they aren't, then you have a bug).
Last edited by DSMatticus on Mon Feb 02, 2015 11:35 pm, edited 1 time in total.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

Can I determine which way each unit is facing relative to the collision point when a battle starts to set the facing int? I see where using an int for facing is important (so if facing = 1 spawn the characters normally, if 2 spawn them this way, etc...), but units will be rotating a lot as they walk around the map. Collision passes the transforms of both objects as well as the collision point, so I should be able to determine their facing using that information (I think) and make the relevant changes to the units.

And can I change the rigidbodies so they can overlap and just set drag to some ridiculous number so they don't bounce off each other? If the physics will help me then it might be worth keeping the rigidbodies.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Pseudo Stupidity wrote:Can I determine which way each unit is facing relative to the collision point when a battle starts to set the facing int? I see where using an int for facing is important (so if facing = 1 spawn the characters normally, if 2 spawn them this way, etc...), but units will be rotating a lot as they walk around the map. Collision passes the transforms of both objects as well as the collision point, so I should be able to determine their facing using that information (I think) and make the relevant changes to the units.
It sounds like you have the right idea. If you want to determine battle facing from tactical facing, the thing you're interested in is the amount of rotation between the vector that represents a unit's tactical facing and the vector that points to the center of the unit that engaged them (or the vector to the point of collision, both make sense and ideally they will produce almost identical results).

If U1's facing vector is straight north and U2's facing vector is straight west and they collide perfectly on U1's east side/U2's west side, then U2 is rotated 90 degrees away from their enemy while U2 is rotated zero. So when the battle music plays, U2 is in correct formation and facing the enemy, while U1is getting hit on their right flank and their right sides are facing the enemy. Does that sound about right?
Pseudo Stupidity wrote:And can I change the rigidbodies so they can overlap and just set drag to some ridiculous number so they don't bounce off each other? If the physics will help me then it might be worth keeping the rigidbodies.
Messing with mass, drag, physics materials on your objects (they control friction and bounciness), and the physics manager's bounce settings are things you'd want to look into to reduce bouncing during collisions.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

Enumerated types don't have to be integers, at least in languages I'm familiar with and I would assume in javascript too. It'd probably be most convenient to make them all vectors, where NORTH is <0,1,0>, EAST is <1,0,0>, SOUTH is <0,-1,0>, and WEST is <-1,0,0>. Then you can use them for easy adjustment and all the vector math and angle calculations you need.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

DSMatticus wrote: It sounds like you have the right idea. If you want to determine battle facing from tactical facing, the thing you're interested in is the amount of rotation between the vector that represents a unit's tactical facing and the vector that points to the center of the unit that engaged them (or the vector to the point of collision, both make sense and ideally they will produce almost identical results).

If U1's facing vector is straight north and U2's facing vector is straight west and they collide perfectly on U1's east side/U2's west side, then U2 is rotated 90 degrees away from their enemy while U2 is rotated zero. So when the battle music plays, U2 is in correct formation and facing the enemy, while U1is getting hit on their right flank and their right sides are facing the enemy. Does that sound about right?
That sounds exactly right. I haven't written any code using rotations yet, so this will get me some useful knowledge.
DSMatticus wrote:Messing with mass, drag, physics materials on your objects (they control friction and bounciness), and the physics manager's bounce settings are things you'd want to look into to reduce bouncing during collisions.
This will also be fun to screw with. It took me a while with my current setup.

On enumerated types: Would it be reasonable to just use an integer between 1 and 4 to determine spawn positions if I set it by using the facing calculations from the collision? I plan on having the units rotate freely as they walk around the map, and when standing still they should be rotating to face the nearest approaching enemy.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
DSMatticus
King
Posts: 5271
Joined: Thu Apr 14, 2011 5:32 am

Post by DSMatticus »

Yeah, you only need four distinct values to represent facing on the battle map, but the point name_here is making is that instead of using 0,1,2,3 (you're programming so count like a programmer, god damnit; start at zero) you should use NORTH,SOUTH,EAST,WEST through the power of enums. That way, your code looks like unitFacing = Facing.NORTH instead of unitFacing = 0. Human readable code is easier for you to conceptualize both as you're writing it and as you revisit it later in the project to crush that bug you just realized you had. Remembering that N=0,E=1,S=2,W=3 isn't hard, but it is an extra layer of abstraction between you and the functionality you're trying to program that you don't need and can only get in the way.
Last edited by DSMatticus on Tue Feb 03, 2015 2:36 am, edited 1 time in total.
name_here
Prince
Posts: 3346
Joined: Fri Mar 07, 2008 7:55 pm

Post by name_here »

A general rule of thumb is that any constant value you use in multiple places in your code should be stored as an enum or const if you'd want to change it everywhere it shows up whenever you change it anywhere it shows up. Otherwise you're going to change it and miss a spot. Not much of a risk here, but it's a good habit to get into and always makes your code more readable.

Anyways, the advantage of making it enumerated vectors instead of constant ints is that it makes it trivial to align the physical unit with a cardinal direction using the built-in rotation rules, and you can use this guy to calculate arcs. If facing is to matter on the field map, contact points within 45 degrees of the forward vector are from the front, 45 to 135 are from the side, and 135 to 180 are from behind. On the field map you'll want make vectors using only the x and y components and use those for the calculation. You'll have to get a bit fancier if you want to distinguish left and right contact points; you can probably figure it out from the signs of the vector components but I couldn't tell you how.

As for always facing towards the nearest enemy, GameObject has methods for finding all GameObjects with a given tag, then there's an example code snippet for finding the closest one, and this will let you rotate to face it.
Last edited by name_here on Tue Feb 03, 2015 3:22 am, edited 1 time in total.
DSMatticus wrote:It's not just that everything you say is stupid, but that they are Gordian knots of stupid that leave me completely bewildered as to where to even begin. After hearing you speak Alexander the Great would stab you and triumphantly declare the puzzle solved.
Pseudo Stupidity
Duke
Posts: 1060
Joined: Fri Sep 02, 2011 3:51 pm

Post by Pseudo Stupidity »

Nice, thanks for all those code snippits in particular.

One thing I've run into trouble with is freezing the entire tactical map when a battle starts. I've got the characters from each unit spawning into the battle area, but because the parent objects are moving they all go flying into space immediately. If the tactical map is frozen this shouldn't be a problem, but I'm not sure how to freeze it when a battle starts.

Do I do this by stopping the game clock (and if I do, can I still run the battle script so the characters in the battle area will fight each other and do their animations), or is there some other way? I heard of a "FreezeAll" command for rigidbodies, but this is a problem spot for me.
sandmann wrote:
Zak S wrote:I'm not a dick, I'm really nice.
Zak S wrote:(...) once you have decided that you will spend any part of your life trolling on the internet, you forfeit all rights as a human.If you should get hit by a car--no-one should help you. If you vote on anything--your vote should be thrown away.

If you wanted to participate in a conversation, you've lost that right. You are a non-human now. You are over and cancelled. No concern of yours can ever matter to any member of the human race ever again.
Post Reply