SteeringController

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

SteeringController

Post by y offs et »

At this time the SteeringController operates well on the X,Y plane, which makes it usable for 2D games.

The addition of an X,Z plane option would allow it to be used in 3D games in a conventional, non-confusing manner.

Also, in 3D, if both planes were usable simultaneously, it offers tantalizing possibilities.

This thought then asks why not also Y,Z and visualizes "Lost in space".
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

a sample

Post by jph_wacheski »

Since most games even 3d ones tend to take place on a plan (the ground, even the solar system is plan-ish) you can actually do quite alot with the current setup,. it is a tad confusing to work with at first, but that is what happens not having written your own code! You have to sorta figure out how this 'black box' of code (the behaviours) will work given different implementaitons. You could check the source to 'know', but even then suprises still arise when actually using these things.
I have spent a bit of time just messing with different setups and observing the results,. I find with most stuff, the more random experiments you do, just for interests sake, the easier if becomes to build stuff later, as you have gained more understanding of what to expect.
Have a look at this setup I did, it shows objects following a leader object in full 3d with the stock behaviors.

As always it all depends what you are trying to do. As you can see some 3d stuff already works, and some, such as 'adjust heading' are set up for x/y 2d it seems.
Attachments
MisBehaving.zgeproj
3d follow the leader,. .
(4.08 KiB) Downloaded 503 times
iterationGAMES.com
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

and some, such as 'adjust heading' are set up for x/y 2d

Actually, to narrow the request down further, in Steering.pas / procedure TSteeringController.ApplySteeringForce(... / if AdjustHeading then...

If this was renamed AdjustHeading2D , and an AdjustHeading3D checkbox was added, it would open up a big area for development. This involves turning the heading pivot 90 degrees to the x-z plane and I'm not clear on the math, so I can't get any more precise.
"great expectations"
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

Here is an illustration. A standard openGL 3D plane with a 2D sprite, which could just as easily be a 3D animated model.
As you wasd backwards and sideways, the sprite changes direction to pursue you, but does not turn to face you.
So you check the adjustHeading in the steering controller and, well, you'll see...
Attachments
Steve2D.zgeproj
(64.52 KiB) Downloaded 518 times
"great expectations"
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

z-up fps setup

Post by jph_wacheski »

I always think of the Z axis as the gravity one,. so the standard ZGE camera is lookin down,. if you do this the facing works just fine,. there is probably some trig tansform you could do to your setup to get it working there too? I just hacked your setup to make it work with z-up (attachement) I took out all the gravity stuff,. for simplicity. Makes me want to do a 2d cutout shooter. ;) cheers.
Attachments
FPS_Zup_setup.zip
Z-up FPS control and camera .zgeproj
(33.64 KiB) Downloaded 505 times
iterationGAMES.com
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

Yeah, I know JP. We've gone over this before.
This is a general request for the rest of the world that doesn't lie on their back with the monitor on the ceiling.

Edit-
I took out all the gravity stuff,. for simplicity
I just realized gravity is an exponential force. Reworked it in whole numbers squared and then Y-= G/1000. Fixed the problem. :)
Last edited by y offs et on Fri Apr 02, 2010 2:55 pm, edited 2 times in total.
"great expectations"
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Hay, don't make fun of the quadriplegic guy typing every thing with his nose,. actually I think of the standard ZGE camera as lookin down. Z zero is the ground, and the carmera is 10 units up in the air.., but it is all just conceptual, isn't it? The point is, what you are trying does work, in the x/y plain. Or perhaps I just don't grok what you are after,. I don't see the difference between what xyz axis is up once you know. But that is just me and I could be wrong.
iterationGAMES.com
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

:D ... his nose!

Seriously now, let's discuss this. I know you were/are a 2D GameMaker pro who moved to ZGE and then discovered the way to "jimmy" partially usable 3D methods. I write this with all due respect to seniority rights and without any insult intended.
However, all the rest of the openGL world sees monitor x = horizontal, y = vertical, and 2D as playing on a billboard, wall, or TV screen. Then, 3D Z = like shrinking yourself down small and walking across your desk and into your monitor upon the Zplane.
The plus side of your way is you are unique, alone, and your source code is pretty safe. Anyone who gets a hold of it has to first figure out what you do, and second decide if they really want to have to make a ninety degree conversion from the norm in their head for every little bit of modification. I know I don't.
The minus side is, you are alone. ZGE can now access .dll's. Maybe next, input from modelling apps, who knows. The point is, everything openGL 3D exterior is done the norm way.
As to the "partially usable 3D methods", using your method, we can't apply UV graphics to meshes correctly. You've done some remarkable things with your objects, but we're restricted in general.

Now, I've previously in this thread posted how to correct the controller and still keep backwards compatibility. VilleK has demonstrated he can rename components and keep b. c.. Simply renaming one property is an || operation. So it should be easy to carry on. It just takes the will.

As a P.S., have you ever wondered why such great app as ZGE has less than 100 members and only a half dozen or so regular forum posters? I submit that, along with the inability to import sounds (.wav, for example), no height maps or terrain ability, this controller twist also is drawback. It's a 3D world. I myself can imagine all the scripting I would not have to do if this small change was made.

O.K. guys, tear me to pieces. :)

P.P.S. - Just remembered, JP. You're viewpoint is called "God Mode" in RTS games.
"great expectations"
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

8)

Funniest thing is that the up-axis debate actually matters for this particular feature. When you'd add a option that makes the "Adjust Heading" feature take the Z-axis in account, it will only work properly with one specific up-axis.

Anyway, you don't want to rely on the results of "Adjust Heading" to align sprites to screen-space ( since it's interpolated ). Let me know what rotation axes you want to use for your camera, and how your "3D Sprites" should behave ( billboard / x-rotation / y-rotation ) so I can whip up a script.

Now for the "tear me to pieces" part ..

- You can already import sounds ( including headerless .wav files ).
- You can already import from modeling apps.
- You can already use height maps ( software and hardware ).
- You can already generate correct UV coordinates regardless of up-axis.
- 3ds Max, Blender and other 3d apps actually do use the Z-axis as up .. Game Maker uses the Y-axis as up though :P

K
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

:roll::roll::roll:

The extent of my knowledge is evident in the help file. If I can decipher it, I can translate it. Then perhaps some others might understand too.

edit-----------
You can already import sounds ( including headerless .wav files )
I've read that. You have to use Audacity 1.2.6. because the newer versions don't have the "export other" option. I got raw trials imported into the component, but was never able to get any output, mainly because the sound documentation is sketchy. :?
You can already import from modeling apps
Yes - elementary .3ds - I was referring to something a little more advanced.
You can already use height maps ( software and hardware
complete :?:
You can already generate correct UV coordinates regardless of up-axis
yes, easily in the norm perspective. More involved with Z-up.
3ds Max, Blender and other 3d apps actually do use the Z-axis as up
I don't care.
Last edited by y offs et on Tue Mar 30, 2010 5:05 pm, edited 2 times in total.
"great expectations"
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

I'm not saing your original request is not a good idea,. far from it. I was only trying to help you acheive your goal,. or what I thought that could have been. :shock: with the current system. (working within the 'limits' is a skill I am working on)

The only thing "partially usable" with my 3D methods is my math skills suck,. so yes I hack around, to make games to play,. using just what I can figure out. For me, when I try doing 3d in GM [see; http://iterationgames.com/Space_Zap_3D_066.zip ], or ZGE, or whatever,. the issue is not the coordinate designations,. (could be dog, orange, cold!) but the math to do the transforms and get the angles needed to move and rotate the objects. You will always need to hold the concept of what those x/y/z or j/p/h ( or whatever) designations relate to in your own game/mind to do the needed work. I in no way am trying to make my examples hard to follow,. ("your source code is pretty safe"?) I am just working this stuff out for myself,. .

I did a bit more while thinking/tinkering on this today,. (see attached) and Kjell is right, you still need to calculate your own rotation when using the Steering Component to get smooth animation. What I did here was use this library script;

Code: Select all

 float Point_Direction(float X,float Y,float X2,float Y2){
 return atan2(Y-Y2,X-X2)/(2*PI);
 }
and call it like this in the update;

Code: Select all

CurrentModel.rotation.z=Point_Direction(CurrentModel.position.x,CurrentModel.position.y,
 app.cameraPosition.x,app.cameraPosition.y)-.25;  //always face camera
with the AdjustHeading ticked off. (you can just change the axis to what you need) I am not sure why the quarter turn is needed?!?

I may also build this one into a little goofy game with a few levels and sounds etc,. as it looks somewhat cool already,. IMHO.
Attachments
doomed_001.zip
.exe new game demo,. inspiered from your example, and doom of course.
(45.27 KiB) Downloaded 531 times
iterationGAMES.com
User avatar
y offs et
Posts: 418
Joined: Wed Apr 22, 2009 4:26 pm
Location: BC, Canada

Post by y offs et »

:) Thanks for that code, JP. After a little conversion, swapping ends, and dropping the -.25 I got it to work. If VilleK doesn't see fit to make it easier on new users, I'll write it up in the help. I'm just trying to translate for a complete noob who would drop in the components, expecting them to work as is, so they could have a simple, working starting point.

As to your Z-up way, I'm just getting too old to want to deal with exceptions to the general ways of doing things. You learn once how it works, and you want to get something done with it before time dims your ability.
"great expectations"
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:?

Sorry to say this, but jph's method is not what you'd normally use / want ( plus it's slow ). When calculating the orientation angle based on the position of a sprite and the camera, sprites will start to rotate even when you'd just strafe by.

So, for wolfenstein / doom type of sprite behavior ( where the camera only rotates over the up-axis ) use ..

Code: Select all

CurrentModel.Rotation.Up = App.CameraRotation.Up*-1; // CurrentModel being the Sprite
K
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Don't be sorry Kjell, I am only after the fastest way to do stuff,. :) no points for thinking of it, or being first, or whatever in my book. I just want to make the fun games.
Just using the camera rotation directly (*-1) works great,. (why didn't I think if it?) Although for some reason, I see almost no difference in speed in actual practice,. this demo starts to loose frames with >350 demons using both methods. I suspect it is the Collision tests, Behaviours, and the Depth Sorting (toggled on) that are the limiting factors. My assume is that these are as fast as they can be, so I will just keep my demon hordes limited to 256 or so. Not a bad size horde as hordes go.
iterationGAMES.com
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jph,

You don't notice any difference because it all happens in a fraction of a millisecond. However, when you benchmark the different solutions against each other you get these results ( lower is faster ).

Kjell ( ZExpression ) = 228
jph ( ZExpression ) = 617
jph ( ZLibrary ) = 937

K
Post Reply