I know exactly what Tokinsom is talking about. I've brought it up in the past.

Here's an article I wrote a while back about default (or "prototype" objects) in the Construct 2 wiki.

http://construct2.wikispaces.com/Default+Instances

I've pasted the relevant parts of it here:

[quote:kvqonf8e]

Construct requires a minimum of one instance of every object type in a project to exist in a layout, with noted exceptions such as Input plugins, Function, Arrays, Dictionary, etc. Each first instance of an object type in Construct determines the default properties for new instances subsequently created either *through the editor* or *through the "Create Object / Spawn Object" action* at runtime.

Since there are many situations where an object might not exist until later in the game (created "on demand" through event code), most developers create a blank "Asset Layout" where each prototype object can be placed. When a project is first opened by Construct, it stores a "prototype instance" of each Object Type in memory. Unless a developer is familiar with the internal operation of how these prototype instances are stored, confusion can result.

From extensive testing, the prototype instance of some object (A) is simply the first XML element of the instance on the first layer (bottom-most layer in the Layout editor) of the first layout (ordered from top to bottom in the Project Window Layout List -- this matches the layout order in the CAPROJ xml file) encountered that contains an instance of the object parsed by Construct.

Until a project is reloaded, the prototype instance assignment will not change. Even if you delete the prototype instance, Construct will continue to base new *EDITOR* instances on its properties/values. However, Construct on preview will always reparse layouts for the first prototype instances of all object types, which affects creation/spawn at run-time.

mindfaQ

It's a wiki, so the idea is that as new information becomes available as Construct continues to mature, the community helps to edit/update old articles. Tagging is a built-in feature as well.

—

DatapawWolf

Sorry about that. I've been out of the country for a while and didn't realize the subscription system wasn't set to autobill from my account. It should be back up now.

I wouldn't get so hung up on meaningless labels. Programmer also sounds a bit odd since typically when somebody says, "I'm a programmer" it is in response to the question, "What do you do for a living?". Additionally, if you're talking with people in the tech industry, 99% of the time, the follow-up question is going to be, "What language do you use?".

This may help answer your question (HINT: it's on the welcome page of Scirra)

Perhaps "Game developer" is a more suitable title.

It really depends on what you're trying to get out of the system. If your ultimate goal is to "learn how to program" then you should probably study a more traditional industry standard like Javascript, C++, C#, etc. If your ultimate goal is just to make great games, then yeah, stick with Construct.

At the end of the day, it's the final result that matters. Game reviewers don't usually take the programming language into account when reviewing a game.

Nesteris

If you're interested in more information about it, I posted an article about how the FPS of a Construct project is tied to the refresh rate on the C2 wiki:

Delta Time and Refresh Rate

Collisions and Framerate

I actually ended up figuring out how it worked on accident as a result of playing with the preview.js file a ways back.

Here's part of the article:

[quote:rsozbn15]

The underlying Construct 2 engine uses something called "requestAnimationFrame" (underlying v-sync related browser timing) to attempt to peg the game tick at approximately 60 times per second, however, it usually matches the display refresh rate of the browser/computer which is nearly always 60hz except in the case of some new 120hz monitors. This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate.

Construct makes use of delta-time in order to be frame-rate independent. A frame-rate independent game tries to ensure that a game behaves in the same way regardless of the actual FPS. In some older games, the movement of sprites in the game was proportional to the frame rate. This meant that if you tried to play the game on a modern system today, the high frame rate would cause everything in the game world to move extremely fast making the game virtually unplayable.

In most cases, this means that delta-time returns the actual time in seconds from the last game tick. However, if the frame-rate dips below 10 fps, Construct will cap the returned value of DT at 0.1 seconds. When this happens, the game will physically appear to slow down. As outlined in the article on delta time, Construct synchronizes the logic and rendering loop through something called requestAnimationFrame which is used internally by the browser to peg the FPS to the refresh rate of the local monitor, typically 60hz so 60fps.

shinkan

Thanks! I plan to add more workarounds in the future.

glerikud

That's a good idea! http://c2wiki.org now redirects to the Construct Wiki!

Hey Chupup,

I'm surprised that setting the animation speed and animation in the same action block doesn't always work:

-- Set Animation "Idle"

-- Set Animation Speed X Value

Do you mean it doesn't work the first time through the animation (assuming looping), or it doesn't set the speed at all?

Your idea about changing animations, setting the speed and then restoring the original animation might work, but I think you'll also have to save off the original frame of animation so you can restore the correct frame as well.

Unfortunately, I have a feeling that when you restore the original animation, Construct will reset the amount of time that has elapsed for that specific animation frame. I'm referring to the speed of an individual frame of animation which is settable in the Animation Editor.

Thanks guys!

I've added a new article to the wiki:

Collisions with respect to framerate

Cryptwalker

I think I played that game a LONG LONG time ago at a friend's house on his dreamcast. Seems like there were a dozen or so really great arcade shmups that were only ported to the Dreamcast. Wish they'd re-release some of them on Steam or even XBLA.

Yes a future time can be set by: time + X seconds

It also should be time >= futureTime.

You can also just attach a Timer behavior to the Sprite:

https://www.scirra.com/manual/167/timer

I've got the permissions set up such that anyone can edit pages. For some reason, anonymous users cannot create new pages but I'm working on getting that fixed.

In the meantime, I've created a generic user to represent the Scirra community that people can use if they want to create new pages or start discussions.

User: constructuser

Password: constructuser

[attachment=0:1fvwxmax][/attachment:1fvwxmax]