|
supermikhail posted:Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me. I don't use Unity, but reading that page real quick sounds like explaining what Unity does internally to serialize certain values, not a Unity method of serializing. So if you need to do your own serializing, I think the answer is the standard .NET C# Serialization approach. HTH. Shouldn't be too hard to just load a library, throw some object at it with the right annotations and get it to spit out some JSON for ya.
|
# ? Feb 10, 2016 22:23 |
|
|
# ? May 18, 2024 22:10 |
|
supermikhail posted:Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me. Yeah, didn't mean to confuse you. Pretty sure you want C# serialization.
|
# ? Feb 10, 2016 22:33 |
|
xzzy posted:I've become a huge sucker for yaml these days, I love the look of the files (they're super easy for a human to edit) and importers/exporters exist for just about every language. I'm sure Unity has one too. I know it does json as well, which is a reasonable alternative for serialization. This is how I bolted YAML support into an existing program.
|
# ? Feb 11, 2016 00:42 |
|
So, I want to know if I have line of sight to an enemy. I guess I should use raycasting for this? Right now I handle my collisions in a layer in my tiledmap, but I could probably make some polygons in a object layer which I could use for collisions, since there are stuff you should be able to shoot through, but not walk through. Does this seem reasonable? Any good guides to raycasting? I'm guessing I use some kind of line and check if it intersect my polygons?
|
# ? Feb 11, 2016 01:28 |
|
supermikhail posted:Oh, dear... So do I want Unity serialization or... C# serialization? I guess it's probably up to me. I think you need to say a bit more than "serialise my stuff" if you want advice. What are you trying to do, and why are you trying to do it? Serialisation is a solution to a problem, and without knowing what your problem is it's hard to recommend a solution.
|
# ? Feb 11, 2016 01:42 |
|
Sistergodiva posted:So, I want to know if I have line of sight to an enemy. I guess I should use raycasting for this? That's one way to do it if you have colliders set up. Since you're using tiles you can use Bresenham's Line Algorithm. https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm Use that to get the tiles that are in a line between thing A and thing B then check if any of them block sight along the way.
|
# ? Feb 11, 2016 01:54 |
|
ToxicSlurpee posted:That's one way to do it if you have colliders set up. Since you're using tiles you can use Bresenham's Line Algorithm. This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping
|
# ? Feb 11, 2016 03:13 |
|
Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised: The blue + red areas combined show the full movement range of the weapon, and the red areas show where it could move but it's currently blocked by something. It looks like it's doing an OK job of calculating those, but there are plenty of cases where my current solution falls apart. I need to find the limits of where it can move. Some notes:
I've already tried solving this in different ways:
Sorry for the wall of text. I feel like this is something that must have been done before, but I couldn't find any sources of information on it. It seems impossible to Google but it must have been done. Someone told me to look into robotics research, but I wouldn't know where to start. If we can send people to the Moon we must be able to reduce a rotation range based on some box colliders.
|
# ? Feb 11, 2016 05:58 |
|
HappyHippo posted:This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping True. That depends on if that is desirable behavior or not. I used that because the way I was generating levels at the time didn't have those "tiny crack between two diagonal walls" situations and I wanted the player to be able to see a square around corners. That's a good link, though. Gonna read that.
|
# ? Feb 11, 2016 06:18 |
|
Nition posted:Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised: You could probably simplify your problem by removing the restriction that you can't shoot yourself from your pre-calculation. Then you can raycast at runtime when the player tries to shoot and make it so any gun that would shoot your own vehicle just doesn't fire. Hell, let them shoot themselves and have a vehicle part that acts as a safety device that prevents shooting yourself.
|
# ? Feb 11, 2016 06:38 |
|
Aren't there things like hingejoints you can use to have Unity enforce rotational constraints? Granted, when I tried them for simple things like doors, I had all kind of crazy poo poo happen.
|
# ? Feb 11, 2016 07:13 |
|
HappyHippo posted:This is the right approach but that particular algorithm can be problematic because it jumps along diagonals. For this situation you want something more like this: http://www.redblobgames.com/grids/line-drawing.html#stepping Wow thanks. This was actually surprisingly easy. I think I'm going with the one that jumps diagonally, since I want to be able to shoot straight, but I could always change and test that later. I feel like I actually learn more translating code from his (javascript?) to java, since I actually have to understand what I am doing. Right now I am using scene2d MoveToActions for my movement, but I guess I could use stuff like this for smooth movement? Because right now I am having to add RunnableActions that detract from my actionPoints as I walk, to get the currentAP/maxAP display under the characters to update as they walk. Problem is, doing it my way gives me trouble trying to stop my enemies when they are adjacent to a player, so they can execute a melee attacks. Warning, this is messy and I should probably not have the logic for enemies ending their turn in the movement code :P code:
Sistergodiva fucked around with this message at 07:43 on Feb 11, 2016 |
# ? Feb 11, 2016 07:35 |
|
Nition posted:Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised: Your problem is basically a textbook inverse kinematics problem for a robot with a fixed length end effector with two rotational degrees of freedom. Too much to bother to find my old robotics notes, but that's what you want to google. E: forward kinematics; I thought you wanted to aim the turrets automatically for some reason. leper khan fucked around with this message at 08:18 on Feb 11, 2016 |
# ? Feb 11, 2016 08:13 |
|
ZombieApostate posted:You could probably simplify your problem by removing the restriction that you can't shoot yourself from your pre-calculation. Then you can raycast at runtime when the player tries to shoot and make it so any gun that would shoot your own vehicle just doesn't fire. Hell, let them shoot themselves and have a vehicle part that acts as a safety device that prevents shooting yourself. Weapons would still clip with stuff on the vehicle though. Rocko Bonaparte posted:Aren't there things like hingejoints you can use to have Unity enforce rotational constraints? Yeah, but if I'm specifying limits on joints, then I still have to calculate the limits. It is possible to have a physics-based solution, but I already have too much physics calculation going on and it's also nice to have stuff like the movement previews in the screenshots above, which I wouldn't be able to do. leper khan posted:Your problem is basically a textbook inverse kinematics problem for a robot with a fixed length end effector with two rotational degrees of freedom. Too much to bother to find my old robotics notes, but that's what you want to google. Thanks, I'll try some more searches.
|
# ? Feb 11, 2016 08:13 |
|
The past few pages of this thread and the past few pages of my personal notes taught me games are collision detection. I was trying to figure out how to test colliding along a plane in Unity, and fell back on thin boxes . . . I think.
|
# ? Feb 11, 2016 08:44 |
|
Rocko Bonaparte posted:The past few pages of this thread and the past few pages of my personal notes taught me games are collision detection. I was trying to figure out how to test colliding along a plane in Unity, and fell back on thin boxes . . . I think. Two things that I have noticed for every time I make a game is: How I handle collision detection often dictates the "coding structure" of my games. And all games boil down to conditions.
|
# ? Feb 11, 2016 14:21 |
|
Sistergodiva posted:Wow thanks. This was actually surprisingly easy. Make sure you check for the case that website he linked shows though. If you're jumping diagonally then you can effectively shoot through solid walls if the walls are diagonal and not vertical or horizontal. If you don't want to be able to shoot through diagonal walls, you need to use the other algorithm he linked. If there's never a situation in your game where you'll have two diagonal walls without having the corner also filled in, then you're fine, but if that's something that could happen you should check for it.
|
# ? Feb 11, 2016 16:08 |
|
Nition posted:
I assume "on-the-fly" means you can change turrets in the game, but not that its happening every frame or something. Inverness fucked around with this message at 16:14 on Feb 11, 2016 |
# ? Feb 11, 2016 16:12 |
|
edit haha ^^^ just said the same thing.Nition posted:
When you say you need to do this on the fly, what do you mean? Surely you only need to run this calculation whenever your car's body changes, and then you'd know the maximum pivot angles for each gun and could just retain those as floats and clamp any attempts for the gun to aim at beyond those until the car changed again? How you'd end up doing that probably depends a great deal on if you're doing your own trigonometry to aim them or relying on quaternion methods to aim at targets, but both methods'll have ways to clamp them. In fact, based on how you can bolt these guns to different parts of your car, and, the ones to be limited are all going to have straight barrels stuck to them, do you ever in fact ever really have to calculate these values on a per barrelled gun basis? You'd think all these barrelled guns would share the same maximum arc range per slot. I'm sure you've thought about that and concluded that you need to do this, it just seems like a surprising result to me. Maybe it's due to when you have far fewer guns vs bristling with them?
|
# ? Feb 11, 2016 16:12 |
|
Nition posted:Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly. This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right? What are the complications? Just that it's not a tight bound? I guess you'd also need to subdivide any collider that is directly above or below, and mind azimuth wraparound but it seems manageable...
|
# ? Feb 11, 2016 17:55 |
|
Xerophyte posted:This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right?
|
# ? Feb 11, 2016 18:49 |
|
Mastigophoran posted:edit haha ^^^ just said the same thing. Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). Vehicles can get pretty complex and Unity's raycasts are petty slow. To get a decently accurate result on a full turret weapon, raycasting 3 degrees apart say can take 10+ms per weapon, which is too much. The collider checking method is much faster (more like 1ms if that). The same weapon will always have the same base movement range, but I'm calculating places where it can't aim due to other stuff in the way, which can be in all sorts of configurations. You can place a weapon on your vehicle in any spot as long as it can shoot straight ahead - it's not like Robocraft where the full movement range of the weapon has to be free. Xerophyte posted:This seems sensible me, it's essentially just projecting the 8 vertices of each collider to spherical coordinate angles and subtracting a hull that contains them from the valid range, right? What are the complications? Just that it's not a tight bound? I guess you'd also need to subdivide any collider that is directly above or below, and mind azimuth wraparound but it seems manageable... It's highly likely that I'm making this method more complicated than necessary due to having to work out a solution myself. It's easy to say "just subtract the colliders from the range" but the maths involved kills me. Certainly it's gotta be like a type of boolean subtract, but like Rocko Bonaparte said although I know what that is I haven't managed to work out how to actually do it here. Especially since this isn't really comparing shapes against a shape, but more like comparing shapes against one infinite-radius chunk of a sphere.
|
# ? Feb 11, 2016 23:00 |
Nition posted:Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). I don't think this is that big of a deal if you don't recalculate. It actually sounds kind of unintuitive. You wouldn't put weapons on a vehicle with the intent of gaining more motion in them by losing parts during the game.
|
|
# ? Feb 11, 2016 23:45 |
|
Yeah I thought about it, but it's kinda dumb if you don't get the extra movement when you lose parts around it. Besides I do have it working with decent performance, I'd just like to improve my janky code that's not always quite right with the results.
|
# ? Feb 11, 2016 23:50 |
|
Nition posted:Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). Vehicles can get pretty complex and Unity's raycasts are petty slow. To get a decently accurate result on a full turret weapon, raycasting 3 degrees apart say can take 10+ms per weapon, which is too much. The collider checking method is much faster (more like 1ms if that). Comedy answer: Bake in the N-dimensional manifold of range-per-weapon-per-potential-blocker and just lookup the index at run time. Then just calculate the manifold by iterating all potential inputs and flagging bad intersections. Thereby circumventing all maths.
|
# ? Feb 11, 2016 23:53 |
|
Since I want to avoid all maths with that approach, I'll just set up an interface where the game presents me with each blocker set and I then manually drag the appropriate limits. Surely there won't be too many possibilities!
|
# ? Feb 12, 2016 01:09 |
|
Nition posted:Since I want to avoid all maths with that approach, I'll just set up an interface where the game presents me with each blocker set and I then manually drag the appropriate limits. Surely there won't be too many possibilities! Are the parts that make up a vehicle all based on a standard unit size? If so, based on what block units are filled in or not around the weapon, you should be able to limit it that way. It's not polygon perfect but I bet no one would notice.
|
# ? Feb 12, 2016 01:26 |
|
Nah, there are realistically way too many combinations. Although things generally snap in a grid, their colliders can be in various places. And it's quite cool as a feature how you can have guns going through small gaps.
|
# ? Feb 12, 2016 01:29 |
|
Nition posted:Yeah I thought about it, but it's kinda dumb if you don't get the extra movement when you lose parts around it. Besides I do have it working with decent performance, I'd just like to improve my janky code that's not always quite right with the results. If recalculation is the problem, couldn't you calculate at build time the spots that would be opened up if a part was removed? At worst you could calculate the shootable area, then remove a part and calculate the differences, and then repeat for each part that could matter. Then just use that data whenever a part is removed during actual gameplay.
|
# ? Feb 12, 2016 03:57 |
|
Nition posted:
|
# ? Feb 12, 2016 04:05 |
|
I'm pretty happy with how it works now and I'd prefer not to change how the game works if I can help it, I'd rather just get my formula right. Currently I'm trying something like a n00b version of Xerophyte's suggestion.
|
# ? Feb 12, 2016 04:59 |
The worst bugs are when something just won't draw, because no matter what you change you aren't getting any feedback. Is it the coordinates? Is it the camera matrix? Is the shader messing something up? Am I missing a texture or drawing with 0 alpha?? Are my polys backward?? Nope, being clipped by z culling. 2 hours of poking around to be fixed by changing one variable.
|
|
# ? Feb 12, 2016 05:29 |
|
Nition posted:I'm pretty happy with how it works now and I'd prefer not to change how the game works if I can help it, I'd rather just get my formula right. Currently I'm trying something like a n00b version of Xerophyte's suggestion. How much computation does it take to test a single ray against the vehicle's components? Because if it isn't long then instead of precalculating the acceptable range of angles you can just test as the turret is rotated - check the ray of what would be the new position, and if it collides then reject the rotation. You'd be doing at most one test per frame per turret.
|
# ? Feb 12, 2016 17:07 |
|
HappyHippo posted:How much computation does it take to test a single ray against the vehicle's components? Because if it isn't long then instead of precalculating the acceptable range of angles you can just test as the turret is rotated - check the ray of what would be the new position, and if it collides then reject the rotation. You'd be doing at most one test per frame per turret. Yeah, this one would be doable I think. Although I do like being able to show the available range when the vehicle is being built - it helps people design.
|
# ? Feb 13, 2016 03:56 |
|
Nition posted:Yeah, this one would be doable I think. Although I do like being able to show the available range when the vehicle is being built - it helps people design. You should be able to get what you want by using a variation on techniques used to implement dynamic shadow mapping for point lights. I'm not an expert on those, but for example, you might start by projecting vertices that lie on boundaries between solid and void away from the center of rotation of the turret, and rendering the faces between the original vertices and projected vertices, with a fragment shader culling fragments further than a certain radius away from the turret.
|
# ? Feb 13, 2016 04:46 |
|
Ralith posted:You should be able to get what you want by using a variation on techniques used to implement dynamic shadow mapping for point lights. I'm not an expert on those, but for example, you might start by projecting vertices that lie on boundaries between solid and void away from the center of rotation of the turret, and rendering the faces between the original vertices and projected vertices, with a fragment shader culling fragments further than a certain radius away from the turret. It'd be awesome to do the calculation on the GPU with a shader but possibly beyond my skills. It has certainly been interesting how asking a "simple" maths question of how to reduce rotation to avoid collisions has gotten me suggestions relating to robotics, 3D modelling, graphics work, etc.
|
# ? Feb 13, 2016 08:56 |
|
Nition posted:It'd be awesome to do the calculation on the GPU with a shader but possibly beyond my skills. It has certainly been interesting how asking a "simple" maths question of how to reduce rotation to avoid collisions has gotten me suggestions relating to robotics, 3D modelling, graphics work, etc.
|
# ? Feb 13, 2016 23:14 |
|
roomforthetuna posted:This is what makes game development awesome. You get to do all the difficult things that serious computer scientists do, but you're doing it under horrible hardware constraints and just for fun! I like it when you realize the algorithm you need was invented in the 60s or whatever.
|
# ? Feb 14, 2016 00:48 |
|
roomforthetuna posted:This is what makes game development awesome. You get to do all the difficult things that serious computer scientists do, but you're doing it under horrible hardware constraints and just for fun!
|
# ? Feb 14, 2016 07:32 |
|
|
# ? May 18, 2024 22:10 |
|
OneEightHundred posted:I disagree, what makes game development awesome is all of the things that serious computer scientists don't do, like deal with the fact that everything in the game capable of moving will, at some point in development, be launched into the stratosphere by a physics bug. I've talked with scientists who launch capable humans into the stratosphere. Games are awesome because our physics bugs make me chuckle, and their physics bugs do not.
|
# ? Feb 14, 2016 11:36 |