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. ;)
Printable View
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. ;)
Just for you. ;)Quote:
Originally Posted by mr_malee
Linky
Now with sound effect (yes, just one :crazy: ). No mute button, so adjust the volume on your end.
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.Quote:
Originally Posted by Son of Bryce
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.
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).Quote:
I could only read 3 keys pressed down at once (apparently a keyboard limitation)
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