Very busy screen. If you ever place advertisements on there, it would personally be a huge turn off. Just looks too busy.

Play and pause button need re-designed. They take up a huge amount of screen real-estate. Condense pause into a single button that can both pause and unpause. Put it somewhere in a corner, probably condesed to only the two pause bars, small and out of the way.

As for the play button. Each level should have a button perhaps appear in the middle of the screen. Press that, it it is gone. Never to be seen again.

Difficulty. VERY and I stress VERY easy. Got to a point where I actually wondered if I could take damage

I understand I am "defending" my base or something. But this is not very clear. Not to make things more busy, but perhaps a better indication of what the bugs are trying to get to? Maybe the turrets have little people running around. loading ammo, shooting useless little guns off. small things.

I personally try to do away with health bars. They take up screen space, and usually dont do much. It might be interesteing, if you went the little people route, that as you take damage, the people die, and perhaps even the guns start to smoke and catch on fire.

As health goes up, turrets are repaired and people start showing up again.

All opinions. Do with them as you will.

Game looks promising. Keep up the good work!

I would only let the car move left and right. Never move the car or the view.

Scroll the background and objects.

View would stay in the correct place, as would the car!

could you attatch a capx. I personally am having trouble following the question. capx would help see whats happening.

> Dont do a collision check, do an overlap check.

>

Can you explain Tylermon? It's the collision checks built into the platform behaviour. it's more along the lines of the animation types than the collision types... ie "Falling" "Moving" "Jumping" and "Standing" if you know what i mean..?

Thanks guys. Will probably just write my own jump.

You would have to apply a speed/force of your own. Don't use the default jump behavior. But using an overlap check, should be better than a collision check for a circle, because it will more accurately represent the shape.

not checking of course, if the player can walk on it. Use a collision for that. But check if they can jump using the overlap.

hopefully that makes sense? I can try saying it differently maybe, my brain is a bit tired haha. Been delving into the realms of multiplayer and wrapping my head around that sort of has my focus haha.

Make the object a solid, and be sure to change your collision polygon.

> I have an event set to destroy an object on the layout if not the host.

>

> My problem is, the game never thinks I am the host.

> I dont know if others have had this issue before or not. but I am stuck here.

>

> As the code is, the player gets destroyed when this should not be happening.

>

You are calling the multiplayer.host check before multiplayer can connect.

So even before it can join the room, its realising its not the host because its not connected, so it destroys the player.

You need to have,

on.multiplayer.joined.room

is host : Associate player with multiplayer.peerid

Else

<invert>is host</invert> player.destroy

Hope this helps,

Tom

That fixed it! thank you.

I didnt think I needed that because I had it below the code that actually joins a room.

Dont do a collision check, do an overlap check.

I have an event set to destroy an object on the layout if not the host.

My problem is, the game never thinks I am the host.

I dont know if others have had this issue before or not. but I am stuck here.

As the code is, the player gets destroyed when this should not be happening.

Made a quick sketch.

When the ball is in contact with the invisible Grey box, that's where the impulse on y happens.

That box is always there.

At the top the ball would sort of Bob up and down floating.

Blank.

Android is not an easy platform to develop for.

Screens are of all sizes and resolutions.

Devices range from poop-to god mode.

Android has no baseline.

I suggest picking a few common devices. Tablet, phone.

Galaxy s3 would be a good average.

Nvidia's shield tablet would mark the new high end capabilities.

Luckily, as an android developer you can actually restrict people from playing if they dont have a device you want to develop for.

Thanks Vikings but in case I did do this on mobile can i actually have it where the player is moving the rim around with his thumb pressing on the rim image on the touch screen device instead of having control direction arrows displayed on the screen ?

Drag and drop behavior?

OK let me try and see if im understanding correct.

You have two layers.

an object on layer 1.

And an object on layer 2.

you want only layer 1 to be drag and drop when on layer 1, and NOT the layer two object?

if that is what you are asking.

My advice:

create a global variable "activeLayer"

if object is on active layer

Enable drag and drop.

Else

Disable drag and drop.