cacotigon's Forum Posts

  • 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.

  • You do not have permission to view this post

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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]

  • Here's a very simple way to do it:

    [attachment=0:n19dxpk1][/attachment:n19dxpk1]

    SpawnFamily is the family of objects that are being randomly placed at the fixed position objects which are part of the Fixed Family.

    Capx attached.

    [attachment=1:n19dxpk1][/attachment:n19dxpk1]

  • The Construct 2 Wiki is up! Right now, we've got about 30 articles up on the wiki ranging from individual behaviors such as bullet, to collision detection, to timing, and everything in between!

    http://construct2.wikispaces.com

    Why does Construct 2 need a wiki?

    • With the team at Scirra hard at work on both maintaining Construct 2 and also developing Construct 3, it's up to the community to pool their knowledge together.
    • Much of the information currently on the wiki wouldn't really be suitable as tutorials (which are really more like "how-to" guides)
    • The forums are not a substitute for a well-maintained wiki. You can only sticky so many threads before it starts to get overwhelming. Additionally, as Construct is developed, older informative threads on the forums may no longer be applicable.
    • The wiki can act as a complimentary reference to the existing manual.

    Wikis are easy to maintain, update, and can grow as Construct continues to grow. Having a community-centric wiki for Construct 2 that is constantly being updated is a win for everybody.

    I'll be updating this thread from time to time to post updates and articles. I chose to host the wiki on WikiSpaces rather than something like Wikia because I wanted the wiki to be ad-free.

  • Generally speaking: Explore. Don't be afraid to get into the nitty-gritty details of Construct. That's the power of having a Javascript-based game engine, you can tinker to your heart's content. Take a look at the JS files in the exporter for plugins and behaviors. You can learn a lot of stuff that you wouldn't find in the manuals, and a lot of the code is well-commented.