... Love the work you're doing with this. Are you designing your own rigid body physics engine for a future game or is it just a math/programming exercise?
Thx for the flowers! Have seen your BMX stuff. Cool stuff, mate! I love games
going for the physics.
Exercise? Nope. It's for real. Two games, actually. It's going to be a custom
build physics engine with special emphasis put on higher accuracy and on a
much deeper degree of sophistication to yield that special something making
your game feel different.
Well, I'm on a different path here. Contrary to common physics engine, which
put emphasis on simulating "larger worlds" but with much less accuracy, the
focus of my engine is more on "smaller worlds" that should behave much more
natural. But one can likewise increase the world and lower the accuracy as
well, which isn't really a problem for most engines. However, scaling upwards
for more realism isn't so easy for most engines (and I don't mean just
lowering the stepsize, which would be easy). Scaling upwards requires to
consider more complicated terms within the equations which are usually
neglected or simplified. This is done on purpose, of course, since if you
want to compute larger worlds you may have to cut some corners. And this is
usually done straight at the physical model you can't change afterwards, since
the entire (mathematical) engine code usually builds and depends upon the
physical model / assumptions being made.
With regard to my custom build engine, I want to have a more sophisticated
physical models -- retaining important terms and solving the equations on a
broader scale. This, however, will ultimately bound the worlds where such
physics can take place due to computational requirements. But, like I said
above, it's pretty easy to scale down on the model an as such to increase the
bounds of the world, if needed. For example, say you have a common physics
engine and you build kind of an indie game happening in a "small world". You
will get the same physical behavior like you will see in a bigger world, since
the physical model used is still the same -- despite you may have cycles to
waste.
With respect to indie games, many of them are small in scope. The idea for an
indie game is usually embedded into a small but yet very artistically created
world. And it is here were I think one can apply much more sophisticated
physics making the world feel more natural (more non-linear), since the
increase in computational power (mobile, tablets, desktops) makes this a
favorable approach. This may allow indie developers to give some of their
games a more lifelike nature increasing its feel without paying huge amounts
of money to make the world just -look- more sophisticated.
So that's essentially the idea behind this engine from a technical point of
view. Which brings us straight to the two games mentioned above.
The first one is sort of an anti-gravity / air / mid-air "racing" game called
ZONE. One can say that the soul purpose of my custom build physics engine is
to make the craft's dynamics feel outstanding. For me, this is a key-point.
But it's not so much about realism (anti-gravity?). That's not the point. The
point is the feeling.
The other game is going to be a pretty competitive and challenging sort of an
air-drifting game using aircraft vehicles. This becomes possible due to my
custom build physics engine. The aircrafts will be able to gain high angular
momentum and high rates of change of angular momentum while still rotating
realistically without having the physics dying in-between. This will allow for
a broad spectrum of motions (air drifts), giving the player the opportunity to
juggle with momentum and throw the craft into the air, into a stall, like
nothing else while kicking around. This game will precede ZONE.
Are you planning to have wind influence in your game, missile? just wondering cuz I'm curious how you would implement it.
Of course.
A uniform wind blowing from some direction is easy, but sux, of course, since
wind is different all the way. Wind gets influenced by its own motion, by
obstacles, by the topology of the landscape, by the density of the air, as
well as by local heat sources etc. But that's pretty much to ask for, but
is what I'm after. However, I'm currently not in a position to do it that
way (time/money constrains). As such I am going to do it in two stages.
Stage 1 (non-phyical):
The idea is as follows; Am going to wrap an axis-aligned structured volumetric
grid over the scene and define a vector field v(x,t) over the grid that gives
me for each node within the grid a direction vector, i.e. a wind vector.
This vector field could be a composition of simpler vector fields making it
behave more realistically. Now imagine you have an object within such a grid
cell that should get be influenced by wind. One of the key observations on
structured grids is that point location is trivial. Once you have the cell
where the point is located in, you simply do a bilinear interpolation of the
eight wind vectors located at the corners of the cell in question with respect
to the point within the cell, yielding a wind vector at the given point which
can then be used to compute sort of a wind force exerted on an object the
point is being part of. One my use the center of mass as a point. Or, if you
also want to have some torque on the object, which is way cool obviously, use
some more points at a distance (leaver arm) from the center of mass.
Stage 2 (fully physical):
Same geometric alignment as above (for the time being). But now the vector
field v(x,t) gets computed according to the real physics. That way the wind's
motion will curve around obstacles within the scene (think more or less of big
obstacles like hills, big houses, huge walls etc -- it depends on the fineness
of the grid) and will create vortices and similar cool stuff. There is a
beautiful equation that has coded all of it into its genes, it's called the
Navier-Stokes equation. This equation needs to be solved on the grid in
question to yield the wind field v(x,t). It's the most difficult equation of
classical mechanics, it's a beast, it eats computational resources alive. But
the outcome is pure beauty.
That's how I'm going to do it. But not today.
Back to some drag computation...
