![]() Drive a toy car into another car whilst making a screetching noise, you’ll have a pretty strong sense of how the cars will act as a result. Trading PlacesĪ weird thing is that we sort of intuitively know how two objects should behave when they collide. Needless to say, with “scatter dice” skid check these collision rules inevitable ended up with a vehicle overlapping another vehicles or terrain and requiring a good deal of finicking to place. Otherwise you leave an opening for the game not to be fun for some players, and that’s literally the opposite of what we’re trying to achieve here! Either the rule is not written it clearly enough or the rule is not right and needs to be changed. Whilst some players will be able to resolve things quickly and in an amicable fashion, I basically feel that it’s lazy and careless on the rules author’s part if the outcome a rule is not clear to “most” players. ![]() Throughout the development of the collision physical engine, two issues kept coming up: (1) how can you position the vehicles so that the inertia and vectors of the two vehicles “feels” right, and (2) how can you do so in a way that is crisp and not open to player interpretation?Īs a prideful games designer, I wanted my game to avoid unclear rules situations that lead to confusion and disagreement wherever possible. ![]() It was dynamic, sure, but it felt glitchy and not cinematic. (You couldn’t drive through other cars at this point). Cars would collide, get randomly pointed or moved somewhere they likely wouldn’t fit properly, and then neither car would be able to move off next turn. “(v1) After the smash attack is resolved, the target vehicle makes an immediate SKID CHECK.Īfter the skid check is resolved, if either car is in a position such that it cannot move away in its next movement, place the attacking car on the far side of the target vehicle, such that both cars can drive off in their next turn.”Īs you can probably guess from the second paragraph, the first paragraph was throwing up some weird positioning issues. This provided a natural initial design for the collision physics: Three of the skid dice faces acted like scatter dice, randomly generating a direction for the skidding vehicle to rotate to or travel in. In the earliest versions of the game, skid checks were bad things to be avoided, rather than a tactical feature of the game. As you’ll see, I’d experimented with different systems that affected the location, facing, or speed of one or both vehicles, and I’ll try to show how they proved problematic. In game terms, there are many possible approaches to handling collisions, and I’ll talk through some the things I’d tried on the way to the right solution for Gaslands. The real-world physical outcome of their impact is a result of their vectors and will be affected by their relative weights. Within the simulation of the game, we are dealing with two fast heavy objects colliding. I designed and discarded a whole host of systems for managing collisions, and I’d love to talk a bit more in depth about why we ended up with this one. That is an excellent topic for a blog post, and I’m happy to take the bait. Why don’t collisions have an effect on a vehicle’s vector (speed and heading)?” Mike, could you comment on the design decisions or iterations that drove the collision system? After the collision resolved, one of the players gave me a funny look and said: “We just drive through each other with a couple more hazard tokens?” “In the first game I ran for my crew, there was a head on collision between two cars each in 3rd gear. Recently, new player Dan Frohlich provided some interesting feedback about his first game, and asked for a little background on how the Gaslands collision physics ended up in their final state. ![]() Gaslands is a tabletop wargame in which heavily-armed vehicles career dangerous into either other, and high-speed collisions are virtually guaranteed. ![]()
0 Comments
Leave a Reply. |