I'd have to see your stuff then to see how you have it set up, but I still think resetting whatever variable you are using to adjust your spawn rate when you un-pause the game would be the best thing to do. It sounds like the easiest thing to do.

Are you switching to a different layout when you pause the screen? If so, use the on start of layout command to reset your spawning variable. Likewise, you have to have some function that un-pauses the game. You could always reset your spawning variable there as well.

You basically want to add the IsPaused condition to your random generation algorithm (how ever you have that set up) So add the condition, IsPaused = 0 then randomly generate (or spawn) your object.

When you pause the game, you want to set IsPaused to 1. So if the game is paused then your random spawn generation should stop because IsPaused doesn't equal 0.

In more english terms, think of 1 as being true and 0 as being false. So you would say (assuming for you random spawn instructions), "If it is time to spawn an enemy (or object) and the game is not paused (IsPaused = 0) then go ahead and spawn an enemy."

Likewise, you would say, "When the game is paused then go ahead and set IsPaused equal to 1. When I unpause the game then go ahead and make IsPaused = to 0."

That way your game has a check to see if the game is paused. If it is, then don't do anything. But if it isn't paused and it's time to spawn something, then go ahead and do it.

ALLMarkMade Use a global variable as a sort of Boolean. Use the on Start of layout and on end of layout for your instruction page to turn it "on" or "off" Add a second condition for your exvery random seconds to see if the "boolean" is true.

so, for example

Global variable IsPaused = 0 ; 0 will be false, 1 will be true to keep to conventions.

On start of layout for instructions page, IsPaused = 1 (set value)

on end of layout (instruction page), IsPaused = 0 (set value)

Add the extra condition, if IsPaused = 0 AND Every X Seconds

That should fix it easily enough.

I'm finding 0 documentation for it on Web Wiz other than it being listed in the features and a thread of someone asking how to send subscriptions to multiple email addresses.

I'd assume from setting up other forum software that it's probably permission issue or permissions not being allowed for it. I would assume that it would show up under the drop down box under thread options. Again, I'm only assuming.

I don't mean to bug about it. I'm just offering whatever information I can for the forum moderators should anyone want to loop into this. But if someone would decide to, I would love them forever!

I took a look over at some of the documentation at Web Whiz Forums and it looks like the software does include the ability to have subscriptions.

That can be read here:

webwiz.co.uk/web-wiz-forums/forum-features.htm

If I can find direct documentation on how to enable it I'll post a link in the hopes that if Ashley and Co. decide to flip the switch for it, it'll make their lives easier to find the stuff for it.

I apologize but this has been bugging me a bit since I joined the forums and I wanted to offer a suggestion for it.

Would it be possible to add thread subscriptions at all? If I'm missing how to do this than please tell me, but otherwise I don't see this anywhere on the forums. In other forums, when a member would create a thread or respond to a thread, they would be subscribed to it. Users could also just manually subscribe to a thread if they wanted to watch it. The user's control panel would then have a list of subscribed threads along with new updates on comments to that thread and the last person to comment under the thread.

That would make watching threads and participating in conversations a lot easier. As is now, I have to remember to track down a thread if I want to see a response, remember the name of the thread, search my name for threads I responded to, or hope that someone tags me in a response. That just seems like a very unorganized way to do it. Thread Subscriptions could keep make that much better. Good examples can be found at Desura and XDA-Developers.

You can also use the persistent behavior on your objects too.

Edit:

After thinking about it for a second and not giving a kneejerk response, I think as mentioned above, using delta time to stop movement, and then the persistent behaviors to make sure everything stays in place, might be the best bet.

arontwose beat me to it with a simpler solution.

The fun thing about Construct is that it keeps a count of the objects. First, make sure bullets are destroyed when out of layout.

Then keep track, of many objects are on the screen. I typically assign some kind of global variable. NumberOfBulletsOnScreen = 0

Now, when you press the space key (or fire key) count the number of objects on the screen. Number of bullets = bullets.Count

'.Count' is appended after the object name to get the total number of that objects on the screen.

For your conditions down "when space key is pressed (or whatever key is the fire key) AND NumberOfBulletsOnScreen < 0

and the actions would be

spawn new bullet

NumberofBulletsOnScreen = bullets.count

This will work because you will keep a constant track of the bullets on the screen every time you fire. The layout always starts it as 0 so it will always allow you to start firing. As you fire it will raise the number of bullets on the screen. When there are 4, it won't let you fire any more. But you need to make sure to keep track of the number of bullets on the screen when the bullets are destroyed too. So you need one more condition and action.

Condition:

Bullet-On Destroyed

Action:

NumberOfBulletsOnScreen = bullet.Count

That will lower the variable and reset it as bullets are destroyed.

I think if you use the right combinations of layout, layout sizes, window sizes, and some good edge detection you could probably get away with it I've been experimenting with it a bit and I've got something like SOTN to work and do what I want while prototyping it.

That said, I'm not sure how memory constraints will hold you back on a map that size. I dont know the specifics of memory handling for that. I don't know if Construct dumps the entire layout into video memory or only what's in the window at the time. Ashley could better answer memory technicalities better I think. With some creative work though I imagine you could keep memory down enough for it to not be a bother.

You mentioned it being in an EXE style game which means your exporting to Node-Webkit. It's still technically a browser, but by exporting and distributing via node you have the side benefit of ensuring more system resources are available because the entire app is downloaded and run natively from the system and not hosted online. It also ensures a desktop/laptop is running the game and not a tablet or phone that is is less powerful.

Shouldn't you be able to cap FPS with the delta time stuff built into C2? I know it would require a lot more programming on the movements and controls. But with the right math, couldn't you control FPS that way?

Either way, I agree with ASHLEY. The built in behaviors have built in DT algorithms which will make sure other things should run smoothly. The only that that would change is the frame positioning on graphics refresh. Given the rate at which smart phone are improving, Google's new JS project, Cacoon, improvements in webkit and such, I don't see a reason to limit frame rate. It would do nothing but limit the experience and cause a headache for devs later on with upkeep (unless you don't intend on supporting your game past a few months).