Just to reinforce the ideas above, because that's the way I would do it, would be to have a flag variable trigger back and fourth. I do this very commonly in my experiments. Traditionally, I would use a bool (true/false variable) but Construct doesn't allow global bools. Instead, just set a variable to 0. When you need to trigger it to true, set it to 1.

For instance,

if flagVariable = 1

Players turn with instructions

at end of player turn, switch variable to 0

if flagVariable = 0

enemies turn with instructions

at end of turn, switch flag variable

You can also add in a time element to the mix, like only allow the player to move if so much time has passed.

if flagVariable = 0 && timePassed = 30 (seconds used as an example here but that can change to your needs)

It's pretty easy. I would recommend prototyping out that specific instance of the game and play with it. Try and muddle with things and when you get stuck, come back here and ask some questions. Always be prepared to give examples or code snippets of your logic to.

fongka2 Thanks for the demo. In the next day or so I'll take a look at it. I understand what your code is saying and it seems like a good, viable usage. I completely agree, there's no need to make the problem more complex if it doesn't need to be.

Also, would you mind if I saved your demo and added it to my GitHub account and whatnot? I'd like to have a documentation source for others in the future that might stumble on this post. I didn't see a lot of documentation on the subject past a couple of forum posts and jayderyu 's tutorial.

Thanks — I actually looked at you tutorial. I'll admit though, I skimmed it and didn't read it thoroughly. I only looked at the code to see what it was doing. I don't remember why, but it didn't do something the way I wanted. You did a damn fine job on that tut!

With that said, Ashley or Tom, is there anyway that Scirra can add in an option to take a snapshot of the entire event sheet or group like we can with just snippets?

At any rate, the more documentation the better. It'll help everyone in the future.

I did run into a problem though with the snippets above. If they layout size is larger than the window size then the controls won't track and move on the layout properly. It was easy enough to fix though. I had to use the pin behavior on the joystick graphics when created and pin them to the invisible touch pads. I also have to keep realigning the initial x and y values for the left joystick to the center of the ring graphic.

These are two different tools for two different jobs. If the window size and layout size are the same, I would recommend using the snippets in the OP. I say this because the having to constantly re-align the initial x and y values use extra compute cycles, albeit very few. if the layoutsize is larger than than the window size, the stuff in the paragraph above has to be done.

I'll update the OP and my blog and the GitHub repo in a day or two when I'm feeling a bit more productive.

When you have time, is there anyway you could provide a quick example file with how it corresponds to creating movement or controlling movement of another object? I was having a hard time finding documentation to do this. I get how drag and drop works to click and hold an object to move it. What I was not getting, or how to make it possible, was how to drag an object, such as a joystick or squares in your link, to make another object, like the player, move in the corresponding direction?

I'll admit that there may very well be an easier way, but not one that i understand at this moment. I wanted two joysticks, one to control movement and one to control player rotation. I wanted the joystick to disappear when not in use. I also wanted them to adjust to where the player places their finger on the screen. I didn't want the joysticks to stay in a static position on the screen.

Edit: To better explain my dilemma from your example, all I'm seeing is two squares with drag and drop behaviors attached to them. How does clicking and dragging correspond to measurement movement to make another object move in a specific direction.

I need dual joysticks for a touch screen for an upcoming hobby project. I couldn't find a lot of documentation to do it and found it wasn't as easy as I originally thought. So I figured it out myself. I thought I would share how I did that the best I can.

GitHub link for repo of prototype: https://github.com/mepis/Construct2/tree/master/Dual%20Joysticks

The article I wrote for my blog sharing the exact same thing : http://kurie.us/how-to-make-dual-joysticks-in-construct-2/#more-127

Capx example file: http://www.kurie.us/Downloads/construct2/DualJoysticksV1.0.zip

I'm a bit lazy, so the rest is mostly a copy and paste job from my blog. If anyone has any questions or needs a better explanation, please let me know. I'll be happy to help how ever I can when I have the time.

First, I assume a couple of things with this prototype:

No more than two touch points will ever be used at the same time, or if there are, the first two touch points will be either joystick.

There will be times when either joystick is initiated separately. As such, different touch combinations and events needed to be handled. This will explain the convoluted events used. I found them to work most accurately in this specific order.

I built this prototype with a couple of idealisms in mind:

The joysticks must disappear when not in use. I wanted to free up screen real estate when it wasn’t used.

The joysticks will be created when the screen is touched and destroyed when touch has ended. The joysticks will be created at the point that the finger touches the screen. I’ve always found joystick control on touch screens to be annoying. Not everyone has the same sized fingers. I tend to miss buttons easily or I get annoyed about the amount of screen real estate used up by touch controls. I wanted to solve both of these issues the best I could.

A couple of points to keep in mind:

The graphics don’t matter and only exist as a point of reference. As such, each graphic can be removed, changed, shrunk in size, or blown up according to needs. All interactions are based around the points in which the finger first touches the screen, not the objects on the screen.

The global variables event sheet contains two variables that should be altered per game and target device: XThreshold and YThreshold. This will adjust how quickly the left joystick reacts to movement from its zero point.

The outside ring around the left joystick only acts as a point of reference for the player. It allows the player a point of reference where to zero out the joystick. This can be removed though it’s suggested to have some graphic to signify the center of the joystick.

First, let’s go through the layout.

Only one object on this example has any behaviors. The red triangle, or the player, has 8-way movement attached to it. I use this to make life easier to move the player around the screen. The joystick will interact with this behavior later on.

It’s important to note that the ‘LTP’ and ‘RTP’ are two giant, clear objects that cover the entire windows. ‘LTP’ stands for ‘left touch panel’ while ‘RTP’ stands for ‘right touch panel’. Both objects are used to listen for and register touch. The left touch panel will be used for the left joystick that controls movement while the right touch panel will be used for the right joystick that will be used for rotation.

The left joystick is a two piece system per say. The smaller black dot acts as a visual representation of the thumb pad while the larger black ring acts as a pseudo boundary for the thumb pad. The boundary acts as a point of reference for the player to indicate where to return to so that movement can be stopped. The black thumb pad will follow the finger and move in all directions.

The red circle only rotates. It’s best to visualize this as a knob of sorts. The player can rotate this knob left and right. The player direction will match the angle at which this joystick is rotated.

Finally, the event sheet.

First, let me explain what’s going on here. The event sheet is broken into three groups, or functions. The first is for debugging labels. This can be ignored. It was only used in the process of making this to see the numbers of the inputs. The next two groups, or functions, control either the left joystick or the right joystick. I had to create three screen shoots (all below) to display the entire event sheet.

Let’s start with this screenshot. First, ignore the debugging group and focus on the Touch Controls group. Within the Touch Controls group is a separate group for the left joystick and the right joystick. Both the groups for the left and right joysticks are designed almost the same with adjustments only for the type movements they provide.

Let’s look at the left joystick first. First, I check to see if the player is touching the screen. If they aren’t, the joystick is destroyed and cleared from the screen. The right joystick is the same. I also set the touchID variable for the left joystick to -1. This is important because the code checks for existing touchIDs later on. Zero is a valid touchID so we can’t have the variables default to zero. Otherwise it causes confusion later on when the joysticks are created.

Next, I check to see if the player is touching the screen, specifically the corresponding touch panel for the joystick (Eg. left touch panel for left joystick and right touch panel for the right joystick).

Next I check for movement logic. This is a bit more complicated to explain. When the player touches the screen, the game needs a point of reference for finger movement. For example, the game needs to know if the player moved their thumb up or down. Notice the argument ‘Touch.XforID(leftTouchID)’. This is also very important. It checks for the X and Y coordinates of the specific touchID.

So, I store the X and Y values of the first touch in a couple of variables to reference. Then, for each step thereafter, I check the position of the finger on the screen to see where it is in relation to the initial touch point. If the finger moved in the right direction (up, down, left, right), the 8-way movement behavior is called to move the player around the screen.

Next, I check for either creation or destruction of the joystick. I save this for last. Please note, we are still technically in a ‘if-else’ type of statement. Otherwise, if the player is touching the left touch panel, check for everything I wrote above and the next paragraph.

This part gets a little silly. All three of the first conditions do the same thing. They check to see if the player is touching the screen, and if they are, they create the joystick. They check against different touchIDs though. If a touchID of the other joystick is a specific value, this code checks the touchID value of this joystick for a specific value. This needs to be done to clear up some confusion when the code goes to create a joystick. If both touchIDs for both the left and right joystick are the same value, weird things happen. As such, I need to assign touchIDs very specifically and that all depends on the current value of the other joystick.

Both joysticks go through this process. Both joysticks check the other’s values before assigning their own.

The final step is register and move the graphic for the joystick.

The right joystick follows the exact same logic and has almost the exact same wording and conditions. It should be pretty easy to follow if you understand the above explanations.

I don't know what your programming background is so I won't make any assumptions there besides that you have none. Don't take that as a personal offense please. i'm just establishing a base line for my reply.

Construct 2 creates a lot of Javascript code when your game is exported. Everything Construct does is based around the capabilities of Javascript and it does it insanely well for a visual editor. With that said, do some research into object oriented programming principles. Javascript can't do it the same way that a true OOP language would, like java, C++, or C#. You can come really close though and use a lot of the same methods and principles.

After you do that, read the manual for Construct thoroughly. That'll give you a great idea of what capabilities you have in Construct and things will start to click. You'll see how everything fits together.

I'm willing to bet you can massively cut events and create much cleaner code that way.

That intro makes me curious about the game. It's intriguing and I'd like to see more. Personally, it makes me want to find out what is so disturbing about the game.

Though, I would still take the advice from above. Show it once and be done. I would be annoyed if I saw it every time I turned on the game. Or incorporate it into a loading screen. Use it in promotional material (Eg. Youtube videos and such). It catches attention.

Edit: I also like the coffee mug in your avatar.

I would suggest an iterative approach in adding features later on. Certaintly, asking for feedback is awesome! Don't rush it though. Play around with the mechanics, like speeding up the foxes. Let others play it with the changes without releasing it. Get their feedback and, more importantly, watch what them when they play it. Then add in other things, like coins, to add additional layers of game play to the game. Just my two cents. It looks like you have a fun game. Don't rush into it.

Semester courses are more common but a yearly lease is more industry practice. DreamSpark is a good example. My DreamSpark account gets renewed per year as long as I am enrolled in the CIS course track at my school. I think it makes more sense for Scirra to do it per year. In reality, a student will need to learn and use the software for longer then the course. Also, with how cheap Construct is, a student could feasibly save the cost of a personal license within a year as well. I think the pros far outweigh the cons in this case. Besides, .83 cents per student per year for an additional license is really cheap. That cost can easily be absorbed.

BluePhaze

Welp, in the terms of Construct, you have made my points invalid. I thank you for the information. I was not aware that IE did not support the controller API. I thought it had. That's rather disappointing.

I understand companies want to push touch as the primary mechanism for input on mobile devices, but the lack of tactile feedback is limiting at best with mobile games. It's forcing developers to redesign input methods. That's not a bad thing, but I still haven't seen a good way to provide input for genres like action or adventure games. Perhaps many of us are to stuck in the old ways of the D-pad and such. Even Apple has recognized this to some extent.

Well, that's good to know and slightly disappointing. The cost barrier isn't high upgrading to Windows 8, but it's also a head ache if you're anal like I am. When do full OS upgrades I prefer to do a full wipe. The upgrade flow from Windows 8 to 8.1 essentially does this so I;m pretty cool with that. But digressing, I can understand PhoenixNightly opinion of not wanting to upgrade. Some people may not have the money to spend. Others may be waiting to buy a new PC. Whatever the case, Microsoft is limiting developer support by doing this. I suppose that is a debate for another thread though and outside the scope of this one. As a tip though, most colleges have a partnership with Microsoft. If a student is in school for a computer something degree (Eg. Computer science, Computer information systems, It administration, etc...), that student will almost certainly have access to a free dreamspark account. I got VS studio 2013 pro and a second copy of Windows 8 for free this way. Also, if I remember right, students irregardless can get a free dreamspark and dev account if they sign up with a school email account. It's been a few years since I've looked at that so that may not be the case anymore.