I'm currently attempting to make a version of the following game: http://www.ebaumsworld.com/helicopter.shtml for MIDP 1.0. I've got my plane working with physics / animation / control etc.. and now I want to add the terrain, using just drawLine() similar to this... I want to randomly generate this terrain on the fly, so that the player can keep going until they crash (with their score then deicded by the timer). I will need to check for collision between the player sprite (a rectangle - im not too bothered about perfect collision atm). What's the best way to go about this? Do I create a terrain class that stores the points for each vertex in a vector and decrease each x co-ord by a fraction each frame? How would I go about checking for collision between a rectangular sprite and a line which may or may not be sloped? [edited by - LazyManc on April 15, 2004 7:35:42 PM]

Well, you seem to have a plan for the terrain generation so give it a try (experiance is the best way to learn). Don''t worry about optimisations just yet, your game looks fairly straightforward at the moment.

As for collision detection, you could try modifying the Sutherland-Cohen clippling algorithm (where your plane''s collision rectangle is the ''screen'') or just use the y=mx+c formula to determine if any of the corners are above/below the roof/floor (not as good as it can miss peaks).

Skizz

quote:
Do I create a terrain class that stores the points for each vertex in a vector and decrease each x co-ord by a fraction each frame?

Sounds like an idea. I don''t know about decreasing the x-coord each frame though. I would probably add a "world-position" to the plane object and offset the terrain according to that (keping the terrain object static).

quote:
How would I go about checking for collision between a rectangular sprite and a line which may or may not be sloped?

You can use line line intersection.

shmoove

Too slow....

I would create a number of "slices" - images that contain pieces of the terrain. Create them at startup and reuse to avoid allocation / deallocation (when a slice falls off the LHS, reuse it on the RHS). using the Image API clear the new slices and draw lines for the floor / ceiling in the new slices, just before they appear on the RHS.

Keep track of where the floor and ceiling start / finish on a per-slice basis. Work out which slice(s) the plane is intersecting with, and do some kind of crude comparison (perhaps with linear interpolation to work out the actual floor / ceil height at that point). So if the bottom of the plane is below the ground, it''s crashed (and top also).

If you want to put obstacles in (like the flash game) you have to remember where they are too and factor in accordingly.

Mark

There''s an old text game called "caves" where all you do is fall down a cave and try not to die.

It''s the same thing you''re doing except the "cave" is scrolling sideways instead of up.

Look at the source for that game and you should be able to figure out how to do it with graphics.

Thanks for the help, it's starting to click now.

quote:I would probably add a "world-position" to the plane object and offset the terrain according to that (keping the terrain object static).

The main reason I wanted to generate coords on the fly was because I don't want the player to ever run out of terrain. If the terrain object is static wouldn't I have to create all the points (and therefore a limited amount of them) before the game runs? If i'm incorrect blame it on my poor programming skills

I want to keep the x coordinates of the vertices alligned for top and bottom, so I should only have to store 1 x coord for both points, correct? I'll probably only need 3 or 4 points (in x) on screen at once, so can I use the following method to store them:

I was thinking of checking to see when the 1st point in the vector x position was < 0, and if it is, then it's off the left of the screen and I can remove it from the vector, and then generate a new set of points and append to the end of the vector? Is this an incredibly slow / poor way of doing it? What would be better?

quote:I would create a number of "slices" - images that contain pieces of the terrain. Create them at startup and reuse to avoid allocation / deallocation (when a slice falls off the LHS, reuse it on the RHS). using the Image API clear the new slices and draw lines for the floor / ceiling in the new slices, just before they appear on the RHS.

I was considering doing it that way but it's my understanding that i'd then have to make sure all the slices started and ended at the same height so that they lined up, or at least create a series of them that joined up in various places, and then pick the correct ones? At the minute i'm just concentrating on getting it working, i'm not too bothered about how it looks, but thanks for the suggestion.




[edited by - LazyManc on April 16, 2004 2:29:07 PM]

Hmm, i'm starting to confuse myself here. I've never used vectors in Java so bare with me for a minute or two...

import javax.microedition.lcdui.*;public class Terrain{		public class Vertex	{		private int x;		private int y1;		private int y2;			}		private Vector terrainVec = new Vector();		public Terrain()	{		// Create vector of 4 initial points			}			public moveTerrain(int speed)	{		// decrease x coord of each point by a fraction each frame	}			public void paint(Graphics g)	{		// paint terrain at new position	}}  

On the right track? Or completely the wrong way to do it?

The only thing that's confusing me at the minute is this; when i'm removing old vertices that have passed off the left of the screen, and I want to add a new vertex to the vector, can I just change the data in the old one and add it back to the end of the vector? Is this a stupid way of doing it?

[edited by - LazyManc on April 17, 2004 6:14:26 AM]

It''s probably easier just to have a circular buffer using a fixed size array big enough to hold enough points to draw the screen and then some, and two indices: one for the left hand most vertex and one for the right hand most vertex.

Messing about with vectors could badly fragment your memory.

Skizz