Cubic Terrain

[clockworkroutine]

Introduction & Story behind the Idea (Ignorable: I like telling stories)
---------------------------------------------------------


I programmed this a while ago for my TBS that I was making and working on for roughly two months - solely perfecting perfect movement through point and click.  Then when I did perfect the movement - I thought "Well this is cool - my characters are moving around objects and can easily clear a maze of any sort."  When the pleasure of that died down - I realized I wanted more - I wanted my characters to be able to jump and scale cliffs.  One reason is because in any popular TBS like Final Fantasy Tactics you had varying terrain and depending on your height and your enemies height you could deal more damage.  For me I'm a perfectionist - somewhat of a "if they can do it I can do it" guy - which makes sense to me because we are all simply human and I could be Da Vinci if I put the effort into it - anyways that's not what I want to do - just my belief.  So yeah if someone could program it into a game then so could I - makes sense right.  

So I worked on this seperate system - perfecting a new aspect to the ordinary flat map.  

Note: you could easily do all this with just an event that tells you to jump forwards - but I wanted freedom to build lucious maps and place important events - plus when you use a point and click system ... if you use a TBS system in general you don't want to be using events - because there are so many characters to deal with.

I made it work - it was fun.  My character was jumping up and down cliffs like they were a flight of stairs.  Serious fun.



Faulty Story about Movement (Ignorable: only programming geeks would understand how it is)
---------------------------------------------------------------

Then a dilemma occured using my "point-click-move" system - it added a host of new aspects to deal with.  Keep in mind I made a moving system that was limitless in movement - that gave me the most freedom - that was smart too; which means that my character would almost always do the following:

1.  Never back track.
2.  Take the shortest route.

Taking the shortest route - is a difficult one to program.  It had kinks but I kind of liked it - as my character would realize he should of taken a different turn when he reached a dead end.  Anyways it wasn't perfect but I did my best.

So that worked perfect with just going around objects that the character had no idea instead of walking around, he could of either jumped over it or climb over it.  The character had no knowledge of a third dimension - I mean who would think that right when the character is 2d to begin with.  But when I did figure out the logistics of making 3d terrain - the character did have the knowledge he could jump up and jump down cliffs.  The endless possibilities of movements occured to this character - nothing became an object - he could jump over anything.  So I finally realized I needed to give this character restricting parameters - in the long run - to have functioning TBS.  I only now began to realize I have to give the character a limit to movement: the amount of spaces he could move + the amount of elevation he could jump over or jump down from.  So that had to be worked into the program.  

Did that.

Now what really got me in a tizzy was figuring out how to get my character from point A to point B in the shortest amount of movement points.  Are you following?

Picture this the character is two spaces away from his destination.  He could walk straight and get to the destination in a single line.  But if he walked straight he could fall 99 flights - or jump 42 flights.  And in a another path - with logic - he could just walk around the pillar or endless pit and waste only 5 movement points instead of the gazillion.

How do you program logic?  I came up with endless ideas - never could figure out how to program him to move correctly.  So I gave up as I could not have a perfect TBS that parred with Final Fantasy Tactics or whatever.  I mean for me personally - I wanted to make a memorable game - a game that would be like nothing anyone has programmed or played.

Disgaea and Phantom Brave have been my favorite TBS games - also Rebel Star.  But Disgaea and Phantom Brave had a kind of freedom about them - about movement - about stats that was wonderfully empowering and fun to play.

I'll have the actual tutorial up - later tonight.

I don't want to hear bull - I've gotten that alot in the past and have left - I'll have a tutorial just be patient.  

My Angsty Bits to Questions I have had to answer to in the Past:  
I'm not blowing steam - this is something that I have done - I'm not going to prove it to you with screens - you can try it or not.  I don't use the program anymore - because it saps away time and enjoyment that could be with friends - I have alot of lonely issues that I'm dealing with because I've developed social problems - well not really but I haven't had the oppurtunity to socialize and so don't really know how.  Its important for me to socialize because I want to help others - but it becomes a problem when you can't exactly approach someone you don't know and is hurt.  

Huh - okay well - this is awkward.

Think before you say junk that I'm just going to ignore.  But if their are some real questions - I'll answer them.

Okay Chums.  Later tonight.

[clockworkroutine]

So what is it about having 3D - that is so amazing?

Why its wonderful and fun.

The freedom of jumping over and scaling buildings is intrigueing - its as if you were spiderman or some wack job bull fantasy hero - Its fun.

Not only once you program the 3D terrain - I can show you how to program how to jump correctly and freely.  Which is so nice.

[Osmose]

I don't know much about RPG Maker coding, but when Sai'Kar was working on a tactics game I got to thinking about a Tactics system, and one of his big problems was pathfinding - detecting obstacles and such. And I came up with what is apparently a common and generally effective solution (According to Ari the Finnish Master of Programming [Like seriously, he's a genius or something]).

It would probably be harder in RPG Maker, but basically you use a recursive function that checks in all four directions to see if it can move in that direction. For example, when the function first runs, it checks the four spots around the beginning point and sees if any are open. If they are, it records them in whatever way is convenient for the application (In RPG Maker it would be a block of reserved variables, I guess) and then uses the function on each of the blocks that were recorded. This way, it follows all possible paths. Each iteration would be one step, so you'd only have to do a number of rounds equal to the possible movement of the character - 5 steps, 5 rounds of checking possible movement.

For finding the shortest path, you just stop once you've found your destination (This is assuming you don't have a jumping system like you described - I'll get to that). When you record a block as mentioned before, you also record the direction you entered from - such that if you walk one space to the right, you record the X and Y of the new block, and also record "West", or however you'd like to signify that you entered the block from the left. Now, once you have this all recorded and you've reached the destination, you simply backtrack - the last block records that you're entering it from the left, and so it moves to the block on the left and sees how it got there. It repeats this until it finds the origin, and BAM - it has the shortest possible path laid out for it.

Now, if you wanted to add in a 3d aspect to this, all you'd have to add is an extra check on elevated blocks to see if the player has enough "Jump" to reach the elevated area, and, if they do, record it as walkable. To make animation a bit easier, you could code in a sort of preference for avoiding these blocks if moving on them would look bad (IE it finds the block right below it opt to move down and right instead of right and down over the elevated part). As far as I know FFT did not dock movement points for jumping. But if it did, that would complicate things but still not be terribly difficult to do once you've got the base system I described down.

Of course, there's even more efficient methods of pathfinding out there, this is just one that's fairly easy to understand and implement. Kudos for effort regardless of what you do, though.

[clockworkroutine]

Thanks - that's very very similar to my own system - or what I remember of it - yet - one thing bugged me - it sounds like you have to use two variables for each recorded position.  One thing about my system was that it didn't record many positions except the one you started from - the one you were current standing on - and the one that is your destination.  I used variables that used logic in some way - like it would use the best choice according to a function that involved variables like the x difference between current position and destination, same with the y.  If the x difference was shortest - it would travel right or left, I think I liked that it traveled up and down though (It made movement more interesting, more zig-zaggy than straight) - but whatever one I chose I made it clear that it had to use the SAME logic throughout the system.  

I had other "Logical Factors" that played a part - somewhat like you said - yet short term and not really recorded:  when my character moved to a space the direction in which he came from would be recorded - so that variable is then used to determine that the character should not back track from where he came from.  This was over rided if the character backed into a corner - by a climatic set of loops that tried its best to get the character out of the trap and find the quickest route, out.  Yea I got rhymes.

The thing about that system that bugs me - the system you noted on - was that it is limiting in a way.  What if the cursor is moved so far away from the original position - and the character has to moved towards it?  It would have to jot down on all those positions.  In RM2k3 there is a limit to variables, 5000.  For some reason I don't know it bugs me that my variables would be used ... what if it runs out.  Wait... what if you did set aside a block of variables - when all of those blocks of variables were used up it could just write it over --- I don't know that seems not limiting - somewhat unfaulty unless after a hundred moves you relize that you took the wrong path - which doesn't seem to me like that is possible - you can definately add to that ... huh sorry I'm lost in my thoughts right now.  I want to program that again.

Maybe its almost rediculous for me to think that I can have players move 10000 spaces.  Well to start I wanted the system to work outside of a battle field - so that the character could roam freely around town as the actual person who's playing the game could bite into a sandwich as his character travels across the map.  The actually travelling becoming a show, as you see him get into corners and bumping around characters - and kind of being like a blind man feeling his way through town.  But still I could have implemented a limit to 100 spaces - even then - slowed walking to allow for more feeding.

Well maybe altogether I didn't understand you like you explained - maybe yours is unlimiting.  But I feel like I have you correct.

About the terrain ordeal - and the jumping system - yea I figure it would be cheap if the character could jump a tower and could still count it as one move - you know what I mean?

[Osmose]

Well when I first considered how I would go about pathfinding, it was in the environment that movement would be limited to somewhere around 7 or 8 spaces (With movement expanding accessories and such - if there was something like Teleport you'd simply highlight all possible spaces except for ones you can't stand on).

I can see how it would be limited in a case such as yours, although really, in that case, as a player I'd prefer free movement without pathfinding myself, or at least limit the player to clicking on places onscreen - scrolling to another part of the map and then having the player walk there when you click is indeed fun but a bit much IMO.

Of course, if you're not in RPG Maker you could store this all conveniently in an array. But yeah, in the case of being as openly compatible as possible it is limited. But trying to be too big is what causes people to burn out, as you have unfortunately illustrated.

If you want a system that could handle what you want, it sounds like RPG Toolkit should do the trick.

[clockworkroutine]

Vague Mechanics
---------------------------



This is what is involved for you to program - mainly to deter beginners who don't know what I'm talking about - but you know I learned best when I challenged myself.  Anyways I hope this vague explaination can help advance programmers know exactly what to do and they don't need a step by step.

What it involves is using the terrain tab.  Each different terrain you use becomes a different elevation.  (I can't remember how I did this ... but I also made a random generator map that coresponded different variables to specific positions of the map - so it was a ever changing terrain ... yet it was invisible because there isn't, to my knowledge, a way to change the graphics of the map without turning the whole map into one big cluttered host of events.)<-- moving on don't let that blurb make you lose track I'll repeat:


What it involves is using the terrain tab.  Each different terrain you use becomes a different elevation.

You also have to set aside a variable for current terrain elevation - and variables of the elevation in all four directions.  These variables like I said check the Terrain ID under the variable menu and store them.

Different Actions
--------------------------

Jumping Up - What happens is when the character wants to scale terrain is that the current Terrain ID is subtracted from the next Terrain ID in the direction that you are moving.  That number is stored in a variable.
That variable is then determined to move the character up - each time the character moves up - the variable is subtracted from.  When it reaches 0 the character then makes one more move in the direction that he was heading to have his feet be on solid ground.

Jumping Down - What happens is when the character wants to fall down terrain the Next terrain ID is subtracted from the Current Terrain ID.  That number is stored in a variable.
That variable is then determined to move the character down - each time the character moves down - the variable is subtracted from.  When it reaches 0 the character then makes one more move in that direction that he was heading to have his feet be on solid ground - well he actually lands where he wants to be.

Moving on Even Ground - The system just ignores if the direction you are heading in, the variable of the Next Terrain ID is equal to the Current Terrain ID.  So the character is just able to move.


Jumping Freely
-----------------------


What it this involves is that you record the direction that you are moving in - if no direction record that as 0 (Again this sounds really confusing if you don't know much about variables).

When you push a button your character is then launched in your direction heading diagnolly, it should be that your character can only move Up-Right, Up-Left, Down, And Up when he jumps.  When the character reaches a maximum amount of jumping ability (so program a stat for jumping or not... when ever you want to stop).  That point in the height is recorded, this point is determined by your Origin Terrain ID which has the variable of the amount you "Jumped up in the air" added to it.

Then that terrain Id is measured to the adjacent terrain Id - if it is equal or less than - the character can move freely in that direction - stopping if the terrain is equal.  If the character finds terrain higher than his direction he bumps into the wall and then falls straight down to the closest terrain Id in that direction ... actually you know what I have to think that through a little more...

When the character hits a wall the amount the terrain id of where he currently is - is recorded - and that gets subtracted from it the origin terrain ID.  The difference between those two numbers is then used to determine from where the character is (His X and Y) - that many spaces below him measure the correct terrain ID to confirm ... Ah you know what this is confusing - you'll get it when you start tinkering.

I'll have a actual things to program later on - probably tomorrow night.

[clockworkroutine]

An array, explain to me an array - I tried my hand at Multimedia Fusion - and there was a function for that never understood it.  Multimedia Fusion has alot of functions - it blew my mind - I didn't understand half of them.  And they keep spurring up.

[Osmose]

An array is one of the fundamental concepts in normal programming - I'll give you a simple explanation, but you should really look into learning a programming language. I believe I put a sticky up on the Programming Forum with links to some good sites a while back.

An array is, simply put, a group of variables. There's about a bazillion ways to work with arrays, but let's work with the VB6 way: Let's say we have an array my_array. This is simply a group of variables. How do we look at those variables? Why, just give it the proper number.

my_array(1) = "Some Value"

The first value in the array (Assuming we don't start at 0 like many languages do) is "Some Value", and if you ever want to reference that value, say, in a formula, you simply put my_array(1) and it will insert that value.

Similarly, there can be a second value:

my_array(2) = "Some Other Value"

It acts the same as the first value but is in fact different. There's a huge amount of benefits from this, including the one mentioned above - we could store all the X values of tiles in an array known as tile_x(), the Y values in tile_y(), and direction in tile_dir(). Then, each tile would have an ID number, and whenever you wanted to find the info of that tile, you'd simply give each array the ID number and it would return the value you need.

[clockworkroutine]

I tried taking a basics programming class for next year - yet I was the near the only person who signed up - so they had to drop the class which they've done for 2 years now.

I guess when I find the time I'll look into it and study it myself online - or through a book.

When I do try to start studying a code language (which I have in the past) - its always type type type.  It's intimidating - I don't know where I should put brackets and what if I put perentheses here - it feels so open ended - where do you start?  Completely overwhelming from the beginning.  That's why I use RM2k3 and that's why I feel most people use any gamemaker.

If I had a teacher I'm sure I'd feel more at ease.  But I'll look into it, maybe I'll find a site that goes step by step like a childrens flipbook - that would be nice.

[clockworkroutine]

I'll post an actual demo when I'm done - I just figured out after months of absence how the answer to a problem I had with the system

I didn't tell you that did I - it isn't that big of a problem - it had to do with graphics - when your character should be on lower terrain and there was a pillar in front of him - he should of been obscured - which wasn't a case all the time.  He'd be in the middle of pillar just sitting idly.

But I figured out a solution - which may involve a little more tedious coding on your part - for each character that you have on a map.  For me I think it is worth it - the element truly adds to the game.

However you could not even have the kind of varying terrain that I talk about - you could keep all the mountains way in the back of the map towards the top of the screen - and made it possible for you to never be obscured - they somewhat did that in the gba Mario Rpg.  That takes no more coding then the aforementioned.

I thought of actually using that idea when I couldn't figure out how to solve the graphics problem.  The idea is kind of stylistic.

I'll post a little blurb after this about the graphics problem - again another vague blurb - but I plan on coming back with the actual guide to coding this.

[clockworkroutine]

My Scrap of Thoughts
----------------------------------


Here's how I try to work out a solution to a problem.  I open up a text pad when I'm inspired to solve a problem - and then jot it all down - all the possible solutions till I find one that is the best one.  For myself I think its neat to read thoughts, its like watching a game of tetris - fitting pieces together - and simply its neat and inspiring to see what people think, how people think.  There's a new book on Einstein and how he thought that I want to read, also there are fiction books solely written on thoughts which is called stream of consciousness writing, I want to read Ulysses by James Joyce sometime:

solving the graphics problem:

What is the graphics problem?  Whenever you should be behind a cliff or pillar your character should not be visible - but he is sometimes.

(Trust me simply working with chipset layers will not do.  Just think of it this way, that since you aren't working with 2d anymore [in a way] that you have to use a different method now.)

Say on the map you are on elevation that is lower than the adjacent square before you - you should be behind it and hidden.

What you can do is go through the entire map and mark where those points are - including the terrain elevation number - and when you happen upon that square you will become unseeable.

Or you could have a built in check system that goes vertically down a collumn of terrain id.  It would have to start at one number - and then match it up against all the numbers in that collumn:

Incidence:
What if the number is infact lower than another number in the collumn - but it is so far away you should be able to see the character standing on it.  Their should be an equation, that the difference apart is added to the original terrain id - if that number is bigger than the latter terrain Id you are visible - if that number is smaller than you are invisible.  

All the ones that make him invisible should be noted, each time the character moves - it goes through the list of data once.

Data should only be for that collumn that he is on and going to.

To make the character invisible you make a switch on the character that turns the page.



Actual Plan if you could not Follow
------------------------------------------------------



What you need to do is create a looping function, that checks from the next position you want to be on.  So you have to grab the X and Y corrordinate - this corrordinate should only be for the collumn that your character is about to move into and your current collumn.

Grabbing that variable's terrain ID, you then have to make a function that checks a square below that position.  These two terrain Id's are compared to eachother - if the original terrain id is lower than that terrain id then you can safely say that the character standing on that position will be invisible or at least half his body will be.

Yet don't stop there if the original terrain id is greather than the next terrain id, because their can be a pillar or part of a cliff that could still cover your character.  So going down the collumn you just add 1 to the Y corrordinate of the next terrain Id at the end of the function.

So it should keep continuing to compare numbers.  Yet now you have to take in account the distance apart from the two numbers - because sure their will probably be a number in the line that will be greater than the original terrain id - but it could be so far away that your character should in fact be visible as you are able to peer over the pillar.

So that equation - the difference between the Y's {subtract 1 ... just do it] should be added to your original terrain id - and then compared to see who's greater and or less than and whether your character will be visible standing on that terrain.

HAve the looping function break when it reaches when it finishes the last corrordinate - you can do that with a branch function that if Y equals the last number then perform the action then end it.

With the checking done - you should have it stored whether you are visible or not - this varaible determines the graphic of your character - blank or not blank.  However you may need to make another graphic that shows only half the body - because if it comes to it your character may be peeping out his head from a pillar top.

Trust me the coding is not that long if you do it right - since its all loops.