I've got to say, I'd love to see this happen at some point... but then I'll have to go through my IT files and re-import the original samples where possible instead of upsampled ones.

A pretty steady 31 FPS here.

AMD Athlon 64 X2 6000+. Dual core, 3 GHz per core. (Running in XP SP3, 32-bit)

4 GB RAM.

NVidia GeForce 9800 GT (512MB)

How to alter the laws of physics within Construct

In the event editor, when you click new action, then choose an object, there should be tabs at the top - Platform, Physics, whatever sort of behaviors they have. This is one place I know of where you can alter their gravity, etc., during runtime.

How to make it to where a layer in the back could interact with a layer in the front (like a tank in the background firing at the player)

I suppose you could have a tank sprite in the background, set to be not solid.

Its shots could be non-solid but have collision, and could start small when fired, then they could grow.. Like..

Every 250ms: Shot.width = Shot.width + 1, and Shot.height = Shot.height + 1

Then, when Shot.width is greater than 32, for example, it could check for collisions with the player and so on, then the Shot could be destroyed.

Or you might have to 'Pick object by comparison'.. Shot.width Greater than 32, then do that.

It is an idea, anyways.

How to create a fully functional pause menu complete with the ability to equip new gear to the main character, change settings, and display statistics

In my game, I have a menu layer. My menu objects are global (I believe). When I bring up the menu by keypress, I set the timescale to zero, and set the menu layer to be visible.

Then it's a matter of just using functions that don't require timescale to be above 0. Just immediately sprite X/Y positions, reading single keypresses through MouseKeyboard, things that don't happen over time as it were (like repeating keypresses from 'Key somekey is held', I think).

Then, I think what I did was have a "group" named menu in an event sheet. When I bring up the menu, I enable this group. This way, clicks or key presses that should happen only in the menu happen only in the menu.

Then I set the timescale back to 1.0 and disable the menu group again when I close it.

How to equip items to sprites, such as a change in gear

You can, perhaps, destroy your equipment sprites or hide them when they aren't needed. Then when one is equipped, spawn a new one or just make the equipped ones visible. I am not sure what is best to do.

Then, when equipped, always have the equipment sprites be moved to certain points on the player sprite. You can set "points", with a name, in every frame of their animation.

For example, a raccoon character of mine has a point named "tail" in all frames of animation. His tail object is always moved to Player's point named "tail".

I have certain weapons he can equip. When the sword is equipped, I destroy the other weapons, spawn a sword, then it's always moved to one of the hand points.

When I switch to a bow, I destroy the other weapons and have the bow be moved to his hand point.

How to code special effects to a sprite for things like spell casting

It is possible to alter the parameters of effects during runtime, I think.. You could do that, or possibly clever use of new sprites on top.

I hope I wasn't too confusing, and gave at least some kind of useful answers. =)

The workaround I would use is this:

Make a global text variable, named like LayoutToGoTo for example.

Make a new layout, named LayoutRestarter for example. In this layout, have just one event, something like:

Start of layout: Go to layout global('LayoutToGoTo')

So, to restart your current layout, you could set the global variable's value to the current layout's name, then go to the layout LayoutRestarter.

To get the current layout's name, it is.. somewhere in the system object. CurrentLayout ? LayoutName ? I forget.

In gamemaker, your objects were stored in a list, and you could add them to the world freely. However, in construct, is seems to me that if you have an object that isn't created on start up(like a bullet), you must still place it in the layout. Although you can place it outside of the game screen, the object still exists in the game.

The "Destroy at Startup" attribute as mentioned is the way to go.

Even if you have a single bullet outside your layout and you set it to "destroy at startup", the bullet object is still able to be referenced in events. You can spawn more in your layout at any time, even though the first and only one placed in the layout was destroyed on startup.

While I haven't looked at the file link, perhaps try making your outer walls much thicker, make sure they are set to bounding box collision, and make sure they are either overlapping or perhaps touching neatly.

Not to hijack the thread but is there a way to pick from a series of numbers?

i.e 100,200,300,400,500 and pick one of those values at random.

There is probably a better way to do this, but what I can think of is:

Store 100,200,300,400,500 in a global text variable named numbers, then:

str(GetToken(global('numbers'),Random(NumTokens(global('numbers')))+1))

something like that.

Or convert it back with

int(GetToken(global('numbers'),Random(NumTokens(global('numbers')))+1))

or float(...)

In the meantime, what do I type in for x and y values in object creation events to place them at random values.

Use a value like Random(641)

Or maybe.. Random(LayoutWidth) for X and Random(LayoutHeight) for Y.

http://sourceforge.net/apps/mediawiki/c ... sions#Math has a description of Random():

"Random(N)

Returns a random number between 0 and N, not including N (eg. Random(3) gives one of 0, 1, 2). If N is a floating-point number, a random floating point number is generated up to but not including N, eg. Random(1.0) gives the range [0,1)"

Yes. You can use this expression:

ObjectName.Count

For example,

System: Compare

Value 1: Sprite.Count

Comparison: Equal to

Value 2: 0

Hmm, well, you could add a global variable, call it something like level. Then use:

System: Compare: Enemy.Count equals 0

• Global: Add 1 to level
• Go to layout global('level')

and make sure the variable level is set properly at the start of the game (its initial value can be changed in the project view).

Hmm.. if you have your layouts named logically, Level 1, Level 2, Level 3, [...] Level 10, Level 11, etc., you could do this instead:

System: Compare: Enemy.Count equals 0

• Global: Add 1 to level
• Go to layout "Level " & global('level')

OR, instead, an alternative, hackish, probably unnecessarily complex way to do it, one I'd recommend against unless all else fails:

You could place an object named LevelInfo on each level, outside the visible play area, or just invisible.. with its own private string variable, NextLevel, and for a value use the name of the next layout, like Level 1's LevelInfo would have the value "Level 2". Then copy your LevelInfo object. Go to layout Level 2, and paste it, then change the variable value to "Level 3", etc.

Then you'd use: Go to layout LevelInfo.value('NextLevel')

There's surely a better way to do it than this last one, though.

It's also possible to set different layouts to use the same event sheet, without needing to use "include event sheet" on each.

Level design has been stumping me, more or less. It seems like it's been a problem for me for a long time in many games. I don't plan them out, making them up as I go along, then at some point I lose interest, unable to think of what else to add to them for some reason. It's like my imagination just quits on it, even though there should be plenty I could do.

I'll be watching this thread with interest. A shape for the way the level should flow sounds like a good idea.

Construct's very versatile, I'd say. Its platform movement can cooperate with behaviors you make through events: Sliding down slopes, double/air jumping, crawling in tunnels, swimming, wall/ceiling climbing, ladders, climbing on enemies a la Legacy of the Wizard.. And while I haven't tried them personally, it should also be possible to implement, through events, ground sliding, air dashing, and other Mega Man-ish features.

The platform movement behavior's pretty convenient to use, and you aren't really committing to anything by using it on an object.

To put it another way, in Construct the "Platform Movement" behavior is simply a behavior you apply to individual objects. Your player object (or preferably its bounding box sprite), enemies, whatever would work with such a movement style - being able to run and jump, and not go through "solid" objects.

Also, hypothetically, just for an example, if you wanted to rip out all the platform elements and turn it into an overhead view RPG game, there is nothing stopping you from doing it but the time required to do so. Choosing platform movement behavior doesn't set anything in stone, in other words.