Well... that depends...

It isn't so much about complex ai at this point, its about the need to abstract the complexity of the character handlers.

I'll lay it out as best I can.

In monogame with c# or in unity, you can create a framework of components that interact with each other with no performance concern. The framework that allows you to create a component based, dynamic set of character handlers in c# will involve very little overhead and running 1000 objects with that behavior with be nothing if more than a fraction of 1 percent of the cpu usage. But the same thing in c3 has tremendous overhead, without even considering adding the actual gameplay functionality and logic (like collision solving). You can already have a project running at 60-80% load with just an empty framework. As great as the event sheet/sol paradigm is, it is aweful for handing instance specific logic, when those instances must refer dynamically to other instances of unknown type. It also doesn't hadnle functions very well either. You end up with alot of ForEach Object loops, and pick another object by UID, loops. Each blank event in the event sheet has an overhead to simply iterate. Doing a forEach (1000 objects -> set variable) will basically have the overhead of processing 1000 events. While a pickAll (1000 objects -> set variable), will only have the overhead of processing one event, with an internal engine side loop to iterate the objects. The latter event is WAY faster than the former, but because we have no way of dynamically referencing other objects other than UID picking, you have to run for each loops whereever. You can create hierarchies, but if the dynamic reference is to external objects, again, you have to end up picking by uid. Sorry for the block, hopefully that all makes sense.

The only viable way I have found is to take as much of the framework and put it into behaviors. this way you can minimize the need to refer to uid compound objects and foreachloops. But, behaviors don't take to each other very well. Scirra made behaviors like Solid and Platformer "Cheat" by having an internal engine link between the two, that you can't create because you can't extend the engine. And, since behaviors can't be extended things can get tricky there as well.

Every Character has a number of required components. They need to know their physical state (on the ground, touching a wall, in the water, etc...), handle collisions and resolve physical overlaps, handle command inputs (move up, do thingA, etc).

The most complex character would be something like this:

State data: Up, down, left, right, surounding surfaceangles, water(full submerged, surface, ankledeep), edgeleft, edgeright, and a few others for testing passthrough.

Colliders: head, foot, sides, high sides, collection, hit, + a few

Each one of those colliders or state checks is going to require a collision check. From there, the most complicated characters with have 20+ input commands to track. Each of those needs to be buffered from frame to frame for allowing combos, etc...

Now comes the list of potential "Characterhandlers" (routines that control how the character moves). These are conditionally applied based on input/commands and the particular state of the character. these Handlers are basically treated as abilities, with their data being stored as modifiable stats (such as lateralAcceleration)

Ontop of that, each character has an inventory of abilities/items. With those abilities come stats that can be dynamically altered by other characters, weapons, etc...

If you make every entity a family that handles all of the above, you get 95% more features than any entity needs. A character doesn't need the stat "acceleration", if it never accelerates. It doesn't need a state check for bonking its head, if it never can bonk its head. And so on... If you put it all in one behavior, that one behavior is also overkill for 90% of objects- and also requires a large amount of back and forth with ACES to communicate effectively with other interacting behaviors.

The ai for all these guys is pretty dumb and basic. The issue is that a rocket, dumb as it is, is carrying fuel, is flammable, has a steering behavior with a homing ai, a number of stats such as armor, fuel capacity, etc... If the rocket was launched from a weapon that confers other abilities or stats. So a rocket, isn't always the same rocket in the game.

And the reason to have a 1000? Because... its like vampire survivor. Not like the game, just the fact that there are alot of baddies and bullets

I like bringing a project back from years ago and being able to get it working in the most recent version. I also like being able to run off of browsers.

yours

winkr7

That is often forgotten gold.

Also as a general thing, not compared to a gameengine but rather specifically adobe. The support is just peak. You post a bug, you'll get at least an answer even if the answer is no. Adobe on the other hand... lol.

Lol, there isn't enough time in the day to rant about everything adobe has done wrong in the last decade. Have had similar issues with tablets, lag, etc... every time you try to contact adobe... "did you reinstall adobe, and remove all other applications from the computer..." when literally every other drawing program just works out of the box or with minimal effort.

Freaking flipped the table, bought aseprite, Sai, rebelle, and affinity photo and designer, all permenent licenses for less than adobe costs in a few months. I still use adobe cs6 to avoid the nightmare of cc, No... every time I see a new piece of drawing software, I'm like oh cool. If only I didn't need a few other applications on the adobe pile of crap. Luckily, I have an license for work, otherwise I would try harder to find alternatives to animate and aftereffects and premier. :(

Scirra is 1000x better at customer service, bugs, and reliability compared to adobe. I keep thinnking I should seel my stocks, but somehow adobe keeps making money.

Absolutely, I assumed you meant single player. If you are planning for coop then it's not going to be an elegant option.

A shame too if you are really looking for performance. The difference between the group and a conditional as I understand it is (forgive me if I am wrong here), disabling the group means the code isn't run at all so it's less work by not having to run through the tree for the same result.

Well... it is single player at the moment... But enemies aren't any different than the player (they pick up gear, have abilities, and in some cases, the player can control them). So they all need the same abstract hook ins for control and handling. In the end, the underlying core behaviors (custom platformer/8direction) is applicable to most characters, even if they have some of it stripped out.

As far as the group goes, The performance of group checks wouldn't make a big deal at all. I use groups for game state, and other big "Only this or that" type behaviors, like UI, for ex.

The performance that negatively impacts my projects is usually always because a.) I want a 1000x , and b.) I need those x-objects to have dozens of functions calls, usually to vector math or other trig functions, and a variety of hookins for dynamic ability routing. Construct3 doesn't inline function calls, so a simple function to calculate the dot product will be 5x slower in a function call than if you just create an action for it. Functions with a single ACE and a few parameters have terrible performance/convenience tradeoffs, if you are going for volume. For dynamic routing, conditional trees are okay, but the larger the number of conditions, the more easily it is to justify dynamic callbacks and other routing patterns.

In the end, I have to end up making behaviors to contain alot of those simple functions. But once you get higher up the food chain, for example creating a platformer behavior that is modular, you can't extend existing behaviors and you either suffer creating behaviors that essentially duplicate function - or you have to find a way to abstract from within construct, which usually requires dynamic routing (ie, function calls).

imo, there isn't a good solution in c3 for creating abstract, scalable patterns. Not in projects that have heavy object counts. They do work perfectly fine in games that keep such patterns limited to a few dozen objects. This is totally doable.

But it always comes down to the stress test. I mean, I fit into that camp of people that gets annoyed if I have to do anything where you have to repeat yourself, but abstraction comes at a cost in c3.

As far as groups go... I think ( knowledge based on c2 circa 2015) that groups were the exact same as system condition evaluating a bool... likely one picked from a dictionary with key "groupName" and it still gets checked everytick. I might very well be wrong on that but I think that's what Ashley said.

Hi all.

For those who have used other engines, what do you like?

I have used unity for almost 9 years now. Ashley sometimes tells us not to compare construct features to AAA engine features, but the fact is, I have complained on Unity forums about all the things that construct does better.

The fact is, nobody over there usually listens at all. Fundamental engine breaking bugs go unaddressed for years while new features get added in other areas.

1. Construct imo, does a kickass job at addressing bugs and getting them fixed asap. Construct is stable in a way Unity has never been.

Outside of that, Scirra is very amiable to feedback that is within the scope of what they can feasibly do, and willing to explain why a suggestion won't work, from their perspective.

2. Construct has a kickass engine paradigm that makes hooking up global space logic a breeze. The SOL is sweet, and the general flow of creating event sheets is great and faster than creating scripts in unity. (Freaking assembly reloading times are an iterative workflow killer in unity).

2.a You make a tweak to your logic and relaunch the preview in seconds. Unity takes minutes sometimes to reload the assembly. It sucks.

3. Construct is Kickass fast at the basics. Importing a new sprite, adding a few variables, and getting it to work is faster in c3 than basically any other engine I have used. I can create a dozen objects in c3 in a fraction of the time I can in Unity.

4. Construct is Kickass at 2d. The rendering modes, the layers, everything. Unity has 2d mode, but remember how I complained about bugs going unaddressed for years. The best part of unity is the ease of extending it (especially the editor and the renderer). Without that (and the asset) market, Unity is pretty bad for 2d games. In recent years, they have added alot of 3rd party tools into their engine proper. I think if c3 could learn anything, it would be to have a better system for creating 3rd party editor side tools and encouraging their production.

Anyway, that's my short list. I think an honorable mention goes to the included behaviors, but honestly, I end up always tooling my own, but the simple ones like drag and drop, are icing on the cake. I had to make all those when I moved to unity back in the day.

Sounds like #7796 which is a bug in Chrome that is fixed for the next release, due out in a week or two.

Thank you Ashley , I got confused and was thinking that was for a different bug, then I forgot you had already said it was being solved. You are a rock star.

Thanks!

On your other post, I shared a bug report link that has these exact steps you wrote!

When you say C3 app, you mean in nwjs, or in Google Chrome?

AFAIK it happens on latest Chrome (also happened about half a year ago, again a Chrome issue), and will likely be fixed around 20th Feb according to what Ashley found. Can use Chrome Dev, or Firefox, for now.

Sorry, I think I must have missed it. Thanks! I've been requesting features that already exist, reporting bugs that have already been solved... and then forgetting I already did those things. ugh, I'd lose my head if it wasn't attached to me. I'm getting to be like that old person who complains about a problem that was solved 2 decades ago and keeps forgetting that it was solved. :(

AnD4D

There is nothing entitled about what you said. Being disappointed that a new feature doesn't fundamentally address what you hoped it would is not entitlement. Its a useful opinion

When I first heard flow charts, I got excited. I think they have a lot of potential, but in their current form they don't do anything for me that I can't more easily achieve using other methods.

After working with them, in their current state, they don't make data easier to work with, instead, they pollute your project with a billion string tokens to keep track. There isn't any reason the user should be doing this. Construct imo, already has a huge issue with not being able to define scope for anything, and this just heaps even more things for the user to have to organize and track.

1. If flowcharts are being intended for to be used as a solution to dialogue branches and not much else, I think they are okay, but the tedium of hooking them up and the amount of "boilerplate" ACES required to use seems odd.

2. I agree with much of what Overboy has said. Being able to use them to set up state machines or behavior trees would be ideal. Creating a seamless way for a flowchart to hook into logic, without having to jump around in a project is a must, though. The current method of connecting logic to the flowchart involves alot of repetitive work, and is error prone. Having a data only flowchart doesn't make sense, given the expectation that flowcharts have ALWAYS had logic boxes.

creating the logic IN the flowchart isn't nec needed though, but having a drop down list of available hooks that have been defined in the eventsheet would be nice. Anything to facilitate connecting the two.

But honestly... I would have WAY more use out of behavior trees and state machines. And flowcharts in construct make it harder to produce those logic structures than defining them in other ways.

Also... naming them flowcharts is wrong. Every flowchart ever does have have embedded logic. I can see why, from a marketing standpoint, so many people have been disappointed. They were expecting aflowchart, not a data tree. I heard flowchart and was like, OBOY, only to find out they are gui for limited json file creation.

Hey all,

The error: "Aw Snap, Something went wrong".

I made a post previously asking if others got this while working in the c3 app. It seems like crashes happen every so often, but they don't seem to have a reliable reason.

However, I found what I believe is a reproducible error. I get it in a completely blank project, every time.

1. Create a sprite.

2. Go to the event sheet and click to add a custom action.

3. Once an object is selected, in the custom Action dialogue give the action any name.

4. Without clicking anywhere else, or filling out any more fields hit "enter". (so type the name, then immediately hit enter.

I get an error, every single time I do this. If I use the mouse to click enter or do other things, I don't get the error. Even hitting enter from "description" or other fields doesn't throw the error.

Can someone confirm this? I am running windows10, using the standalone c3 editor.

What do you think about activating/deactivating groups? Not elegant in terms of number of events/lines but super simple and easy to maintain.

Got digger gear? Disable the normal duck movement group and enable the digger variant group.

Got the double jump? Enable that sub section of the jump folder that allows for it.. or for simplicity just disable the normal jump group and enable the double jump group.

Your character is any combination of enabled and disabled groups/behaviours this way.

I have no idea how this compares in terms of performance but I would imagine it would work fairly well.

I may be stupid here, so correct me if I am wrong, but groups don't work on a per instance basis. If a group is disabled, its disabled. In the end, the group functions as a simple conditional anyway, I believe, so it is basically the same cost as have a condition. I actually made my first platformer ever in c2 using such a method.

The biggest issues I face comes down to performance, so there is a real possibility that brute forcing all possible ability checks on every active character will be costly. At least, based on preliminary tests I did a few months ago