# Tile-based game design problem

This topic is 5169 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I've hit a really tricky issue with a design issue that affects tile-based games, and I'm hoping there is a good solution to the problem that others know of. Basically, let's suppose our tiles are squares laid edge to edge (eg. chessboard). There is a unit on one square (square A), and an enemy two squares across and one square up from it (eg. a knight's move away), call it square B. Now, the problem is : if a projectile is launched in a straight line from square A to square B, which of the squares between it should it pass through (in terms of the game engine)? Now, as far as I can tell, I have a number of options which all have flaws from a design perspective : 1. The projectile passes through neither of the intervening squares. This is not ideal, since this can easily make attacking on such an angle either more or less advantageous than other angles. 2. The projectile passes through both intervening squares. This is also not ideal, for the same reasons as above. 3. The engine offers the attacker the choice of either square for the projectile to pass through. This has the effect of giving attacks on such angles an advantage though eg. if you were on B, it would take two tiles to block shots from A, whereas on a different angle you'd only need one. 4. The projectile randomly passes through one or the other square. This disadvantages attacks made through the angle, since results are not predictable. Is there a better solution? Note that the same problem is faced on hex-based maps, so that doesn't help.

##### Share on other sites
It's a hard call without knowing what type of game we're talking about, but in many tile based games, if you're going to let projectiles be launched in directions other than up,down,left,right, or the diagonals, they should probably not be restricted to the tile-based design, and have them fly along their path, which you can use math to figure out.

assuming the projectile is fired at a given angle, simply update it's position using
x += cos(angle)*speed
y += sin(angle)*speed

you can check what tile it is within given it's x and y values easily.

If you don't want projectiles flying at random angles, I'd recommend restricting them to the 8 directions that are easy to figure out.

##### Share on other sites
Hi,

I have a similar problem, in a Tactics Ogre clone game. I am using java to implement the thing.

##### Share on other sites
What if you absorbed it into your gameplay design?

i.e. Different weapons would respond differently to the exact same situation. That way, from square B's standpoint (defensively) if you had information about which weapon square A was using, you could adjusted your strategy to position yourself in the best available square. From square A's position, you could choose which weapon to fire for the situation at hand.

Obviously, I don't know enough about your game to know if this is even a possibility, but it's just an alternative idea.

--Ben

##### Share on other sites
On a tile based game i wrote 2 years ago, the Projectiles were indipendant from the constraints set by the tile engine. This IMO is the best course of action since it will make for less headaches.

##### Share on other sites
If you are looking to modify the shot based on what is in the tow tiles your best bet would be to take both into account. Lets say you are averaging the effects of a woods tile and a plain tile.
Woods tile adds +1 to hit roll
plain does not modify
average the 2 = +.5 to hit

If you are looking to see if it hits another enemy in the intervening squares try hitting both at 50% chance

Basically use both squares at 50%

The best solution would be to work on a hex field, but you run into similar issues there.

##### Share on other sites
I'm just curious. Why restrict anything to operate within the tiles? Shouldn't they just be the backdrop of the game?

Per pixel movement seems ideal and better in about every way? If you're going real old school and restricting everything to tile increments, well, you do have yourself a problem :)

I might just hack it to do per pixel movement for just projectiles and other things that pose similar problems...

##### Share on other sites
Quote:
 Original post by catchPer pixel movement seems ideal and better in about every way? If you're going real old school and restricting everything to tile increments, well, you do have yourself a problem :)I might just hack it to do per pixel movement for just projectiles and other things that pose similar problems...

Pixels are squares. You will run into exactly the same issues only on a smaller scale.

Edit: nasty tone removed

##### Share on other sites
Quote:
 Pixels are squares. You will run into exactly the same issues only on a smaller scale.

Hm, maybe you could suggest something better to move the objects on the screen by? ;) By "per pixel" I am implying moving things by floating points, but the fractional positions really just translate to the pixels on screen in the end.

Either case, a grid of 640x480 is much better resolution than a map of 32x32 tiles, or something similar.

Quote:
 Edit: nasty tone removed

Thanks, I think.

##### Share on other sites
Use IntersectRect(). But for this, you'd need every tile to hold a RECT property. Either that, or create the rect when analyzing the tiles. By doing it this, way, you can still have tile based character placement, but pixel-based projectile placement and it could hit both sides.

1. 1
2. 2
3. 3
4. 4
Rutin
17
5. 5

• 14
• 9
• 10
• 12
• 17
• ### Forum Statistics

• Total Topics
632906
• Total Posts
3009157
• ### Who's Online (See full list)

There are no registered users currently online

×