We seem to be getting onto a number of different topics here :T

NotionGames I would argue that a game like Ubi actually is perfect for the platform behavior. It's incredibly simple in terms of platforming and uses a large resolution which hides or nullifies the issues and inaccuracies I mentioned earlier. Now go make perfectly accurate and bug-free Super Metroid engine and tell me the platform behavior is ideal ^^;

I think it's more like...leave behaviors alone and give us more options to make what we need when we need it, using events. What Newt said is actually how Stencyl works lol.

Not sure Mario's the best example here...C2's platform behavior is fairly capable of that. Thing is, even if the platform behavior is suitable for your game, you're still going to have to put up with all of this:

-There are occasionally gaps between the platform object and walls

-Can't fit into space equal in width or height of the object

-Can't fall into small gaps in the wall or floor, even at slow speeds

-Can't be pushed by solids without shaking or being propelled upwards

-"Pops" upwards when jumping around edges

-Jump height varies with framerate

-Sometimes clips edges of platforms without triggering "is on floor"

-Gets teleported to the top of jump-thrus when ~16 pixels from the top and moving horizontally

-Has no ceiling or wall slope detection

-Can't disable certain components if not needed

-Can't retrieve certain properties

-Can't toggle collisions with certain objects

-Can't be modified to work like the platform engines in, say, Sonic.

-GAME BREAKING bug where behavior gets stuck in-between falling and landing. This has been reported numerous times. It locks your player to the ground and you cannot jump.

and there's no raycasting and point collisions and all that jazz for, say, perfect wall-tracing and detecting slopes...but that's another topic I suppose.

...Anyway, all that's just off the top of my head. I've played around with "beginner" platform engines in MMF2 and GM that don't have any of these issues. And you should keep in mind the platform behavior has been around for like 4 years now...if it's based on CC's then that's more like 7 years. Similar lists can be made for just about all the behaviors.

I think one of the risks of event-based behaviors is that it's actually pretty difficult to write a flexible, general purpose movement without just fragmenting it in to a bunch of entirely different behaviors.

But that's exactly the point! You may have heard of GM's "Grandma Platformer Engine". This one platformer engine, made by a single GM user, is literally in hundreds if not thousands of GM games - everyone starts with it and adds/removes/tweaks as needed to perfectly fit their games. Since its completely open to the community, everyone is familiar with it and can work together to do anything imaginable, including debugging. And if it simply doesn't work for someone's game, they can write their own from scratch using what they learned from other platform engines. Paired with proper inheritance and modularity this makes C2's behaviors completely obsolete! C2's behaviors are totally closed off and we rely on a single person to fix and modify everything. They try to be one-size-fits-all which ultimately leads to an extremely convoluted and buggy mess incapable of more unique and complex movements such as Sonic's or whatever.

I'm not saying behaviors should be removed entirely - we both agree they're great for prototyping, beginners, and simple stuff that shouldn't need a bunch of code. The problem is that everyone here sees them as the only option, and what choice do they have if event-based behaviors are entirely nonexistent and even frowned upon due to the misconception that the existing ones can do everything they need, flawlessly?

The only question is who's capable and willing to start a series of event-based behaviors like this. Maybe after C3 is out I can team up with a few people and give it a shot. Or you can remove the "custom behavior" and provide event-based templates of sorts ^^; Eh, we'll see. All I know is C2's built-in behaviors have fallen short for all of my games, as simple as they appear to be...so I'd like to expand our options.

We've always designed C2 to be a general-purpose game engine and avoided any "cookie cutter game" type features where you're forced in to one style of gameplay. The built-in behaviors are all designed to be customisable and flexible for different purposes, at least to some extent, and if they don't work for you there's always the option of custom logic via events.

Yeah I'm just gonna say it: The behaviors are one of the banes of C2's existence. They are wonky and buggy and after years of work just don't cut it, even for simple retro platformers or zelda-likes. Great for prototyping and newbies but that's it. We need people coding their own behaviors with events. Not only would they be truly customizable this way, but far more stable and feature-rich as they can be shared, improved, and tested by the community as a whole. They'd make better programmers too, in the long run. The problem is literally everyone using C2 relies on behaviors and no one even talks about event-based ones, so if that's the direction you want to take, you're screwed. I often find myself on MMF2 and GM forums for this sort of thing, but they provide more of the necessary features than C2 does.

I'd go so far as to say this is one of the main reasons there are so few genres of C2 games. "Oh there isn't a behavior for that so eh I think I'll make a platformer or something". That and single-purpose object types, extremely limited family/inheritance, no modularity, and so on...but all of that's been discussed for C3 already.

This has been requested before but I can't find the thread and forgot if Ashley commented. Anyway, it would be nice if we could have another type of "Trigger Once" that plays nicely with multiple instances. I often find myself with situations like this:

+Enemy is Active (bool)

+Trigger once

-Do a thing

or something like

+Enemy.TimerVar > 5

+Trigger Once

-Do a thing

But it only works for one instance and no placement of "for each" helps here. You have to make another var and do this:

+Enemy is Active (bool)

+Enemy.var = 0

-Do a thing

-Set Enemy.var to 1

Looks like no big deal but when you use it for AI and such it gets really annoying with all the extra vars and conditions.

The Scroll effect doesn't work on export. Only tested on NW.js...The image moves but does not repeat.

edit: aaaand it looks like Somebody has jumped ship. Awesome.

Was snooping around temp files in appdata\local\mygame and noticed that there are thousands of 1-150kb files being created in \cache each time I preview. One file per image frame, it seems. That...doesn't sound good...? On my SSD too...great.

I believe they're somewhere in \appdata\local\yourGame\....derp? There's a local storage folder if that's what you mean. As for C2's built-in save/load stuff I'm not sure. You probably shouldn't be using that for actual game save data anyway O-o it's more of a debugging thing far as I'm concerned.

Contruct was made to be fast and easy to make games for those who can't or won't code. Unfortunately, much of the way contruct operates makes assumptions about what the game dev needs. I find those assumptions to be uninspiring and somewhat limiting. Based on a number of conversations with ashley, I feel construct is developed with the lowest common denominator in mind. And for something that is supposed to be easy for all, that makes sense. But it makes it hard to make unique, innovative games in the best of circumstances /:

Uuuugh, this a million times. This type of game engine needs to start at the top and work its way down, like SuperPowers is. Otherwise you're only setting limitations and restraints for the future. /offtopic

Eh. Unity is astronomically more powerful than Construct will ever be. Thing is, when people say it's great for hobbyists/indies, they still mean ones with extensive histories with coding and game development.

My only gripe with it is the workflow..at least for 2D/retro games. It's absolutely ridiculous how much work and knowledge of the engine it takes just to create, say, an animated sprite character, or a working tilemap system, or custom platform behaviors/controllers. Even if you know what you're doing, you'll spend 10x longer doing it in Unity than C2.

But yeah...if C3 had Unity's exporting capabilities, it'd probably wipe everything else off the market. Shame.

Nope. Would be nice though. All the defaults are ridiculously high for the type of games I work on.