Platform game structure?

At the risk of not helping, can I suggest not making a platformer yet? Platformers are not simple at all, they require a lot of work, can be incredibly complex, typically have a lot of content and it can take months of development to realise you're not ready for it yet.

If you haven't written a game with various states, levels, spawn points and so on, then I'd suggest making a simpler game with just one level and little content, and focus on completing it to a high standard. A project of this size won't take anywhere near as long, will teach you a lot about loading and switching states (even simple games need a main menu, game over screen, high score table, etc), and if it doesn't work out then you won't have spent so much time on it.

I'm making a platformer with a friend. This is a complex thing and I'm learning too. I'll tell you what I know. (Settle in, long post ahead.) But first some background that I think is relevant.

Background

Here's a video screencap of what we have at the moment.

It is more complex than our previous projects. I'll run them both by you for perspective.

1) My absolute first game was this moon base simulator. Its not very animated.

2) Then my friend joined and we made a clone of Winterbells. Its dramatically simpler, but it features animation that we hadn't already done and this experience directly influenced how we worked.

You could say game #3 here is the Moon base game TIMES the jumping grab the pies game.

First we had to make an entity animation tool and wound up making a set editor. You need something like these tools. There are probably decent free ones around.

The game program is put together like so:

There's a Session class which contains the game state. It features a list of all Entities, floors and walls. (Note: Floors and walls are just invisible horizontal and vertical lines that have separate, custom collision rules.)

Every game cycle, it iterates through every Entity and calls its DoIt method. This method is the entity's very own behavior code. I'll get to that in a moment. It also broadcasts events to every entity that is an EventListener. Then it goes through another cycle and tells each Entity to paint itself.

A lot of the structure is in the Entity classes, which are a tree.

The Entity base class implements basic, basic position code and has blank virtual methods DoIt and Paint.

From that I have the DecalEntity which has a simple image surface, can scale and tile, and has a blank DoIt method.

Also from Entity I have an AnimatedEntity class which implements all the animation features. This class lets call an animation sequence by name and even setup a callback for when its done. It also gives us access to the current frame's collision and action bounds.

Then on top of that, an InteractiveEntity which implements gravity, collision and has methods for subclasses to control itself and interact with other entities. All things physical, basically.

Subclassing THAT we have the player entity which overrides the DoIt method which handles player input.

I also have, subclassing InteractiveEntity, a FlyingEntity which is the basic flying monster shown in the youtube clip, however I am tossing this and going to have scripted entities instead.

Stepping back for a moment, about who loads what when...

I'm thinking that I will _call_ the Session's run-the-game method, get a value back representing the game's state (paused\lost\won), show a menu or whatever and when I want to load the next level, I load up another Session and tell it 'Go'.

Basically on the stack I have the grand state, maybe with your progress through the levels, then on top of that the actual play session runs as a called function.

If there are any horrible problems with that method, I guess I'll find out in a week or two when I get to it.

And uhhh, that's how its put together.

[Edited by - JoeCooper on January 20, 2010 3:53:26 PM]

There is a platform starter kit available for XNA. Try starting with that and modifying it to do what you want.