This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

M.C. Kids and old platform game programming concepts

M.C. Kids and old platform game programming concepts
by on (#51131)
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]

by on (#51135)
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.

by on (#51136)
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

by on (#51137)
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? =)

by on (#51138)
tokumaru wrote:
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.

That said:

The M.C. Kids post-mortem is a baseline, not the bible, as tokumaru pointed out a couple times.

by on (#51141)
tepples wrote:
Not if it's a ladder-based game like Lode Runner or Rod Land.

True, I didn't think of that. But since the OP mentioned SMB, I think we should take jumps into consideration.

Quote:
The M.C. Kids post-mortem is a baseline, not the bible, as tokumaru pointed out a couple times.

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".

by on (#51163)
Quote:
I doubt there is something as comprehensive as that M.C. Kids article, specially if specific for the NES.


No, not only for NES. I mean abstract platform game concepts as well.
Like what follows in your message.

by on (#51171)
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.

by on (#51175)
Thanks! I am going to look at them, even if qbasic terrorize me
more than assembly :-)

by on (#51179)
If you want the source code to my ancient Qbasic Zelda 2 clone, just ask.

by on (#51200)
Thanks, but from what I already download I think that qbasic is not for me, decisely.
I hoped that my first steps in C=64 could help, but no way :-)

by on (#51205)
tokumaru wrote:
BTW, players should be able to move up through air... don't characters jump in your game? =)


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.

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