Creating a smart tile placement brush

Discussion in 'Game Development (Technical)' started by Valen, Mar 5, 2005.

  1. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    Basically what I want to do is make a map editor that supports StarCraft style placement of tiles on the map. As many of you probably know, StarCraft has an isometric look but in reality the map is made out of 32x32 square tiles which are properly arranged to make the map look isometric. It's possible to do this by hand (one tile at a time), but it would be torture to make maps this way. I tried searching Google for articles on the subject, but couldn't find anything. Does anyone have experience with this kind of thing? Do you know of any articles or sites discussing this? Thanks in advance.
     
  2. Teeth

    Original Member

    Joined:
    Dec 6, 2004
    Messages:
    165
    Likes Received:
    0
    You might need to go into more detail about what you need - I can't tell from what you've written what you want an answer to.

    Is your problem to do with having areas of the map that are higher up than others?
     
  3. Vectrex

    Original Member

    Joined:
    Aug 22, 2004
    Messages:
    205
    Likes Received:
    0
    no he's talking about how starcraft automatically picks the best tile variation for what you're drawing and what's next to that tile. It's very cool, you can eg just select the water brush and draw away and it'll make all the edges fit nicely.
     
  4. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    Crap, I just realized that what I wrote only makes sense if you've actually used the StarCraft Campaign Editor. Sorry about any confusion I have caused. Vectrex has got it exactly right -- I'm trying to figure out an algorithm for a diamond brush made out of square tiles, such that tiles around the diamond are automatically made into transition tiles blending with the surrounding terrain. I hope that's a better explanation. It's really helpful if you've used the SC editor. Here's a screenshot. The green diamond is the brush, and the surrounding high ground was created with a single click. Each square in the grid is a single tile. I hope this makes things more clear.
     
  5. ggambett

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,982
    Likes Received:
    6
    Ahhhh now I get it. So they use a completely flat map of square tiles but looks like an isometric 3D map. Neat!

    Not having playing Starcraft I have a doubt though... can you walk behind these hills? I guess not, looking at the editor. So, do you have to be unbelievable careful when designing maps to avoid breaking the illusion, or it Just Works?
     
  6. Dan MacDonald

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,424
    Likes Received:
    0
    You can basically walk behind walls to the extent of the green diamond. The top two sides line up pretty close to what the observable collision region is in game.
     
  7. Teeth

    Original Member

    Joined:
    Dec 6, 2004
    Messages:
    165
    Likes Received:
    0
    Ah, ok - that's pretty freaky :)

    I always thought they just had a third dimension to their map data. A second layer, IYSWIM.

    Let's see... I suppose for every tile you could have a reference to a slope tile, so that when you place the higher-level tile, you check the surrounding tiles and just change their identity to the referenced tile.

    I'm trying to make a tile-based game at the moment and was simply going to use multiple dimensions for the map instead of burning it into one layer.Then again, I have good cause for that as I intend to have houses and stuff in there...
     
  8. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    Yep, the map is completely flat. "Neat!" was my thought too when I realized this. :) Here's another screenshot, with some more stuff in it. I added some marines as close to the terrain as is possible, for those of you who are curious. You can't put units or buildings "behind" the terrain. I think they have a bit mask for each tile and use pixel perfect collision detection for units, but I'm not concerned with this. The reason I decided to use this type of map system (other than the easy to work with nice looking isometric perspective) is because it makes building placement very simple. Each tile is either true or false for placement of a building (you can see the false tile highlighted red in the screenshot). Buildings are snapped to the grid, and combined with the true/false tiles it's a no brainer to figure out if a building can be placed somewhere.
     
  9. ggambett

    Moderator Original Member Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    1,982
    Likes Received:
    6
    Very interesting in fact, and now I think about it, it enforces a constraint that is good to enforce : no units or buildings can be "hidden" from the player.

    I guess there are "ramp" or "stair" tiles to connect different heights?
     
  10. Teeth

    Original Member

    Joined:
    Dec 6, 2004
    Messages:
    165
    Likes Received:
    0
    You've got to love Starcraft.

    The rule about not hiding stuff from the player is really good. Difficult to achieve with things like buildings. Can't remember off-hand how they did it in UFO?

    I've looked into tile editors myself on the web, and found not much more than a few people's short descriptions of their own projects, most of which are e.g. Rollercoaster Tycoon style isometric map tile work, or just plain top-down.

    The advantages of Starcraft's system are fairly plain to see, now I've stopped to think about it. Firstly, your map data may be stored in a much more logical fashion, as the representation becomes orientated to the screen rather than isometric coordinates - a square map looks like a square on-screen and not a diamond. Secondly, you can have your isometric tiles like normal, but areas of floor can be broken up into smaller chunks for variation.

    For the implementation, it's probably not too bad going from an existing isometric tile engine. You could either set up your new, smaller grid map system, keeping a record of the isometric tiles you've put down (one record for every four squares - draw yourself a grid and overlay an isometric representation, you'll see), of course changing that data whenever the user puts down a new tile and thereby giving you something to work from when deciding what new tiles to lay down in the affected smaller grid squares. Or, you could extend an existing tile engine to have eight smaller squares for each tile you have, and change the data like that. I guess it's really the same thing, though in the latter implementation your isometric map data remains diamond-shaped on-screen. Sorry if that doesn't make sense.

    I'll call the smaller tiles minitiles. What I'm saying is that you keep a record of tile types in an isometric sense, so that you can know what minitile types to put down. A tile (which consists of eight minitiles however you look at it) might be say, a transition from cliff to grass. You know which minitiles you NEED to place down to make it look like that, so you can put those down, and you might mark off say 3 of the squares as "definitely just grass" so your code could go through and fill those up randomly with your grass minitiles. You might do the same for the clifftop.

    Let's say you decide have a isometric tile that alters a number of minitiles around it. Your data might look like this:

    Code:
    tile[0][] = { 0, 1, 2, 2, 1, 0 } 
    tile[1][] = { 1, 2, 1, 1, 2, 1 } 
    tile[2][] = { 1, 2, 1, 1, 2, 1 } 
    tile[3][] = { 0, 1, 2, 2, 1, 0 } 
    
    This tile data would affect 9 isometric tiles. The 2x4 section in the middle is the target tile, and the surrounding numbers affect the minitiles of neighbouring tile types.

    And you might interpret that data when you lay the tile down as
    0 - don't change the contents of this minitile
    1 - choose a random minitile from that isometric tile's type
    2 - this is set transition minitile data that you look up by comparing this tile with the tile it's contacting.

    So for the 1s in the centre, you look up the tile type and of course it's the type you just laid down, say water, so your code chooses four water tiles and drops them in, then it looks at the surrounding tiles and what ho, they're all grass so all of those 2s can become water-grass transition bitmaps, so it grabs them and slots them in, and then it drops in the random grass tiles in the other 1s and leaves the 0s alone.

    It's a bit more complicated than that obviously, as every minitile is part of two isometric tiles. I guess you might store two references to your mother isometric tile data within each map tile. Only in the editor, of course. Once you'd exported the map for gameplay there would probably be no need for such data.

    Er, sorry, I went on a bit of a ramble there. Hope it helps and wasn't completely not what was required.
     
  11. Nemesis

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    273
    Likes Received:
    0
    Haven't given proper thought on this, so take the following with a pinch of salt :) :

    Perhaps it is worth having functionality of some sort to define mappings of the sort:
    (base_tile, adjacent_tile0, ..., adjacent_tile7) => actual_tile

    Basically, the mapping defines the actual tile variant for the base_tile being placed. The base tile would represent a generic feature like water, or rock. The actual tile would be a variant, like water's edge on one or more sides.

    Setting the edges could be a manual affair or perhaps the tile set could be arranged in a certain order so that the editor can figoure out the mappings without resorting to manual setup by the designer.

    Here I'm assuming that a tile brush will only affect it's immediate members but in reality it could affect tiles further out in a recursive manner e.g. placing water near a clif edge could cause the edge to 'cave in' to make room for the water's edge.
     
  12. Pyabo

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    1,315
    Likes Received:
    0
    I've done something similar to this... It's just a matter of looking at the surrounding tiles and dropping the appropriate graphic based on that info.

    In my experiments with this, a single tile contains all the edge graphics. Finding the correct tile is just a matter of creating a bit field that represents the neighboring tiles -- there are 8 neighbors, so it works out nicely. Then this bitfield is used as an index into a lookup list which points at the correct graphic to drop.

    It could work the exact same way here, there's only two differences: translating from iso-tiles to actual tiles, and that the editor is modifying each neighbor tile rather than the single tile you're working with. The logic is still the same though... when you drop a tile, look at each neighbor and assign it the correct graphic based on its neighbors.
     
  13. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    Yep, that's right. There are ramps but they're placed as "doodads" and not via brushes. They are still however a part of the terrain. I used to think that the doodads (which include rocks, trees, and other stuff) were objects placed on top of the terrain like buildings and units, but now I realize that the whole map that you see other than the buildings and units is composed of tiles! So the whole map is actually made of one single layer. This must've been quite a bit of work for the artists, but it does explain how SC was able to run on such low end computers -- all they had to do was render a single layer of tiles (plus the buildings/units) at 640x480x8. I believe initially the minimum requirements were a 486/66 and later changed to Pentium 90.

    There are some interesting ideas here so far. The overall consensus seems to be that when placing a tile you should look at the tiles around it to figure out how it should look, which makes sense. I've just been a bit confused playing with the StarCraft editor because it makes a different number of tiles per brush click for different terrain types. Since it's far easier to show it than explain it, here's yet another screenshot. What I'm saying is that when you click in that spot (where the diamond is) with this brush, the editor creates that entire area. I'm not sure how they implemented this, but I do know why it does it. If you look at the diamond, you'll see that the floor under it (the size of the diamond) is different than the floor in the pit in general. This is a different tileset for use within the pit itself. This in-pit tileset however can never be closer to the walls of the pit than it is in the screenshot, which is why that entire area was generated. So the question is did they use some sort of recursive algorithm to generate such complex terrain brushes, or did they just script each brush individually?
     
    #13 Valen, Mar 7, 2005
    Last edited: Mar 7, 2005
  14. Teeth

    Original Member

    Joined:
    Dec 6, 2004
    Messages:
    165
    Likes Received:
    0
    Well, I'm guessing from that that they have some kind of relationship from one tile type to another. In the screenshot you posted, you could recreate the effect by looking at the tile you have just laid down. It's like a second pass - take your empty map (these are the isometric tiles I'm talking about, not the smaller ones):
    Code:
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    
    You then place your metal plate tile (type 1) like you did there in the screenshot
    Code:
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 1 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    
    And I guess your tile type would have info saying "must not have tiles of wall type next to me", which type 0 is, and it would also have info saying "use type 2". You then go through your map and change all the tiles that are next to a tile of type 1 that are also flagged as walls (type 0 is a wall in this case), and change them to that type:

    Code:
    0 0 0 0 0 0
    0 0 2 2 2 0
    0 0 2 1 2 0
    0 0 2 2 2 0
    0 0 0 0 0 0
    0 0 0 0 0 0
    
    ... and then your type 2 tiles might be all like "Oh, but we need a type 3 (transition between wall and meshed flooring) between us and the wall" and so forth. Your screenshot shows a panel floor tile surrounded by a ring of metal floor tiles surrounded by a ring of wall tiles, surrounded by uncut terrain. I was going to mention before, but the upper level tiles in the outdoor maps also appear to affect the three tiles immediately below and to the lower left and right as viewed on-screen. This makes it look fairly tapered, and you can see where the artists had to work around that to make it look more 3D and not big and flat. But essentially it's the same thing: "Ah, I'm a upper level tile - check those three tiles below me to make sure they're of the correct type and change them if need be". It seems the editor definitely works broadly on this level before getting down to the stage where it chops the tiles up into 8 sections and starts randomising stuff.
     
  15. Valen

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    133
    Likes Received:
    0
    I think you're totally right about this. I can't believe I didn't see it! A classic example of not seeing the forest for the trees. :) I was so caught up in looking at the "small" tiles that I forgot about the isometric tiles they make up. I also just realized why in the last (indoor pit) screenshot there's more floor under the diamond than above it. It's because the perspective (angle) that they're using makes it seem like the distance is longer. In fact it's the same exact distance in isometric tiles (two isometric tiles in every direction). Now I have something to work with, thanks!
     
  16. Teeth

    Original Member

    Joined:
    Dec 6, 2004
    Messages:
    165
    Likes Received:
    0
    Yeah, totally. It looks so wrong at first, but when you consider it in terms of actual tiles, it's so right. Hope it works out for you!
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer