Ashley's Forum Posts

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

  • Doesn't look like a file got attached...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I use Cubase LE for audio (when I need an audio editor, which isn't that often). It's very good, getting close to professional audio standards. I can see how it would be tricky to learn as a beginner though.

  • Thanks for the good bug report, the debugger thing is fixed in the next build