Should you work with limitations or overcome them?

Started by
3 comments, last by Xai 10 years, 6 months ago

Hi folks,

Right now I have a tile-based map file that has the following content


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXBXXXXXXXXXXXXXXXXXXXXXX
AXXXXXXXXBXXXXXXXXXXXXXXXXXXXXXXXXXX
BBBBBBXXXBBBBBBBBBBBBBBBBBBBBBBBBBBB

X represents "Air", A represents the player's spawn position and B is a solid tile.

All that gets rendered to this

Yu2VgNv.png

But you can see that my map is pretty much aligned, i.e the number of columns(i.e tiles) per row is the same for each row which works fine with the way I implemented my simple physics, but what happens if I change it around like so


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXX
XXXXX
XXXXXXXXXXXXXBXXXXXXXXXXXXXXXXXXXXXX
AXXXXXXXXBXXXXXXXXXXXXXXXXXXXXXXXXXX
BBBBBBXXXBBBBBBBBBBBBBBBBBBBBBBBBBBB

Which renders to this

d829g04.png

The red square is my player, he spawned to the position like in the previous image, but when I jumped he landed on the air, unable to jump anymore(because my code that sets a boolean flag if the player can jump never gets executed) and when I move, there is no collision detection. The black part in there means nothing is being rendered on those positions, no tiles there.

So here is my question. Do I treat this as a bug, or just accept that this is a limitation I have to work with? Because perhaps fixing this will require me to refactor most of how I handle physics in the game, or how I calculate the index for the array of structures where my map is stored, which I believe is impossible since I think the way I am doing it now is the only way to calculate the array index.

How do I handle physics? Well, falling off a tile on my map required me to detect two things, whether the tile below me was air, in which I case I set the flag to fall BUT I also do a second-stage IF where I check if the the tile next to the tile below me was solid and there was collision, in which case I didn't fall. Why did I do this? Because my code determines the column the player is with a simple division like playerX / TILE_WIDTH which works fine, but has some quirks in that I need to be perfectly in the next column for it to properly work. For instance 15/32 = 0, and that resulted in my falling off code needing to do the second-stage IF check.

Perhaps it's bad design, I am not sure but with the way I store my map, this was the only way I think.

Advertisement
It does not make sense in my opinion to have some parts of the map with no tile and no logic. What about simply assume that a blank tile should be threaded as air? I actually also think spaces would be better than Xs to represent air since it woukd be easier to distinguish the other tiles.

I'll second what apatriarca said, there should always be a default behavior for "unknown" situations (like black tiles).

It's not totally clear what you're trying to accomplish with your physics simulation. Is your game a smooth sidescroller or does your character move perfectly between columns all the time?

If you're having trouble with your character being "perfectly in a column" for collision checking (maybe using floats for X coords?), why not round the X coordinate of the player up or down using something like floor() or ceil() and check collision against that coordinate? It would make "gridding" your characters position easy in terms of physics but still allow smooth floating point based rendering that looks nicer.

What I understand from your post is: "my design requires that level files have valid tiles in every position" and "I provide an level file that is missing tiles".

So... just don't do that.

If these level files are hand-editable by users, well then you'll obviously need to provide some validation when you read them, and reject invalid files. Otherwise, you don't need to do anything, since you control the level files and can just not make invalid ones :-).

And also, you can just "validate" the level file upon loading ... just a simple flag as you try to load it that trips if you encounter anything "unsupported" and let the user know. At a minimum just report the row/column of the first error you encounter. Just like if you need an 80x25 map, and someone only gives you half the data ... don't "fix" the code to run the map. Fix the code to detect the error - so you can know why it fails.

This topic is closed to new replies.

Advertisement