Tag Info

New answers tagged

1

(coincidentally I just wrote about this topic for my book. That chapter should be released next week; here's a brief summary) There are two primary steps to what you're trying to do: 1) Determine which direction to face 2) Rotate the player to face that direction The first task is handled via transforming the direction vector from camera-space to ...


0

This seems to get the job done, special thanks to a forum member Entity for this answer: core::vector3df(sin(core::degToRad(rot.Y)), -sin(core::degToRad(rot.X)), cos(core::degToRad(rot.Y))).normalize();


1

You can do the trig functions yourself if you want, but it's a lot easier to use a rotation matrix. In the background it will do the exact same sin/cos stuff, but it's already programmed for you, so why redo it? I'm not too familiar with Irrlicht (or C++), but adapting some code I found on their forums, it'll probably look something like this: ...


0

As it currently stands, his positive z direction is equivalent to your negative z direction. Notice in the top right corner of the scene view, you have an axis indicator to tell you where the camera is currently facing (it says Persp, and shows x, y and z). Also notice how in the tutorial, his axis is aligned in the opposite z direction than yours. If you ...


0

The code is good and Unity it's working correctly (look at the arrows on the screenshot, they're pointing in the right direction). As far as the screenshot helps me to debug, you just need to rotate the object and go torwards th


1

You could randomly take a new looking direction or a point to look at for the camera, then just lerp or smooth damp towards it. Here is a simple example made with Unity that might get you started, feel free to modify it. You might also want to add player's camera movement to that so the player can actually control aiming. private float t; private Vector2 ...


1

Instead of mPointer.stopRotation() you need to gradually apply negative acceleration (torque) to get to your desired point. So, you have currentPoint, targetPoint and currentSpeed (I will measure all of them in grades as I guess that's also how you do it - for currentSpeed grades/second). The distance in grades that the wheel must travel from currentPoint ...


0

Given you can do a discrete collision check between the agent (that is you player) and all the obstacles you can do something like this: while ( not_found_collision ) { move the agent a distance D along the path; // D must be small enough to prevent // tunneling - the radius of a sphere that is fully contained in the agent // ...


1

If you want, you can predict your movement with the Periodic Interference Test (PIT), which is fancy for "Place myself in the next position and if I collide with something, revert me to the last safe position". This is fast, easy, relativly safe and should be sufficient for your game as long as you don't move to fast (aka make two big jumps in a frame). ...


0

I would personally discourage you from any kind of direct map-player communication there is no need for it. It is game logic responsibility to handle such interaction. Often, there is some kind of GameObject manager or component system. As for multiple players/maps, server should be resonsible for instantiating maps and moving players between them.



Top 50 recent answers are included