Ashley

It seems that C3 is still mostly unusable with source control on account of the .c3proj file and UID shuffling.

The .c3proj

If more than 1 collaborator adds a new behavior, effect, object type, family, layout, event sheet, script, or timeline, it modifies the .c3proj and creates a conflict. This might be the case with removing and renaming as well. This can be resolved by hand, but is obviously very error prone and can easily corrupt the project.

As it stands, all users except one must basically only touch existing contents.

I'm not the expert here but one potential solution that comes to mind is replacing the .c3proj entries with individual files and populating the project bar etc. from those instead (basic project properties can remain as one file). Each object already has its own .json file anyway so why not just extend this format to the aforementioned assets instead of making lists inside the .c3proj?

UID Shuffling

Furthermore, UID shuffling can be detrimental and risks breaking many things in your game or outright corrupting it. UIDs are the only auto-assigned reference that instances get which are identical in both the editor and runtime. They are often used extensively to manage objects in save data or managing connections between objects in and across layouts. The only alternative is manually-assigned instance variables but...imagine a Mario level with hundreds of coins per level or a Metroidvania with hundreds of items scattered throughout the world, each one given a manually assigned variable to prevent from respawning or what have you. That is just insane, but there are C3 users who are doing just that to prevent their objects' only real IDs from being scrambled.

Again, not the expert here, but sequential UIDs might not be the safest approach. I believe skymen had proposed some sort of UUID but he would need to elaborate on that.

Taking a quote from your GitHub tutorial: "Source control is widely regarded as mandatory for any kind of professional development." I strongly agree with this sentiment but as it stands even small teams cannot use C3 together with confidence. I see that improvements have been made over C2, we aren't quite there yet. If Construct 3 is to be viewed as professional software, especially with paid tiers and increasing prices, then its compatibility with source control needs to be locked in. Thank you for reading and I hope you give these issues your consideration.

This is a perfectly valid request undeserving of the sarcasm and useless snarky responses.

"Simulate Jump" only works if the object is on the floor, and the built-in double jump feature is silly and shouldn't be used for coyote time anyway.

Instead "Simulate Jump" should just execute when it's called, allowing any amount of proper mid-air jumps and/or coyote time jumps determined by instance variables. If the player only wants "Simulate Jump" to work on the floor then they can pair it with the "Is On Floor" condition instead of it checking for them. It's not rocket science.

Also, not only does setting the y vector to a negative value not give you jump sustain, but it doesn't trigger "On Jump" either. Seems the only ways to trigger "On Jump" are by using "Simulate Jump" when on the ground, or by executing a built-in double jump...so, y'know, there's that.

As I've mentioned in the earlier posts, "Set Canvas Size" does not affect internal resolution as you are suggesting it does - it merely changes the external resolution but without changing the window size.

Please take a look at this .gif: media.giphy.com/media/A2OHsceP7gBTRADQvm/giphy.gif

Or the .c3p itself here: dropbox.com/s/mbe5ma4s677pt0c/Internal%20Resolution%20Test.c3p

This is what happens when setting the canvas size to 200%, 300%, etc.

I get the exact same results regardless of fullscreen quality mode or any other project properties / display modes.

If it is supposed to work how you are suggesting then maybe this is a bug?

I think there is some confusion over the terminology here. I'm not talking about window size / canvas size / external resolution, which is all "Set Canvas Size" affects. I'm talking about internal resolution or what is maybe more commonly known as resolution scale, which pertains to rendering quality. It is, admittedly, kind of hard to describe because it's implemented differently in various games and engines. C3 already has it, my only issue is that I have no control over it.

Please take a look at the images below.

These are from a C3 project with a 320x180 viewport, in fullscreen, on a 2560x1440 display.

With low quality fullscreen, the internal resolution stays at 320x180 (100% resolution scale). This results in blurry text and chunky pixels on the rotated object.

However, with high quality fullscreen the internal resolution is automatically changed to the display's 2560x1440 (800% resolution scale), resulting in ultra crisp text and smoothed-out pixels on the rotated object.

This is the desired result, but I don't need the internal resolution or "quality" to be quite so high because it can become taxing on the GPU. I would like to limit the internal resolution to something lower like 1280x720 (400% resolution scale), while keeping the external resolution at 2560x1440. This way I get slightly crisper text and smoother movements / rotations, but not quite as much as I would with the full-on 2560x1440 internal resolution. In exchange I get better performance.

You might be thinking "Well, a 340x180 game should not be using high quality fullscreen anyway" but that is not always true. Many low-res pixel art games these days opt for higher internal resolutions or "high quality fullscreen" because it makes movements & scrolling smoother, and allows them to use text instead of spritefonts. 380x140 was just for the example images anyway, as it makes the difference in fullscreen quality modes very apparent.

Hopefully this explains the issue well enough. I know I'm not the best at it. I can try to find other references or examples if needed.