Moach
Crazy dude with a rocket
Hello, fellow space-people! - i got a very geeky little challenge for ya.....
as some of you may already know (since i talk about it annoyingly often), i'm working on a trials bike game....
you know, one of those ride-over-obstacles physics driven type deals.... it's a flash game, and i'm coding it in HaXe (which is sooo much better than AS3)
anyways....
i didn't wanna have the game "cheat" itphysics for its handling to become playable (as these games usually do)
so instead, i decided for a largely overdone stability-augmentation control system, which can be compared to something akin to a fly-by-wire setup such as that on EuroFighter jets....
well, first things first - let me explain what we're dealing with here....
this is what the aforementioned abomination looks like:
that mad-scientist looking control panel to the right is what i'm dealing with... i made it just so that i could tune the bike handling dynamics to an optimal stable/fun sweetspot
but it's tricky.... sometimes changing a single parameter makes a world of difference, but then changing something else makes it irrelevant or over-sesitive.... anyways, the goal of my work for that past month has been solely that of finding this "optimal" setting
this tuning is of great importance for this type of game - since the general "feel" of the bikes handling is a lot of what makes players enjoy themselves addictively or casually browse away in boredom/frustration
well, i've set up a whole scheme to make this more manageable....
the game is capable of saving and loading simulation config files, so it's easy to swap between settings and compare things that worked before....
as you can see, i've been up to a LOT of seat-of-my-pants tuning work up 'till now (i had even considered using some genetic algorithm at one point)
the game also saves and loads the tracks you race on (it starts out as a crude map editor thing, so you can create a track before you go)
well - you can get the swf and some of the lastest config tests here: http://dl.dropbox.com/u/1374365/XCC.zip
the zip contains the swf file for the game, a "default.bike" file (which is not auto-oaded by default, despite the name) and a folder with some saved tracks i made for testing or just thought were cool....
well - these are the controls you need to know:
in EDIT MODE:
click and drag to "paint" the track
WSAD keys move camera
ENTER to build the scenery and start riding
F4 -- load track file (only in edit mode)
in RACE MODE:
LEFT/RIGHT arrows -- lean back/forward respectively (hold both to duck)
UP ARROW -- accelerate
DOWN ARROW -- brakes
SPACE BAR -- unflip bike
ENTER -- unflip bike and return to track start
F5 -- sace track file (only after built)
F11 -- load handling config file
F12 -- save handling config file
well, off to lunch -- BRB -
Edit: ok, now i'm back, where was i?
right - let me help you get started, so you at least kinda know what you're doing....
the riders name is Bob - so ii'll refer to him as such from here on....
bob is controlled by a system of 6 PID loops, with different parameters and functionality, each accounting for a specific aspect of his movement and how he reacts to forces and acceleration as he goes....
each controller can be individually configured by its respective panel on the control UI..... so let me explain a bit how it works
the topmost controller in the panel (the purple-ish one) is for bobs torso rotation - it works towards rotating bobs body a few degrees (quite a subtle effect, really) back and forth according to his position relative to the bike and to the current inclination angle
it does very little for handling... it's almost just for making the motion look a little more fluid
now, the three blue controllers are of greater importance - they are called "subcontrollers" - because of the way they are wired to the final two XY loops (the yellow output controllers below)
this is called a "cascade" setup - in which one (or in this case 3) loop sets the target for another....
now, since each loop handles only a single floating-point value, some inline logic is installed in order to convert back and forth from this single-valued representation into 2d vector form.... but anyways, that's not very much relevant, it's more important to understand what each controller does and what to expect of tweaking it
the rotation sub-controller
this one gauges the rotation velocity of the bike as it spins around, and determines how bob should move tangentially to the rotation center in order to try to slow it down to zero....
it doesn't actually stop the spinning too much, but just by "trying", it makes it much less prone to toppling over on steep terrain or during jumps and other stunts as long as the parameters are properly tuned
the counter-acceleration subcontroller
this is set to respond inversely to the bikes acceleration - so if bob throttles up and starts going forward, he'll also pull himself forward to compensate the forces.... moreover, when bob lands from a jump or rides over some bumpy patch, this controller also serves to stabilize the bikes motion, since bobs own movement affects the bike as by Newtons laws
again, it won't prevent acceleration, nor will it stop bumps from knocking bob around -- it's just another stability measure, which if tuned correctly, makes for a stable ride (or if not, makes bob try and jump off the bike, even tho i haven't programmed him to yet)
the command-response subcontroller
this last loop simply tries to minimize the distance between bobs body and the "target" set by the players controls when leaning around (see also the "command targets" tab)
this is useful to eliminate "command slack" (a nasty effect where bob doesn't move all the way to the target) - but also allows bob to react to the other two controllers before he finishes doing what he's told
the outputs of these three controllers are added up to an XY vector (we'll call it the "control vector") - this is then wired into the final two (yellow) loops
the X and Y output controllers
the sole purpose of these is to mediate the control vector and the output acceleration for bobs body
it measures the error between bob's velocity and the control vector, then outputs an adapted acceleration which bob must respond to....
i can elaborate more on it later - but righht now, i've encountered some errors in my code, so i'll have to upload a fixed version before anything else....
but anyways - feel free to play around with the variables and see what each does for bobs riding skills.... if you think you hit something good, please post the .bike file so i can check it out :thumbup:
i thank you for your attention
as some of you may already know (since i talk about it annoyingly often), i'm working on a trials bike game....
you know, one of those ride-over-obstacles physics driven type deals.... it's a flash game, and i'm coding it in HaXe (which is sooo much better than AS3)
anyways....
i didn't wanna have the game "cheat" itphysics for its handling to become playable (as these games usually do)
so instead, i decided for a largely overdone stability-augmentation control system, which can be compared to something akin to a fly-by-wire setup such as that on EuroFighter jets....
well, first things first - let me explain what we're dealing with here....
this is what the aforementioned abomination looks like:
that mad-scientist looking control panel to the right is what i'm dealing with... i made it just so that i could tune the bike handling dynamics to an optimal stable/fun sweetspot
but it's tricky.... sometimes changing a single parameter makes a world of difference, but then changing something else makes it irrelevant or over-sesitive.... anyways, the goal of my work for that past month has been solely that of finding this "optimal" setting
this tuning is of great importance for this type of game - since the general "feel" of the bikes handling is a lot of what makes players enjoy themselves addictively or casually browse away in boredom/frustration
well, i've set up a whole scheme to make this more manageable....
the game is capable of saving and loading simulation config files, so it's easy to swap between settings and compare things that worked before....
as you can see, i've been up to a LOT of seat-of-my-pants tuning work up 'till now (i had even considered using some genetic algorithm at one point)
the game also saves and loads the tracks you race on (it starts out as a crude map editor thing, so you can create a track before you go)
well - you can get the swf and some of the lastest config tests here: http://dl.dropbox.com/u/1374365/XCC.zip
the zip contains the swf file for the game, a "default.bike" file (which is not auto-oaded by default, despite the name) and a folder with some saved tracks i made for testing or just thought were cool....
well - these are the controls you need to know:
in EDIT MODE:
click and drag to "paint" the track
WSAD keys move camera
ENTER to build the scenery and start riding
F4 -- load track file (only in edit mode)
in RACE MODE:
LEFT/RIGHT arrows -- lean back/forward respectively (hold both to duck)
UP ARROW -- accelerate
DOWN ARROW -- brakes
SPACE BAR -- unflip bike
ENTER -- unflip bike and return to track start
F5 -- sace track file (only after built)
F11 -- load handling config file
F12 -- save handling config file
well, off to lunch -- BRB -
Edit: ok, now i'm back, where was i?
right - let me help you get started, so you at least kinda know what you're doing....
the riders name is Bob - so ii'll refer to him as such from here on....
bob is controlled by a system of 6 PID loops, with different parameters and functionality, each accounting for a specific aspect of his movement and how he reacts to forces and acceleration as he goes....
each controller can be individually configured by its respective panel on the control UI..... so let me explain a bit how it works
the topmost controller in the panel (the purple-ish one) is for bobs torso rotation - it works towards rotating bobs body a few degrees (quite a subtle effect, really) back and forth according to his position relative to the bike and to the current inclination angle
it does very little for handling... it's almost just for making the motion look a little more fluid
now, the three blue controllers are of greater importance - they are called "subcontrollers" - because of the way they are wired to the final two XY loops (the yellow output controllers below)
this is called a "cascade" setup - in which one (or in this case 3) loop sets the target for another....
now, since each loop handles only a single floating-point value, some inline logic is installed in order to convert back and forth from this single-valued representation into 2d vector form.... but anyways, that's not very much relevant, it's more important to understand what each controller does and what to expect of tweaking it
the rotation sub-controller
this one gauges the rotation velocity of the bike as it spins around, and determines how bob should move tangentially to the rotation center in order to try to slow it down to zero....
it doesn't actually stop the spinning too much, but just by "trying", it makes it much less prone to toppling over on steep terrain or during jumps and other stunts as long as the parameters are properly tuned
the counter-acceleration subcontroller
this is set to respond inversely to the bikes acceleration - so if bob throttles up and starts going forward, he'll also pull himself forward to compensate the forces.... moreover, when bob lands from a jump or rides over some bumpy patch, this controller also serves to stabilize the bikes motion, since bobs own movement affects the bike as by Newtons laws
again, it won't prevent acceleration, nor will it stop bumps from knocking bob around -- it's just another stability measure, which if tuned correctly, makes for a stable ride (or if not, makes bob try and jump off the bike, even tho i haven't programmed him to yet)
the command-response subcontroller
this last loop simply tries to minimize the distance between bobs body and the "target" set by the players controls when leaning around (see also the "command targets" tab)
this is useful to eliminate "command slack" (a nasty effect where bob doesn't move all the way to the target) - but also allows bob to react to the other two controllers before he finishes doing what he's told
the outputs of these three controllers are added up to an XY vector (we'll call it the "control vector") - this is then wired into the final two (yellow) loops
the X and Y output controllers
the sole purpose of these is to mediate the control vector and the output acceleration for bobs body
it measures the error between bob's velocity and the control vector, then outputs an adapted acceleration which bob must respond to....
i can elaborate more on it later - but righht now, i've encountered some errors in my code, so i'll have to upload a fixed version before anything else....
but anyways - feel free to play around with the variables and see what each does for bobs riding skills.... if you think you hit something good, please post the .bike file so i can check it out :thumbup:
i thank you for your attention
Last edited:
