Open Cheeseness opened 10 years ago
What is everyone working on as far as physics goes? I'm trying to introduce some friction / reactive forces so the carts don't slide off hills so much. This might conflict with a bunch of other stuff going on at the moment, but it seemed like the simplest part to start poking at.
I believe @bobsayshilol and @ErikBehar have mostly been responsible for driving physics as we have them now. @MindofKlink is also poking around with some bits and pieces.
I've been playing around with the front forces when pressing the 'A' and 'D' keys. The code so far shows '60' and '-60' respectively and I've been trying to find a good balance at around '5/-5' or '10/-10'. With this, I'm able to tap either 'A' or 'D' key to slightly nudge the cart in a particular direction but if held, it gives very tight cornering. When I release either key there is a slight delay in the camera normalising behind the car. I might tweak the camera mechanics a bit more if everyone is cool with that?
In the 4 player split screen I've been able to run through different carts so at least we know colliding with other players is possible, just need to add collision detection. I also agree with @MattGingerich in that we need to work on some friction/reactive forces. As it currently stands going up any slight incline forces the cart to almost go in a 90 degree angle off of it. I'm still tweaking those and when ready I'll push it into my fork so everyone can test it out before pushing it to the master.
I don't have time to work on this at the moment, but from what I found the best way to deal with introducing friction is to have wheel colliders added as subcomponents to the car model. There's lots of tutorials out there on making cars in Unity, which I think the golf cart could draw upon (someone posted this video in the chat today which I thought was pretty good: https://www.3dbuzz.com/training/view/unity-fundamentals/physics/7-wheel-collider). For all I know, this has already made its way into the build, but hopefully it's still useful to comment here.
Sounds good, @MindofKlink. Try to separate any camera tweaking into a separate pull request if you can :)
Just realised the tweaks I've made to the movement.cs file completely messes up between scenes. I've been basing it off the level_01 scene with the 4 player split screen rather than the car_test_01 scene. WIth the tweaks I've made (-5/5 for left right and 4500 for velocity), it completely destroys the turning in the car_test_01 scene.
It might have to do with the split screen quadrupling the values. Please don't pull anything from my fork just yet until I get this sorted.
In level 1, you can change to single car by turning off the four_Split_view by clicking in the right tab on the first selection box at the top left (right before the name of the object). Then clicking the same on single_view to turn it on. Also, do the same under the UI-objects.
Also, the camera is in no means final and definitely will need some tweaking with turning.
Hey guys.
I've gotten carts with wheels (animated!), acceleration, braking, cart collision (in theory), they can go up hills etc., and there's 360 controller support. I'm not exactly sure how to submit them here, but they're uploaded to my git repo forked from an earlier version of this repository.
https://github.com/Randdalf/bad-golf-community-edition
http://i.imgur.com/lPJrXNf.png
It's pretty fun to drive about!
http://blogs.unity3d.com/2014/01/17/new-sample-assets-beta/ In this asset pack there's a car Prefab that might be a good working Point for the cart also. There's an empty car Prefab where you can add a model and it has lots of settings you can tweek to get the handling you want it to have. If not use it straight off, it might be a good source to pull from. I added a golf cart model to the car model and it worked pretty well after a Little tweeking.
slimline read my comment above, my one has all the basic stuff we need from that lol
After playing around with both, the extra stuff that the sample car prefab provides makes it feel like it's worth using that as a base.
Would somebody be interested in setting that up with one of our cart meshes?
Got a fork commited with a first implementation. https://github.com/slimliner/bad-golf-community-edition
@Slimliner Could you write up a short wiki page in the style of bob's Networking how to to assist cart creators and anybody who wants to try tuning cart behaviour?
Concerning the camera I made a little test by putting a camera target node in front of the car ( [0,1,7] ) and tweaking a bit with the smoothFollow parameters (something like 12,3,2,4), it gives a crazier feel to it... and it allows to see where you're going. The only thing is jittering that appeared... but by putting FixedUpdate instead of LateUpdate in the script it fixed it. Anyway congrats for the work so far !
The skid marks and sounds are funny, but it makes the whole course feel like a black top. Are we planning on replacing the sound with driving over grass noises (basically white noise) and parted grass textures?
I also think it would be cool if we registered the rough area of the course, and when the cart is in this area add external vertical force to the wheels based on a wrapping surface of Perlin noise. Registering rough terrain could also help with Look and Feel (Issue #67), because we could dynamically add grass billboards here using the terrain system.
The skid marks and sounds are just there to be replaced or removed, whichever we decicde. They're ripped from a cargame on tarmac, and are wrong for this game.
I've been messing around with InControl to see how it works. I think the easiest way to handle multiuser input is to have input that's keyboard/mouse and then allow gamepads for the other slots. That way we can when the game starts allow the user to select input device before the game starts.
I didn't see some easy way to allow for random inputs the way I thought at first though, since InControl uses predefined axis inputs and buttons (RightStickX, RightStickY, Action1, Action2 etc).
Would this be good enough? Otherwise someone needs to look at this more and figure out how to do that.
@Slimliner there is a localmulti branch with a test InControl setup if you want to take a look, I've tested it with several gamepads, and it works in general.
It needs some work on making it user configurable so it turns on and off certain things in the scene... I'll probably get on that sometime soon if someone else doesnt
branch: https://github.com/Double-Fine-Game-Club/bad-golf-community-edition/tree/localmulti
The cart should reset onto the course if its y position falls below a certain threshold. It's no fun to fall forever.
Also, having it not be possible to leave the world is probably a good idea too :D
Agreed with Cheese. The course should be enclosed somehow, perhaps by a thick forest that cannot be passed?
We've also had some cliffs and things done in #5
@bc5389 has contributed an automatic respawn script to handle falling out of the map. It's not hooked up to anything currently ( #162 )
Our current cart physics model effectively makes the ball an immovable object when it's collided with. Fixing that by modifying cart dynamics is likely to result in poor cart handling.
Patrick's design notes talk about the gameplay value of running over balls as being about giving your opponents a worse "lie". With this (along with the faster paced gameplay that we are aiming for) in mind, allowing players to roll the ball ahead of their cart feels like it's going to be a poor fit.
Lots of cart->ball collision behaviour has been discussed in IRC. The option that feels most appropriate to me is something that doesn't rely on physics, but instead has us applying velocity to the ball in much the same way as our swing mechanics do (giving us programmatic control over the outcome).
Patrick has highlighted that getting the cart driving aspect of the game feeling fun and solid should be a top priority.
We'll need to focus o making sure that handling and collisions feel right (right meaning fun, and not necessarily real-world accurate).