This is a second part of my game map explanation series. Please see this post for part 1. We have previously discussed the front-end part of the strategy game map building, and will talk about the back-end. And to begin with – the MySQL database schema!
The schema is better shown on this image:
To make it all work, we will use the following model to fetch the database data and render the tile.
The code is pretty mush self-explanatory. There are just two moments I would like to comment.
- The
MapTileIteratoris used to iterate the tile neighbors in a right order – clockwise starting with top left corner. - For now, every tile is rendered with the coords (x:y) in the top left corner. This is for made easier development. But, as people mentioned on CodeReview, this is not the best way in a performance perspective.
- This is still under development and I am going to add transitions between the tiles with different ground types, which is why I need the neighbors data when generating the tile.
- The images are cached in files and apc_cache.
Any comments welcome!
P.S. I am new to gists so this post might be a bit messy. Please feel free to suggest any other code embedding systems for WordPress.com!
game::dev('lamp', 'etc.'); 
Two questions.
Why PHP?
And why not put everything that occupies a tile, into a single table called map objects. That will contain, water, grass, sand, giant boulder, wall, door etc. Instead of defining a table for every object type.
I’m not saying it’s wrong or right, I have no idea. I just want to know your reasoning.
1. php – because I am pretty fluent with the language
2. I wanted to have separate classes implementing one interface for surface types in order to make it more convenient and flexible to use. For example, some ligic and/or methods could be only applied to ice, but not the sand.
And thanks for your questions! 🙂