rambo,

Go to my website www.ashatej.com and try the controls in the game ptRaid.

If this is what you are looking for, then the source code for the game is posted here in the games forum.

There is also a joystick demo in the games forums too (but I was never quite satisfied with it)

I have attached the game gui code from ptRaid to this post.

(It is only on js file, but for some reason this forum won't let you post js files)

cheers,

Shri

Shri,

Thanks! I think this is pretty much what I'm looking for and your code is going to be an excellent starting point. I have found your joystick demo too. Why are you not satisfied with it?

Anyway here I want to make a game a bit like Endless Zombie Rampage, so quite different from ptRaid, but the controls should be similar.

Is it possible to have both mouse+keyboard AND touch controls (virtual joystick) at the same time with the Wade Engine?

rambo,

Yes you can have mouse+keyboard+touch all active at once with Wade.

My understanding is that mouse events are mapped to touch events and so they are the same thing from a programming point of view. Keyboard events have to be caugh separately via getKey... events.

In the gui code, you may notice that there are a bunch of variables for whether a given key is still down (wKey,aKey,etc).

Wade has an isMouseDown method, but not a similar isKeyDown method.

The effect of this is that when a user holds the mouse down on a key -  say left turn - then when the update fires, the boat will continue to rotate left until the mouse is released (up). The key variables do the same thing for keyboard events, so if you hold the 'd' key down, the boat will continue to rotate left until the key is relased. These actions allow the player to just hold the mouse / key down / touch without having to keep clicking, key pressing or tapping.Without this, the keyboard controls are 'sticky'.

The way I defined and then access the key variables (wKey,aKey,etc) can be done better (probably a hash table), but I was putting this fix in at the last minute and just did it quick and dirty.

I did the joystick demo a while ago and was still figuring out how to do things with wade. So, the code is not as elegant as I would hope. Maybe I will revisit it some day and rework it.

I checked out the link for the game, it was fun and in the spirit of the halloween season.

good luck,

Shri

I just wanted to add a couple of points:

1) keeping track of key states is really something that should be built into the engine, thanks for bringing that up. We'll try to add it for the next release, which is only a few days away.

2) yes our forum software doesn't let you attach .js files for security reasons apparently - however that's what share & fork is for :)

3) rambo - just so I understand what you mean... how would shooting work with the virtual joysticks? do you click in the middle to shoot, or do you shoot every time the finger is lifted?

We have a small project in the works that uses twin stick controls. I have uploaded it to share and fork, feel free to check it out here

Control's are wasd to move and move mouse to aim for computer, and the twin stick's are for touch screen.

You might need to run the demo in a pop out window to make the keyboard controls work. Hope it is useful.

Hi, I'm almost finished with this game and I still hope to make in in time for Halloween. I have a quick question: what is the best way to make a user interface? I have done it and it works well but when I move the camera, it moves. I am using the onUpdate event to reposition it, but maybe it isnt necesary?

Hi Rambo. I am just about to update share and fork with our twin stick shooter. In our game, we used the following...

wade.setLayerTransform(this.layers.ui, 0, 0);

This means that the given layer will essentially ignore the camera and always appear to be in the same place on screen unless you manually move it, perfect for UI. You can then move your player in an onUpdate function, and lock the camera to him using wade.setCameraTarget(this.playerCharacter);

I hope this helps. please message back if it is not what you are looking for or you have questions :)

The below is from wades online documentation

Rambo,

The set layer tranform will solve your moving gui problem.

However, setCameraTarget may not be the exact solution you are looking for on the player movement.

On an iso game, it works fine, because seeing the edges of the board where there are no tiles is "normal".

However, in a top down 2D game, as you scroll around, if the camera follows the player, the background can scroll off the

screen leaving just the page background.

From looking at the latest version of the twin stick shooter, I suspect that there is more than just setCameraTarget(player).

Take a look at this thread

http://www.clockworkchilli.com/forum/index.php?/topic/146-best-way-to-create-background-map-for-2d-top-down-game/

for background info then look at the code I posted for ptRaid.

If you take a look at the code look at how I setup and use the gameWorld object. Then in the file gameWorld.js, there are two methods that should point you in the right direction game, the initilaization code and the onUpdate method.

now get cracking, halloween is just a day away.

cheers,

Shri

Hi all.

Rambo. Please upload your game to share and fork when it is done. Would very much like to see what Halloween treat you have made for us. If you need help at all feel free to message throughout the rest of the day. :)

Shri. You are correct that there is more going on. If your game world has edges that your character can move right up to but not cross, you need to unlock the camera when your character gets close to the edge. This however creates the problem that you might be close to say the top of the game world, but close to the middle in terms of x axis.

This situation would require the camera to unlock on only a single axis, y, but stay locked on x. In the twin stick shooter(that I only spent 2 days on, mainly to mess around with the dual controls) the camera position is simply set to the characters position in the characters onUpdate function. If the character goes outside a boundary aka close to an edge, we simply stop updating on the required axis. Hopefully this makes some sense, just wanted to clarify :)