Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Warsong

can someone explain the concept of how a multiplane game works?

This topic is 6040 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

well in a 2d platform game the character jumps (y axis), walks (x axis) and it has gravity. but what about a multiplane game like double dragon or finalfight? where the character walks x and y axis (y?) and jumps y axis (y again?) when the character jumps he reaches the enemy above him but he wont get hit since it is not level eventhough it seems that way. can some one explain how that works in lamens terms? the same thing goes for top down view games in the sence that how can the character jump? what logic is their? and the 2 1/2 d game that have platforms. it seems not many will know about it since computer games dont seem to have any. :o diablo doesnt have platforms for the characters to jump on a higher ground. an element that is missing in diablo

Share this post


Link to post
Share on other sites
Advertisement
This is a graphics programming question, so I''m moving it to the Graphics forum.

--------------------
Just waiting for the mothership...

Share this post


Link to post
Share on other sites
You have an x axis, y axis, and gravity. All you need is to use an z axis that is projected on the y axis, then decrease the z value by gravity over time.

The y value at the time your character starts to jump is key here. Think about it, it is very simple!

Share this post


Link to post
Share on other sites
The way I worded that could have been confusing, so I'll clarify with some graphic interp. below.

Ok, when I originally stated what I did before I was speaking from the prospective that you were using a y axis value that was projected like pictured below. As such you just needed an axis relating to the dimention in which the jump occurs, and with my abstract way of thinking I reassigned the name Z to the remaining axis.

........Z
........|
________|___Y____
........|../
........|./
........|/
-----------------X
......./
....../
_____/___________


The standard and univerally understood way to word it would have been to say, "You have an x axis, z axis, and gravity. All you need is to use an z axis that is projected on the y axis, then decrease the y value by gravity over time adding it to the z value to determain your on screen y value." As pictured below.

........y
........|
________|___Z____
........|../
........|./
........|/
-----------------X
......./
....../
_____/___________


As I screwed-up the first explaination I will put this in more detail. Now we move left and right along the x axis, on this axis the ratio of movement in that dimention to movement on screen is the same. Our z axis is were movement toward and away occurs, the movement on screen will be one for every two on this axis making a 45 degree angle of slope. Now the y axis is only used when the character jumps or is standing on something, movement along this axis is represented by the same exact magnitude on screen.

To solve the issue of platforms and jumps we must bring in gravity and "anti-gravity" so to speak. Gravity will be a force that acts over time, each interval gravity will subtract itself from your y value. When you jump the y value will increase and be reduced over time, this would be a problem if you didn't jump constantly and had a fixed range for values on the y axis. That is were "anti-gravity" comes in, if you make platforms with which you contact add a fixed y value. Using such a concept your character can only come in contact with objects on the same range of x,y,z. It is also a help at finding the proper sorting order.

*EDIT*
Formatting was very bad the first time around, sorry!
*EDIT*

*EDIT*
Still formatting issues.
*EDIT*

Edited by - thewayout_is_through on February 3, 2002 5:54:52 PM

Share this post


Link to post
Share on other sites
so what at least help the guy
sheesh
but yeh what the other fellow said
have another plane where if u hit it u wont go below it
its just collision detection

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
thanks for the help thewayout_is_through
but i am wondering some thing here.
So games like "double dragon" and "land stalker" or "congo bongo" are they 2D or 2.5D? I am trying to make a 2d game maker and I figure those games are using multi frontgrounds/backgrounds. which gives it the illusion or 2.5D

Insted of a 2d should it be a 2.5D? So to make these games it needs a 2.5d engin?
So the 8 bit systems have a 2.5d?

If you don''t know what land stalker is chek it out on googl.

Share this post


Link to post
Share on other sites
thanks for the help thewayout_is_through
but i am wondering some thing here.
So games like "double dragon" and "land stalker" or "congo bongo" are they 2D or 2.5D? I am trying to make a 2d game maker and I figure those games are using multi frontgrounds/backgrounds. which gives it the illusion or 2.5D

Insted of a 2d should it be a 2.5D? So to make these games it needs a 2.5d engin?
So the 8 bit systems have a 2.5d?

here is a pic of land stalker
http://www.classicgaming.com/rotw/landstalker.shtml

Edited by - warsong on February 4, 2002 4:11:09 PM

Share this post


Link to post
Share on other sites
actually 8bit systems had 3d engines as well. 2.5d was meant for isometric games which allowed more mobility then side scrollers mario. it was more of a marketing gimick and a way to classify those oddball games that broke the 2d mold but were not quite 3d. though ALL top down games (even if you could jump) are considered 2d games. mainly because you only move in 2 axis at a time. crash bandicoot is another good example of a 2.5d game even though it uses polygons and allowed jumping.

in double dragon you moved left to right. the movement on the platform was dictated by a plane collision like said before. since the position was projected onto the screen, it was quite easy and fast to do this. you can store an x/z coordinate in world space for the sprite. x for horizontal movement, z for depth movement. y is used to determine how high the sprite may be. collision detection merle check the y and if it was above or below the current plane (this is why those early games did not allow sprites that could be under a bridge with sprites above the bridge). you could store these planes as rects which had a x,z,y coordinates. y was for height, x for length, z for depth. when you draw the sprites you merely do some persepctive (some of the old games did not veen bother with the scaling) correction on the origin for the sprite. using the old
screen_x = x*z;
screen_y = y*z;
you could of course modify that slightly to handle different scenarios. this one is meant for speed and simplicity (ie the coordinat system has no z=0 and linear perspective that can go from 1.0 to 0.5 or 0.5 to 1.0 (the low and high end numbers can change as long as z > 0 )

hope that makes more sense. if you are maing a "game making engine" you should pick pure 2d or go for pure 2.5d because they dont mix to well (since art for 2.5d tends to have some depth added via the art instead of the cpu doing the work, though now a days you could handle the depth stuff with textures using a 3d card which would be pretty fast). since i am assuming you are pretty new to coding games, i would suggest going a pure 2d tile based engine. its much more flexiable in the long run and probally easier (especially if you dont understand how 2.5d works)

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!