[WIP] pinball

ah cool, thats really good feedback, I did think of end control points being able to move at the same time, but opted for single, again, i'll have to add a key modifier in there.

I know what you mean by control points too close together and trying to select them, again like you said, a control key modifier would work :), when not holding down control you wouldn't see control points.

i'll get those one-way gates in asap.

with the exporting, I guess I just like to manually select and copy, but yeah, I can still load up the text and automatically copy it for you.

groups is the next big thing, I'm planing on adding in group sub editing and groups within groups, group coloring, layer coloring, group naming, object/group rotation, just some features that make editing easier, maybe a zoom key too :)

Render - sounds like a great idea, I unfortunately don't have the skills to do that, i'll create a "load background image" button for you to see and play :) (I was going to do this anyway as I need that functionality to build my table)

slight, I love your table right now, really professional looking, because you have been able to create a table that is so good I'll really try to make the editor as best I can. I wasn't planning on releasing it publicly because actually playing the pinball game might require some programming within flash, and I haven't actually created a standalone "pinball API" yet. But I'll try to keep a developer swf which is just the engine and possibly release it in the future. Would be really nice to port to Adobe AIR and wouldn't be too hard ;)

Yeah, I almost mentioned zoom. zoom would be sweet.

This whole thing has got me thinking again about making a flash pinball. Though the math in your collision methods is probably far above my head. A precalculated bitmap containing a surface normal and/or object ID for every pixel where collision occurs would suit me better, because I am a dirty cheater. :D

edit after seeing your edit:

Cool, glad you like it. Yeah, I figured it's going to be tricky to get decent gameplay without code, some kind of quake 1 style entity editor that lets you chain inputs and outputs together with logic gates would be an awesome thing indeed, but the amount of work in creating and managing that, plus the limitations it would carry probably make a pinball API for developers the better option.

Or I could just design a table or two for you to code if you're interested in that, it would probably be the simplest way. ;)

Quote:

---

Originally Posted by mr_malee

Ray, so you're saying that on every collision dampen the ball's velocity?

---

Well, no. Not every collision. If you are willing to take this the extra mile to simulate as close to real-world as possible, there are a few different "properties" to the objects a ball can collide with.

First, there are the "rubbers". These are found around most objects on the playfield. Its VERY bouncey rubber. I'm not sure you'd need any dampening to simulate this.

There are plastic and metal channels. There's quite a bit of dampening on colliding this type of material. For example a ball entering a "channel" at an angle wouldn't bounce side to side. A steel ball has a lot of mass, and a thin metal rail or plastic won't reflect much of the impact energy.

Flippers, are plastic with a ring of rubber, but this rubber is stiffer than that found around other playfield objects. I've watched the ball come down the full length of a playfield (velocity determined by gravity and table slope angle) and upon hitting a flipper that was already extended, the bounce back was only about 3 to 4 inches.

Lastly, I don't need to tell you this, but there are parts with "kickers" that specifically knock the ball away, and this of course would increase the ball's velocity.


Tell you what, my pinball machine still isn't fixed, but I can probably set up and record some manual experiments showing a ball striking various parts, using only gravity-based velocity. It's not perfect but could provide a good reference for comparison?

~Ray

you need to allow for obstacles that can move.
you need to allow for obstacles that can catch the ball and then move the ball

Ray, I don't think I want to go as far as simulating different rubber properties. I'm using a very basic system atm, friction and bounce. But yeah any references you can give me would be great. I'm not trying to create a super realistic pinball game, just a bare ass one.

blink, I would like to add moving objects and have angular, linear velocities on them which both modify the ball and the object itself, but this engine is far from a rigid body engine, far far from it.

At a certain point realism won't add much more to the game. In all honesty the chances are absolutely zero that people will recognize "Wow, that rubber is simulated really realistically". It either looks real or looks fake, and right now you are looking pretty real.

There may be some physics glitches, but at the moment its a pretty fun simulation. I think that friction and bounce are more than enough to finish up the physics, after that I think interactivity (Of the table) becomes more important.

I think it would be better to implement what Ray suggests by adding a single extra variable per surface, rather than hardcoding properties of different materials.

Right now you have 'bounce' on some surfaces but not others, although personally I would call that property 'kick' or 'push' (I'm assuming that 'bounce' currently adds force directly along the surface normal as a kicker should, rather than multiplying the bounce velocity without affecting direction, but not sure 100% if this is the case or not in your engine.

In addition to 'kick' you could have 'dampening' or what I'd call 'bounce' and combining kick and bounce would let you make all sorts of behaviour.

For example, the rubber slingshots at the side would be bounce: 0.95, kick: 4. Regular rubber parts would be bounce: 0.95, kick: 0. Kickers would be more like bounce: 0.5, kick: 8. Drop targets you want to stop the ball before it hits the rubber behind it, so you'd use maybe bounce: 0.05, kick: 1. The point is to leave it open so that you can tweak individual parts to get the behaviour you want.

You could possibly even get rid of your second class of objects, and give every surface these two properties, even though most of them would be kick: 0.

Also consider negative values for kick and bounce could be used to define non-solid surfaces that slow down or accelerate the ball, either along it's current vector or toward a vector determined by the surface.

edit: actually, if you are using friction and bounce already, it's probably what I was referring to above as bounce and kick respectively. All you'd need to do is allow default friction to be overridden per surface in the XML.

I agree with Ray and Slight, you need some rubber effect, especially on the flippers so as to allow some level of finesse rather than just smacking the balls around.

You also might want to add some basic tilt ability in your control scheme. Bumping the pinball machine gently at the right moment in order to control the pinball's path is one of the key aspects of the game.

It's difficult to simulate the force of the tilt, so most pinball progs I've played use a combination of the time the tilt keys are held down together with the frequency of their combined usage to determine when to tilt-freeze the game.

note - I can already tell I'll be "wasting" several hours on your game and editor, so kudos to you from the start! :)

Quote:

---

Originally Posted by slight

I think it would be better to implement what Ray suggests by adding a single extra variable per surface, rather than hardcoding properties of different materials.

---

yep, will add that tommorrow, the good thing about the editor is this can be done basically with xml :)

Quote:

---

Originally Posted by slight

Right now you have 'bounce' on some surfaces but not others, although personally I would call that property 'kick' or 'push' (I'm assuming that 'bounce' currently adds force directly along the surface normal as a kicker should, rather than multiplying the bounce velocity without affecting direction, but not sure 100% if this is the case or not in your engine.

---

yes, the force from a bumper collision uses the collision normal * bumper.bounce.

Quote:

---

Originally Posted by slight

In addition to 'kick' you could have 'dampening' or what I'd call 'bounce' and combining kick and bounce would let you make all sorts of behaviour.

For example, the rubber slingshots at the side would be bounce: 0.95, kick: 4. Regular rubber parts would be bounce: 0.95, kick: 0. Kickers would be more like bounce: 0.5, kick: 8. Drop targets you want to stop the ball before it hits the rubber behind it, so you'd use maybe bounce: 0.05, kick: 1. The point is to leave it open so that you can tweak individual parts to get the behaviour you want.

---

yep, going to add that too, every "collision object" will have these new properties:

bounce (the elasticity of collision)
mass (mass of the object, 0 will just mean infinite mass)
friction (friction of collision)

bumpers bounce will change to force.

Quote:

---

Originally Posted by slight

You could possibly even get rid of your second class of objects, and give every surface these two properties, even though most of them would be kick: 0.

---

Certain objects might need functionality in the future so I'll keep the classes for now.

Quote:

---

Originally Posted by slight

Also consider negative values for kick and bounce could be used to define non-solid surfaces that slow down or accelerate the ball, either along it's current vector or toward a vector determined by the surface.

edit: actually, if you are using friction and bounce already, it's probably what I was referring to above as bounce and kick respectively. All you'd need to do is allow default friction to be overridden per surface in the XML.

---

this is a weird one, atm, you could create that effect by subscribing a collidableEvent object to a listener which slows the ball down whenever it collides. I want to keep collidable objects as collidable objects, if I add semi-collidable objects its just going to get me confused ;)

so if you did want this functionality I guess you'll have to wait till I develop an developer API :)

Quote:

---

Originally Posted by JerryScript

agree with Ray and Slight, you need some rubber effect, especially on the flippers so as to allow some level of finesse rather than just smacking the balls around.

You also might want to add some basic tilt ability in your control scheme. Bumping the pinball machine gently at the right moment in order to control the pinball's path is one of the key aspects of the game.

It's difficult to simulate the force of the tilt, so most pinball progs I've played use a combination of the time the tilt keys are held down together with the frequency of their combined usage to determine when to tilt-freeze the game.

note - I can already tell I'll be "wasting" several hours on your game and editor, so kudos to you from the start!

---

yeah, tilt will be in, not sure if I'm going to add that to the editor though, something that will just exist. I'm not sure how easy/complecated it will be, off the top of my head I was just gonna modify the ball's velocity randomly and check if the player tilted too much in a certain time threshold.

and about the rubber on a flipper, I dont really understand what you mean by that, you want the ball to receive a force even when the flipper is static? and possibly when the flipper moves?

I'm gonna leave the flippers off for a while, I need to concentrate on getting the game done, then I'll go back to them with a fresh perspective, and bug you guys again :)

there'll be an update tommorrow, I have added functionality to the editor but its not working the the game yet. Prepare for groups :D

"off the top of my head I was just gonna modify the ball's velocity randomly and check if the player tilted too much in a certain time threshold"

If it's any help that's pretty much how I've done it. I've not gone for a "directional" tilt, you just basically shove the bottom of the table forcing the ball up.
In saying that, I've not quite nailed it yet, at times it can look a bit like blow football.

Squize.

Just checking in to say that it's looking very sexy so far.

i never actual try tilting when i play pinball, I get caught up to much in the frantic gameplay, anyone know what should actually happen? assuming that the player can only push the table up, left and right

haha. now your moving those objects.
the tilting is generally in an up/down direction and usually done with the hip. if you use your right hip it tends to push the machine left a little and vica versa. but mostly up down

For a tilt by pushing up on the machine (simplest) you just add velocity to the ball in the down direction.

The tilter will usually push the machine when the ball is near a bumper, usually at the begining to a drain for instance, hoping to move the pinball down so that it bounces against the bumper rather than draining. Good tilters will move the machine side to side as well for the same reason, to finesse the ball to a desired position.

Whatever force you add when player hits tilt, you should remove once tilt is released.

Pushing the table up accelerates the ball down faster for the brief duration of the tilt, then accelerates it upward. Timed correctly with a collision, the ball bounces much higher.


Left/right tilt is way more effective at the close end of the table than at the top, because you are physically pivoting the table on it's rear legs, you more or less shift the front of the table under the ball so pushing right with your left arm makes the ball drift left relative to the table without much change to it's direction once the tilting finishes, usually you do it when the ball is just about to hit the middle of a lane separator pin to make sure it bounces into the lane you want.

What you guys are calling "Tilt" is actually "nudging". Tilt is the outcome of nudging too hard, and the machine halts all input, flashes "TILT!" and the ball eventually drains out. They do this because people would otherwise lift up the entire machine which is not only cheating, but can damage it when it falls back to the ground.

Nudging in simulations like this one is nice, but not all that useful. However, you have to have this feature because you never know when conditions will happen that cause a ball to stop somewhere. The player needs the nudging ability to get the ball moving again.

(PS: Didn't have time to make the video today. Sorry!)

I have recorded some video footage, and begun uploading them to Youtube. Unfortunately, I'm not a great speaker, my table was not angle-calibrated, and all in all, this might all be less than helpful.

But enjoy anyways!!!

http://www.youtube.com/user/thingies4U

^^ weird, the titles are all there, but I see four short videos of ants or termites or something?

Still uploading. It's taking forever. I'm on video 10 of 12

cool, nice video, I think my game is not apply the slope of the table correctly, instead of me using just gravity, I think I need another number, tableSlope. And combine the two to get the y force. maybe something like this:

gravity = ((1 - (ballPositionY / tableHeight)) * tableSlope) + gravityConstant

ballVelY += gravity

ballPositionY += ballVelY

does that seem correct?

I'm gonna fix up the physics to allow for masses, elasticity and friction of all objects. When thats done I can just tweak the numbers. Thanks again for the reference video, helps a lot.