66

You need to change the shape of the field of view. So that when you move in any direction, the same number of new squares become visible. Here is one possibility:


66

Dungeons and Dragons 3.5 (pen-and-paper RPG) has a solution used for both movement and grid-based radius calculations: diagonal movement costs 1.5 what orthogonal costs. Since the diagonal of a unit square is approximately 1.414, 1.5 is pretty close. Because D&D 3.5 only supports integer movement, the way this is actually calculated is that orthogonal ...


62

As Marton notes, there are several "figure of eight" curves that might fit your needs. Perhaps the simplest is the lemniscate of Gerono, which has the parametrization: x = cos(t); y = sin(2*t) / 2; and looks like this: However, the lemniscate of Bernoulli may be visually more pleasing; it has a parametrization very similar to the lemniscate of Gerono, ...


38

My first suggestion would be to just stick with A = Counter-clockwise and D = Clockwise movement. It is not very confusing and is pretty much the "standard" (i.e. most common) choice when it comes to orbital movement like this. Another way would be to change the way your game moves. Instead of moving the player when they are on a planet you could rotate the ...


35

I wrote a series of articles on this. It is based on the same ideas you've read elsewhere, but explained in a very detailed and (I hope) accessible way. In particular, the article about the client-side prediction is this one.


30

Frame based simulations will experience errors when updates fail to compensate for non-linear rates of change. For example consider an object starting with position and velocity values of zero experiencing a constant acceleration of one. If we apply this update logic: velocity += acceleration * elapsedTime position += velocity * elapsedTime We can expect ...


27

I'll use some linear algebra structures since it's easier to describe the operations that way. In case you don't know how to implement these vector operations I'll give a quick explanation at the end. So let's say you start with these values: startand end mark the end points of the movement, speed is how many pixels it should move by second, and elapsed is ...


27

You need to take the sum of the directions, normalize that, then multiply by the speed. I tangentially answered this as part of my response to Preventing diagonal movement Specifically: velX = 0; velY = 0; if(keyLeft) velX += -1; if(keyRight) velX += 1; if(keyUp) velY += -1; if(keyDown) velY += 1; // Normalize to prevent high speed diagonals length = ...


26

To have diagonal and orthogonal movement reveal approximately the same area, you need two things (each of which, alone, has already been suggested in another answer or comment): Approximately circular view range: On its own, this won't give exactly the same revealed area for both types of movement. For example, in the image above, orthogonal movement ...


26

There is a great way to do exactly what you want. In addition to a float velocity you'll need to have a second float variable which will contain and accumulate a difference between real velocity and rounded velocity. This difference is then combined with velocity itself. #include <iostream> #include <cmath> int main() { int pos = 10; ...


25

Some possibilities: Lemniscate of Bernoulli Lemniscate of Gerono Lemniscate of Booth Watt's curve


23

It's not that hard to create a fairly good car movement (but this post will be pretty long). You'll need to "simulate" a couple of basic forces to make the car move physically plausible. (All the code samples are pseudocode.) Acceleration First, you'll obviously need acceleration. Something as simple as the following line would do: acceleration_vector = ...


20

You will want to separate the game speed from frame rate. Check out this article: http://gafferongames.com/game-physics/fix-your-timestep/ I'll sum up parts that apply to your problem. We face 2 issues: Frame rates may fluctuate and vary across different hardware, so you want to keep game speed constant and independent of frame/rendering rate. It is also ...


20

Use physics. First you'll need to establish this: 1. Hovercraft physics principles The hovercraft's engines will produce an upwards force of magnitude F, that is opposite in direction to the gravitational force G. The vertical component of the sum of all forces acting on the hovercraft at any given time will be: sum_of_forces.y = G - F The First Law of ...


18

Game characters are usually animated using a technique called skeletal animation: (Image source: Valve Software) Each 3d model has an invisible bone structure (the red and teal lines in the image above). Each polygon of the model is connected to a bone. When you define a motion sequence, you define it as a sequence of rotations of the bones around their ...


17

There's a number of options: Do as you do. You've already said it doesn't look smooth. There are some flaws with your current method though. For x, you could use the following: tempx += speed * dt while (tempx > 0.5) move sprite to x+1 tempx -= 1 while (tempx < -0.5) move sprite to x-1 tempx += 1 this should be better. I've switched the if ...


16

Use floating values for movement and integer values for collision and rendering. Here's an example: class Character { float position; public: void move(float delta) { this->position += delta; } int getPosition() const { return lround(this->position); } }; When you move you use move() which accumulates the ...


16

When the character gets out of the ship, reorient the view so the character is on top of the planet, and then move the view with the character as they walk around. This way the character is always on top with respect to the view when on a planet, so the left/right controls can stay consistent no matter where you land.


15

I have a personal logic issue on a regular basis that you seem to be expressing here. It's that sometimes you're looking at the logic and programming from the wrong direction entirely. In this case, you seem to not be realizing that from the beginning you know which is happening, because of the logic code. You should already know, programmatically speaking, ...


14

Well in the simplest sense you have something like this. y |\ | \ m | \ s o | \ p v |(a) \ e (y)e |angle\ e m | \ d e | \ n | \ t | \ |__________\ x movement (x) The speed is however fast the enemy is, and you can determine how much they ...


14

You'll want to get a vector based on your current velocity and heading. Then use that vector to increment your position. //first get the direction the entity is pointed direction.x = (float) Math.cos(Math.toRadians(rotation)); direction.y = (float) Math.sin(Math.toRadians(rotation)); if (direction.length() > 0) { direction = direction.normalise(); } /...


14

One way in which many old-skool games solved (or hid) this problem was to animate the sprite. That is, if your sprite was going to move less than one pixel per frame (or, especially, if the pixels/frame ratio was going to be something odd like 2 pixels in 3 frames), you could hide the jerkiness by making an n frame animation loop that, over those n frames, ...


13

Separate your direction selection code from actual movement code. Choose Direction by checking which keys are pressed. Store it as a unit (normalized) vector. Multiply your Direction with Speed and with DeltaTime. Apply resulting transform to your object/camera.


13

Bresenham In the old times, when people were still writing their own basic video routines for drawing lines and circles, it was not unheard of to use the Bresenham line algorithm for that. Bresenham solves this problem: you want to draw a line on the screen which moves dx pixels in the horizontal direction while at the same time spanning dy pixels in the ...


12

It seems you've already answered your own question. A* is likely the best approach. Yes of course it can be used in the way you describe, including using the height information to avoid mountains. As long as you're able to access information about any grid on the surface of your world, there's no reason you can't use it in the A* heuristic. Finally, you're ...


11

Use a List called "Path" to store the way-points that describe your path, and a doubly-linked list called "Snake" to store the moving objects and Path. The leading object defines new way-points as it travels. The following objects move along the path as defined by these way-points. Each object has a security zone defined by some distance. If the leading ...


11

To add to Savlons answer: There are two ways of doing this Vector2D objects(Assuming your positions are vectors): Vector2D diffVec(B.posVec-A.posVec); diffVec.normlize(); //Assuming it's applied on the vector itself // and does not return a new one. //This vector is now a unit vector which represents the heading/Direction //without the "speed" (Well ...


11

Yes, the Update loop is ideal for this. There are no special plug-ins required and you can do this with the free version. Basically you move the objects a tiny bit towards their destination each frame. When all those frames run one right after the other, it gives the appearance of smooth movement. A self contained script would look like the one I've created ...


11

Since you are using a grid and know which direction the user is proceeding there is nothing constraining you from adapting the prior answer and using a different fields of view depending on the direction. For example you could extended the field to include the corners when you travel in cardinal directions and shrink it down two squares on each end in your ...


11

The "normalized direction vector" is how this task is usually approached, and how I often do it, but lately I've simply been clamping the resulting movement vector. It usually achieves the same end result and the code is a lot simpler: var moveSpeed = 6.0f; function Update() { var movement = Vector3.zero; movement.x = Input.GetAxis("Horizontal") * ...


Only top voted, non community-wiki answers of a minimum length are eligible