Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 3 down vote favorite

I am currently contemplating the layout system for my php based game but i've run into a couple of worries. So my idea is a 9X9 grid where the center 3X3 are inner castle. The inner castle will be 6X6 if you enter it(click on it). and with the option to expand the inner castle converting one of the 9X9 tiles to a 4X4 inner castle tile. So here is my question: What is the best way to tackle this type of layout? my original idea was a 18X18 grid and saving it in the db as (idCastle, Y, X) where X is a string of 18 numbers long telling me if the tile is an inner/outer tile or a inner/outer building. but i am not really fond of this idea and would like to hear some other ideas on how to tackle this. Thanks in Advance,

Gert

share|improve this question
I'm not sure if I understand this tile expansion. Does your original 9x9 grid actually consist of more tiles and just looks like 9x9 if shown with a particular level of detail? In that case, clicking on a tile would zoom in to see more details. Or do you have a 9x9 grid, with some tiles leading to other grids once you enter them. So, for example, only some of the 81 tiles in the 9x9 grid could lead to new and independent 4x4 grids once you enter them (or indeed to differently sized grids, depending on what is built on a given tile). Which of these alternatives do you use? – BerndBrot Aug 30 '12 at 18:26
in the beginning the 81 tiles will consist of 72 buildable tiles and 9 which will show a castle and once you clicked on that you see the inside of the 3X3. the outer 72 can become encased by the wall at a price if they are next to another one. which will lead to more room in the inner castle. The inner castle has double the amount of tiles so 3X3 in the outer is 6X6 in the inner. and my question is what the best way would be to store them in the database and differentiate between inner and outer castle. – user1636490 Aug 30 '12 at 21:53
OK, some more questions, then I think I'll be able to answer: What exactly happens to the outer and inner layer if you buy one of the empty tiles on the outer layer? (A picture would be great.) Do you then have 10 castle tiles and 71 free tiles on the outer layer (3x3 + 1 adjacent castle tiles) and 40 castle tiles on the inner layer? (6x6 + 2x2 adjacent castle tiles)? Are there also empty tiles on the inner layer, or does the inner layer only consist of castle tiles? – BerndBrot Aug 30 '12 at 22:24
@BerndBrot 10 castle tiles and 71 free tiles on the outer layer (3x3 + 1 adjacent castle tiles) and 40 castle tiles on the inner layer? (6x6 + 2x2 adjacent castle tiles) This is correct and the way i want to do it. i just don't like my current solution. – user1636490 Aug 31 '12 at 9:49

1 Answer

up vote 0 down vote accepted

It depends on whether or not information about the outer layer tiles can be deduced from information about the inner layer tiles. If they can, then database normalization suggests to treat information about the outer layer tiles as redundant and only store information about the inner layer tiles. This is how this might work:

table tile // only inner tiles are recorded
    id (or use [castleID, x, y] as a composite primary key])
    castleID (int)
    x (tinyint) // on a 18x18 grid
    y (tinyint) // on a 18x18 grid
    content (whatever) // content of the inner tile for castleID at position <x, y>

This will result in 18x18 entries for every castle, assuming that you save all non-castle tiles as well. You could also just store castle tiles and assume that if there isn't a record for a given position, the tile is unoccupied. In order to get information about the outer layer tiles, you have to fetch information about the respective inner layer tiles and deduce information about the outer layer from that.

If, on the other hand, information about the outer layer tiles cannot be deduced from their respective inner layer tiles, you have to add another table for the outer layer tiles:

table outertile
    id (or use [castleID, x, y] as a composite primary key])
    castleID
    x (tinyint) // on a 9x9 grid
    y (tinyint) // on a 9x9 grid
    content  (whatever) // content of the outer tile for castleID at position <x, y>

The content field is just a placeholder for whatever you want to store with respect to your tiles. In actuality, it might be an id of a record in your building table, or several fields like startedBuilding (timestamp), spriteFile (varchar), etc.

share|improve this answer
Thanks on your input so far. The problem with the first approach is that if i don't have a record in that spot i cannot know if its an inner or outer tile. And the thought of having to deal with 324 rows per castle isn't really attractive. The solution i think i will use is to make a table where the value of X are a 9 number string and using substr i can figure out if its unoccupied, has a building or is a inner castle tile. And from that i can build the inner castle based on the outer castle layout and using the records in the inner castle to populate the tiles. Thanks for your help again. – user1636490 Aug 31 '12 at 17:19
In the first approach, if you don't have a record for a given spot, then it does not matter if it's an inner or outer tile; in either case the tile is not occupied by anything. 324 rows per castle is no problem at all. Even if you have 1 million castles. Relational databases are really good at this stuff. Just build your indexes right and you should not experience any performance issues. Also, keep in mind that a castle only needs all these records if it extends over all available tiles. If you want to save rows (for whatever reasons), why not save a string with 324 characters? – BerndBrot Aug 31 '12 at 22:18
So i could save the 6X6 of the inner castle with their respective X, Y and inner castle defining attribute and letting players expand on that with buildings and letting them define empty spaces with inner castle attribute. At which point ill add that record to the table. – user1636490 Aug 31 '12 at 23:00
Yes -- as long as all non-bought, non-castle tiles are fully defined by there not being a record for that tile in the database. If you want to differentiate between different kinds of non-castle terrain, you would have to add a row for each tile, no matter if it's part of a castle or not. – BerndBrot Sep 6 '12 at 8:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.