[WIP] Pinball Racer

Got a new project in the works and thought I would share some early eye candy results. It's basically a mode7 racer with a pinball theme (proposal). The development team is 4 people (not all programmers - so hooray for some non-programmer art). The total development time is limited to 10 weeks, we're about 3 weeks in. :yikes: Unlike most of the junk I do, this one will actually be finished because it's a course project. (Not for me, but for my teammates - I'm just auditing).

Here's a demo of our renderer applied to a stock level from mario kart, with a little extra pinball stuff tacked on.

I've also been working on a neat content creation tool, "ScannerProgram", that automates the point and polygon extraction process, so our artists can just sketch points on top of the mode7 texture and the renderer can yank it all out without them ever having to touch a keyboard. They got real excited about level design once they saw how easy it was to rip a texture into polygonal map geometry. You can see how this program works in the full source.

Quite a bit of physics/gameplay code has been thrashed out by other team members, but we've yet to merge the display code and world state code, so the renderer doesn't show anything but static geometry.

More to come later. :) Maybe I can get some of the other team members to blog a bit about their contributions here. (don't think any of them are FK'ers or lurkers though)

Looks like a good start rachil! Can't wait to see the finished game! - and the progress nonetheless :)

i can't find the server

Quote:

---

Originally Posted by slicer4ever

i can't find the server

---

Working on my end ... but on the other hand, the server is down the hall from me. Perhaps you need to right-click and save as, then open it locally on your machine? I know direct linking to swfs sometimes causes them to be blocked by IE (presumably other browsers too).

i got it thanks

it looks very good rachil. how come there's four windows though?

yeah, very nice stuff

The target platform is a standup arcade machine with four joysticks where every player is controlling their own little splitscreen, ala Mario Kart 64.
(And I thought getting one window working at 24 fps was tough!)

Target platform (video).

Split screen racer.

awesome! excited to see it progress. seems to run fantastic.

An update today, now there is some non-placeholder artwork that has finally trickled into the game.

This level is called "aztec gold". Players will race around a track inspired by the aztec sun stone (see Illustration 2) and activate all the symbols of the aztec pantheon/zodiac to jackpot the track. The central jackpot area has not been textured yet, just laid out.

No physics in this one yet, those guys are working hard but the big merge has yet to take place. Will be in by next update.

Here's the demo.

Word of warning, it's 2.2 MB to download, so don't strain anything. (On your end or mine!). Hooray for content! :)

wow! that looks cherry.
have you tried progressively blurring the slices as they receed into the distance. it might cut down on that flicker in the distance (there's a name for it but i can't remember it)

I'd call it aliasing (too many texels being represented by too few pixels = undersampling), but there might be a more specific term that I'm unaware of.

Yeah, z-fogging/blurring will probably be put in there at some point to make it less noticeable. Using the built-in filtering that flash applies to beginBitmapFills doesn't really help, because the image is drawn scanline by scanline and you'll never filter along the screens y-axis. But fogging would probably help.

Glad you liked it & tanks for the feedback. :) More to come (~1 week?).

wow, that looks cool. Didn't understand the shaking though when you press the up arrow key, what exactly are the controls?

anyway, looks amazing :thumbsup:

Quote:

---

Originally Posted by mr_malee

wow, that looks cool. Didn't understand the shaking though when you press the up arrow key, what exactly are the controls?

anyway, looks amazing :thumbsup:

---

Controls are left/right and space to scoot ahead.

The camera is wonky right now because it is yanked from a code with more degrees of freedom. Up/down is supposed to pitch the camera, but there's a different line of code elsewhere in the app that is resetting the elevation angle to -20degrees all the time. But the access to that variable is not synchronized with the display, so the camera pitches a tiny bit down, the frame is rendered, and then the pitch is reset again, then another frame is rendered, etc.

In the final version the camera won't be under player control anyway, it will always be chasing a ball. There will put a similar wobble/jerking effect in the game for when you're driving over a friction surface, but it will be deliberately coded in and polished, not the result of a bug.

Thanks for trying it!

Quite *****ious for such a tight timeline.
good luck

Update today. :) The physics code has been integrated with the rendering code so the game has collision rules instead of being a free-ranging camera demo. There are placeholder screens for the title, high scores and how-to-play - although none are production quality yet. Some support for obstacles (bumpers, drop down targets, rollover targets) is in there too. So you can roll over some buttons and they light up, hit a bumper and it will knock you around, and if you sit on the guys nose all the drop targets go crazy. (The collision detection doesn't work for arbitrary shaped obstacles yet, so their response is not yet tied to their geometry). Still no sound, maybe by next update.

5 weeks down, 5 weeks to go! Are we gonna make it? :scared:

Downloadable at same URL as post#1. Swf is now up to 4.4 MB.

I expect the final product to be about 40-50MB, but since the game is not meant to be web deployable, we can make it as big as we want. We're choosing to go for a load-screen-free approach by embedding every piece of content directly in.

EDIT: It will probably get upset that there's no high score server around (it does on my box, at least). That code is specific to our platform and doesn't fail in the most graceful fashion. Should still be playable however.

always love your stuff,

by the way who does the GFX stuff,- the other members? If you need some neat marble or ball renderings or some splash screen PM. I will try then to make some free time for that (not charging for that)

Thank you for the positive feedback :)

The artwork for the Aztec level is actually all "programmer art" of my own and is intended to be a reference design for our artist & technical artist (who are currently painting designs of their own). I can't really take credit for the parts that look pretty, all the "daysign glyphs" are borrowed from:

http://www.azteccalendar.com/azteccalendar.html

Fortunately, they are all released under Creative Commons. I think they look gorgeous, finding them is what convinced me to do an aztec-calender level. I could never make it that pretty without 3rd party help. The rest of the painting was done in ... Paint (lol). I am learning Gimp and it's come in handy for the rotation and color shifting effects, but it's basically all composited using Paint because it's all I know.

Our pipeline is intended to be: the artist and designer do a cocktail napkin sketch of the level and its key obstacles/features, then the artist creates a painting of the level. Next the technical artist creates a wireframe overlay that is passed into a (hackish) feature extraction program, and finally myself and the technical artist crank out the gluey code to make obstacles bounce and react to the players. Granted, with a 10 week schedule it's not clear how much pipelining really goes on.

By next update I hope to have new artwork to share that is contributed by teammates. All the rendering tech in the world is still frumpy without some good art to back it up, so I am really pushing them to make some pretty content.

Quote:

---

If you need some neat marble or ball renderings or some splash screen PM. I will try then to make some free time for that (not charging for that)

---

I would like to take you up on that, splash screens in particular. Let me consult with members of the team and the instructor and see what they think. (The instructor might insist that all content is created by us, but I am not sure)

Subscribing to the awesomeness :)

that rocks, whats it like with 1 player? I wanna see full screen goodness :D

This looks awesome. First time I've seen 4 player split-screen action in Flash.

No offense, but I'd rather see a Mario Kart battle game than Pinball Racer. Haha. ;)

Quote:

---

Originally Posted by mr_malee

that rocks, whats it like with 1 player? I wanna see full screen goodness :D

---

Just for you. ;)

Linky

Now with sound effect (yes, just one :crazy: ). No mute button, so adjust the volume on your end.

Quote:

---

Originally Posted by Son of Bryce

This looks awesome. First time I've seen 4 player split-screen action in Flash.

No offense, but I'd rather see a Mario Kart battle game than Pinball Racer. Haha. ;)

---

I sort of agree, but wanted to try something I hadn't seen before. OTOH someone in the class showed me a GBA or something that was running Mario Kart inside a pinball machine bonus level, so I guess it's not all that original of an idea.

Mario Kart has a real legacy of fun, I'm hoping we can tap into some of the magic in the original game. Just the other day, I was probing the team to see if we wanted to migrate away from the racing aspects and towards a battle-style game. (This is an easier program to write, IMO, because there's less design work needed to make a fun arena than a fun racetrack). But the final decision was to stand by the racetrack style design, so... damn the torpedoes & full speed ahead I guess. :)

oh yeah, thats what I'm talking about, awesome :D

Hey, I was just curious as to how you were going to handle the input for 4 users... I only ask since when I made my little finger twister game I could only read 3 keys pressed down at once (apparently a keyboard limitation) so thought I'd flag it for you here.

Quote:

---

I could only read 3 keys pressed down at once (apparently a keyboard limitation)

---

4 if you add the mouse button, 6 if you add scroll wheel up & down (can be mapped as well by many gamepad/joystick mappers).
Alternativly some Javascript to send some special signals just like they did with the Wii controler hack for the Flash player- pure JS.

As far as I understandd Rachil is developping it for some kind of arcade machine, so no keyboard limitations there.

Update today :) Here's the list of added features, at least the ones I can remember:

1. Sounds added for many more gameplay events. (rail collision, ball collision, boosters, rollover targets)
2. Drop targets - hit it and it drops into the surface, pops back up later.
Spinner targets (my personal fave) - hit it and it spins for bit, then comes to rest.
3. Improved rail physics - rails can be specially marked to encourage "sonic-style" style curvy physics.
4. Camera easing, which is a little disorienting but its growing on me.
5. Refinements to menu screens. The title screen is particularly pretty. You have to just wait a few moments when you launch the swf, then it will progress to the title screen. The first screen is currently the high scores because that was the last one we were working on. And of course, it doesn't work for anyone outside of our sandbox because the high score server isn't present. One of the other team members implemented a "dot-matrix" display which takes an input image and produces a orangey pixellated screen. Then they just piped the output of our renderer, and made a really cool animation in dot matrix form out of it. It's worth the wait IMO.
6. Draw distance implemented, far objects are dropped out of the rendering list early (no transform is even done, just a transform of an anchor point). More an optimization than a new feature, but there's enough clutter on the track that this is pretty much essential.
7. The biggie, which is the game is finally getting fun ('bout time!). With the rail physics and targets you can finally start to feel some of the combo-mechanics emerging, especially on the "cheetah/eagle" side of the map. (The snake/gecko side of the map still needs alignment and tuning). Hit the boost and then the drop target and you can light up all the rollover in one swoop, then hit another drop target which will fling you towards a spinner. Still a little rough to pull off, but it's pretty satisfying when you get it to work in one smooth motion.

Single viewport version.

Single viewport version again, but the real fun is the four player splitscreen on our standup arcade, when you get the trill of "the chase" (and hopefully, "the blow-by pass").

Four weeks to go! :eek:

Large update today. Coming on the home stretch, and things are coming together architecturally and thematically (er sorta!). I feel the level designs are a little weak/uneven but I am hoping with the last 10 days or so we can make a strong push to polish them up to uniform, high quality. (crosses fingers)

Laundry list of changes, no particular order...

1) Instead of embedding all our assets directly into the swf, they are now fetched at runtime using the built in loader class. This probably doesn't mean much to you - you have to download 25 megabytes one way or another. But it's a huge difference to us as developers - recompiling only requires 400K of bootstrap assets and is dramatically faster. Caused top to bottom changes in our program architecture - so many changes that we clobbered our whole SVN and started over with a new, modified "version 0".

2) Laps are detected. Although the maps don't generally indicate what direction you're supposed to be headed, smart folks like you can figure it out. Once you're done racing (3 complete laps) your bonus target/combos are used to adjust your final lap time downwards. Only the aztec map defines any bonuses so far.

3) Neato level select screen, that actually IS an in-game map running through the real engine/physics. As players jump in, they can have a mini battle where they "vote" for the map they want to race upon. There are multiple targets, each time you bounce a target you cast another vote for it, map with most votes gets picked.

4) Arcade style "attract loop", with title screen, demonstration play, high score display (incomplete) and author credits page. The high score entry at the end of the race is also in pretty good shape.

5) Four maps, of various stage of completion. Aztec gold (which has been in every build), an OSU themed track, a Haunted House themed track, and a Driving School track that doubles as the demonstration play.

6) Flipper type obstacle (only used on Aztec Gold so far).

Zipped program swf+trackpack available at:

http://esl.eng.ohio-state.edu/~rac/k...ball_racer.zip

(27 MB total)


We have about 1 week to go, so any recommendations on what aspects of the game needs the most patching up would be GREATLY appreciated. Thanks for commenting. :)

plays very nice, I would liek to see a mini map in there though, I got pretty lost on some of them!

Very cute demo, hope we can play 4 on the same screen, that would be very fun.

Can I ask what you used in terms of physics for the edge detection, it seems pretty solid indeed. Mine always seem to have one sneaky spot or another where the object sneaks through the wall (Usually at interections). Yours (seems really solid I tried to break it extensively!). Great work.

I wasn't the main physics implementor (see the credits page in-game) but I did help with its design, mostly using lessons learned from writing doom and quake-a-likes. The map representation is really similar to what I did in quake-a-like, it's just reduced to 2D instead of 3D.

1) The roamable space is decomposed into convex polygons (see http://board.flashkit.com/board/showthread.php?t=741628 ) Edges of a polygon are either inpenetrable walls, or shared between two adjacent convex polygons and crossable. (There are like the portals in the quake-a-like portal renderer)

2) All object positions are 3-tuples: x coordinate, y coordinate and host polygon. When an object (like the ball) wants to move, it walks the edges of its host polygon, testing if the new position lies outside the polygon. If so, the ball is (i) constrained back to tangent with the edge, and velocity bounced, if the edge is solid or (ii) "handed-off" to a neighboring polygon if the edge is shared.

3) Ball-to-ball collision is circle-to-circle - the response restores tangency and exchanges momentum. Almost all object collision primitives are circles, only the droptarget and flipper use polygonal collision primitives (and they're still convex). The ball-to-convex-polygon collision routine [these are like the brushes in quake-a-like, and are the one part of the physics which I implemented] was a problem I had solved already, it loosely involves casting a ray from the inside of the polygon towards offending ball, and then seeing which edge straddles that ray. I am not 100% sure it's correct but it's done OK so far in 2D and 3D tests.

4) The tacit assumption that shoestrings this whole thing together, is that a ball is not so fast that it can completely fly through a polygon in a single frame, missing a bunch of obstacles in the process. So high velocities (or equivalently, large displacements between consecutive frames) are the real problem for our system. To compensate, the physics code runs at a higher frame rate than the renderer (a factor of 8 to 1 or 16 to 1, we're still tuning it out). So even velocities that are visually perceived as very fast by the player are resolved into multiple, tiny steps for the physics integrator. There is also a hard cap on the velocity, but it's large relative to how fast players are typically going.

5) One thing that you get for free is a natural partitioning of collideables much like a quad-tree. When a ball moves, it is never tested against any obstacles which lie in different host polygons or any edges which are members of different host polygons. (In reality, this is slightly weakened, objects from 1-neighbor-over polygons are also dumped into the list of things to check, but the fundamental gain is still there - you're querying a small neighborhood instead of the whole map).

Some things we're still displeased with:

1) The physical response of the flipper is completely wrong (it does not account for the velocity of the flipper, it just bounces off the flipper as if the flipper was at rest). The physics is not difficult for this, but it's more of a refactoring issue. The flipper was added last on a whim, and making its response physically correct would require architectural revisions that we are unwilling to make with a closing deadline. It's behaves more like a pop up barrier (that's either "There" or "Not There", in one of 10 or so swept positions) than a moving obstacle. We find this acceptable in-game, it's not so incorrect that it becomes unfun.

2) There are still problems, if you want long enough you can observe an NPC ball "escape" the map and happily wander off into the sunset. This is most likely to happen where a polygon has an extremely small exterior angle (like a joint that is almost a straight line) or where the rails sharpen to a thin point. I would like these errors to be eliminated altogether, we notice them more often because we always run the code with 4 viewports and one a weaker machine (so all the time deltas are larger, resulting in larger frame-to-frame displacement even though the velocities are the same scale across your machine and ours). Before we seal the code, I want to have my physics guy try adaptive integration, where the number of subframes used to integrate the ball position depends upon the velocity. So slow balls get pushed in one big lump, and the tiny substep computations are only expended on the fast balls.

Thank you for spending time to test! I will pass along your praise to the man behind the curtain :)

PS: You can jump in multiple players, you just need to mash their button on the joinup screen (if you hit 1QAZ that should get em all in). Their controls are pretty unintuitive so I recommend you still race as yellow, who gets the nice "arrow key+space" control set. I suspect you observe more errors when you've got more players dropped in, due to the lower frame rate/larger dt.

We have finished our project (at last). I hesitate to really say it's sealed, because some team members are planning to implement additional maps, but to me it's done and over. I think I'm almost to that point where I never want to touch flash again but naah just need a little break :)

New features since the last update:
1. Attract loop improvements and a looping song/beat.
2. Custom soundsets for most of the levels.
3. (the biggie) Added a fifth level with a vegas theme. IMO, this map is what really justifies downloading the newest version of the game. I feel it's one of the strongest maps visually and thematically. Vegas is in the top row, second column, if you're having trouble telling the icons apart and want to skip straight to the new goods. I wish we had filled up all 12 spots on our map menu, but we were really in over our heads as far as artwork creation goes. Instead we're just focusing on the positives... we have plenty of room to grow!
4. Post-mortem of the process. (OK not really a game feature, but still a nice little show)

Here's the game link (32MB), download and unzip to a folder.
http://esl.eng.ohio-state.edu/~rac/kart/pbr.zip

And here's the link to the post-mortem (in powerpoint)
http://esl.eng.ohio-state.edu/~rac/kart/pinball.ppt

Thanks for all the support and feedback while we were working on it. :) Hope it meets the original expectations!

really nice flash project!
not only are the physics and graphics technology impressive but also the performance the ideas and many of the graphics,
good job