In considering the design of marble-in-maze games where you tilt the table to get the ball to the end of the maze without going down one of the holes, I wonder whether anyone here has considered the modelling of the sound of the ball hitting the walls...
The ball doesn't always make the same sound.
This other question covers the rolling sound:
Sound of a rolling ball
But I am more interested in the bouncing sound - I am often struck by how unrealistic it is in most people's version of the game.
What are the factors to consider to work out how to produce a realistic sound?
How must the sample or raw data then be processed or generated?
There are some good links in the Sound Modeling section of this page from a course at Carnegie Mellon: http://www-2.cs.cmu.edu/~djames/pbmis/index.html. The instructor, Doug James, is now at Cornell as does similar research there (http://www.cs.cornell.edu/projects/Sound/).
I've never tried to implement any of these methods, but I suspect that they're overkill and/or too slow for a small game. However, you might be able to generate several samples offline and choose an appropriate one at runtime.
Hope that helps.
Related
so I've been trying to see if I can make use of Wheel Colliders for the past several months now. As much as I've managed to figure out more and more things about how to set them up properly, there's some things I've been noticing that seem impossible to avoid:
Even if your friction sideways stiffness is lower, there's a chance that your car will continue to "spin" or "rotate" in the direction you were steering if you JUST hold down your input long enough to get the car beyond just rotating. I've noticed this will happen, whether for example the "SteerHelper" or "TractionControl" functions are doing their work or not. This will put a dent in ensuring smooth turn movement. Now, I don't know if maybe this is just due to realistic car physics (I mean, I can picture the car skidding in scenarios where they lost grip of the road for sure), but it just feels kinda glitchy. Sometimes, even when I'm not turning, the car will start to turn a little to the left or right and then gradually seem to "lean" that way in terms of applied torque to the rigidbody. I've seen many suggestions for trying to stop the rigidbody from doing this. Here is one way I'm trying to work against this:
rb.AddTorque(-rb.angularVelocity * 2);
However, it seems that the car will still "spin" more than intended. What would be ideal is to be able to MAYBE allow the car to turn a little extra after the left or right steer buttons were released (maybe more or less depending on the vehicle), and no more than that to ensure there is maximum control to give the engaged and maybe arcadey game play I've been going for for a long while.
It's been difficult to adapt an ideal friction curve value that would give the most ideal feel of a drift turn, especially a more arcadey one. I'm not trying to go for wide turns that slow you down, I'm trying to go for tight (yet controllable) turns that allow you to preserve most of your speed. I find that especially at higher values of stiffness, as I know many people have observed in other posts, that again, the car will turn back an extremely high amount sometimes (you drift left enough, a force is turning your vehicle way to the right). It's sad, because I've wanted to be able to say I've "mastered this beast" and used it for my purposes, but I don't know if that's really a good practical expectation for anyone. I even worked my own alternate friction curve values that would be used in the controller:
But I guess as some people say, you can't polish something that's broken? Moving to the third point...
I've read so many posts that show how to adjust a vehicle's center of mass, or to add more colliders in different spots to correct it, using scripting to add an offset to the center of mass, etc. So many tips that say, "lower the center of mass, you'll find it" and I give that a try. When the center of mass is too low, my car can get pretty shaky on the terrain (not that it hasn't in the past, but it's often been things I could correct, like the weird initialization of the attachedRigidBody of the wheel colliders themselves in the beginning, etc). High enough, and of course, (even when it's lower sometimes???) the car will just start spinning in the air on either multiple axes or specifically the forward z, when you drive off a ledge or bump into something with a high enough speed. It just seems inevitable.
I've been trying to give my benefits of a doubt. I like to think there's a correct way to use this thing, and that I'm just not familiar enough with Unity3D physics concepts. However, it just seems more and more that I'm investing too much time in a broken component - or, maybe I just never got the best grip of physics.
I was about ready to try just convex mesh colliders around my tires, and just abandon the idea of gripping physics altogether, but I'd love to hear suggestions to either address anything I've mentioned above, or just a more ideal package to move onto. I've glanced at packages like Vehicle Physics Pro, but I do want to be sure I'm getting something that makes sense.
Full disclosure: I'm in the middle of trying to make a game that feels incredibly similar to F-Zero, but with wheels.
Thanks in advance for any thoughts or suggestions you can provide.
(Maybe not an answer per se, but hopefully helpful.)
Note Unity also suggests to possibly give the car a constant downward force via script. It might be telling that such workarounds are officially given, one would think proper physics would, well, properly work without them.
There's some assets you might want to give a try generally:
One is the Unity Asset Store asset called Arcade Car Physics, and it's free. I've tried it and it works (but not sure if it works for your needs). It's using Unity's native Wheel Collider plus extra scripts.
Another is the Arcade Car Physics github project. It has nice plane stabilization and more, and works well. It's not using the native Wheel Collider.
Then there's this asset called Vehicle Physics. Instead of native Wheel Colliders, they've create a fully custom wheel system so that it would be more physically workable. The asset is not free, but they offer a free demo executable where you can drive around different vehicles, and that works quite well. (I haven't yet bought this asset myself.) As a downside, some reviews mention there's some complexity in setting this up (and I suppose future support for this custom Wheel Collider hinges on the company continuing to exist).
Good luck!
I'm wanting to figure out if a user is not moving at all, walking, or running using the iPhone. I'm not trying to implement a pedometer. I just want to know around about if someone is moving briskly, slowly, or not at all. I don't need mph or anything like that.
I think the accelerometer may be able to do this for me, but I was wondering if someone knows of any tutorials or example code that might be able to point me in the right direction?
Thanks to all that reply
The accelerometer won't do you any good here - it will only capture changes in velocity.
Just track the current location periodically and calculate the speed.
There are no hard thresholds for walking vs. running motion, so you will have to experiment a bit. The AccelerometerGraph sample code should get you started on how to get and interpret accelerometer data.
The Accelerometer is good, but if the user has an iPhone 4 or iPad 2 you should use the gyroscope.
CMMotionManager and Event Handeling Guide - Motion Events
Apple Documentation is the best example you can get!
People have a different bounce in their step between walking and running which can be measured with the accelerometer, but this differs between individuals (what shoes they are wearing, what surface they are upon, what part of the body is attached to the iPhone etc.), and this motion can probably be imitated by shaking the iPhone just right while standing still.
Experiment by recording the two types of acceleration profiles, and then use some sort of pattern matching to pick the most likely profile candidate from the current recorded acceleration data.
I'm working on a 2D game (kind of like a top down space shooter) for the iPhone using an engine very similar to cocos2d (not exactly though) on OpenGL ES. I'm trying to figure out how I'm going to do collision detection.
All the ships for my game are images, and the game will load the image as a texture onto the screen. I've got very very simple detection going already that basically just takes the rectangles of the images and checks to see if those collide and can do that just fine.
But, of course the ship isn't perfectly taking up the entire rectangle so there is whitespace in there. So my question is how am I supposed to account for that whitespace? Do I have to have the matrices of the ships stored? Or is there another way? I've also heard of possibly using the Chipmunk physics engine for collision detection? How would that work?
(1) regarding Chipmunk, the short answer is yes you should immediately download chipmunk, donate something to the bloke, and start learning about it.
Working with that for a day or so will basically answer all the questions you have. If you want to work with physics games you're going to need to get in to it.
(2) you ask about using an approximation ("just" a rectangle) instead of something more accurately shaped like your spaceships. In fact, you'll be perhaps amazed to learn, that is precisely how it is usually done in all your famous big-name games you've played since we were all kids! Indeed sometimes you might use little more than A DOT (!) to detect collisions.
What you'd probably do in production is try a more complicated model, and play with it for a few hours and see, is it actually any better to play with than your simple dot or rectangle model.
If you do want to make a more complicated model -- just make one! Build it up from three or four rectangles using your current system. Try them "all against each other", and have "one big one to check first" to see if it is even anywhere near each other (sort of a simple spatial hashing).
You will find that when you do it with Chipmunk, which as you now know you have to immediately begin after reading this message, you just build it up the same tedious way. It's not a magic bullet. But if you were going to use a "more complicated model" yes it is better to go with something standard, chipmunk, to do the work in - it will get done quicker and better. There is heaps to learn and you should hop to it!
(3) Unity is not just for 3D Finally if you want to do it the smart-ass grown up way, you'd have to use Unity3D which will let you access the very metal, the Nvidia physics on the chipset. Note that unity works perfectly for 2D games also - you just click one button in unity to use a 2D projection (many brand-name ifone 2D games are done exactly like that).
If you use that approach, you can (if you want) have "absolutely exact" physics, with every nook and cranny of your model modelled.
What is the downside to doing this? Ah hah ... well the thing is, you need superb actual 3D models of all the stuff in your game! (Like you see them building in the "how we made the movie" special features that come with your favourite Pixar blu-ray.) To do that you need things like autodesk, maya and the like. you would quite likely buy some models ready-made from a digital prop shop (no need to build "a chair" as it has been done 1000 times already and you can buy one for ten dollars).
(Unity3D is completely free to use for a few months while you see if it can make you money.)
Incidentally on the Chipmunk front --- you can just use Corona which is ridiculously easy to use and has chipmunk-like physics completely built in with zero effort on your part! You could have the whole game done in less time than it took to write this email. You could be selling your game already and thinking up the next one. Or, you could use "Cocos" which indeed has a chipmunk-like physics library built-in .. personally (just me) I do not like and won't touch cocos - but of course many games use it.
(It seems pointless, to me, using cocos which is a "for idiots" product, when you can just go ahead and use Corona, which is a "for idiots" product but stupendously easier to use, 1000x more solid, and probably literally 10x faster to finish your product and start making money.)
Noel Summary:
So in some sense using Unity3D (and hence, the actual nvidia physics on your computer's chips) is the ultimate solution if you want detailed nook-and-cranny collisions. Going down one step, Chipmunk is exactly, precisely what you should be using on the ifone/ipad for 2D physics -- it is precisely what is used in all the famous games we know so well. You have a bit of learning to do so hop to it - it's superfun. Finally go right ahead and just make your current model more complicated if you wish - roll your own by adding more rectangles!
And the fourth point is, be sure to remember that in games, astonishingly, you can often get away with remarkably simple physics (often SIMPLER!! than one rectangle - just a damn point - ie, simply measuring the distance between centers!) Fifthly after going to all the effort of testing more detailed physics, you would play test one against each other, and find out what is the simplest physics you can get away with.
I am hoping to build an application similar to those egg shaking applications, to better understand how to detect motion on the iphone. I've been looking at accelerometer methods and motion and motion methods, but can't seem to get working what I want to do.
The specifics of my need are as follows: I want to be able to play one sound when user shakes the phone away from them, and play another sound when they shake back towards them. The motion from the user would be very similar to an egg shaker, with two different sounds able to be played depending on whether they moved the device towards or away from their chest. It would also be good to measure the intensity with which they moved away or towards.
Any ideas?
I've searched apple's sample code for a similar application, but there doesnt seem to be one.
Look at this game which is open source and makes great use of the accelerometer. It's a good one to be able to tell which direction you are going, but I haven't messed around much with intensity. I'm sure it's easy enough once you get into the details.
http://github.com/haqu/tweejump
I am working on a Labyrinth style app for iPhone using Chipmunk and openAL. I got everything working except the ball rolling sound. What I have tried is playing a small sound for each update in the ball's position so that the overall effect sounds like the ball is rolling. Based on advice on this forum I tired using velocity of the ball to adjust pitch of the sound. I have the following problems:
I cant hear the sound at all when I am playing this sound in a chipmunk call back. I can hear it elsewhere.
Even if I got this working somehow, the sound I should play has to be very very short as the ball doenst take too long to roll. THere has to be a alternate way.
Can anybody please help? I can even pay for a simple application that did this if the sound is also included.
I recommend cheating... record (or find somewhere) some longish looping sounds of the ball rolling at different speeds. Have one of them playing, based on the speed of the ball. As the ball's speed changes, you can cross-fade from one sample to another. My guess is that that will sound more realistic than just varying the pitch of a single sample.
Of course, it may be enough just to have one longish looping sample, and only vary the volume proportional to the ball's speed. I'll have to go track down my labyrinth game and check. :)