Flow

Published August 21, 2009
Advertisement
I've had a real productivity streak this past week and have been able to push forward amazingly with the project. Before I began the system rewrite back in May I disabled a lot of functionality and now most of that is reimplemented using the new system. I'm very close to being perfectly happy with the entity system and yesterday it occurred to me that I should back away from it now before I start wasting time on minor implementation details. Given it's functional and stable I need to keep pushing on ahead if I'm ever going to make a game out of this.

The major improvements:

The Vehicle component, which controls the steering behavior movement of actors, has had its update code more or less rewritten. For its first incarnation I pulled most of the code directly from the Reynolds article, as I have mentioned in previous posts. That is, it used a very simple physics simulation where the different behaviors produced a propelling force. On the other hand I had grown to like the movement scheme I used in prototype 1, which is based on exponential interpolation (see below), so now the system uses this model instead.

As it works now, each behavior produces a velocity vector, all of which are summed to a desired velocity which the system tries to match up with. In this process speed and direction are treated separately to allow for more freedom. Speed is interpolated towards the desired speed using the weight 1-e-C(t1-t0) where C is a constant. This results in an interpolation that approaches but never reaches the endpoint value, giving a smooth damping effect. Also, since the system uses fixed-size timesteps, the weight becomes a constant expression. The direction is angularly interpolated towards the target in the same way although the shortest path around the circle must be determined first.

This was the model I used in P1 and, although not realistic to the point, it is smooth and pleasant to the eye, it's easy to get a feel for when playing, and it's very easy to maintain. The inputs are two interpolation weight and a maximum speed, and from that on everything else is naturally bounded. Perfect for autonomous control. The weights are divided by mass to simulate varying inertia.

The final model has one more regulation though. The motion may seem reckless if the agent is adapting to a large desired velocity opposite to its current direction. Because the forward acceleration begins before the agent has turned, its trajectory is something of a wide circle, which may cause it to slam into things if space is narrow sideways. To remedy this the desired speed is scaled by the saturated dot product of the current and the desired directions. For 180-90 degree diffs the speed will go to zero, and for 90-0 degree diffs the speed will gradually increase, and it works beautifully in practice. [cool]

I will keep the "reckless mode" movement around as an option for missiles and other full-speed-ahead things that seriously look cooler without the safer driving classes.

Here's the final expressions. angleLerp does linear interpolation on vector angles, after deciding the shortest path around.

// Update speed ( reckless mode )speed += ( desiredSpeed - speed ) * accelWeight / mass;// ... or// Update speed ( delicate mode )speed += ( desiredSpeed * clamp( dot( direction, desiredDirection ), 0, 1 ) - speed ) * accelWeight / mass;// Update direction.direction = angleLerp( direction, desiredDirection, rotSpeedWeight / mass );


Beyond that I've made an emitter component to handle particle effects, removed all old generation game objects and made sure the new ones match them, given components the ability to remove and create new entities by event functions and worked through a ton of bugs and shortcomings.

What's the next step?

There are still a number of problems with the entity-component system but as I said I'm not sure I should bother with them now. The vehicle component works now but it is not cleanly written and it's grown very bloated. In fact I consider splitting it up into three components, one for the steering, one for the facing control (since objects don't necessarily face the way they travel; take a gun turret for example) and one for simple motion with constant velocity. But I need more field experience with the system before I decide how to proceed with this.

The collision detection is both slow and error prone, but unless it acts up more than usual it can wait. It works most of the time. [rolleyes]

One thing that can't wait is the Audio component which, again, has been put off until the last moment. However this should be a simple matter to port from the old system.

The game has been overdue for a visual makeover for a long time and today I began looking into what style it should aim for. The reality is that I'm not a trained artist and I have no plans to enlist any others, so the style I pick must be simple enough for me to pull off myself. I toyed a bit with some palettes in Inkscape and made these background asteroids to try the colors (hey at least they're better than the old ones [grin]). I'll likely go with some flat style like this and spend more time picking good colors to set the mood.

Previous Entry VC++ 2008 Bug
Next Entry Flow, cont.
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement