Gw Temp


Tutorial - 'TBS Height' by Guest

An item about RPGMaker 2000 posted on


Teaches you another important factor in TBS's, height. Maybe another part to the TBS tutorials? The author is unknown at this point.


Tactical Battle System Height (Part I)

I decided to write a tutorial about Tactical Battle Systems (TBS). There isn't much information involving TBS or many games that include it. It is my belief that there are a couple of reasons why not many games use this system when created in RM2K/3.

* Firstly, before RM2K3 came out, many of the tasks faced with a TBS were much harder. For example, RM2K3 allows for 7-digit variables, which makes storing information much easier. There are also more options, more pictures available to display and so on.
* Secondly, even in RM2K3 a TBS is difficult to program. Programming a TBS is probably just as much work as an ABS, or perhaps more.
* Thirdly, and most importantly is the style of game play involved in a TBS. Have you ever played Final Fantasy Tactics? Disgaea? Vandal Hearts? Etc.? What was ONE key element that these games had involved that current TBS RM2K/3 games don't have? HEIGHT!

Height is very important to a TBS. Without height you simply have a plane that the characters move on. While it is possible to make an enjoyable game that is a TBS on a plane, it is very difficult. Why? Because movement is limited to a 2-dimensional world and the point of a TBS is perform TACTICALLY! Limiting movement limits the amount of "tactics" that go into a game. So now that we have that straightened out what are we left with? Skills, AI Intelligence, Story, Display, etc. But these are all things that normal RPGs, whether they use a DBS, CBS, ABS, etc must deal with. So we will only concentrate on how to add in the effect of height into a TBS and what issues will need to be resolved.

One final note: I have not discovered all the issues involved with height, nor have I solved all the issues that I have discovered. I hope that this article/tutorial/whatever will help inspire someone out there to continue on and collaborate ideas together to find and solve these issues so that one day we may have a REAL TBS programmed in RM2K3!

Tactical Battle System Height (Part II)

Movement is one issue that arises when including height in a TBS. There are currently two ways to move in a TBS that I know of. One is ONE?SPACE movement and the other is AB movement. (Thanks go to Disillusionist for inspiring me on ONE?SPACE movement)

In a ONE?SPACE movement system the unit moves one space at a time. After moving a space in the direction desired, the unit continues to move until he is not allowed to move anymore. For example, if the unit were allowed to move 5 spaces the unit would move one, then again, and again, and so on. The unit could stop movement at any point and forfeit the “extra” movement points in order to commence in an attack. Whether or not the “extra” movement points are stored or dumped or whatever is up to the programmer. How does this differ from AB movement? In AB movement point A is the original space a unit sits on. The user, or AI, chooses the target end position known as point B. The unit commences to move to that location automatically. This method requires checking availability of movement along the entire path. Cycling through all possible paths to find the “best route” (IF possible) and displaying the unit moving to that location properly. Personally, I feel that the ONE?SPACE movement is far easier to code and much better, however AB has a cleaner form to it, and it allows the user to see exactly all opportunities of movement before executing any movement. Also, in an AB movement system programming movements such as “Teleport” are much easier.

Ok, so now that we have the type of movement established, how do we tie in the fact that character moves one space (jumping down 2 spaces) when in the game he is really moving three tiles? The only method I could think of is by creating a “standard” size board that would fit the largest map you would wish to have your game on. When I say size, I mean the number of tiles in RM2K3, not the TRUE size of the map. Personally, I chose 40x40. Simply design all your maps on the 40x40 default map with “blank” spaces as unused spaces. For maps that are 40x40 tiles 1600 variables are required. 30x30 = 900. 50x50 = 2500 and so on. The MAXIMUM I could come up with is 70x70 = 4900. The issue with this is that RM2K3 only allows 5000 variables as the maximum, so choosing a 70x70 tile map only leaves you with 100 variables left, which is NOT enough for a TBS, especially one involving height. I chose 40x40 because it wasn’t too small, nor too big, but mainly the right size. 30x30 is also a great choice. Once you go beyond 40x40 it gets to be too large. Also, do not do anything such as 30x45 or such. Keeping it square will make life SO much easier for the display later on. Now, why would we need 1600 variables? Well, because each tile will be tied to a variable. When a map “loads” an event associated to it will load all the hard-coded data into those 1600 variables as a reference.

* +1234567 is how a variable is in RM2K3.
* +TXXYYZZ is how we will assign each of our 1600 variables (preferably using the FIRST 1600 variables to make life simpler)
* XX, YY, ZZ will hold the coordinates associated with that tile. The +T is if you wish to include other effects such as terrain into your game. Also, since variables can be positive or negative this can be used as a switch or to give more range on terrain types (-9 to +9) or to involve NEGETIVE height (below sea level).
* For empty tiles such as mountain sides or unused space 0000000 is best used.

Again, personally I chose to use it to enhance the number of terrains I can have. This means that the lowest height you can have is ZERO height and the maximum is 99, though you’d really only want to reach 20 at maximum for display purposes. A function will be needed to parse tile information into temporary variables. Preferably, the next 100 variables (1601-1700) should be left alone to store temporary tile information. This gives the programmer the option to store 20 different PARSED tiles. Each tile splits up into 5 variables, the first being the ID of the original variable. The other four are used to store XX, YY, ZZ and +T (or –T).

**UPDATE** I discovered an issue with this method when it is mixed with the layering method. One tile would represent two different locations, one of them “behind” the mountain and one of them that is the top of the mountain that a player can move onto. The issue here is that the method of storing the information to the variables doesn’t account for tiles that have 2+ locations associated to them. So movement has once again become an issue. Either that or display will be an issue and a new method must be found which will be more efficient than the layering method. However, I think it would be easier to change the movement method rather than the layering method because a new display method might still run into the same issues.

Tactical Battle System Heights (Part III)

If you chose to go with AB movement then moving an AI or character would involve cycling and storing to variables. Let’s assume that the maximum movement you allow in your game is 10 XY spaces and whatever amount of JUMP spaces. Simply go through a cycle and store the possible movements somewhere. There are 3 ways to do this as I see it.
* Use the +/- of the original variable (1-1600) as a switch of available movement.
* Create an additional 100 (10x10) variables that store a REFERENCE to that variable ID (1-1600).
* Create 1600 switches to parallel the 1600 variables (which is VERY wasteful).

Checking to see if a move is possible is simple. The priority goes like so (code it yourself, remember to store original position and work out other variables as needed):

Compare the coordinates of the tile above to the “current” tile. If the tile is within possible range and movement is legal, flag it. Let’s say that the tile above is [04,04,00] and the current tile is [03,04,00] … you would simply subtract one from the max XY moves and continue on with the cycle. Now, if the tile above is a mountainside then it’s variable would be 0000000, which means just check the tile above it until a REAL coordinate is reached. Perhaps the maximum jump 3, but after continuing up you find a REAL coordinate that has a height difference of 5. The move would be illegal and there is no point continuing UP. Then you would go back to the last position and move RIGHT. If RIGHT is possible then flag the tile and return back to moving UP. If RIGHT isn’t possible, try moving DOWN. If down ISN’T possible, try moving LEFT. If left isn’t possible and you return to the final original position, all possible moves have been flagged. Also, you might want to account for things such as road blocks (a tree) or an enemy, which cannot be walked through.

Also, something to take into consideration is the option that if the height difference is one, no "jumping" is required, so no jump points are affected. But that is dependant on what the programmer feels like doing.

If you went with ONE-SPACE movement then programming movement is much easier. You would simply do basically the same but include a “cancellation” option, which would undo the last movement. Also, it is easier since there is no cycling, but rather just check each move individually as it happens. To do this simply set aside MAX XY moves x 3 variables. So if 10 is the maximum XY moves, then you need 30 variables. Firstly, before any moves are commenced, the original location, XY movement and JUMP are stored into 3 variables. The next 3 variables would store the location you moved onto, the remaining XY movements and the remaining JUMP movements. Repeat this process, with the “cancellation” moving a pointer variable back one step. Once there are no more moves in the XY left, the user is forced to either use movement “cancellation” or perform an action (movement is disabled). If an action is chosen, the player’s position information is updated and the game continues on.

Tactical Battle System Heights (Part IV)

While GAP jumping (or horizontal jump) isn’t necessary to have a good TBS, it does enhance the tactical part of the TBS. Why would a unit jump down wasting his jump capability and get stuck in a canyon? He shouldn’t and wouldn’t unless the programmer really doesn’t feel like programming in horizontal jumping.

In an AB movement scheme horizontal jumping would be more of an “add-on” to the movement cycle. Once the movement cycle completes, a new cycle would begin which would check to see if jumping a gap is possible. This is very tricky to add in, but I think I have tackled the issue (again, coding is left up to you):

Cycle through all the flagged possible moves and find out how many movements in both XY and JUMP are left over if the move was completed. Let’s assume that NO XY moves are available, but the JUMP has 3 left. We move on because you cannot simply jump UP and land in the air, you must move in the XY also. So anything with at LEAST one XY movement will be checked. This also applies to less than 2 JUMP and also it applies to any flagged tile that is on the lowest 2 heights of the map (0 or 1). Simply use a similar routine… if the tile above is 2 heights below, then in a forward fashion (if you wish, attempt diagonal jumps). Check to see if a landing tile is within jump range. A landing tile would be JUMP spaces away in the XY moves if it were equal to or less than the jumping height. If you are jumping a gap and jumping up a height too then the total JUMP required would be the XY spaces away + JUMP spaces. The two added together would be required of the jump.

I’m still having an issue resolving cycling through the movement again. For example, say you started NEXT to a gap. After the first cycle of moves goes through, the second cycle would be the GAP jump test, which would result in a GAP jump available. Now, if after the gap jump there is still some movement in the XY left (or even in the JUMP left too) then that position must go through the ORIGINAL movement cycle again to add more possible movements. And once again, check for GAP jumping capabilities on the newly added flags. This could go on quite a bit depending on how many GAPS you place into your map and how much JUMP and XY move capability you allow.

The ONE-SPACE movement method is VERY nice if you wish to involve horizontal jumping in your game. The reasoning is that you can simply eliminate the need to flag all possible moves with a cycle and simply check to see if UP, DOWN, LEFT, RIGHT from the CURRENT position is legal. If so, move. Horizontal jumping and standard jumping, along with object blocking, etc. can all EASILY be checked, and if legal, perform that move. Now, what if you were next to a gap but simply wanted to go into the canyon instead of jumping the gap. Then you would simply need to bring up a popup option asking if they wish to jump the gap or go down into the canyon.

Tactical Battle System Heights (Part V)

Range highlighting is EXTREMELY tricky. I have only found TWO ways to do this so far. One way involves 1600 events, the other max XY movement squared (if it was 10, it would be 10x10 = 100). Simply put, in the 1600 events method each event would correspond to a tile of the map. If a flag goes off, the event’s conditions are changed and the event is altered in some form. Let’s assume that you only wish to highlight using 2 different colors: Blue for movement range (assuming you used AB movement since ONE?SPACE isn’t necessary for this) and red for attacking. Other ideas could be to use green for assistance magic (i.e. heal or haste). Regardless, the event should look like so:

PAGE 1 (No conditions required) and BLANK image
PAGE 2 (Condition 1 required) and a BLUE “tile” image that is transparent
PAGE 3 (Condition 2 required) and a RED “tile” image that is transparent

Now, this is VERY inefficient because each map will have at LEAST 1600 events! Of course, if you make ONE map that has no “map” but rather loads an image or uses the events to display the map instead of BLANK then it might be worth it.

The other method involves using max XY movement squared. For our example, lets use 10 as the max XY movement. So now we need 100 events. What happens is that these events by default are colored blue transparent. The next page will be red if flagged, then green, etc. however many colors you wish to use. These events are in a portion of the map that isn’t visible ever because the map is encapsulated so that the ‘edge’ cannot be reached. This will be explained in more detail when you reach the MAP displaying section. Anyways, so if a tile is “flagged” to have it highlighted, it simply calls the first available highlight event to be moved to its position. Setting up a pointer to associate which events have been moved, or simply cycle through them all at once can do this. It’s really up to the programmer in the end. But once the move is completed move all the highlighted tiles back accordingly.

LAG is the issue at hand here when it deals with highlighting.

Tactical Battle System Heights (Part VI)

MANY MANY MANY ways to go about this. I’ll discuss them all for the most part, but concentrate on the simplest way, or at least what I believe to be the simplest method. Firstly, trying to achieve 3D in a 2D engine is very difficult. You’re adding ‘depth’ without truly showing it. Have you ever drawn a cube on a sheet of paper? I’m sure you have. Well, how exactly did you draw it… that’s right, you drew the depth at an ANGLE. Now, this is the ultimately most difficult, but most realistic looking method to displaying 3D on 2D. What is the issue with this method? Firstly, a tile will be the corners of 4 separate tiles, making variable associations and display far more difficult. Secondly, every graphic artwork will have to be custom tailored to fit the “angled” scheme. If you really want to take a stab at this method, go for it. But for the most part, I will be discussing two methods and a third possibility of a method, which is moreover an extension of the better method.

Firstly, I will discuss the first and lesser method. The following method requires four separate maps to be drawn out; each map is a side view of the original map. This requires a LOT of time and effort. Now, to improve on lag and easier coding, all four maps are placed in one single map so events can EASILY be moved from one ‘map’ to another. This is seen very often in many RPGs where the programmer designs all the interiors of a village on one single map and spaces them out far enough so that one cannot be viewed from another. The same is done here. When the player decides to alternate the view to another angle, an event will transport that unit to his associated position of the other map. If a player was on a tile of location [01,02,03] then he will be transferred to the tile associated with [01,02,03] on the other map. The issue that arises here is that the variables have already been loaded into slots 1 through 1600. This means that the player must hard-code variables 1-1600 for each SECTION of the map. I have found no other means around this. But before transferring the players to the new map tiles, load the associated view of the map’s variable list into the variables, and then shift the views. This could lag the game severely especially if a player shifts back and forth between views while thinking of his next move. This would make the game very bad. Lag is NOT good for a game. Ok, well for now, let us ignore the lag and move onto the next issue. The position the character is on currently does not exist on the alternate view map because it is being blocked off by the image of a mountain. Just imagine a 2x2 hill that is four units in height. The height of the side will be four units long making it impossible to move a character BEHIND it. The character will have to stay on the original map and be flagged. Upon his next visible move he will be transported to the location appropriately so that he is displayed. Now, let’s pretend he is already on the map and now wishes to move BEHIND the mountain while already visible. Does he simply walk over the mountainside graphic? Do we transport the character off into limbo? Or do we make the character invisible? All questions with possible answers that lead into severe programming and lag issues, among other issues such as clean flow of the game.

The alternate and better method is to scrap the four view map method altogether. Rather, build a LAYERED method. The layered method involves just that, building layers up. The first layer will be a complete plain or a plain with holes in it where the mountain bases will be (it’s really pointless to place a plain tile if your never going to view it). Next add some events into the sections where mountains will be placed. The default image of these events will be used to design the mountains (by this I mean the areas that are higher in level). Now, when a player walks “behind” a mountain a switch is enabled which will cause the events of the mountain in question to change the image to an alternate one; this can be done by creating a new page with a condition (be it a switch or variable) which will be the same image but transparent (or completely invisible, whichever the programmer wishes to choose). This allows it to seem as if the game is allowing the user to see “behind” the mountain by looking through it. This method is surprisingly VERY useful because it eliminates the need for the variables to be reloaded for each view of the map. It also allows the user to “peek” behind a mountain. A problem with this method is that unless the unit is moving the character doesn’t see the unit because the mountain blocks it off. The solution to this would be to create an alternate view of the unit which could be an outline or the unit with transparency turned on rather than invisible. This way it shows that there is something there, but only BEHIND the mountain. This is the method I prefer for now because the final method is still requires more thoughts and is moreover an “extension” of the second method.

The third and final method is exactly like the second with extensions. Firstly is the possibility of using only Panorama and pictures to display the map and it’s “layers”. The second is to create a TBS default map, which handles all the similarities between the maps including events and such. This “default” map will contain all the hard-coded information for the variables and simply load what needs to be loaded. This saves the programmer from having to copy events and items to other maps, which can get redundant. Perhaps, only special cases of maps will be separated from the “default map”. Regardless, this is still in question if it is necessarily any better. Also, using pictures and panorama is more difficult than using standard events and tiles.

Tactical Battle System Heights (Part VII)

Well, here it is… this is my final part of TBS Height. Some issues that I have discovered but not yet succeeded in fully understanding how to develop them “simply”. Also, this isn’t the LAST of my thoughts on Height involvement in TBS, but rather the end of my current knowledge. Have you been inspired to solve the issues at hand coming up? Have you been inspired to go out there and program your own TBS involving height? Have you been inspired to just read through this whole thing and actually enjoy it? If yes to any of these than I have done my job. If no, then shutup! :-P

Unresolved Issues:
AI Intelligence involving height (ex: does an archer always seek highest ground, even at the cost of being out of range? Etc.)

Well, that’s pretty much it for now. Can’t really remember the other issues. But I’m sure you’ll find them out and DISCUSS it. Collaborate your ideas and thoughts and let’s have someone finally create a TBS with height… a TRUE TBS.

UPDATE: Issues discovered with movement using the layering system. Tiles now must “represent” data for two locations, which isn’t possible at the moment.

Whose tutorial is this? PM me if you know.