Ashley's Forum Posts

  • They're really simple. They just repeat stuff.

    + On spacebar pressed

    + Repeat 5 times

    -> Add 1 to global variable 'test'

    When you press spacebar, 5 is added to 'test' (it adds 1 five times, instantly)

    + Start of layout

    + Repeat 100 times

    -> Create Star at random(640), random(480)

    Creates 100 randomly positioned stars on startup.

    There are some variations like For (loop over a range of numbers), For Each (repeat once for each instance of an object), and so on. You can read more in the Conditions article.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • See the Function Object.

  • Families show the private variables which all the objects in the family have in common. You can use the Family Manager to quickly add a variable to all the objects in the family.

  • I'm saying there's no point talking about whether loading levels from files or using the layout editor creates smaller files. As you say, the difference is negligable, so the more important things to worry about is if you want to spend the extra time writing a level editor, and so on.

  • You can also use families to generalise all your different kinds of bullet and projectiles, using private variables to set how much damage they cause, what kind of explosions/effects they create, etc.

  • The difference between using the layout editor and a level editor is going to total a few kilobytes in a game which is probably several megabytes. The question is not about the filesize of each - it's about development time, allowing the user to design their own levels, etc. - those are much much more important than whether your file size is 1% smaller.

  • Yeah, I think you'll have to use an external install creator program. I'm not sure how customisable the built in one is.

  • Yeah, there's a big difference, so I doubt you can use any shader editing programs. Construct has a lot of unique parameters and generally none of the matrices you'd use in 3D. Shaders are usually very short and fairly easy to write anyway - check out the sources to a few of them in the Effects directory to get a feel for it.

  • It comes up straight away as a system expression with description if you search the wiki

  • As long as menu operations don't make use of timedelta!

    You actually can use timedelta while paused - you can set it and set it back over a section of events, like:

    + Always

    -> Set timescale to 1

    -> Set Opacity to Opacity + 100 * TimeDelta

    -> Set timescale to 0

  • Bah, I keep forgetting. I made it with 0.98.6 which isn't out yet

    It should be out tomorrow or the day after though, so you can try again then... besides, it's basically:

    + Always

    -> Subtract TimeDelta from variable 'time'

    Round it off to display it and you have a uniquely decreasing counter

  • You should read that the CPU and GPU work at the same time so if the screen takes longer to render than the events take to process, the events have no impact on performance.

    As for making events run faster, generally just favour readability and whatever's easiest to maintain - you only need to optimise it once your game is running too slow. Before then, you cannot know if anything you are doing is making the slightest bit of difference.

    As for your other questions:

    • Some events are faster than others, but generally the difference is negligable - notable places people waste CPU time is nested 'For Each' loops, which with two nested levels with 1000 objects each, runs a million iterations every tick, etc. A single for each is usually fine though.
    • Instead of having a lot of separate triggers it's faster - and more readable IMO - to have a series of subevents under one trigger. Subevents can be used similarly in other places to make events only checked when another event is true as opposed to all the time.
    • Additional instances of objects cause more CPU load, because most conditions test all instances of an object. "Mouse is over X" has to iterate all instances of X for example, so the more X exist, the more processing there is to do. This generally only becomes noticable over an entire event sheet of events. You probably don't need to worry about memory load because rendering or CPU time will become a bottleneck sooner.

    In summary concentrate on making your game render quickly. 90% of the time the game is waiting for the screen to finish drawing rather than waiting for the events to finish processing before a tick is complete. Avoid intensive shader usage, and stick to PS 0.0 effects and plain old alpha-channeled sprites wherever possible. They're fast.

  • Yeah, TimeDelta does this fine.

  • PS: Setting timescale to zero is a good way to make a pause right?

    Yes, definitely!

  • It works fine, you just have to enable unbounded scrolling or make the layout area big enough for the screen to rotate.