Implementation

Adding in a 3rd dimension for Isometric RPGs

Does anyone remember X-COM's UFO: Enemy Unknown? It had a limited 3rd dimension added to it. The height box allowed your forces to move up or down into 3 possible heights, which allowed for different levels in the towns and spacecraft. I think that using certain strict guidelines, it is possible to get a height field into the game. The way that I see it, you need to be able to bind the height by a certain region. For example, we are using cubes to represent these boxes; an isometric tile represents the area on one face of these cubes (because we are thinking about moving around this 3D environment without a restriction on viewpoint). The centre of view is at position <x, y, z> (which is our player coordinate) and is bounded by some value. To make it possible to view with a height-field while keeping a reasonable frame-rate, the bounding occurs to reduce the number of cubes that we need to consider when rendering. Now to actually put this into a definite example we use numbers. Our player is located at <20, 45, 3> and we have a vertical bounding of 10 for example. We then need to render each "layer" (height field) of this world between [z = -7] and [z = 13]. The x and y bounds are dependant on your screen and layout, and is already covered in any isometric tiling example.

Adding THE 3rd dimension for Isometric RPGs

On a more 3D oriented approach, I have seen people who have been apparently making "outrageous" statements about having a random tiling system that uses 3D. Well, I do not think that this is as an outrageous statement as it seems. In a similar way that any of those 3D games use objects that can be placed anywhere in their world, you can create "3D tiles" that can be placed anywhere in your world. These "3D tiles" can be placed on the map the way that the actual tiles used to. It is a fairly simple concept that would add the benefits of a full 3D engine (being that you could add in rotation and 3D stuff like that) and lighting (such as shadows, highlighting etc.). Simple concept, a little harder when creating "tiles", and a fairly simple way of introducing a new look to a simple isometric tile engine. It should still be faster than any 3D game as well, because you already have a defined bounding box (i.e. within a certain range of tiles) and the rest can be clipped by the screen (or clipping region). This can also be used in combination with the height fields that were mentioned above (height-field * local-z position gives you a placement on your overall height). I would definitely like to see this implemented into isometric style games. About what I said regarding "more difficulty creating the tiles", it may not be difficult at all, because a lot of the tiles are already created using a 3D renderer. They are just pre-rendered so that they can be blitted to the screen using the old isometric blitting engine, whereas the 3D version just needs to import the 3D file and use that. The importing is what is going to be the difficult part, but I leave that for a specific implementation…

Adding unlimited maps, allowing the option to explore

What really annoys me about isometric games at the moment, is the fact that you have such a limited area to explore. There have been many algorithms developed that can create realistic randomly generated terrain, but I have not yet seen a system that allowed full openness in its world. A certain popular Roguelike (that is the sequel to another slash 'n' hack Roguelike) of late has been using a method which has been part of discussion for some time, but I haven't actually seen implemented. Instead of having your world consisting of dungeons of different levels or depths, the new system uses an open world that is broken up into lots of little square/rectangular maps. These maps are stored separately, and are loaded when needed. The maps that are loaded are based on simple rules:

The reason why you load the surrounding maps is this; because your player wishes to roam freely around the world without any noticeable load times (that is the major concern for us) then you need to have the next map that they are going to get to already loaded. To do this effectively, you just load ALL the maps that surround the current one that the player is in. Due to memory restrictions you can choose for this to be a small buffered layer of maps, or if you have fairly free resource space then you could load more. The more you can have loaded, the further the player has to go to reach the limit of that which is already loaded. Now that you have this delay factor, you have some extra time to load some more maps from disk when the player enters the new map. On leaving the map that the player was on, they enter one of the surrounding maps that has been buffered into memory. The maps that are now considered out of range of the player are released and the new maps that are considered in range of the player are loaded.

This very simple concept has not made any noticeable impact on the majority of the isometric games industry. I would really like to see some thought actually put into this as it would really open up a New World of fantasy, science fiction, and "present day" game implementations that really allow for Role-Playing on a large scale. Limitations or boundaries in such games really seem to push people away from computers with the message "we can make your old pen-and-paper RPG look really snazzy, but we can't make it have the same freedom" which is something that really is not true. For roguelike games, Diablo II used a system, which seemed to work on a similar principle; a large open world that was divided up into smaller "maps" that were loaded as the player moved from map to map. It was a poor implementation of the system in that the load times tended to lag the game dramatically when moving from one map to the next. Perhaps this is just a minor detail that they overlooked because they were using computers that were too fast for testing this (I am thinking SCSI Hard Drives with fast disk caching). This would mean that they did not change the priorities of their disk reads so that they became less prominent on the system. Another reason for it may be that they were not loading/creating the next map until the player came within a certain distance from it. This is a major mistake, and I think that it really should not have been done like this. The boundaries in that game was far too restrictive, and I think that on the map implementation level that I have seen many Beginner Game Programmers (i.e. Proficient Programmers who are new to Game Programming) create far better map and world systems than that in Diablo II.

(New) Implementing the Flowing Fighting System

This is the actual Implementation side of things for the Flowing Fighting System (Realistic Sword-fighting – "Aiming for the head" and Flowing fighting – Bringing in the arcade fights) based on the discussions from the corresponding discussion threads Sword Fighting - RPG and Flowing Fighting System.