Obviously, I haven't just started a blog to document things without having done a little bit of thinking beforehand. Not a lot mind you, but some. And like many ideas, the idea came from playing some games (in this case, Oblivion, which I had managed to avoid playing before) and having a new toy (the
C4CPC for the GX4000, an easy-to-update virtual-cart system using an SD card for storage).
I also saw a Kickstarter for a
C64 RPG and I guess that also played on my mind.
My first thoughts were scribbled onto paper, and are certainly not complete - more basic ideas about what features should be included, how the game would be presented (I have a note: "Zelda-style, not Dungeon Master") and how the screen would look, perhaps. I thought about graphical styles for different areas of the game - castle, caves, sewers, outdoors, mountain, etc; what the game should feature - shops, NPCs with conversations, quests, objects; and how to save memory on a limited memory system whilst having large game maps.
My first idea was that some maps would be large, and some would be small. Some would be stacked, and some would be quite flat. Yet they should all follow the same definition format.
For example - a central point of my game (for now) would be The City (with no name yet).
One of the things that irked me about Oblivion (and many RPGs), is that cities and towns are a little bonkers. A massive fortification supporting 20 houses, an inn, a church and a castle, for example. Now even back in medieval times, cities weren't tiny like that. So I wanted some sense of scale without using too much memory, or too complex data structures.
One option is auto-generation of a large city from an approved random seed value. But that would generate the large map in my limited amount of RAM which I need for tracking dynamic game state - and I expect an RPG to have a lot of that. However I'm not ruling it out for dungeon generation later in the game.
So what you need to do is create an effectively detailed city from large building blocks, which themselves are not giant graphical assets, but built-up from smaller assets. If you've ever used SEUCK on a C64 you will know the concept, and many games did this on the 8-bit machines.
After some iteration, I have settled on a full-screen 36x28 cell display of the playing area, and a map can have, for example, 64 of these screens in an 8x8 arrangement. A 'tile' (wall/floor/road/water/etc) in the game is 4x4 cells, so each screen only needs 9x7 tiles to define it, which may hopefully be a mere 63 bytes if I limit the number of tiles (I can use different tilesets for different maps for variety). Additionally, I am considering that we can store a 4x4x4 set of screens for a map with 4 levels (The Castle Keep, for example) in the same format. I might as well round up the screen to 64-bytes for alignment (one byte metadata per screen perhaps?). The memory requirement here is 8*8*64, or 4KB if we keep a lid on things. Or we could consider allocating 128KB of our Plus ROM to screen definitions, allowing a 2048 screens within the game.
Obviously every map will have associated metadata - not only what tileset to use and the dimensions of the map, but we need a record of intra-map portals (e.g., up these stairs to another floor) are, and links from this map to other maps (out of the city gates to wilderness, down this well to the caves, etc). We may also want sparse maps rather than grid maps, so we don't waste memory on empty screens (for example, mountains are mostly non-traversable - unlike Oblivion where you can ride a horse on a sheer cliff-side - so let's store the valleys and passes and not the peaks).
Additionally object instances within the map need enumerating - although these may be global as they can move (e.g., with the player). Each instance of an object will have a location, which at this stage will certainly be a Map Id (I'm sure the game can limit itself to 256 maps!), a Screen Id (within the map - theoretically we could have 16x16 screens), and a Location within the screen. Note that we have a 9x7 screen, so there are 63 locations. Additionally, we can have more fine-grained object locations - an 18x14 grid gives us 252 locations - conveniently this fits inside a byte.
I'm not going to get too het up on memory allocations and the like now - the game will evolve and decisions now may prove distressing to fix later on if a non-agile approach to the game is taken.
In my mind, I'm guessing a screen will be around 10 metres wide by 8 metres high, and a tile just over a metre square - at least in the city. In the mountains and wilderness we can have a different scale, games have gotten away with a lot less!
I wouldn't be surprised if eventually I end up with a small castle with 20 houses, an inn, a church and a castle. But let's aim a little higher...
