This Twitter thread from the developer of Celeste shows some of the things they implemented to help the player/make the controls feel better:

twitter.com/MaddyThorson/status/1238338574220546049

A talk on difficulty balancing from a developer of The Witcher:

gdcvault.com/play/1020846/Fun-or-Frustration-Game-Balance

I thought the else condition operates the same way, but with the downside of still having event block overhead unlike the conditional expression. This is interesting, thanks again for these experiments.

I could be wrong, somebody correct me if I am, but I think the ELSE condition still checks every instance (not only those that failed the prior condition).

To give credit, it was eleanorjmorel who showed me how much faster conditional expressions can be.

The only problem I see is that the browser just doesn't offer a viable monetization method. At least not in any way that would rely on being performant.

Windows Wrapper would most likely return equal results since it was done using Edge, but the wrapper is not a great option... yet.

Yes, I am more interested in desktop publishing, not browser or mobile, so the new Windows wrapper definitely perked my interest, but for me it needs some Steam integration first (at least achievements) to be a viable option.

1) I think part of it is because the GML scripting language is not typed, so even when it's compiled to C++ code, it probably has to do a lot of inefficient type checking/casting. And if I remember correctly, certain types of variable lookup can also be slow, which is why GameMaker people will often copy them into a local variable first. So it's not as fast as a C++ engine could be without a scripting language.

2)

a) Behaviours was simply assigning the Bullet and Wrap behaviours to the object. Wrap was set to wrap to viewport. In the create object event, the Bullet actions were used to set a random direction and velocity to the Bullet behaviour for that instance.

b) For the events, I deleted the behaviours from the object and I added two instance variables - sx and sy (speed x and speed y). Then in the event sheet - on create object I set sx and sy to random values. Each step I use actions to apply movement - i.e. set sprite x = x + sx*dt, set sprite y = y + sy*dt. Then there's a series of IF events to handle the wrapping:

if sprite x < 0 set sprite x to 800 (800 being viewport width)

if sprite x > 800 set sprite x to 0

if sprite y < 0 set sprite y to 450 (450 being viewport width)

if sprite y > 450 set sprite y to 0

c) Avoids all the if statements by putting it into a single conditional expression when applying movement to the object, i.e. each step:

action - set sprite x = x < 0 ? 800 : x > 800 ? 0 : x + sx*dt

action - set sprite y = y < 0 ? 450 : y > 450 ? 0 : y + sy*dt

These expressions allow you to 'short circuit' the evaluation, i.e. if the first part (x<0) is true then the rest of the checks will be skipped. This is what I wished the ELSE event would do...

Hope that makes sense...

I don't know about web audio to answer that sorry. Maybe if it can't process the HRTF fast enough it has a backlog of audio commands that it's still trying to process? But that's a completely wild guess...

Were you using the HRTF option? If so I wouldn't call this a bug per say...

HRTF is a very very computationally expensive method. Back in the day PCs required specialist hardware on separate audio cards to handle it. Some modern devices like the Microsoft Hololens still have dedicated hardware for it. Sadly great positional audio somewhat died out with dedicated audio hardware, if you ever played something like Thief 2 with the hardware support, it was amazing.

True HRTF is still relatively rare even in modern AAA games on PC/console, and often they'll only implement it for selected sounds, i.e. short sounds that are important for positional awareness, like foot steps, gun shots etc. I wouldn't think of using it on mobile. My guess is the crackling/popping is because the CPU cannot process the HRTF audio fast enough to fill the audio buffer - and this is why it's more noticeable on mobile than PC.

If you still want to use positional audio, the equal power option should be much cheaper to process. I believe there is an even more lightweight stereo panner node in web audio but not in Construct 3, that is something I would really like to see implemented to help mobile performance.

As to why the old iOS versions didn't display this issue, my guess is they only had limited web audio support, so maybe positional audio support was only recently added, i.e. on older iOS it probably detected it wasn't supported so reverted to normal audio.

I found plenty of information on upscaling, but not so much with downscaling. If I'm using a 4K viewport (3840 x 2160) and displaying fullscreen on 1080 monitor, how is the downscaling handled?

a) Is everything rendered at 100% to a 4K canvas and then downscaled together 50% to 1080?

b) Or are the objects individually downscaled to 50% and then rendered to a 1080 canvas?

Or some other way...

Hi all,

Mostly for a bit of fun, I have a few questions to ask you, my answers are included below and I would like to hear yours.

1) What's a small thing you appreciate about Construct 3?

You can download the manual as a PDF and easily print it. It's crazy to me how rare this is for game engines. Maybe I'm getting old, but I like to work with a paper reference in front of me, especially because I'm working on a single monitor.

2) What's a good thing in Construct 3 (or handy tip) that people might not know?

I just discovered this today - the 'Recreate initial objects' action. When I saw the name I thought ok I guess it could be useful. Today I realized it can load objects from different layouts with region and offset. That's huge... that's Spelunky type procedural level generation made simple.

3) If you could choose one thing from the Construct 3 suggestions list to have next - what would it be?

This was a really tough choice but I chose: construct3.ideas.aha.io/ideas/C3-I-1409

The ability to rotate timelines (I would also add scale timelines) - I feel the current implementation is good for platformers, SHMUPs etc. - but not as useful in games the involve rotated movement like a top down shooter.

Just to offer some thoughts, I would prefer save/load/delete scene graph actions, instead of a 'clone' action. To further elaborate, the downsides I see to a clone action are:

- The scene graph would have to exist in the layout at the time it is cloned.

- There would be no simple way to share the scene graph across layouts.

- The scene graph would be cloned with non-inherited transformations that have been applied to children after the scene graph was created, i.e. it would difficult if you wanted to re-create the scene graph in it's original state when it was first created.

I would like it if we could 'save' the scene graph data to JSON or memory in it's current state using a string based 'tag'. The scene graph data would be saved at the global level so it could still be accessed when switching layouts. In the editor we could also store this 'tag'. The 'load' action would take the 'tag' as an input to create a new copy from the scene graph data. Finally, for memory management, a 'delete' action to remove the scene graph data corresponding to the input 'tag' (not ones created in the editor).