I am working on some areas for my game and wanted to get feedback on the general layout of things. It is a mix between an RPG and platformer. You can see an example of how the game plays here:

And what I have so far of one of my areas is here:

http://img833.imageshack.us/img833/8852/startingarea.png (warning: large image!)

Please note that the background is white because in-game it renders the background (as per the video). Also note all in-game assets are NOT present in the image export because that layer also contains collision data and is very hard to see the actual layout if I show it as well -- this includes vertical platforms (as hinted by the rails), doors, enemies, flame pipes, item boxes, etc. And of course, the left part of the lower drop is not done yet.

I just want to know if the general flow of the areas makes sense or if I will cause too much confusion for the players. I want to lead them somewhat, but give them freedom without them feeling totally lost.

Any feedback would be greatly appreciated!

There's not much to say. It looks pretty solid and intersting. The level flows looks good too, best to finish your level and give it someone to test it. Feedback of testers is a good way to improve your design.

Looks good in general, relatively good feel to how it moves. I have a few things to consider though. Please remember, that for the most part, this is just my opinion.

1) early in the video, when jumping from one floating island to another, the landing site actually went completely off the screen. This makes it more difficult to make sure your going to hit it.

You might want to lower the screen view a little, or zoom out a bit. Maybe even only change the Y/Height if the player moves outside of a certain Y range from the last platform they rested on. I.e. jumping wouldn't make the screen go up and down.

2) The camera movement is a bit jerky. (It called me names)

- I would recommend a leash camera with a spring and friction. Right now, it appears you have the camera tied directly to the player, so when they jump, the scenery moves as intensely as they player's force.

- Example of spring : http://www.myphysicslab.com/spring2d.html - though this only shows a spring, and without friction, so it just keeps moving.

- without involving too much physics, I'll just give you the concept of a very simple spring. Determine the difference between the X locations of the center of the view on the map and the location of the player on the map. Then, reduce it to 90% at every update, or 95%. (I.e) CamX = (PlayerX - CamX) * 0.95. Then do the same for Y. Also add an if statement to determine if CamX is greater then PlayerX, and if so swap the subtraction variables.This will allow the camera to move a little more smoothly. Normally, I would apply polar coordinates, and multiply the distance by 0.95 (also taking into account a leash length and friction), and then reset the camera to the new polar coordinate from the player, but that involves a bit more physics.

3) from looking at the image map, its hard to determine where the player should go. What happens if they were to go all the way to the left side of the map? is it an alternative way out of the map? Its not bad, I'm just a little confused from its purpose.

4) there were areas where the player had to jump down, into something they could not see. I.e. the point where you landed on the enemy unit by accident. You are creating circumstances that prevent the player from succeeding without luck. Usually the idea of jumping down to where you cannot see is instinctively bad for game players who don't have some kind of assurity that they will be OK I.e. will players land on spikes, on an enemy or perhaps a bottomless pit that just gets called death?

- Perhaps a peek method, I.e. if a player crouches, or holds a button plus a direction, the camera will shift that direction so they can see a little farther.

5) relating to (3), since the player has no specific direction, I.e. in Super Mario Brothers you could only go left, for instance, it seems like something else about the level should imply a direction the player should go. I didn't see hints.

6) This may not relate to the nature of your game, but it didn't feel like there was a purpose to the level. I.e. In SMB1, you immediately have a very simple character to jump over, and then a block to hit and you get a mushroom to make you big. You could make it through as a small character without squashing anything, getting the mushroom/extra life, using a warp, etc...but it does introduce you to the concepts. Then you leave the level through a pipe, hinting that pipes can lead you down.

- Typically in a game, each level has a purpose to show a challenge of gradually increasing difficulty, introduce a concept, or move the plot.

- to be fair, there is not a lot to go on, so you very well could have more than the video and text showed.

again, these are just some takes I had on it. Over all, I like what you already have.

Just a critique based on the video; the collision detection for your box hits doesn't seem to be consistent. Don't know what kind of collision detection you are using but it might need some tweaking.

On the camera, I agree. Right now it is hard fixed to the player, but this is simple to adjust. I think I'll combine springy camera with down to look down. Not sure how I want to handle jumping/falling yet though. As far as direction goes - I have not added NPCs yet so that may be part of the confusion. There will be someone at the beginning to give some direction. I'll think hard about the 'falling into the unknown' scenario - I didn't really think about it like that as I know the map and forget the player will not. Do note the maps will be explorative and you will be able to go anywhere (well, anywhere possible given your skills and inventory) you'd like at any time. Open ended I guess you would say. It's a hybrid of action/platformer and RPG - i'm sure I should have specified that earlier.. sorry!

As for the physics PyroDragn, I use Box2d - what part seems inconsistant? I have to tweak box2d a bit to feel more platformerish. The player itself has a circular collision at his feet (really, the bottom half) as it makes certain things easier to deal with (getting caught on collision boundaries and such). The up/down platform is a bit odd but I believe its some sort of floating point issue as it only 'shakes' sometimes. The character actually suffers from infinite inertia until I figure out a better way to define the bodies to prevent sliding while also preventing wall-hugging.

Thanks for the input guys! I'll adjust what I have and try to work on the camera some so the game isn't so mean to the player

Oh and for the camera again -- I first want to try the opposite of the 'lag' style, making it move to show more vision in the direction the player is going - smoothly expanding to a certain point, and settling on center when stopped (down and up will adjust up and down offset of course for looking).

what part seems inconsistant?

Around the 14-15 second mark in the video, when you're jumping to hit the second ! box, it doesn't seem to detect the hit each time. You end up jumping once when it appears you're still inside the box (3rd jump) and the fourth jump looks like it should register, but you don't get the last coin until you pause a moment for your fifth jump. Looks mostly like you're able to repeat a jump while inside the box and therefore the collision doesn't register since the last collision is still valid.

Very clever observations. Currently I do not have a good way to tell if i'm on the ground or not so there is currently no limitation on jumping (aww, busted ). If I double jumped that was an input mistake on my part. For the 'not registering' issue, that is because I have a minimal delay before you can hit the coin box again. It does see it as individual hits, but disregards the hit due to the minimum time delay not being exceeded. I'm actually going to animate it a little bit and not allow it to be hit again until animation finishes. Really keen observation again, I'm impressed :D

[quote name='Tim Sarbin' timestamp='1358898732' post='5024512']
Currently I do not have a good way to tell if i'm on the ground or not so there is currently no limitation on jumping
[/quote]

I'm guessing with your jump physics, you can tell the momentum or force propelling the player. If that Y-force is at 0, then you are on the ground. That doesn't solve for jumping from the moving platforms, or a clever player timing the second jump at the pinnacle of a previous jump though. I guess it really depends on your player. In my games, I haven't adapted any external physics engines, so determining ground was pretty easy. I'm not sure about Box2D, and how that works.

How do you prevent the actor from falling through the ground if you can't tell whether the actor is on the ground or not? Something in your code is aware that it's happening.

ADDENDUM: It just occurred to me that this may be due to some library/tool handling the collision for you; if that is the case, you may want to bring this question over to the coding/libraries section on the site...or seek out resources specifically for that library. Sorry I can't offer more, but I've never heard of Box2D until this thread. :(

Surely there is a collision event you can react to. Such as when you collide with enemies. Does a similar event fire for the ground? That can tell you.