Why do city tiles have to be square?

[BLANKBLANK 4,414]

Read the last two paragraphs of this article (in the link below) in pcgamer about Simcity, the author proposed curved tile boundaries and suddenly it would make everything so much more cooler.

http://www.pcgamer.com/2013/01/26/are-simcitys-cities-too-small/

Maxis can keep their fragmented regions, the cities would look more natural giving the boundary which is curved plus there would be a bit more space to build.

For that matter if you were to have continguous city tiles why do they have to be square? Why can't you have an option to divide up your square region by assigning the lines which will partition it and each piece of course will be a city tile.

In short, why do city tiles have to be square?

[Ocram's Razr 963]

The Glass BOX engine only supports simulation BOXES. That is the reason.

Good luck!

--Ocram

[DmainEvent 195]

They don't have to be. But the game was poorly designed from the beginning.

[EXVAS3221 5]

Read the last two paragraphs of this article (in the link below) in pcgamer about Simcity, the author proposed curved tile boundaries and suddenly it would make everything so much more cooler.

http://www.pcgamer.c...ties-too-small/

Maxis can keep their fragmented regions, the cities would look more natural giving the boundary which is curved plus there would be a bit more space to build.

For that matter if you were to have continguous city tiles why do they have to be square? Why can't you have an option to divide up your square region by assigning the lines which will partition it and each piece of course will be a city tile.

In short, why do city tiles have to be square?

I agee on that why did maxis, do this too use, I would never understand? that one of the resones i am not buying it is not natural, like you were saying. i am sorry maxis you pushed out so meany great titles intell now?

[BLANKBLANK 4,414]

The Glass BOX engine only supports simulation BOXES. That is the reason.

But within the city tile the Glass Box engines must handle simulator elements (curved roads, congestion, demand, crime and anything that creates a zone of effect) which follow non-linear paths bound to a square city tile. If they (Maxis) can effortlessly create curved roads and zones to fit such roads, then surely they have freed the simulation of being constrained to grid-like parcels (like that of SC4). Since the simulation must be a finite collection of points presumably laid out in a square grid upon a square tile, then on tile with a curved boundary a square grid would more or less fit (with a small tiny pieces of space unoccupied with points at the border).

Note: When I say square grid I'm referring to the basic layout of the points: they always have an equal distance between them, and I'm NOT referring to the SHAPE of the entire bunch of points forming a city tile.

[Indiana Joe 1,750]

It's much easier to program a square game. You have basic x and y coordinates of everything, instead of some complicated circle coordinate system. Even the curved roads have x, y coordinates within the square.

[BLANKBLANK 4,414]

It's much easier to program a square game. You have basic x and y coordinates of everything, instead of some complicated circle coordinate system. Even the curved roads have x, y coordinates within the square.

Easier yes, but a Cartesian coordinate system can apply to any shape of tile, just set your origin and you can start programming. Besides for circular or elliptical curves, polar coordinates (circular ones) can be even easier to model such curves and have only two components; radius from the origin (O) and the angle of rotation between the positive x-axis and the line OB (where B is a point, and the length of OB the radius). They even have modelled the curved roads using polar coordinates!

[Vahr 341]

Because its easier and more efficient to use a simple bound-checking function for the purposes of locating and placing objects.

For a position (x, y):

if x > 0 and x < WIDTH and y > 0 and y < HEIGHT then (x, y) is within the region bounded by (0,0) and (WIDTH, HEIGHT).

Also, data structures for things like the terrain heightmap are inherently disposed to rectangular areas. For a rectangular area, you simply need to store a linear array of height values to define the terrain, that fills in row by row. For a irregular or arbitrary shaped area, you'd either have to bound it within a rectangular area and have a lot of zeros in the data, or store the terrain data as triplets (x, y, height). Both of which are not memory and computationally effective.

[DmainEvent 195]

Because its easier and more efficient to use a simple bound-checking function for the purposes of locating and placing objects.

All area's are simply 2 dimmensional arrays (x-y coordinates). You would be storing the same number of coordinates, lets say [100] X [100] you would just need some kind of data structure to define the irregular shape. You could have a random shape generator that runs an algorithm on the coordinates and generates an irregular shaped map and store that. The return result would probably just be a linear array defining the edges of the map. Similar to how a height map defines the height for each [x][y] value, the edge map would say if this n'th [x][y] coordinate is an edge or not. I am not an algorithms guy, but to me this doesn't seem like an impossible task.

For a position (x, y):

if x > 0 and x < WIDTH and y > 0 and y < HEIGHT then (x, y) is within the region bounded by (0,0) and (WIDTH, HEIGHT).

All the edges of the map would be known already. So that same same function would apply to an irregular shaped map.

Also, data structures for things like the terrain heightmap are inherently disposed to rectangular areas. For a rectangular area, you simply need to store a linear array of height values to define the terrain, that fills in row by row. For a irregular or arbitrary shaped area, you'd either have to bound it within a rectangular area and have a lot of zeros in the data, or store the terrain data as triplets (x, y, height). Both of which are not memory and computationally effective.

Again, you could apply a height map to an irregular shaped list of x,y coordinates. Tripplets is essentially what a linear arrary is. You have a x-y array and a third array z or h for the height map. So for an area of NxN your height map would be of size N. So if you had a x-y-z array (a 3 dimensional array-[x][y][z]) you have precisely the same storage requirements, and the same O (1) to find the values. So that isn't a problem either. Actually you would also need another linear array to represent the edges [x][y][z][e-for edge]. So basically when you have an x-y coordinate, just check the 4'th array value at N to see if it is an edge value (you could make it a bit or a byte if you want to store other edge info), If 0 you are outside the map, if 1 you are in.

All path finding algorithms are based on the roads (and other paths), so there really is no reason that the map would affect any of them.

Again, I am not an algorithm's guy. But I don't see why this would be that hard.

[nhgriffith 179]

I don't think there is a programming need for rectangular zones. However, if you really think about it, rectangular zones remain best for creativity. If I'm the type of player that wants to optimize my space, I'm going to stick to grids no matter my boundaries. However, if I want a more creative layout to my city, I've got a blank canvas, and a straight edge only influences me if I'm worried about space efficiency.

Go to a museum. The paintings are hung in rectangular frames.

Give my city a curved edge (or frame, if you will) and watch. That curved edge will actually stifle my creativity. I'll be more apt to let a curved boundary influence my curved designs than a straight edged boundary. Meanwhile, the efficiency nut still builds a grid, and if anything, is annoyed by the non straight boundary.

Paper is easy enough to cut or tear to a no straight edge, non rectangular shape, and yet I never see artists manipulating their canvas edges in this way. Why should we, as city designers, require maxis give us non straight edges to influence or creativity.

Moreover, the lack of terraforming and existence of terrain features helps shape our cities with non straight edges, even if the white line boundaries we're given are straight.

[MandelSoft 2,769]

There is another thing that may be hard to make non-rectangular city boundaries: collision detection. This is a mechanism to check if objects don't cross each other, like roads and buildings, water, other roads and even the city boundary itself. Collision detection is hard to program, especially when it's not a rectangular or box shape. If you would have a non-rectangular object with collision detection, it would involve complex trigonometrics and other complex math. And that will take up a vast amount of resources, especially when you need to do this for hundreds, even thousands of objects...

[DmainEvent 195]

There is another thing that may be hard to make non-rectangular city boundaries: collision detection. This is a mechanism to check if objects don't cross each other, like roads and buildings, water, other roads and even the city boundary itself. Collision detection is hard to program, especially when it's not a rectangular or box shape. If you would have a non-rectangular object with collision detection, it would involve complex trigonometrics and other complex math. And that will take up a vast amount of resources, especially when you need to do this for hundreds, even thousands of objects...

Collision detection is easy if you know the boundaries of your objects...

And Anyway, what collisions are you detecting? Basically the boundaries of a map. It's not like they have a dynamic simulation where if you click in one city you are simulating that, and the other cities are not being simulated.

So In my estimation, there is no programmatic problem with non-square tiles.

[Fornix 4]

The choice for square has probably partially been made to ensure an equal playing field for the leaderboards. Different shaped regions would mean some people may be at an advantage whilst others may be at a disadvantage in terms of sim traveling times and such and therefore have an easier or harder time ranking on the leaderboards.

[Hoipus 292]

Then just have leaderboards sorted into ratios like "criteria"/square meter

[nhgriffith 179]

Then just have leaderboards sorted into ratios like "criteria"/square meter

The problem isn't about different amounts of area. The problem is about how the same amount of area is shaped.

Consider 4000 square meters as our city size.

In a perfectly shaped circle, this gives us a radius of about 36 meters, which means the absolute farthest distance between any two points in this map is going to be 72 meters. Now, by road, for a sim, this could potentially be slightly longer, but not by much.

Take that same 4000 square meter size and put it in a perfect square. The length of each side will be about 63 meters. The length from one corner diagonally across the map of a square 63 meters on each side is about 89 meters.

Meanwhile, if we suppose that the area isn't actually a perfect square, but instead is a rectangular shape, that's say 40 meters by 100 meters, the diagonal length is even longer--almost 108 meters.

So, the point is, different shapes have longer farthest-point distances within them despite the same total land area. When things like commute time make a difference in the simulation, the only fair thing that makes sense is to give everyone the same shape when it comes to leaderboards.