Hello! I'm Tom. I designed a game called Gunpoint, about rewiring things and punching people, and now I'm working on a new one called Heat Signature, about sneaking aboard randomly generated spaceships. Here's some more info on all the games I've worked on, here's the podcast I do, here are the videos I make on YouTube, here are some of the articles I wrote for PC Gamer, and here are two short stories I wrote for the Machine of Death collections.
ToastyKen: This actually reminds me a bit of Jason...
Ryan: Create a base state object that has properties on it,...
Jabberwok: I think, in the case of the tumor, we could probably...
I’m working on the grappling hook game again now, and I’ve got the rope wrapping nicely around things, going slack when it should, and even making sounds. In this video I show you how that looks, then – with fair warning – get into how the code works.
Sounds from freesound.org
Retract noise: eelke
Grapple impact noise: taylorsyoung
Tom Bennett: Hey, love how the game is coming along. You said in the vid that your levels will only have 1 or 2 buildings similar to gunpoint, but I was wondering how much grappling you would be able to do if it between only a couple of buildings?
Causeless: Here's what I said on youtube, if it's any help:
"Messing with angles to determine when to unwrap seems REALLY weird. Here's what I consider a more correct way - Cast a ray to both the current grapple point, and that point's parent (instead of just the parent as you were doing before). If you can see both, then it'd unwrap.
You may think this would cause issues if you traveled around an object completely, but then you'll have created the new grapple points in the process of spinning around it anyways.?"
About the grapple rope going through things... that's a much trickier solution. It's delving into the realms of continuous collision detection, which is a crazy huge issue that's been around for ages.
It's much easier to find a solution which works "usually" than it is to find one that works in every case.
The easiest solution is just to check for collisions more. Instead of checking every rendering update, check every physics update which happens a lot more... of course, at even higher speeds (or with even thinner objects) it's still miss.
The harder solution is to check against object's corners for collisions instead of the whole thing, and then do some maths to find what corners are within the rope angle change between the previous frame and the current one, and then sorting them to ensure the new grapple points are created in the correct order. That *should* work in every situation, and will give improved accuracy to your current sim (where in some cases the line hits away from a corner then cuts through the object).
That is probably too much trouble to be worth it, though.
LTK: It's really interesting to see everyday physics being modelled in a game that has no prior preconception on how these things should work, whereas we all have a (mostly) intuitive understanding of what happens when a weighted rope gets caught on an object in mid-swing. It kind of makes you appreciate both the inherent complexity of physics as well as the challenges faced by programmers daily a bit more.
Clark Redd: Will this game eventually have human character models or will it star a rectangular prism?
Micael: Hi, the problem of the physics only checking X times a second is due to a setting called Fixed Timestamp (I believe that's the name), which is by default 0.02 (1/0.02 = 50), which is also the reason why you should use fixedupdate since it's framerate independent, you can just decrease that value to say 0.01 and now you have double the fixedupdates, OFC this requires more performance, but your game is already extremely light so it's a non issue.
You also have physics options about penetration and the way such things are calculated to make it more accurate.
Looking at your code I would advise that you stop commenting every line of code, unlike what you might think commenting everything is a bad coding practice, comment only when the code itself isn't clear about it's purpose. Comments get quickly outdated leading to programming errors, adding to that they reduce the ability of one to see a bigger scope of the code on the screen, since at this point half the lines are comments.
Also for commenting methods/functions use XML comments which appear on intellisense popup making them far more useful than regular comments, since they describe the method/function and it's parameters, all without even having to go to definition.
I would advise a quick read of a introductory book to c#/programming like head first c#, and something like c# in a nutshell as reference book, somethings mentioned in those books will not work in unity OFC, but most stuff does apply.
If you do not wish to spend time reading I would at least advise you grab a trial of visual studio 2013 (something above the express edition), and the trial of resharper since resharper will suggest alternative ways of doing things, will indicate unused variables, possible null references, and introduce you to lots of c# features that you might not know about, all around it will make your code far better, with very little time investment.
ghosttie: Just out of curiousity, what happens when you wrap the rope all the way around an object? Can you unspool it by going back around the object in the opposite direction?
I think the solution to the floating blocks is airships - they're higher than any building and so would allow you get on top of any any building, plus they move around so that adds an extra layer of complexity.
Alex: I tried doing a hiking/climbing game with ropes, I got to the point where I could wrap around object, but unwrapping...god that was awful, I spent month without succedding, (I still havent ) ! Glad you did it !