Pixelville Part 1 - Aims, Planning and Challenges
While in my experience such projects are rarely ever considered finished, I would like to at least get the following done:
- Be able to create a randomly generated city within a set of parameters.
- To draw the city from an isometric perspective, at several levels of zoom.
- Be able to create all textures and detail for the buildings and landscape procedurally, that is no external resources (images/sounds etc.) will be imported to the program.
- Finally, to provide a automatic camera panning routine, and possible add a basic amount of animation (long term).
Procedural generation of cities is not a particularly new idea. Models with deep complexities can already can be found [PDF], supporting very organic road structures, population densities etc. Very little of that detail transfers particularly well to the pixel art world, for example curves/circles are notoriously difficult to draw realistically by hand, let alone by computer. For that reason, in this project I will be sticking to a very simple grid pattern, one that is not wholly unrealistic: many US cities today have a grid-like structure, particularly in the city centres.
Grid layouts are also much friendlier to program. The code will essentially store the city in a two dimensional array of grid squares, typical of many of the early simulation games (many of which are a big influence on the project). This lends itself well to an Object Orientated approach, such as that below.
This way, the data describing the cities composition is completely separate from the rendering process, allowing multiple levels of zooming (and possibly rotation?).
While drawing the basic shapes for the city shouldn't be too challenging, adding detail and textures will be a challenge. Some textures only need to be generated once then used repeatedly, such as road and grass tiles; building textures will vary greatly and will some can be reused, they will generally depend on factors such as height, type of building, and other factors. Also early experiments with Java's TexturePaint object suggest that it will not be flexible enough for the job, meaning a custom isometric texture renderer may have to be implemented.