Sorry your browser is not supported!

This has actually gotten to be over 2 weeks old now due to difficulties with uploading, but here is just something I wanted to try to see how well it might come out. So far I like it alot, but there is going to be one major hurdle, and that is very reflective reflection on the lane. The reflectiveness of the lanes is an integral part of the 'bowling experience', and so I'd like it to be implemented as effectively as possible. And looking at photos and video, it looks like it would be fairly difficult to recreate at least pretty closely.

And a screen just to see what it is...

Good job
I am a little confused as to how to aim the ball. I need to aim to pick up all the splits I am leaving.

Have you tried Dark Physics if so how does it compare to Newton in your opinion?


p.s. I bowled a nice 245 on my Wednesday night League

Yes, now that I'm home I can describe the demo in a bit more detail...

You will notice some of the 'skeleton' of Newton Demo 02 left over, as this is what it was built around. I was having the strangest problem in that if I tried to write my own program from scratch that if I tried to use "NDB_NewtonCreateConvexHull" AT ALL in my program, the program would crash. But, the Newton Demos that used this command all worked fine. The error was very strange. If I tried to write even the simplest program that used NDB_NewtonCreateConvexHull, it would crash immediately upon reaching that command. But the demos worked fine. I still don't know why this was happening, but starting with Demo02 (the one with the rigid bodies), and stripping parts of it away, I could then get to the core of what I needed to start with, and so I did. I'd still like to know why I couldn't write my own program using a convex hull that wouldn't crash.

But anyway, so the core of Demo02 is mainly what's in place, and so to grab the ball is still in that Newton demo's funky way of grabbing objects. A bit strange, but once you get the hang of it, it's not so bad (it mostly depends on where your grab lands on the ball). All of the strength, aiming, spin, release, etc. of handling the ball will be a very important part of the game, and so that part will have to be designed very carefully; I'm thinking of some kind of aiming arrow and a click-meter like a golf game, but I'd also like it to be challenging. In any case, the rubber-band-grab-method probably won't last much longer.

I think the physics look just fine, after watching alot of bowling video. Probably about as close as I think I could get it, so the aiming, spin and throw part should be just as good, hopefully.

As I said, this version is actually a couple of weeks old now, I've added a couple more things since this version. I have a pretty well unbreakable system for determing if a pin is standing or not, and that was an imprtant thing to get done..maybe not as easy as one might think. It's not as simple as just asking "is the pin standing or not"...hehehhe. I thought it might be that easy, but turns out it's not. You actually have to do some math.

So with that, I can start the scoring system, (bowling) frame by frame, and I'm not fully brushed up on that yet..but not to worry I have plenty of sources that describe how it's done. And did you know, if you hit a pin, and it goes sliding way across the lane but some remains standing, it still counts as standing? If it slides 3 feet out into the lane, but it still standing, it still counts as standing. I never knew that, but the system I have in place can still account for that.

Apart from any of the mechanics of physics or workings of the game is the graphics side. Since the physics and action is so good (maybe?) and pretty well reliable, I'd of course want to make the graphics of the alley, lanes, and objects to be as top-notch as possible. It could really be a great showcase for DB, though I'm sure TGC would have other ideas since they have their own physics system now (drool). But for myself, I'd like to make it as graphically impressive as I could, and the high reflectivity of the lanes is probably my biggest concern. It's just not easy to replicate that kind of look. I'm convinced that the shiny lanes must be a part of the overall look, at least that's how I'd want it to look. I know there are lanes that are 0% reflective, but that would be in an alley probably from the 20's or something that is so worn that wood is fuzzy on the surface. I've seen lanes like that. Maybe that would be in the first 'level' of the game, where you start out playing at the old cheap lanes, but eventually you'd need to be able to get the fancy lanes, as a reward in the game.

Codger: Yes, there is no keeping track of scores from ball to ball at the moment. I was working mostly on the working part of the game; the physics and action. Try using the Right mouse button to grab the ball, and you can roll it to the side a little to go for that 1-3 pocket.

Also, the screen shot might show a different version than I've uploaded here: I implemented a replay system too, and I was surprised at how cool it came out. You can record a perfect frame-by-frame replay (up to 10,000 frames), then play it back at full speed, or any amount of slow-motion that you want. But, that may not be in this version, I can't remember. The other keys should work the same though.

I haven't tried Dark Physics yet, Codger, but of course I would like to. I heard it's something like $60 though, so I'm not sure how soon I'd be getting that. As good as it sounds, I have to again praise the Newton wrapper for what it allows us to do with rigid bodies, for free. I haven't even tried one other part of the wrapper, been having too much fun with the rigid bodies. I'm glad to know an experienced bowler checked it out though, and so far it has met with approval. I'd like to make it as fun and good-looking as possible, so hopefully I'll get there.

You need to have at least one memblock command in your code or else you'll get an error, as tree collision and convex hulls require memblocks to create. Otherwise the memblock functionality is left out of the EXE, due to the nature of the compiler.

I figured it must have been that, but didn't remember seeing any memblocks commands in the demo's codes, so I disregarded it as the cause. Thanks for the info.

Some new screens of how it's progressing...using a new reflection technique. I have another post in the DB Pro Discussion area concerning a Z depth problem, but this is concerning the game as a whole.

First, showing how great this fake reflection is working...perfect!

And here is the game as it looks as a whole...

Also you can see the scoring display in action which shows which pins have fallen or still standing...

As soon as I get past all the graphical hurdles (if they can be surpassed), I can start working on game play (interface/mechanics/scoring).

I've since added another light to the room (the 'house lights'), and this has made my objects look a little bit differently (the polygons become more apparent with harder lighting). So, I'll have to do some more work on my models , just a little. These are actually the low-poly version of the pin models at around 720 polys per pin. The originals were more than twice that per pin, so I had to try and cut them down some. They would actually roll better with a higher polycount; you can sometimes see the 'chunkiness' in their rolling when they roll at a very slow speed. Because it's made with NDB_NewtonCreateConvexHull(), a higher polycount would actually help them roll more smoothly. But it's not even perceptible unless you're VERY close to the pin, and it's rolling VERY slowly, so it's not even worth mentioning, really, except that they would look that much better. But since there is the added benefit of the having the physics work better, it's probably worth trying...a high- and low-poly version.

This the high-poly ball too, more than 1200 polygons alone in the ball. Most likely, that's way overkill, but I wanted to try it anyway, so I could have a smooth ball, along with the actual-geometry finger holes where they were just textured on before.

So, I guess I'll show some pictures...

Night bowling?

Have you seen the fire pin? It's cool, it has a flickering light that goes with it that lights up the pins around it with a yellowish light...

And after all my problems with the fake reflection technique, I finally got it fixed...

This is showing a sort of TV cam right now, but it will probably become some kind of scoring screen, as well as for replays...

looks cool

Nice job, I see your very well structured with your camera programming techniques.

Physics is something that I haven't ever really learned properly. Gerat job.

Well, I don't claim to be a physics major, but without having to program your own physics routines because of Newton or maybe Dark Physics, using physics in your program becomes much more viable. If you have a project you'd really like to get done, I strongly encourage you to try one of the physics packages. If anything, it's a heck of a lot of fun, even if you're just throwing objects around and watching how they react. Then to actually build something, that actually works, well, that's just rewarding. Artists build something with their hands. Programmers build something with their minds. Great fun.

I've since reworked my pin model a little bit and is looking much better now. See a previous image that shows some bad shading as a result of some welded points (or were they un-welded? I can't remember), at the poles of both the top and bottom of the pin. Fixed that, and adjusted the reflection to be a bit more bold (I swear, the lane is practically a mirror in most places...very important to get that effect).

Also see a previous image of the ball and it's specular reflection. I'm seriously considering the idea of a 'fake specular reflection'. It would be a small disc, slightly concave to match the radius of the ball, that fits on the ball and is always pointed toward the light source. This would allow me a very nice looking specular, since it could be textured with a very nice gradient of any sharpness desired (either a very soft, gradient specular, or a very sharp one). Though the DB/DirectX specular is good, I would be afforded much more control over how I want it to look. Also, by doing this I can then use the regular DB/DX specular control for added control over the overall shading. Of course, I can only do this for this one object because it's a ball.

[See image]

I was also trying this out, Set Sphere Mapping On. I like it, except that the reflection is unchanging with the camera's view as it should be. I thought that was the reason that the command specifies a 'fish-eye' view of the reflection scene, so that it could change with the camera view. But it doesn't, the reflection is always fixed toward the camera. I didn't want to go through all the work of setting it up, but does anyone know if Set Cube Mapping On will change the reflection according to the camera view? If so, then that's what I'll use. Otherwise, the Sphere Mapping will be used, but only very very subtly (change the brightness/contrast of the sphere map). I wouldn't want it to be very obvious that it doesn't work right, so I would make it barely preceptible that a reflection is there.

Hey, what a cool reflection effect! No need to use CUBE MAPPING, and it's in real-time, and is extremely easy on the frame rate....

Heheh, this doesn't exactly work right, but...

All of the reflection techniques seen here are faked, there's no use of reflection abilities of a video card anywhere...

Uh oh. I just got a 1-hour playable demo of a new game, "Saints and Sinners Bowling". Looks like there is some competition in the bowling arena. I got it at GameSpot, but I'd guess you can get it at other sites too. I don't know what it was made with, but it looks good and plays good. A big difference though, it is made in a cartoonish style. The bowling itself is pretty realistic, but everything surrounding it is cartoonish. There are "charms" you can get for your ball (or the pins, or the lane) such as the "rubber pins" charm or "fill the gutters with cement" or "moon gravity". Each has the effect you'd expect, and they work pretty well.

But what this does is pretty much set me back from making a cartoony-style, fun-ish type of bowling game, since they pretty much got it nailed with S&S Bowling. It's only a 12 MB download, so I'd suggest anyone interested take a look and see what they think of it.

Since I probably can't top what they've done with a cartoony-style bowling game, I guess I'd have to go in the direction of "serious bowling simulation", as boring as that sounds. However, I believe my game has some merits. At least now I know exactly what direction I'll have to go with it (towards more serious). I had been looking at "The Simpsons Bowling" (arcade), and now this new game, to see what they did with "special" balls to add to the gameplay fun. I can't rule out that my game won't have some of those effects (I did make the fire pin, after all...what it will be used for, I don't know)...but for the most part, I see my game leaning towards a more serious simulation, which just sounds boring. But I'm pretty sure it would come up flat if I tried to match all the cartoonish antics they put into S&S Bowling. Any comments from anyone who's checked out S&S?

Looking very nice. I made a bowling game with Newton for the TYTT competition a while ago. It's sat on my hard drive, waiting to be finished and possibly converted to Dark Physics. I also had problems with Convex Hulls for a long time, and don't know what I did to fix it.

It was surprisingly simple to make the basic game. But fine-tuning the physics to make it look real is a huge task!

A graphical treat for all fans of DBP. I've just finished my real-time shadows system WITHOUT Set Shadow Mapping ON. If you didn't know, Set Shadow Mapping ON can kill an application's frame rate. It's great because of its accuracy (like raytraced shadows), but is not without its problems as well. It can cause graphic anomolies (like black dots or other strange effects on your geometry), and can even cause these anomolies on other objects in your scene (like the objects that receive the shadows). And apart from that, turning on even ONE object for shadows can slow a program to a
halt; at least it does in this program. I can't even turn the shadow on for the one ball without it slowing the frame rate down to 20 or less (choppy and unplayable). So, I had to come with a system for shadows.

In this first image you'll see I'm demonstrating all of the effects I've applied for this game so far (with the help of suggestions, though it's all my work). All reflections: faked. Shadows: faked. And my program still runs at the rate I'm expecting, 60 fps. With the shadows, I'm showing that they are in real time; they change as the object moves, which is why you see I'm lifting a pin up so as to change the shadow that it would make. See the shadow matches the pins laying down and the one standing up, and I'm trying to show it for the pin that is mid-way fallen over, but it's hard to show it with just 1 image (an animation, you could really see it well). I can set their darkness/density simply with a call to Set Alpha Mapping ON, for whatever I think it should be for the lighting conditions. The shadows are made with just another textured object, so all it adds to the CPU time would be the same as it would be for adding any other textured object, except that they are only 2-poly objects! (10 of them, of course). Don't mind the large overhead shadow that the pins are within; that's just textured on the lane, nothing special. Oops, I noticed I haven't done the one for the ball yet in this image.

Right now, the shadows only appear 'right' for a light that would be directly over the pins. Fortunately, I have my scene set up almost exactly like this, since there is a usually a light for the pins on each lane (up inside the 'pit'). OK, there is the only hint I'll give. Can anyone guess how this method is achieved?

This image is again trying to show how the shadows work. As much as I'm impressed with these methods, they are only effective on the lane surface. There is no possibility of either the shadows or the reflections following the contours of the scene as they should properly, but that didn't bother me too much, since I'm quite pleased with the effects on the lane, and there shouldn't be a great deal of call for them to operate this way anyway. I'm not sure how much freedom the player will have with the camera (though I'd like it be as free as possible), and I can control what views
they will be able to have at the scene, so it shouldn't be too much of a drawback if these effects apply only to the lane's surface.

My guess is that you have a camera in the position of the light and use the "silhouette" of the pin to make the shadow image. However it's done, it is a really nice graphical demo

I made a render that was supposed to be some sort of a backdrop for the back wall of the alley, above the pins. Alleys have many different varieties of these, ranging from fun styles, to artistic, or other styles. Finishing a complete lanes room will be a challenge to get done. But here is a render I made yesterday (taken from a bowling tournament poster somewhere in Germany, I think), that you can have and use if you want.

Well, that's a good and logical guess, but how would I get an individual pin masked-out from the rest of the camera's image to use as a shadow texture? And how would I get the pin to fill the camera view perfectly to use as an image? I could see maybe if I hid every other object in the scene and left just the current pin visible, but that still doesn't account for getting the pin in maximum view to fill the viewport (for maximum efficiency in use of texture size). Also, that method implies using Get Image in real-time and manipulating that image further to use as a texture. Get Image in real-time is a no-no.

You have the right idea, but eliminate any need to have to grab images from the scene itself...

OK, let's try again. I like lateral thinking puzzles

How about an extra camera and extra set of pins, way out of view. These pins are simply coloured grey, on a black background. You have an additional plain on the floor of the alley, and you set the image of this plain to the second camera. The plain is ghosted/transparent to get the effect of a shadow, rather than a solid colour.

If that isn't how he is doing it then it is still pretty clever!
Game looks great both play wise and graphically.

Hey Bat, that's a very good solution, I never even thought of doing stuff "out-of-view" like that. Hmm..you could have the camera set to the same view in relation to a plane (so that plane is always in the full view of the camera). It would not become part of the final shadow image, but just used for reference in placing the pin for a snapshot. But the way I was thinking would be to have just 1 extra pin (grey, like you said), and position that in the same orientation as the current pin you're checking, and snap a picture (grab an image) for the shadow. But I believe that would mean either:

a.) grabbing 10 images, once per frame (ouch?)

or

b.) having 10 seperate cameras, one for each pin? Though intriguing, i'm not sure it's possible (10 cameras). Too bad though, because "Set Camera To Image" works much better than trying to grab images...

Of the two, I'd like to think I could get something working with the b. method because it seems like that could work. You did manage to hit on an idea I hadn't considered yet though, so points for that...good job.


But I think you'll find this method even more efficient. And this will apply to any DB project, so any DB'ers who miss this thread will be missing a very effective technique:

There are only 2 drawbacks: This method can only work on any kind of cylindrically shaped object. It has to be possible to turn the shape on a lathe, no protrusions. And the other is that it can only work on 1 plane, it cannot follow contours (since the shadow objects are planes, after all). Other than that, you can have perfect-looking shadows, very efficiently. If there are contours to the scene, then you have to use image-hiding and Z techniqes to mask out the over-spill of shadows where you don't want them to show, like I've done in the Bowling program. (Unless people know other tricks...). But, there are definitely situations where it could be used extensively, I'm thinking something like 2D games, or some kind of action-puzzle game where all the gameplay takes place on 1 plane...this technique would be perfect for it. So on to the procedure...

I can give most of it away by mentioning 1 phrase: remember I said the object HAS to be cylindrical? ....
...
...


...

...

Pre-rendered shadows.


I have a series of 30 images, rendered from Lightwave, from a top view of a pin rotating from vertical to horizontal. The pin is colored completely black, but it affects the alpha channel. What I end up with is 30 TGA's of each of the frames from staning straight up to laying completely horizontally. You can imaging the 1st frame is pretty much just a circle, as it's the straight-down view of the pin at 90 degrees. Next frame, you start to see a little bit of the head in the shadow. Next frame, the head is showing a bit more "out" in the shadow...next, next, next...until you reach the last frame which just looks like a silhouette of a pin from the side (this is when it's at its maximum length). This is the shadow for the pin at its various stages of falling over. I mentioned before this technique works for a light that is overhead, but more on that later...

So you can see that these frames represent the shadow as it would be in its various stages of the pin rotating to horizontal. Good, but it has to be applied to the shadow plane rather specifically, or that is, the shadow plane has to be handled very carefully:

It starts out as a plane that is the same width and height of a pin, like a bounding box except that it's a plane (it matches the width and height dimensions of a pin exactly). It also starts out laying flat on the ground (like a shadow), and facing the Z axis so that it can be pointed correctly. Also, its axis is at the very end of the plane, not centered. Think of it as the origin of the shadow, and the shadow extends out from it (like a real shadow). Of course, this origin is placed at the object's location.

Now that the shadow plane is placed comes the more complicated part. The plane has to extend in the direction that the object is leaning. Think again of the pin going from vertical to horizontal. If the pin is standing vertically, then the plane (which begins as the full length of a pin) is too long...it should be more (or exactly) like a square. Remember, the light source is directly overhead. And for the pin laying horizontally, the shadow would be at its full length (size). So not only does the shadow plane need to point in the direction of the object, it has to change size to match the length of the shadow created by the pin. If you picture it directly from the side (the point falling to the right, for example), and imagine the 'straight down light', you can see how the shadow's length would change. Then, instead of the pin falling exactly right, imagine it falling to the right, but a bit away from you, toward the back. This is where the pointing comes in, because the plane has to go in the direction of the object to match. Both are important, the point AND the scaling. And remember about having to be cylindrical? It's funny, by being cylindrical, you effectively remove an axis that has to accounted for in the shadow: the width. The width will never change depending on the light, only the length.

So after come complicated calculations, the plane is pointing correctly, and is sized correctly (length), but it's still in the position of the axis on the object. Think of the pin standing straight up again. We've got the shadow plane scaled to square, and pointing (though it doesn't really matter for this 'frame' of the shadow since it's square {a round shadow, that is} ). But, the shadow is beginning from the center of the object; it needs to be placed a bit further back from where it started, as in, a round shadow underneath a pin standing up. You might think the adjustment to pull it back would come from the width,like I did, but it doesn't....it comes from the method for pointing the shadow:

To determine where to point the shadow (and ultimately which frame of the shadow to use), we need to know which direction the pin is leaned in. You could try to determine this with all kinds of complicated angle calculations, but there is an easier way. Say hello to the "pinbob". It's a small sphere (hidden) that is located
like this:

1.)Place at object's position
2.)Orient to same as object.
3.)Move Object pinbob,dist#.

dist# is the length of the object's positive Y axis. Since the pinbob was oriented in the same direction as the object, what we end up with is the pinbob located at very extents of the pin at the head, whichever way and in whichever direction the pin may be leaning (whether towards or away from you, to the sides, or anywhere in-between). The pinbob is a very important reference locator device, a 'helper', if you will.

The pin bob gives you the direction to point the shadow plane: Point Object shadowOBJ(1),Object Position X(pinbob), .1,Object Position Z(pinbob). The shadow plane was placed at Object Position X(pin(1)), .1,Object Position Z(pin(1)), [[ both .1 on the Y]], so it points to the same height and doesn't become tilted. So now it's pointing correctly, how about the scaling?

There is a maximum distance that the pinbob can ever be away from the pin itself, and that is the full length of pin's positive axis when the pin is laying exactly horizontally. When the pin is standing straight up, then the pinbob's difference is 0. When the pin reaches horizontal, the pin bob is at its maximum difference. Both the image to use (1-30) for the shadow, and the scale (length) of the shadow are determined from the pinbob difference. Obviously a pinbob difference of 0 means the 1st frame (straight up), and the maximum pinbob difference (horizontal) would mean the last frame of the shadows (the longest). The scale and image number of the shadow plane are derived as percentages of the whole, depending on the position of the pinbob in relation to the object's axis.

And the final step, how much to pull the shadow back from the object's axis. Imagine the laying straight horizontal again. The shadow is scaled to the correct length and pointing toward the head, but is begining from the origin of the object, which somewhere around the geometric center of the object. But how much to pull it back? You need the negative axis length of the object, too. So for the horizontal pin, it would need to come back its maximum distance, to match the location of the flat bottom surface of the pin. This is the negative axis. The shadow plane is pulled back on the same percentage scale coming from the pinbob, except that what you're percent-agizing is the negative axis, to know how much to pull the shadow back from the origin. And except that whatever value you get, you need to use the negative of it (pulling back) : Move Object shadowOBJ(1),-(dist#).

And the image to use for the shadow is determined by percentage too, except INT(), on a range of 1-30, since I know I have 30 frames of shadow animation. 0% of pinbob/the maximum = frame 1 (first). 100% of pinbob/the maximum = frame 30 (last). And anywhere in between. You determine how much fidelity you want in your shadows representation by how many frames you decide to have, and it can be any number, doesn't need to be powers of 2 or anything...you could have 47 frames of shadow animation if you wanted. I have 30 frames and it's just about as good as it needs to be. There is only a very slight noticeable jump in frame images for the shadow when the pin is just starting to fall over. There is where is some of the greatest change in the images, so you might see the shadow image change frame if you're close enough with the camera. But it's extremely slight. I'd bet 40 frames would be silky smooth with the minimum number of images required, but I haven't tried that yet. The 30 looks fine.

The frames images range from 8k big at the smallest, and the largest is 17k! All they are is black images with an alpha channel; very small. But they are pretty large, for your reference, my frame #30 is 474x147, and frame 1 is 134x136. Yes, I have to get these images scaled correctly, because DB is having to scale them internally to use them. But these sizes allow for fine detail. You don't really see any pixelization because the images are large enough (and alpha smooth) that they can be viewed much closer than would ever need be, and still allow for clarity (defined edges and not pixely).

So then it's: Texture Object shadowOBJ(1),shadowFrame and Set Alpha Mapping ON shadowOBJ(1),50. You have to call Alpha Mapping every time you re-texture an object, so that's a bit of an extra step, but oh well. And there it's done. What you get is shadows that you can draw yourself, and can also be variable (with degrees of Alpha Mapping) depending on the lights for your scene and how dark you want your shadows.


It's an excellent method, but I've been thinking of it even futher:

Of course it works for a sphere as well, but there's really no need because the shadow would always be a square plane. Or would it? Remember how the light for these shadows is always directly overhead, so that a shadow is projected straight downward onto the floor? Well, what if (looking from the side), you moved that light a little bit to the side...the shadow would stretch in the light, just as it did when the light was directly overhead and the pin was rotating. In other words, the images for the shadows all stay the same...it depends on the light position as to which image to use. So the challenge is....:

What would the considerations be in making the shadows if the light could be anywhere and not just directly over head? The height of the light in relation to the object would affect it, but another effect would come into play: the movement, or placement, of the shadow, would change in relation of the light's position to the object's. I.E: Pin laying horizontally (looking from the side view), but the light position is between the pin and the camera. It would make the same side-laying shadow image, but its position is 'skewed' (instead of being directly underneath the pin), and now the width scale would have to start coming into play.

You can see, the images for this scenario would still remain valid, just that their positioning and scale(s) would need extra consideration for a light that could be anywhere (and have the shadows react properly). I haven't worked it out, but through from pretty fancy figuring, one could figure out a way to make the shadows work for the actual lights in the scene instead of an assumed overhead light...If anyone figures it out (before me), then I'd save some time, though that is not high on the light of priorities for the game. But as a curiosity, and because it is in fact more accurate to the real world, I'd eventually want to look into it...

And here is what you get for your trouble:

All effects added. Bear in mind that the pin reflected in the ball laying down is not the pin in front of the ball laying down pointed to the right. It is the one laying down pointed to the left. You can see the foot of the pin pointing to the right reflected on the ball.

The ball looks a little orange-y in this picture because I had removed the room model surrounding the lane, and the reflection is mixing with the ball color. Normally (with a room in place), the reflection doesn't change the ball's color that much.

I'll issue the challenge for the ball reflection as well: It does not use Set Cube Mapping ON, which is not in real-time. This is in real-time. Also, without Set Reflection Shading ON. That doesn't work at all on my machine (does it work on anybody's?). There is really no need for cube mapping. With this method, you get real-time reflections.


I've also improved the physics dramatically since any version I uploaded here. Totally tweaked. Just finished a higher-detail collision/physics model for the pins, which you can see in the image in the pin which is half-way fallen into the gutter. The only part of the pin which is unaccounted for (collision-wise) is a small section at the thinnest part of the neck, and it's even smaller (height-wise) than what you see the pin resting on in the image. That, and I greatly improved the pin's response to react more like real-world. I had the axis set at the pin's exact middle, which looked great, but when the ball comes in and hits the pin at the widest part of the body, since the pin's axis at the middle of the pin was higher than ball itself, the pin would 'kick out' its foot too easily. The pin rotates about its axis, so if it's at the center then a hit at the body would cause quite a spin around the higher axis. In reality, a ball hitting at the widest part of the body would not cause that degree of spin. It spins the pin a bit, but the real spin axis would be just slightly above the widest part of the body (where the ball hits), because of its center of mass, and that the neck and head are on the other side of the axis from where the pin gets hit. I've watched alot of video, and tried to adjust the axis to as close as I could get it that looked right, and it's looking pretty good. I've seen pin reactions that look exactly like I've seen on TV, like the kind where the ball must just kiss the side of a pin in order pick up a split of some kind. If you've seen it, then you know that on those very light side hits, the foot will kick out just slightly, making the pin fall down, but slide the rest of the way across the lane. That's how I've got it working now, adjusting the axis made for a more realistic (to my eye) reaction...

I've been thinking about the shadows. I don't know if this is possible, but it would mean that you could have shadows over contours. You make an object which matches the top surface of the lane and gutters exactly, except for the UV coordinates. You set the UV coordinates so that the texture would appear unstretched if you looked at it from where the light is. You ghost it and set transparency on. Then you texture it with an image from a camera where the light is in relation to the pins. This would be a long way away and have grey pins which are rotated the same as the real pins. I think it should work

Clever! Can't wait to try the new version.

Great graphics, this is looking very very good.

Hmm, Diggsey, that is a pretty good idea...sounds like it should work. But I wouldn't mess with the UV coordinates. I'd make the plane object (except matching the contours, like you said, let's call it the 'shadow plane', whatever shape it is...)), and make the camera look down on the scene with the grey pins. As far as the UV'ing for the 'shadow plane', I'd make it just a simple planar mapping on the Y, the entire size of the object (4 corners).
And the image to paste on it would just fit to the 4 corners.
It sounds good, I may be experimenting with it soon...Well, I hope someone gets something out of my method anyway...

Nice idea, Diggsey, it works! (See image) I set up a quick test to try it out, and got it working. It works, and pretty well, but there are a couple of drawbacks. I don't know if it's my system, or if it's in DBP, but I can only get a 512x512 image out of Set Camera to Image, or else I get an 'illegal image error' from DBP if I try to set it bigger. On a 800x600 screen, you can see the effect of the small texture. Also, there is no variability in the shadows. I can either have a totally black shadow, or none. It's because I have to use Ghost Object instead of Set Alpha Mapping On, the images from the camera do not have an alpha channel to use with Alpha Mapping and thus gain control over their transparency. The objects used for the shadow image (the 'grey pins') work pretty well for the shadow-texure image, but there is little adjustablity. You need to be able to get an opaque image of the shadow pins WITHOUT any shading shading on them, and I couldn't get that to happen. If you try to set the shadow pins unaffected by lights, then they come out all white. It's the effect that is needed, but they need to be a middle grey for the shadow effect. And they need to be unshaded...any shading on them causes the shadow image to have varying degrees of darkness in the shadow (like the shading on the object), and real shadows are not like this. You can try Set Object Diffuse, Set Object Specular and Set Object Specular Power, and also Color Object, but if the object is anything other than completely black, you will see the shading on it, and see that variation in the shadow too. It's a fine idea though, and will most definitely have its uses in certain situations, so thanks for that.

OK folks, I'll lay off this thread for a while until I've made some real progress as far as game-play or a playable game, at least. I've bored you enough with explanations and such.

But thanks again for all the kind comments, and helpful suggestions...I'll try to get something made that is playable and hopefully enjoyable.

Nice work. I noticed one error in your last screenshot, which you might want to work out. The 2 pins on the far right...It's the one behind that takes priority over the one in front for teh reflection, should be the other way around

Yeah, it seems to happen on all of the objects in the reflection. Looks like you'll need to change your fake reflection subroutine or somehow mess with the drawing order.

Yep, exactly...it's because the reflections need Disable Object Zwrite on them...so a higher numbered object will show in front of a lower number. There's no way to say which object numbers might end up in front of others, so I don't know how I'll manage it, but that was something I was going to look into as well...I'm not sure if there will be a solution.....

Enable Object ZBias is the command you are looking for. I think so anyway.

You could just check how far from the camera the pins are

Nice work.
Friendly advice:
To solve your problems with Convex Hulls and TreeCollision
you must put this function at the end of your code.



Once more nice job.

Thanks alot friends. I've actually done a lot of work on it in the last few days. Scoring bowling is easy to know how to do (for a person), but writing a program to do it was tricky! I really didn't think the problem through before I started programming it, so I ended up having to go back and change this and that, on code that wasn't set up for the problem at hand (not structured very well for the problem). But now I got it worked out and now you can actually play a scored game, with marks, bonus ball scores, etc., as in real bowling scoring.

COOOOOL
<expects demo soon>
I love bowling games

Probably the last interim demo before it becomes some kind of fully playable game. You will notice lots of little errors here and there, namely:

- On the 1st ball of the game, you can knock the pin sweeper out of position if the pins hit it. It won't break the game but it probably won't work 'right' after that. You can try to re-set it with the 'p' key.

- Sometimes a ball will end before you've gotten the chance to roll it, either on the 1st or 2nd ball of the frame; could be any time. You'll just get a 0 for that ball. There's some kink in the detection that I need to find.

- The ball swing control sometimes begins out of view, and its left-right control is reversed.


Basically it's just a demo to show some of the new stuff, ... and that it's closer to having all the framework in place to start completing a game. There is no control for spin yet, as the swing/roll device is just being started. It's just to get an idea of what a roll might look like. It does not have the full power that will be available when it's finished either, it's about 80% in this demo, so you can imagine even harder hits when it's complete.


But the swing device is along the lines of how I'll make it work. To swing:

First, using the mouse left-right, position the ball left to right on the lane where you want. Up/down with the mouse changes the direction of the throw (use the BRIGHT end of the aim as the direction). Press Left Mouse Button to set the position and direction. The aiming direction is VERY sensitive! You'll want to set it as straight as possible (straight down the lane) nearly every time...

Next, swing the ball swinger so that it's like a bowling throw at the very bottom of the swing; i.e. the ball closest to the floor.

Now, to roll the ball, swing the swinger to the back a little (just beyond bottom, toward camera), through the bottom, to forward a little (very little). When the ball is just a little past bottom and forward, then press X. The ball will be released on the trajectory it was at in the swing when you released it (pressed X). So it's possible to send the ball flying, but to really do it, just keep the swing within a small area around the bottom of the swing, and you can test some real rolls. Don't press X WITHOUT swinging the ball forward, though, or it will cause an error. There will be more to this control as I develop it.

You can still move the camera around, but only after you've set the ball position on a new roll, since rotating the camera still uses the Left Mouse Button, and setting the ball position does too, so only try to move the camera after you've set the ball position. There are a couple of preset camera positions on the number keys 1-9. Most of the controls (if they still work) are listed with the H key.

I fixed Z-sorting issues on objects with -Disable Object ZWrite- (all reflections) (can you guess how?). And improved the aiming device (not so touchy to aim down the lane toward the pins), but still no spin control, no approach, etc.

No demo, just an image to show that the order is fixed....

Very nice screenshot. Are you planning to model out a full bowling alley for a background, because your graphics look nice, and it would be a very pretty environment (if you like bowling alleys that is)

Just got back from bowling myself... I did bad today Though another dude got a 296 game... Missed the last strike, what a bummer.

Yes, I'll try to make it as good-looking as I can for the surrounding alley...possibly lightmapped for the best look, but I'm finding that more work than I could dedicate to it right now. Seems you need to have all the textures for *one* object (the entire rest of the room) in *one* texture bitmap, so the lightmapping can be applied correctly? It seems to limit my use of smaller, repeating textures (for better displayable resolution) on things like the floor where a repeating texture would look better than one that's just stretched out to be full size (blockier-looking). So I haven't figured out how to get that done for the best look, but I have made some of a surrounding room to start with, and as it progresses, I'll have some interesting surprises there...

The main focus right now is on getting a working, useable swing device going, that will work well with the game and fit in with the 'sim' concept of the game...something like they try to do with golf games. They try to make the device operate similar to the mechanics used in the real swing, and that's what I'm trying to reproduce, since I decided I have to go in the 'sim' direction. You could see a little of that in the last demo, if you tried it, with the action of the swinging arm (well, represents the arm, anyway). That will definitely remain part of the swing device, but as you could see it's a bit touchy right now...a little too easy to send the ball -over- the pins... : ) This swinging action will represent the 'strength' portion of the throw (hitting the best timing for the hardest throw) - but hard throws will not be a 100% necessity for the best scoring.

Right now I'm working on the approach, which will also contribute (but not as much) to the power of the throw {good timing}, and for possibly commiting fouls if the foul line is crossed. I believe there are generally 3 methods for the approach: the 3-step, 4-step, and 5-step approach. I'd like to have the ability for the player to choose which they'd use. Right now I'm animating a bowling shoe, to be used to display the steps the bowler takes as they approach the line. But it's just the shoes, no bowler model (good visibility : ).

So, after positioning and aiming, what you'll see is the shoes taking the steps towards the line on the approach. During this approach, you'll be operating the swing from taking it back, then bringing it forward, to the release. So in the timing of the approach steps, you'll have to learn to swing properly, plus release at the right point, the get the ball to curve (or not) where you want it to. The aiming is easy now...it's just a dot that you can adjust that moves back and forth just in front of the pins. Wherever the dot is, is where the ball is thrown (from the ball's position to that dot; straight line). I found that aiming need not be a crucial part of the throw. Any bowler can say "OK, I'm going to aim for the this spot", and that spot can be anywhere, but it's the quality of the throw that will determine if the ball makes it there or not. So aiming and positioning is pretty straight forward, there won't be a lot to learn there.

The aiming is a straight line, but that will be adjusted by the spin, which is the last part I have to work out. The ability to release at the proper point will have a great effect on how well the spin works out. Because, if the ball is released and it flies through the air for a time before contacting the lane, its spin will affect the path of the ball less than a ball that was released and began immediate contact with the lane. So it's really just a matter of getting the release to work correctly. Well, those are the ideas I have for how it will work, hope you like it. With all the things I have to add, it may be a while before anything tangible comes out of it, though...but I will try to make it the best I can. If it fails and I can never finish it, then I may just put out the source code...but that wouldn't be for at least a year.

Being an avid bowler, I like it... Sounds very cool, good luck with all that, and I look forward to seeing this finished