Hello,
can anybody point me to some docs that describe what is behind
games like Super Mario Bros 1-2-3, not as particular as disassembly,
but concepts that were used to develop games like them.
I found an interesting article about the development of M.C. Kids, for
example,
http://greggman.com/mckids/programming_mc_kids.htm
but nothing else.
Bye,
tano
[/url]
M.C. Kids and old platform game programming concepts
Moderator: Moderators
I doubt there is something as comprehensive as that M.C. Kids article, specially if specific for the NES.
There are basically 3 things you have to worry about, which are the key elements of 2D platformers:
Map scrolling
Involves controlling a "camera" which follows the player, and as this camera moves you have to update the background to display new information fetched from the level maps.
Object management
You must keep track of active objects as well as load new ones. You have to have them interact and you have to draw their sprites once you have finished processing them.
Collision detection
During the processing of objects, you'll have to detect collisions between objects and collisions with the level map, in order to successfully calculate their states and positions.
There are basically 3 things you have to worry about, which are the key elements of 2D platformers:
Map scrolling
Involves controlling a "camera" which follows the player, and as this camera moves you have to update the background to display new information fetched from the level maps.
Object management
You must keep track of active objects as well as load new ones. You have to have them interact and you have to draw their sprites once you have finished processing them.
Collision detection
During the processing of objects, you'll have to detect collisions between objects and collisions with the level map, in order to successfully calculate their states and positions.
I've been wondering about techniques for this as well.
For example, I've tried declaring certain areas of my map as different object types. At the moment I support 4.
- Air
- Solid
- Stairs
- Cover
My player can move left and right and down(fall) through air, but not up.
He cannot move at all through solid.
He can move in any direction on stairs.
He can move the same as in Air, when in Cover, but I then change the foreground/background bit on the sprites so he appears to be behind.
I suspect the "Cover" is a bad approach and I should instead call it "Air" and have a separate value describing extended attributes such as "Cover" or "Pain".
In any case, I keep writing and rewriting the code and I still havent found anything overly clean, so anyone have tricks that they like.
Al
For example, I've tried declaring certain areas of my map as different object types. At the moment I support 4.
- Air
- Solid
- Stairs
- Cover
My player can move left and right and down(fall) through air, but not up.
He cannot move at all through solid.
He can move in any direction on stairs.
He can move the same as in Air, when in Cover, but I then change the foreground/background bit on the sprites so he appears to be behind.
I suspect the "Cover" is a bad approach and I should instead call it "Air" and have a separate value describing extended attributes such as "Cover" or "Pain".
In any case, I keep writing and rewriting the code and I still havent found anything overly clean, so anyone have tricks that they like.
Al
Yeah, "cover" and "pain" should definitely be extra attributes, as that information is not related to how solid the blocks are.
The hard thing of making a complex game (which is usually the case of platformers) is that we often bump into things that make us want to change the whole architecture of the project, so we get stuck rewriting the same thing over and over. I hope that with time I can make better design decisions and not have to change everything every once in a while.
BTW, players should be able to move up through air... don't characters jump in your game? =)
The hard thing of making a complex game (which is usually the case of platformers) is that we often bump into things that make us want to change the whole architecture of the project, so we get stuck rewriting the same thing over and over. I hope that with time I can make better design decisions and not have to change everything every once in a while.
BTW, players should be able to move up through air... don't characters jump in your game? =)
Not if it's a ladder-based game like Lode Runner or Rod Land. There was a topic on gbadev.org a few years ago about those.tokumaru wrote:BTW, players should be able to move up through air... don't characters jump in your game? =)
That said:
The M.C. Kids post-mortem is a baseline, not the bible, as tokumaru pointed out a couple times.
True, I didn't think of that. But since the OP mentioned SMB, I think we should take jumps into consideration.tepples wrote:Not if it's a ladder-based game like Lode Runner or Rod Land.
Heh, that makes me look lika an M.C. Kids hater... I guess I don't hate it (don't like it much either), and that article sure is a good read for anyone who's thinking about writing their first platformer, as long as they use it as an inspiration, not to copy from it like it was "the platformer bible".The M.C. Kids post-mortem is a baseline, not the bible, as tokumaru pointed out a couple times.
I found this one tutorial quite interesting: http://www.strille.net/tutorials/part1_scrolling.php
It talks only about scrolling and updating the level map, but this is one of the most important things in a platformer. The maps are object-based, like in SMB1. All the code is for Flash (a very old version of it, actually), but the concepts still apply.
Another thing you could do is look at some QBasic games. This is how I learned the most about how games work. These games usually come with source, and Basic code is usually easy to read, much more so than 6502 assembly. Just keep in mind that some of the games are not very well structured.
It talks only about scrolling and updating the level map, but this is one of the most important things in a platformer. The maps are object-based, like in SMB1. All the code is for Flash (a very old version of it, actually), but the concepts still apply.
Another thing you could do is look at some QBasic games. This is how I learned the most about how games work. These games usually come with source, and Basic code is usually easy to read, much more so than 6502 assembly. Just keep in mind that some of the games are not very well structured.
Actually, I got sick of re-writing the engine over and over so I've attempted to go with a table based approach. Unfortunately I think this has limitations too, but I wont know till I hit them.tokumaru wrote: BTW, players should be able to move up through air... don't characters jump in your game? =)
My player has a number of player states
STANDING
JUMPING
FALLING
CLIMBING
And I have 3 different object types
SOLID
AIR
STAIRS
And I have 4 different directions (up, down, left, right)
So I make 4 tables (one per state) with 3 rows (one per object type) and 4 entries per row (one per direction)
Then whenever I need to process an interaction, I can check to see if its valid, and what state my player should convert to.
As an example:
; Standing:
;Solid-> up, down, left, right would be: INVALID, INVALID, INVALID, INVALID
;Air- > up, down, left, right would be: INVALID, FALLING, STANDING, STANDING
;Stairs->up,down,left,right would be: CLIMBING, CLIMBING, CLIMBING, CLIMBING
But jumping and falling would behave differently.
Also, this allows me to add a new state (like ghost) where solids dont block me moving left and right (but maybe they do block me travelling up and down so I dont fall off the screen)
I dont know if this approach is good or not, because "invalid" is a sticky case that muddies up the cleanliness of the code. If I'm jumping and hit a solid, I need to transition to falling, etc.. I'm getting around this at the moment by using an "invalid" table but I dont like it.
Al