Cars in a roguelike

[BrightBit]

Hello rogues,

I want to create a roguelike in my spare time and therefore I've done some mockups as guides and to help me see technical challenges. You can see some of them and their progression on the Pixeljoint forums if you're interested:

My Mockups on Pixeljoint.com

One of the resulting challenges is the integration of cars and their corresponding game mechanics. Right now, a car can use more than one tile of the playing field, i.e. it can be two tiles long and just one tile wide. The implication is that I also have to rotate the cars when they change their direction.



The image sequence above should illustrate how I would handle the car movement. The car can move one or more tiles in one turn along its main axis. The player can change the direction at any time but before the game really rotates the car the player has to confirm the new position, i.e. a turn will require two key presses (but just one turn). During a turn the car can only move one tile.

What do you think about this car movement solution? Feel free to criticise any of my other graphics on the Pixeljoint forums as well. Criticism and comments are highly appreciated.


Greetings
BrightBit

[Skeletor]

I suggest you to take a look at Roadwar: Europe.. maybe one of the games I played the most in my childhood. You were controlling a gang of drivers/bikers pillaging different countries of Europe, with a very cool, tactic and complex combat system (handbrakes.. lots of cars with different stats.. drive-by shootings..).

[BrightBit]

Thank you Skeletor. I didn't know Roadwar before although as far as I could see, it doesn't have pedestrians, does it? In Roadwar the cars seem to move just one tile each turn. A combination with pedestrians wouldn't feel right in this case I think. Those humans would either be as fast as the cars or even slower (e.g. one tile every two turns). The acceleration idea seems interesting, though.

My main problem with the integration of cars is that I want to make them feel faster. The player will be a human that is allowed to enter several vehicles and he should feel a difference between walking and driving. If the player wants to reach a certain goal I want him to know that driving will be faster in both terms: real world time and tiles per turn.

Still, I will need to find some time to play and investigate that game a little bit further.

BTW: Did you look for the mockups I made? The guys on Pixeljoint.com don't know much about roguelikes so I was hoping to get some feedback from real experts.

[kraflab]

I really like your art and the way your interface is set up.  Of course it is impossible to give a meaningful analysis without seeing it in action.  My only critique is that in the first image you have everything visible. Is the player omniscient here?  Visibility and not knowing what is around each corner is important in roguelikes, though not necessary.  Of course, since these are just mockups I can understand if you are just including all the art to show how it looks rather than having things grayed out.

[BrightBit]

Hi kraflab and thank you, too.

The player won't be omniscient but I actually thought about using a tile revealing system as in Jagged Alliance 2 where you can see everything except the interiour of buildings and npcs but I am not sure on this one. This definitely will need some experiments to test it first. However, my reasoning for this decision so far is that I would like to keep the game visually appealing (for a roguelike). Too much black would make the overall game look darker which at least in theory is something I want to avoid.

[requerent]

What rendering engine are you using?



A car should have to be driven with respect to its rate of movement. If a car is moving faster, then it should do so without the player being able to control every discrete step. If you turn while going too fast you'll enter a drift-- you can intentionally turn too early to drift into the turn, but you do so at a loss of exit speed.

With these qualities of driving in consideration, it may be better to have cars 'jump' to a target tile based upon their speed rating-- you can then interpolate to the target tile and see if any collisions occur. I ask about the rendering engine because you can render the full 10 tiles worth of movement while only passing 1 turn worth of gameplay.

So a car has a few features to consider- rate of acceleration, turning speed, and breaking speed (you can base all of these values on the actual physics- but imo that's pointless)- don't forget current velocity.

Based upon these things, you can have the player 'plot' their movement based upon the constraints of their velocity. IE- car is facing west moving at 5 tiles per turn. The car has a breaking speed of 3 tiles per turn and can accelerate 2 tiles per turn. That means that the player can move the car west a number of tiles within the range of 2-7.

Now- suppose we want to initiate a turn while we're moving forward. Graphically, it would be useful to have a 30 and 60 degree tile for the car, so that the renderer can communicate the progress of the turn. Otherwise-- A player has the option to initiate a number of turns based upon their turning speed. IE- suppose turning speed represents the number of 90-degree rotations possible in a single turn of play. You don't even need to make the player do anything complicated, you just widen the range of possible moves (inclusive of facings) available for the player to choose from. The player just chooses a target tile and whatever facings are available for that given tile. The current speed is then adjusted based upon whatever speed was necessary to reach that particular tile at that particular facing.

This gives you a lot of flexibility-- a player could make a 180 degree turn or do other fancy maneuvers. If you wanted a less forgiving system, you'd want to force the player to consciously choose how much they're braking- this would put the player into positions where they might spin-out, over-turn, or drift off of the road.


Now- the last thing to consider is interpolation and collisions. Two cars, one heading north and one heading west, both approaching an intersection-- one is moving 9 tiles per turn and the other is moving 5 tiles per turn-- You can either logically subdivide the game-loop so that we evaluate logic at a discrete step equivalent to 1/45th of a tile (this would not effect rendering)- that way we can deterministically see if the objects collide, or you can evaluate the paths of all objects within their respective bounds to see if their movement paths cross, and then test reasonably possible collisions. Honestly, you won't do much harm to your simulation if you run a logic-loop to step the game forward. It's technically more expensive, but with a turn-based game it's no biggee. If your game engine allows it and you're interpolating the graphics between tiles, you can just use the built-in collision detection provided by the engine.

Nice pics!

[Game Hunter]

A car should have to be driven with respect to its rate of movement. If a car is moving faster, then it should do so without the player being able to control every discrete step. If you turn while going too fast you'll enter a drift-- you can intentionally turn too early to drift into the turn, but you do so at a loss of exit speed.

With these qualities of driving in consideration, it may be better to have cars 'jump' to a target tile based upon their speed rating-- you can then interpolate to the target tile and see if any collisions occur. I ask about the rendering engine because you can render the full 10 tiles worth of movement while only passing 1 turn worth of gameplay.

Based upon these things, you can have the player 'plot' their movement based upon the constraints of their velocity. IE- car is facing west moving at 5 tiles per turn. The car has a breaking speed of 3 tiles per turn and can accelerate 2 tiles per turn. That means that the player can move the car west a number of tiles within the range of 2-7.

That's about as much as I'm "with you" regarding the mechanics for using the car. While it would be totally awesome to work in pseudo-physics handling and rendering the car at an arbitrary rotation, I don't think it works given the level of discreteness going on. Based on what I can see in the images provided, the car is two units big, and BrightBit doesn't seem to be doing a whole lot with regards to interpixel collisions: include the factor that the aesthetic is going more for simplicity (sacrificing, if you want to call it that, the mechanics by doing so) and the complexity you were describing doesn't really fit all that much into what's going on.

Basically, what I'd do with car movement is allow the player to increase or decrease the speed (maximum and increment dependant on the car), which determines how many units it crosses in a single turn. (The input for this should be independent of movement, as it will predetermine the distance traveled.) Naturally if there are obscales between the two points, the car will crash, with the damage dependant on speed. The idea will be that the player will have to decrease speed accordingly in order to make sharp turns. For example, this is what I'd expect for a car turning at 1 speed and 2 speed, respectively, given the current model:

...     ...
.X. --> .XX
.X.     ...

...     .XX
.X. --> ...
.X.     ...

Turning at faster speeds could also take longer, if only because there are some obvious braking requirements. Alternatively, you could force extra horizontal movement, changing the obstacle tiles. Here's an example for a 3 speed car, where the asterisks indicate collision checks:

.....     ..*XX    ..*XX
.....     .**..    .***.
..... --> **... OR ***..
X....     .....    .*...
X....     .....    .....

The collision indicators could easily be shown during the confirmation. (A lot of this is repeat of requerent, but I figure that pictures help.)

You may also want to take into account "stafing": that is, moving to the left or right without actually turning the car. This can probably be accomplished with the use of diagonal keys, which would otherwise have limited use in the car.

I essentially agree with the interpolated collisions for moving objects. You don't need to do into TOO much detail, I guess, but there should be a difference between high-speed and low-speed collision damage.

[jim]

Gearhead is pretty good with inertia and controlled velocity, too.

[requerent]

A car should have to be driven with respect to its rate of movement. If a car is moving faster, then it should do so without the player being able to control every discrete step. If you turn while going too fast you'll enter a drift-- you can intentionally turn too early to drift into the turn, but you do so at a loss of exit speed.

With these qualities of driving in consideration, it may be better to have cars 'jump' to a target tile based upon their speed rating-- you can then interpolate to the target tile and see if any collisions occur. I ask about the rendering engine because you can render the full 10 tiles worth of movement while only passing 1 turn worth of gameplay.

Based upon these things, you can have the player 'plot' their movement based upon the constraints of their velocity. IE- car is facing west moving at 5 tiles per turn. The car has a breaking speed of 3 tiles per turn and can accelerate 2 tiles per turn. That means that the player can move the car west a number of tiles within the range of 2-7.

That's about as much as I'm "with you" regarding the mechanics for using the car. While it would be totally awesome to work in pseudo-physics handling and rendering the car at an arbitrary rotation, I don't think it works given the level of discreteness going on. Based on what I can see in the images provided, the car is two units big, and BrightBit doesn't seem to be doing a whole lot with regards to interpixel collisions: include the factor that the aesthetic is going more for simplicity (sacrificing, if you want to call it that, the mechanics by doing so) and the complexity you were describing doesn't really fit all that much into what's going on.

Basically, what I'd do with car movement is allow the player to increase or decrease the speed (maximum and increment dependant on the car), which determines how many units it crosses in a single turn. (The input for this should be independent of movement, as it will predetermine the distance traveled.) Naturally if there are obscales between the two points, the car will crash, with the damage dependant on speed. The idea will be that the player will have to decrease speed accordingly in order to make sharp turns. For example, this is what I'd expect for a car turning at 1 speed and 2 speed, respectively, given the current model:

...     ...
.X. --> .XX
.X.     ...

...     .XX
.X. --> ...
.X.     ...

Turning at faster speeds could also take longer, if only because there are some obvious braking requirements. Alternatively, you could force extra horizontal movement, changing the obstacle tiles. Here's an example for a 3 speed car, where the asterisks indicate collision checks:

.....     ..*XX    ..*XX
.....     .**..    .***.
..... --> **... OR ***..
X....     .....    .*...
X....     .....    .....

The collision indicators could easily be shown during the confirmation. (A lot of this is repeat of requerent, but I figure that pictures help.)

You may also want to take into account "stafing": that is, moving to the left or right without actually turning the car. This can probably be accomplished with the use of diagonal keys, which would otherwise have limited use in the car.

I essentially agree with the interpolated collisions for moving objects. You don't need to do into TOO much detail, I guess, but there should be a difference between high-speed and low-speed collision damage.

I was actually thinking more along those lines-- but it really just depends on what role driving a car has in the game and how punishing the mechanics are to the player. If we consider the ruleset, a player skilled in knowing how the car moves will essentially have a range of end-states/positions available on each turn. If the game is more tactic or strategy oriented, I think it's prudent to give all available states each time the player makes a decision (and then they just click on the one they want).

Is the player the driver or is the player tactically commanding the driver? We often say that 'the player is the character' in roguelikes, but in most cases we're really just making tactical commands to increase survival. We're never concerned with the mechanics of combat (parry/riposte/lunge/block etc), we just sort of have faith that our 'warrior' knows how to be a 'warrior.' So... does the driver know how to drive or are we the driver?

I think the novelty of being the driver would be a lot of fun, but the punishment for anything short of perfect driving might wear on even a very good player (because 'skill' here is NOT reflexive), especially if cars have different properties. However, it'd only be interesting to provide a set of possible outcomes for the player to choose from if the game itself was tactically intuitive.

In the end I think your method is best-- driving is a fun gameplay mechanism in and of itself.

[Pueo]

Is the player the driver or is the player tactically commanding the driver? We often say that 'the player is the character' in roguelikes, but in most cases we're really just making tactical commands to increase survival. We're never concerned with the mechanics of combat (parry/riposte/lunge/block etc), we just sort of have faith that our 'warrior' knows how to be a 'warrior.'

Sorry for going off-topic, but I think that's an interesting thing that's been bugging me.  For my project, I was wondering whether or not I should include a more "in-depth" combat system (with parry/riposte/lunge/block/etc), but it just never seemed to fit, and I couldn't figure out why.  

I think it's a weird combination of the messages (in-game) almost always saying: "you," or, "it hits you," or, "you drink the potion," and yet "you," as in the real you, aren't actually saying, "Ok, now I'll parry, then riposte, etc," you're saying, "Ok, little guy, now it's time to attack that drake. Oh no! Run away!"

[BrightBit]

Wow, thank you guys for all your feedback.

So it's time for some answers I guess.

@requerent:
I am using Ogre and I am programming in C++. You might think that Ogre is overhead but it has certain advantages that I am interested in (mature community, CEGUI compatibility, shader support, etc.). Here's a small video showing my first steps. I initially wanted to create a minecraft clone, so it doesn't really show the actual state of my game: Infinite Terrain Video

@Game Hunter and requerent:
I like the idea of showing all available states for possible car movements but I also think it might feel slow (in comparison to the movement of a player) if the player has to click the desired state. Maybe those available states should only be shown if the player changes direction. If he keeps moving into the direction of the previous step he just needs to press a "skip turn/step" key. If he wants to increase the speed while keeping the direction he needs to press the corresponding key for this direction and the key for the opposite direction to decrease speed.
This way moving horizontally or vertically can feel fast while turns (changes in direction) will feel a bit slower because of the 'state selection' but that's okay. I mean, making turns with a real car also feels slow, doesn't it?

However, there's still a small problem. The roads I am using won't support smooth curves, i.e. only manhattan like layouts. So turns like these:

# = Road
C = Car
/ = Possible Collision
. = Not Road

#####     ##/CC
#....     #//..
#.... --> //...
C....     #....
C....     #....

...would cross nonroad terrain and therefore result in the car driving against pedestrians. You might say that the player needs to slow down before turning but I am asking myself how this would feel and if the mentioned approach is precisely and easy enough to do it. I guess this discussion would highly benefit from some kind of prototype.

Is the player the driver or is the player tactically commanding the driver?

I'm not sure if I really understand this question but I tend to say: The player is the driver. Does it help if I say that I am aiming at making the game feel like a turn-based GTA 1 (at least in regard to car controls)?

@Jim:
I tried to play Gearhead and it looks really interesting but I don't understand the control mechanism, so I sadly wasn't able to see the "inertia and controlled velocity".


Again, thanks in heaps for your feedback. Your thoughts helped me a lot.

[Game Hunter]

@Game Hunter and requerent:
I like the idea of showing all available states for possible car movements but I also think it might feel slow (in comparison to the movement of a player) if the player has to click the desired state. Maybe those available states should only be shown if the player changes direction. If he keeps moving into the direction of the previous step he just needs to press a "skip turn/step" key. If he wants to increase the speed while keeping the direction he needs to press the corresponding key for this direction and the key for the opposite direction to decrease speed.
This way moving horizontally or vertically can feel fast while turns (changes in direction) will feel a bit slower because of the 'state selection' but that's okay. I mean, making turns with a real car also feels slow, doesn't it?

Yes, I can see this working, especially if we're using the numpad-for-movement approach. So let's say that the car is moving up:
8 - increase speed
2 - decrease speed
4 - initiate turn counterclockwise (to the left)
6 - initiate turn clockwise (to the right)
7 - initiate strafe counterclockwise (shift to the left)
9 - initiate strafe clockwise (shift to the right)
5 - confirm and move car

Confirm should also work with any other defined wait key, like spacebar. These controls are generalized with (counter)clockwise so it always makes sense (if you're moving left, the keys would instead be (respectively) 4/6/2/8/1/7/5). Similarly, for mouse users, you could have a loosely-visible HUD over the car that shows what tile to click for these various commands (click on the car to move, click ahead of the car to increase speed, click to the car's left for a counterclockwise turn, etc.). Additionally, since moving the mouse constantly to just tell the car to keep moving would suck, I'd make it so that clicking anywhere outside the defined tile-HUD counts as a wait.

However, there's still a small problem. The roads I am using won't support smooth curves, i.e. only manhattan like layouts. So turns like these:

# = Road
C = Car
/ = Possible Collision
. = Not Road

#####     ##/CC
#....     #//..
#.... --> //...
C....     #....
C....     #....

...would cross nonroad terrain and therefore result in the car driving against pedestrians. You might say that the player needs to slow down before turning but I am asking myself how this would feel and if the mentioned approach is precisely and easy enough to do it. I guess this discussion would highly benefit from some kind of prototype.

You could just keep with the snap-to turning if you feel that the large-curve turning would force players to spend too much time at on-road intersections. You could also allow for both and give some kind of toggle between on-road and off-road styles. Maybe if you're on a road tile, pressing the "turn right" button once selects the snap-to turn and pressing it twice selects the large-curve turn, and vice versa if you're not on a road tile. (Since this would toggle, a third press would go back to snap-to, fourth to large-curve, etc). This works quite nicely because all motion has to be confirmed via wait button anyway, so it shouldn't be too much for the player to handle.

With regards to a car's speed, I'm basically thinking that part of a car's stats is how quickly it can increase, how quickly it can decrease, and what its maximum speed is. A typical car might be able to increase and decrease speed by 1, with a maximum speed of 4. Cars with better handling should be able to decrease speed rather easily, while speedster cars should have better increase and maximum. In this way the player might get to choose between a fast car and a stable car if they're trying to escape police or whatever.

[requerent]

Ogre is a fantastic engine with great support-- it's definitely ogrekill, but I also tend to find myself leaning toward 3D engines for 2D applications (with exception to RIAs).

If you're using ogre, you aren't limited in terms of how you present the progression of each turn. This means that you have a number of interesting choices in regards to how you allow the player to make decisions. In that light, I would suggest a different approach. The problem with fixing the game simulation at 1 tick per turn is that if the player is moving very quickly, the board state radically changes each turn. This requires that the player spend more time studying the changes on the board instead of making decisions. For fluid gameplay and a more driving-like experience, you're going to want to give the player the opportunity to make decisions as often as possible.

With that in mind, you can step the game forward based upon the player's movement speed. If the player is moving 10 tiles per turn, you can draw objects tweening between tiles and subdivide the progress of your logical game loop by 10. Because it is turn-based, we only really need to stop the game whenever the player has the opportunity to make a new decision. This allows the player to effectively make decisions at any point. Stuff like direction/speed/inertia and other factors will still make driving interesting. If you buffer the input properly, you can make the game feel 'real-time' when the player is holding down a button (especially if you force confirmation input when an enemy appears or something thereof), or when the player executes a goto-style command. A goto command is essentially the same thing as what has already been discussed- it's just like autopilot mode: usable when there are no enemies. To make things interesting, you can implement a reaction time mechanic that sets an upper limit as to how many salient ticks take place per turn, and even offer buffs/debuffs that manipulate their reaction time.

[BrightBit]

@requerent:
Sounds interesting but I really start to be unable of deciding whether it will be better or not. I guess I really need to implement a small prototype to test all or at least some of the ideas now.

Here's just a small update/mockup for the "show all available states" idea:



Red state indicators mean that there will be a crash. Black indicators present safe targets. A transparent version of the current car will show its new orientation after selecting the corresponding target/state.

[Game Hunter]

Here's just a small update/mockup for the "show all available states" idea:

...

Red state indicators mean that there will be a crash. Black indicators present safe targets. A transparent version of the current car will show its new orientation after selecting the corresponding target/state.

Looks pretty good so far. I take it the mockup indicators don't include all possibilities (since the right side is missing turning positions). Are we looking only at possibilities for a given speed? If so then the red indicators on the left wouldn't be reachable, if not then the surely we're also missing the speed-1 indicators as well. I'd only show indicators for a given speed so the player isn't swamped with too many options: it should be simple enough to change the indicators with an appropriate increase or decrease in speed.

I suppose we haven't really considered the possibility for driving the car in reverse, although it shouldn't be all that different from driving the car forward. I think most cars take measures to prevent reverse gears until you've stopped, so forcing the player to hit zero before moving into negative speeds is probably reasonable. At that point just have a maximum negative velocity that's some amount less than the absolute speed of the car itself (though this can certainly vary on a per-model basis).

Regarding the graphical stuff, you should probably decide whether or not you want to commit to sub-turn rendering at all. Since (I assume) this game isn't only about cars, you'd want to include this kind of animation for anything that would have sub-turn movement, like projectiles (not guns but anything thrown for sure) and structural/environmental collapse (e.g., falling buildings). You may want to consider applying the mechnical framework for these things anyway, since they could very well help in applying the causal effects even if they're not explicitly shown. It'd be a pretty large undertaking though, so it's totally your call.