Robobomb

 Hey guys. This is a game I've been working on for the past two months. The gameplay was inspired by Bomberman Hero on the N64. For now I have a running tech demo of the mechanics and a couple of levels which are for the most part complete. I'd really like to keep going with this but I feel it needs more people to test it just to see if it feels right or if it needs anything else.

Here's a link to the game:
http://www.stencyl.com/game/play/38883

The main character is Robo, a walking "bomb factory" that's trying to escape from the laboratory of his creator, Professor Durnick.

 A quick rundown on gameplay:

 Try to get to the end of the level by using your bombs to progress. Avoid colliding with enemies and your own explosions to avoid taking damage. Your health is shown at the top left corner of the screen.

The Controls:
- Use the left and right arrow keys to move around
- Press the up key to jump
- Press X to throw a bomb

 I've tried to simplify this game more since the last time I posted it. What are your guys's thoughts? Does the gameplay feel right, is there anything game breaking?

 This is more of a prototype than anything, but I'll continue to update it, thanks in advance to any testers and feedback!

Interesting start.

Controls are way too hard to start with.  (Ok, I'm not a good gamer but you should aim for the baddest of them all)
At least make an in game tutorial about the controls.
Start with some real easy levels and let the player learn how to throw the bomb in the air etc..

Have fun with this!

You know that makes a lot of sense I'll keep that in mind. I've noticed that these current first levels are a little too "platform-y" so will definitely rework those.

Hi,
its a good start.
I was a bit lost how to get trhough the upper gate.
I would let the player explore a bit more before running into stops that early.

Cheers!

Ok so it seems the game's biggest problems so far are the lack of explanation and not enough time to let the player explore the controls. Great advice you guys thanks!

I finally figured out how to get up through the first upper gate. I agree with everyone else--a gentler introduction to these tricks would help.

Is the explosion actor's collision box set to sensor? I ran into some odd bugs, like being able to drop a bomb inside a wall. One time I fell into the wall.

 Yep the explosion was set to a sensor to make it "go through" other actors and collide with them. As for the bugs I was wondering if I could get some help with them? I think the reason the bombs go through the wall is because of how tiles are made into a single shape, is there any way to make a collision work while inside a tile? The same goes for when you get pushed into a wall is there any way to fix this?

I'm not sure what's happening when the character blinks, but I seem to only be able to walk into the wall when that happens.

The problem with the bomb is that if you create the actor at an (x,y) that is inside the collision box, then it'll just appear inside it. So if the player is standing against the wall, then point at which you create the bomb is likely inside the wall.

Pushing the character back a little bit if they drop a bomb while standing up against the wall ought to solve the problem.

I see. So as long as the bomb (or any actor for that matter) is created outside the collision box then the collision will go through. Any actors that are created while collisions are overlapping won't allow the collision to run?
 This can help me out a lot I'll try pushing the character back a bit when standing next to a wall. As for the blinking what happens is that the blinking animation belongs to an "invulnerable" group. This is to nullify collisions with enemies and explosions and any other hazards. There's a sort of knockback effect to it however that forcibly pushes the player back and it may be what's causing this. I'll look into it I need to find a way to stop the player from being pushed when next to a wall or just take it out altogether.

I see. So as long as the bomb (or any actor for that matter) is created outside the collision box then the collision will go through. Any actors that are created while collisions are overlapping won't allow the collision to run?

It's helpful to remember that collision boxes aren't solid shapes. Rather, think of them like fences. If something is created inside a collision shape, then it's "fenced in".

If you're (or anyone else passing through is) new to Box2D, then it's also worth noting it has a few quirks--although working around them is usually easier than writing your own physics engine from scratch (which is an option, by the way. That's the route I chose).

You can sometimes get glitches if two animations have different sized collision boxes. The greater the size difference, the more likely you'll see issues. For instance, if an animation has a tiny collision box and the actor is pushed up against a wall, what will happen if the animation suddenly switches to one with a large collision box? Now the wall and actor boxes are overlapped.

You can also run into problems forcibly setting x/y positions if the change in position crosses a collision boundary. Depending on the circumstances it might not be often, but it's worth keeping in the back of your mind in case something does go wrong.

 Merrak, I really do appreciate all of this advice thank you. There seems to be a lot more going on "behind-the-scenes" than meets the eye.
 I've noticed the issue of going from small to large collision boxes occurring when I tried to make a bomb and explosion  as two separate animations rather than actors. The collisions weren't responding and I didn't know why (a bomb wouldn't affect a switch or enemy despite what seemed as though they were colliding). Is there any plausible solution to this? Basically can explosions and bombs be set as the same actor in any way and still get then to collide with other actors, despite the size differences?

The collisions weren't responding and I didn't know why (a bomb wouldn't affect a switch or enemy despite what seemed as though they were colliding). Is there any plausible solution to this?

Double check the collision group settings. Sometimes it's helpful to use a print block to print output to the log viewer in order to test if a collision is responding... just to rule out a problem with the code that is executed after a collision occurs.

Alright i'll check it out when I get the chance and see what happens.

Just an idea:
I had those "wall glitches" as well for a long time untill i realeased that the problem was changing collision for the player.
Is is always the same when you change direction? Otherwise it could be a problem
Are the origion points (in animations) all centered? Otherwise it could be a problem

Cheers!

I think I see what you mean one side of Robo is slightly bigger than the other. They are centered however as far as I know but I'll double check.