Sign in to follow this  

Tile-based game design problem

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by catch
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...


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

Edit: nasty tone removed

Share this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
If I'm understanding your question properly, then I would say that bresenham's line algorithm would fix your littly problem. It would get your projectile from point a to point b. You really can't make it look good in the situation you've described where the target is two squares across and one square up. As the guy mentioned before, it would look better with smaller squares. It is convenient to subdivide your tile based map into smaller units, the most convenient unit being pixels.

Share this post


Link to post
Share on other sites
Umm, the question is a gameplay question, not a math or intersection question.

For example, firing 2 tiles to the right hits 2 tiles. Firing 2 tiles to the upper right hits 2 tiles. Firing a knight's move [2 movement distance] would hit 3 tiles if done by intersection, making it more powerful.

Most games I've seen handle this by making the projectile arc. Thus the projectile only hits 1 tile within a radius rather than a 'line' of tiles.

If the projectile always produces a numerical result, you could simply make the "middle" tiles take a % of the result [as they only recieve a % of the blast?]

Share this post


Link to post
Share on other sites
Yes, it is a gameplay question thanks Telastyn.

Unfortunately I intend to have both arcing and direct projectiles, so I can't use the 'arcing' rationale all the time. Also, the projectiles may cause a qualitative change, so I don't always have the option of dividing the effect up proportionally. Think 'Finger of Death'. Good suggestion though (also thanks Thermo, but same problem if I do 50% chance per square - which square do I check first?).

As for changing to a per-pixel game, I have considered this, since it would solve the problem (players would not really notice if the "tiles" are that small). There are very good reasons for sticking with plain tiles, for both simplicity in design, and better gameplay. I should clarify that this is for a turn-based strategy game.

For instance, if I did do per-pixel movement for projectiles only, then I would have to represent the actual shape of every unit in order to find out whether a hit occurred. For the purposes of this post, assume I am restricted to unit-sized tiles at least - I'll start another post if people really want to know why I'd stick with straight tiles.

I don't have an issue with the drawing of the projectile, or working out the tiles it intersects - just the gameplay issue really.

Share this post


Link to post
Share on other sites
If the qualitative effects are singular, that is once the "finger of death" hits something it stops and the unit dies, I think that passing over the 3 tiles is not so bad.

Share this post


Link to post
Share on other sites
The effects won't always be singular, so the solution must work in both cases.

EDIT : Actually the proportional distribution could actually work. For quantitative effects, I apply the results proportionally, and qualitative effects I apply possibly. Thanks to Telas, Thermo. The coding will be a real pain, unfortunately :(


[Edited by - Spalaen on August 19, 2004 6:35:49 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Spalaen
The effects won't always be singular, so the solution must work in both cases.

Thanks to Telas, Thermo.

No problem. I am always glad to sound like I know something. ;)

Quote:
but same problem if I do 50% chance per square - which square do I check first?).


This is easy to figure out. It hits the tile adjacent to you first. If you want proof, draw out the tiles and draw a line from the unit to the target. If the effect is singular you may want to lower the probability slightly below 50% (consider its a shot that is dodged more easily.

Hope this helps.

Share this post


Link to post
Share on other sites
Quote:
This is easy to figure out. It hits the tile adjacent to you first.
Doesn't work for hex-shaped tiles unfortunately (which is what I'll be using). The square tiles were just to make the example easier to follow. I actually had a rethink, and I don't want to go with 50% probabilities - will go with attacker's choice I think, if anyone's interested.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this