I'm started a XNA project to make a game similar in gameplay to Super Spy Hunter on a NES, which is used as a feature reference. The first thing I thought of is how to store and display level. Currently I'm thinking of using some tile graphics editor and custom pipeline for drawing level. I'm not sure however, that all is possible to implement every feature of reference game, but at least it's a start.

Question is, looking at a given gameplay video, can you think of any possibly better approach then to design level using a tiles?

By "better approach" I mean which will be either easier to work with, which will be more "natural" for this kind of game. The doubt comes mainly from a huge technology gap between then (1990) and now. So there is possibility that using current cpu power this could be done easier.

Update 1. As I continue study reference game and @ashes999 correctly mentioned procedural generation also comes into my mind. I began to think game logic is something like (simplified):

while next road section exist:
    get road section data;
    set road generation options (borders type, road type, etc);
    set road section lenght;
    while not end of a section:
        generate road;
        apply pseudorandom eye candy stuff;

this all looks like a pretty good data driven algorithm.

  • \$\begingroup\$ What do you mean by "better"? \$\endgroup\$
    – Thomas
    May 9 '12 at 8:38
  • \$\begingroup\$ @Thomas see updated question. \$\endgroup\$ May 9 '12 at 9:56
  • \$\begingroup\$ In a word: PCG. Procedurally generate the level; this allows you to create "infinite" length as needed by the user. \$\endgroup\$
    – ashes999
    May 9 '12 at 21:22
  • \$\begingroup\$ @ashes999 this one was certanly in my mind too. I actually think the reference game uses combined approach. \$\endgroup\$ May 10 '12 at 1:43
  • \$\begingroup\$ @ashes999 I also think you should post your comment as an answer. \$\endgroup\$ May 10 '12 at 2:06

In a word: PCG (procedurally generated content). Procedurally generate the level; this allows you to create "infinite" length as needed by the user.

What does PCG mean?

In your context, PCG means: only create as much of the map as necessary (maybe 10 screens worth or something ahead of the user). When you "run out" of road, recreate more.

The content is generated algorithmically. Looking at the video you posted, I would just randomly generate the width of the road; that's it. Generate enough ahead compared to what you need.

It's really simple, and flexible; you get "infinite" road.

  • \$\begingroup\$ Never thought about making it a random road. That's an interesting idea. Thanks a lot! \$\endgroup\$ May 10 '12 at 6:29
  • \$\begingroup\$ PCG is awesome. It's not a silver bullet, and it's harder because you work on algorithms, not specific cases. If you get time, I suggest making a roguelike -- that'll throw you into a game that's almost 100% PCG, and you'll get the hang of it. That's what I did :) \$\endgroup\$
    – ashes999
    May 10 '12 at 14:53

It is a very hard work to create such a long map with tiles. I propose a "better" solution:

  • The border of ther road is series of line sections, you can render render poligons with texture. It is quite simple. The road can be filled with textured poligons.
  • The background (water, grass, etc) is just simple texture, you can just address the map based on the position where they start (or end). You need to create a screenspace rectangle, covered by the texture, and shift it slightly. At the borders, you can create two of these rectangles, and align them accordingly.
  • The large background elements (houses, bridges, etc) can be added as big objects, with custom rectangles. Since they have no other purpose, just decorating the background, they are just freely positioned spritest, textures (or models)

For the foreground, you can use address the enemies, and other objects based on their positions on the map.

This solution is also good for 3D but you need a bit trick for the road part, the rest is almost the same.


  • Border: You only stores line segments, which is independent of the lenght of the segments, and you can freely edit the map easily. And the border line can be even used for collision detection.
  • Background: Tiles takes larger data, and more time to set. As you can see, in the gameplay, there is a lot of water. Instead of setting a few thusand tiles, you just store a texture name and a value of the beginning (mesured in distance from the beginning. E.g. WATER 0, GRASS 200, WATER 500, etc... Of course, you use some structure and an array/list to store them, but it is much less data then the tiled version.
  • Buildings: Each building covers a whole bunch of tiles, which are closely related (you dont want to put a single wall tile in anywhere else). It is obviously less data, than the tiled ones, and can be easily moved.
  • \$\begingroup\$ It's certanly somewhat hard, but: 1) I don't quite get how your solution is different from actually using tiles; 2) it's not clear how to store level data. \$\endgroup\$ May 9 '12 at 17:13
  • \$\begingroup\$ See the updated description. \$\endgroup\$
    – Matzi
    May 9 '12 at 17:29
  • \$\begingroup\$ Well, most of possible problems it not a big deal for modern tile editors, but a large tile map itself is certanly is. I understand your proposal now, storing "tile lines/regions" instead of "tile points". Certanly a possibility here, thanks. \$\endgroup\$ May 10 '12 at 2:21
  • \$\begingroup\$ Not exactly, but you can imagine it that way. Define larger regions with textures, but it is not like using tiles. \$\endgroup\$
    – Matzi
    May 11 '12 at 13:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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