|
Socoder -> Web Development -> Storing a large grid in a database |
|
| Thu, 22 Jan 2009, 19:29 | |
|
mindstorm8191 |
I have been wanting to make a browser-based game for a while now, and after playing www.Travian.com for as much as I have, I am trying to avoid making a copy-cat game. My game will be a mix between Travian and Sim City; you'll be able to build a city, and then defend it against neighboring cities as you push your city borders further and further. Now, the problem I'm seeing is handling an extremely huge map on a single database. If I keep it looking alot like Sim City, there will be a lot of squares on the map, each with unique data. I'm expecting to have to read this data frequently, and write new entries from time to time. So I've come up with three options, and I don't know which one would be best. The first is to store the map in record chunks, each one holding a 4x4 or larger square area. With each record collected from the map table, I will read from a long string that holds information about each individual map square. The second option is to use 2 tables, one to manage where each square is located, with an ID to another table, each containing all the needed data for that square. The third option is to keep all the data in a single table, and let the database figure out how to organize it. What do you guys think? If anyone knows which is probably faster (or if you know another faster way), I'd like to know. Thanks. -=-=- Vesuvius web game 
|
| Thu, 22 Jan 2009, 22:08 | |
Stealth
|
Use a MySQL database. It's easy to use with some simple PHP code. You can preform some pretty fast read/write operations with it. -=-=- Quit posting and try Google.
|
| Fri, 23 Jan 2009, 05:23 | |
JL235
|
I think you should implement it in the most simple and straight forward way possible and then devise some benchmarks to run against it. If it's too slow then try to optimise the system and then and run against the same benchmarks. The benchmarks should accurately reflect real usage. |
| Fri, 23 Jan 2009, 05:43 | |
Jayenkai
|
Don't overthink it.. Remember that Amiga, SNES, and other 8-bit game/computer systems were perfectly capable of Sim City. First up, cut the Extremely Huge map down to segments.. say 256x256 (8-bit int) From that, give each of those a reference, 16x16=256. That'll be a 4096x4096 grid.. If you make your references larger than 256, then you can build right the way up to mega-cities. Within each 256x256 grid, keep about 3 layers. Layer one would be the basic "Draw this" layer.. This will be sent to the player almost instantaneously, and displayed on their screen. Edges are more important than center tiles, since they act to stream the edges, or unloaded areas, constantly. After that, keep checking the central tiles intermittently, to ensure they're up to date. Thinking Sim City, that would essentially be "What gfx to use" and "R/I/C/Road/Power" That's enough info to get the game to draw it. After that, keep rechecking tiles, to get extra data about them. That'd be the stats for each tile.. The value of the tiles, the underground water system, any labels assigned to the tiles, and things like that. The most important step, though, is to have your game do a lot of the work, rather than getting it from the server. Again, in Sim-City mode, if a police station's placed down, then you can assume the Law map would show 0-crime in that area. Similarly, the health/fire/education stats are simply grabable from the data the game has, rather than having to get every little piece from the server, all the time. -=-=- ''Load, Next List!''
|
| Fri, 23 Jan 2009, 06:09 | |
|
Stealth
|
I was under the assumption that this was woo browser based. So all the data would have to come from the server.
-=-=- Quit posting and try Google.
|
| Fri, 23 Jan 2009, 06:15 | |
|
Jayenkai
|
"woo" Whatever the game is, it's still going to have a teensy bit of processor power. It'll be enough, I'd imagine... I mean, if not, then it's probably a bit too much to handle a super-mega-sim-city clone.. You'd need to scale RIGHT back!! -=-=- ''Load, Next List!''
|
| Fri, 23 Jan 2009, 06:18 | |
|
JL235
|
Plus if you can identify what are going to be the expensive areas early on you can then try to design the game with those sections in mind as being more componetisable then usual. i.e. make it easy to change later. |
|
|
| |||
|
| ||||