Basic info about platformers...
I have run a search for an answer to this question and haven't found quite what I was looking for so I thought I would pop a post on here...
What are the general rules about designing and coding platformers (eg JSW)? I have tried messing around before and while getting a character to jump and move around isn't too difficult the bit I find hard is coming up with a system for the platforms.
How is the player character's collision detection done (how do you know which part of the player has hit a platform?) What about the platforms themselves, is there a standard way of giving them their properties and again, how do you detect for the top and bottom of it?
I'm just looking for general info, psudo-code even. This isn't for use on the speccy itself so I don't have to worry about saving memory etc...!!
Thanks to anyone who can help!
What are the general rules about designing and coding platformers (eg JSW)? I have tried messing around before and while getting a character to jump and move around isn't too difficult the bit I find hard is coming up with a system for the platforms.
How is the player character's collision detection done (how do you know which part of the player has hit a platform?) What about the platforms themselves, is there a standard way of giving them their properties and again, how do you detect for the top and bottom of it?
I'm just looking for general info, psudo-code even. This isn't for use on the speccy itself so I don't have to worry about saving memory etc...!!
Thanks to anyone who can help!
Post edited by Scoops on
Comments
One of the simplest way to do collision detection is by doing what is called a bounding box collision test. The bounding box is simply the smallest possible rectangle (in case of 2d sprites) that encloses the entire sprite. In case of a simple 8x8 sprite, the bounding box would be 8x8 too.
The bounding box for each sprite can be maintained in a structure. A simple sprite structure can be something like this:
The bounding box info can be maintained as a structure like this:
struct RECT {
int x1, y1; //top left of the box
int x2, y2; //bottom right of the box
}
That's all the info you need to compute the dimensions of the box.
The sprite structure then holds a RECT attribute within itself, which will act as it's bounding box:
struct Sprite {
int x, y; //current position of the sprite
RECT BoundingBox; //collision rectangle
IMAGE* img ; //the link to the sprite image
.
.
.
}
After this you just derive different character sprites from the Sprite struct (you can use a class if you want OOP's) like:
Sprite player, ship, table;
At the time of initialization of the properties of these sprites, you compute the bounding box for each of the sprites, which you'll use subsequently for collision tests.
As for the tests themselves, you simply check if the bounding box of one sprite overlaps another. If they do, you have a collision.
The problem with this kind of test is that it may signal a collision even if the sprite pixels themselves do not overlap, because the bounding box is an approximation of the shape of the sprite.
You could use pixel overlap tests to actually fine tune the collision. The usual way is to do bounding box test to quickly sort out non-collisions, and then do a pixel overlap test (if you require that is) to do a more accurate test.
You can find more info on the subject in this article on gamedev:
http://www.gamedev.net/reference/articles/article735.asp
Bytes:Chuntey - Spectrum tech blog.
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
http://groups.yahoo.com/group/manicminerandjetsetwilly/
edit: *actually it only says that by implication, but it is true (& mentioned in most JSW editors)
[ This Message was edited by: darkman on 2004-10-17 21:42 ]
Actually, it's if a guardian collides with *anything*, you'll die. That caught me out on my first attempt, and in all the games I've made using JSW editors, I've had to make sure that guardians don't collide with anything at all.
D.
Mind you, the room data also gets corrupted by visiting the 'illegal' screens by using writetyper or pokes but I don't know why that happens.
By the way, are any of your JSW games available on line ? Must be better than anything I could do !
[ This Message was edited by: darkman on 2004-10-18 00:41 ]
Nope, they're not, and Nope, I doubt it :)
My little 'un likes them, but I've got the only copies and it's staying that way :)
D.
As far as platforms go, you`d be well suited to knock up a simple map editor, this could be used in multiple games in the future as well, so won`t be a waste of time, and is pretty essential if you wanna be doing platform games.
What it does is be able to load in the graphics that you`ll be using for backgrounds, and platforms, which are stored as blocks of 16*16 usually if it not spectrum, or 8*8 for spectrum... you then are able to move around up/down/left/right 8 or 16 pixels at a time placing the graphics blocks - whilst you map data is updated.
You load in your generated map data into the game, and read value`s for what block is pasted where, for static screens, and also scrolling, and it has the added advantage of also letting you know when the player is standing on solid platform, or when he`s walking /jumping if he hits/walks against a solid block...
It`s best to group the order of your graphic blocks so say the first 200 are normal background, say 201 to 230 are for diff` types of platform, and 231 onwards can be special things like spikes, transport blocks etc
by grouping them like this it`s easier and quicker to test the value`s around your character... like if mapdata(posx,posy)<=200 then `it`s ok to run about, fall through, jump through these areas...
If the mapdata is on platforms you know what to do, and because you have say 30 different blocks available for platforms, you can accomodate different graphics, but also effects... i.e. invisible platform, used by having a background graphic, that is given a number between 201-230... or crumbling blocks (not forgetting to update your mapdata from within the game, if summit crumbles)....
Also, you have your dangerous blocks which kill, or transport you etc etc
I cannot encourage you enough to write a decent map editor, it`s much easier than the actual game code, and will give you as much use as most any other thing you`ll code...
Best ofluck :)
Oh, and whatplatform will you be using, just outa interest?
If there is a collision, then you test whether the printed items overlap. If you only work with PRINT AT positions, then the ATTRIBUTE is enough (or the SCREEN$ with altered characters)
The platform I am working on is the Mac. A format that hardly ever sees a remake, a great shame...
I hope you reconsider your decision to suppress them. Over 60 Spectrum MM/JSW games have been released by now, but we could always do with a few more! :)
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
http://groups.yahoo.com/group/manicminerandjetsetwilly/
I have "Tidbits" sections in my List of MM/JSW Games for minor variants, games with just a few rooms edited (e.g. less than 25% of the rooms), or which otherwise don't count as true new games IMO.
--
Dr. Andrew Broad
http://www.geocities.com/andrewbroad/
http://www.geocities.com/andrewbroad/spectrum/
http://www.geocities.com/andrewbroad/spectrum/willy/
http://www.geocities.com/andrewbroad/spectrum/willy/list.html
Also available is oolite an excellent Mac remake of Elite - the bestest game evah in RetroGamer's reader's poll.
http://www.remakes.org/
Despite being poohed on for suggesting this last time and having never actually written a platformer, I would be very tempted to organize each screen as a state machine.
Each state of the state machine is a single rectangular box with rules:
1. The "ground level" of the box. If player jumps, it stops falling at the ground level.
2. How to leave the box. If you go off the left side of the box, you move to state N. If you go off the right of the box, you move to state M, etc.
3. Things in the box (eg, power ups etc).
You can make each state as detailed as you wish. The advantage is that your program only has to make computations about collisions, etc, based on a single state's characteristics, rather than doing collision detections on everything in the screen if a table is used.
And, state machines are very, very easy to deal with. They make programming so much easier.
That's my two cents.
Write games in C using Z88DK and SP1