Rebellion 2 Tactical Engine

[swx]

I've been working off-and-on on a Rebellion-inspired strategy game.

 

After a number of engine switches (and switches back), I've finally settled on an engine I like. I've been working on a tactical game, and have coded the basics for everything I need. However, I wanted to bounce a couple of questions off of all of you. I'll be periodically posting questions in this thread.

 

(1) Movement Behavior. After experimenting with a number of different movement styles, I've decided to take a step backward, so to speak.

Rather than moving and turning at the same time, ships turn towards the desired position, move to the desired position, and then turn to the desired heading (fighters behave differently). That is, they move more like rotary wing aircraft than wheeled vehicles.

I did this because I felt that it was too difficult to effectively control units that turned and moved at the same time. It's much more difficult to control units in Empire at War or Sins of a Solar Empire than it is in, say, Starcraft. How strongly do people feel about turn-and-move as opposed to turn-then-move? Don't worry about implementation. It's trivial to code either. (In fact, turn-and-move makes pathfinding easier since it can be done through steering behaviors.)

[Slocket]

I think in the original tactical they did move first then turn to fire. I think it makes little difference. I would go with whatever is easy to program, 3D battles are hard enough to code.

 

I was trying to make the 2D window click fest exactly like the original Rebellion. Once I realized I am buried in layers on windows complexity...I think rewrite of the code to use ZOOM like in SoGE. I realize do whatever the engine makes life easy to do.

 

DB pro does have a simple 3D command to pilot a ship. You use something like point in this XYZ direction vector (it can be stored easy in a 'string' form path for it to follow) and move a small distance in that direction. The model is lead by the nose through space. The model has a front point that follows the line and it looks like Move and Turn simultaneously but that is just a nice quirk of the 3D battle engine so I go that way. But if you are doing something different, by all means use the shoot and scoot method for raw programing to make life easier. I think it will not make any real impact on the game.

 

I hope some one including me will actually get something out the door. I know we are all doing our own way, but I think it will be a good thing once a leader emerges. That way if one project dies, there still is hope.

[swx]

Coding either is easy. It's the difference between commenting and uncommenting:

 

if (isTurning) velocity = 0;

 

I'm more interested in the impact that it will have in the game. It's a matter of "realistic" movement versus controllable movement. Empire at War is truer to the movies in that ships move and turn at the same time, but, as a result, it's impossible to accurately control units' movement.

[steel]

Multiply velocity by a vector that runs in the opposite direction from the back of the model.

 

I would like to talk to you swx if you would read and respond to my PM, that would be fantastic.

[Master_Xan]

Hmm... which method do YOU like more? If its that easy to change, you can pick the way you want it and add it to the list of "if the testers don't like this, I'll change it"

 

Personally, I always go for functionality over realism. Yes, getting shot tends to kill people in the real world, but not every game can be Rainbow Six. So in my mind, control should come first, unless that fine level of control isn't needed.

 

You may take into account that turning, then moving, will drastically impact certain ships in combat. Like SSDs, which turn rather slowly. Moving and turning simultaneously would improve the player's ability to respond to changing circumstances with slower ships. Those few seconds can mean all the difference, and leave the player frustrated if it costs them (like when said SSD needs to turn around and retreat). From that perspective, functionality dictates move-and-turn simultaneously, rather than a two-step process.