Do you get any errors or whatever?

So, it seems, if you change the properties of a behavior after creating a file that saved those properties, construct doesn't know what to do with the save data.

For example, If I create a new behavior and I leave in the this.myproperty that comes with the same behavior and then take it out later, the save file has a place for that property. When trying to load it it doesn't know how to interpret it.

I think.

I should think if it loaded an unknown property it should discard it at the request of the user. Idk... I havn't tried editing the xml file to correct yet, mostly becuase I am lazy and found it a good opportunity to restructure and rebuild those projects anyway

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

>

Can you elaborate on what those things are? 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.

Tokinsom already got to most of what I would say.

The prebuilt behaviors are great for speed and prototyping. But they really aren't that general purpose though. You can't make a mario game with the platformer and solid behavior. It is impossible... unless the platformer behavior is only for the goomba . You can make an approximation, but specifically you have made a construct 2 platformer game, not mario. At any level of analysis this is painfully obvious. This is rooted in the way the behavior handles and resolves collisions. If you want a custom movement option, the custom movement behavior still only lends itself so far before the limits of the system become obvious. You can only make specific kinds of custom behaviors with it.

Those behaviors are non flexible and only as general purpose as the creator could envision them being used for (And I would never expect you to be able to envision every use case). But at a core level, I can't edit the way they work because they have been tied to the c2 black box. The assumption made in the behaviors is that they are good enough. You don't need to do any low level work, and anything can be achieved as is. But that's wrong. Using the behaviors... You can't create parallel worlds like that one game where you can jump to the background. You can't create n+ because you can't get surface normals and projections. You can't create mario because it uses an entirely different way of detecting and resolving collisions. you can't create sonic for much the same reason as mario. You can't create dustforce because you need raycasting and collision normals. The list goes on. You could make these games using events but that would be a royal pain in the ass in the event sheet (I know, I recreated tile based collision detection with 4 resolution types and 12 different slope angles as well as halftiles.... just for fun and tied it to behaviors that ran point based collision resolution). But since I can't save the events as a more abstract behavior, it really is a waste of time, and the lack of true OOP makes event scripting something like that even harder. And it's less efficient. So, the end result is that I create behaviors, and plugins... that need to talk to each other. You never designed behaviors and plugins to have to talk to each other and told us not to make them like that, but even the way you use solid and platform and platformer is breaking your own rules... you just are able to do it better because you can integrate it with the engine, which the rest of us can't. There are no solid groups for collision filtering, push out nearest doesn't work as well as it should, there are no projections or contact points provided, there is no end collision and so on. Solid collision resolutions also have some built in constants (why aren't those exposed as properties?)...

Does this all make sense? And Ive only touched on platformer stuffs... There are many of the other behaviors yet to talk about. I have never outright said it but, physics sucks in construct. It isn't even adequate. Not only that, there are not but a few people using construct capable of changing what physics can offer. Unless you are making a very basic physics game, physics is worthless. But that's my whole point! You can't make anything beyond simple basic things with the behaviors reasonably.

So, in the end I code... usually in an environment tailored to it, because that makes the most sense. The end path of construct as I see it is coding, but it isn't as easy to get into coding for construct as say, unity. Which means ultimately, Unity actually is easier

Don't get me wrong, I like construct. I would still buy it again. But it is a prototyping tool for me and an instrument to teach/introduce kids to programing. I stick with it because I am visual and it is easy to see and interprete events for me. Once I got my own library of plugins and behaviors made, things can be swell in construct.

(btw) every time I write a long post like this construct logs me out and doesn't save it... super annoying. I have to copy my response every so often to ovoid losing my work.

Ethan - it makes sense in a way. The further one tries to go down a one path fits all super easy mode, the more you get sloppy lose fitting results or have to squeeze something in a way it wasn't intended to be squeezed. The focus on ease of use at the exclusion of features that would benefit the "advanced" crowd seems a bit myopic. Of course, in the end, the amount of work to actually write a plugin and hook it up to construct depends on how many ACEs you need available to construct (which is easier than codding for mmf so I hear). What makes it hard is the fact that getting objects to interact is much easier in events than through behaviors (meaning you usually need alot of ACEs). The fact that Ashley actually integrated attribute behaviors (like solid and such) into the core engine demonstrates there needs to be a better interface for getting plugins/behaviors interacting.... but I'm getting a bit onto another subject here lol

Hello,

For whatever reason construct 2 won't open my save files. I never have had this problem before. I am of course using some custom behaviors, and I found the one responsible, but I can't figure out why it causes this. It has made it impossible to open my projects. I can create a new file, add the behavior, and no matter what I do it can't be opened the next time I load it.

I have scoured the behavior for anything out of place, but why should a behavior affect a c2 save file? Any help would be appreciated.

Dito on the above post. But I would add that It takes alot longer to get comfy with unity, but it is more powerful. by a long shot. And to be honest it is more flexible too, but you have to know how to code. You have to understand that what makes construct "easier" is that some of the things needed in a 2d game are already taken care of. But if you are in the habit of writing all your own plugins and behaviors anyway... unity is far better, and is much more extensable than construct. 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 /:

My main project is in unity, my prototypes are in construct.

Kyatric - It stopped crashing after the first day of download. I just wanted to see if others were having problems and if there were known issues with the release.

bladedpenguin - I think we are of similar dispositions then. I remember at one point being smitten with constructs speed. I was blazing through prototypes. Then when the time came to actually fix bugs, polish, and begin the actual game... I quickly realized, if you want it your way, there is no substitute for coding it yourself. One year ago, I thought I was a few months from release for a wii-u game... ... ... Well, nothing like telling people your almost done and then finally admitting to yourself that you've barely begun

I like coding though... It just gets old after programing for a month straight on frame work and other stuff you can't readily see the progress in. Prototypes are fun to make. The actual game... sigh...

Ashley , well , that all makes sense. In a way, it's cool that it is uniquely a construct 2 problem, it makes you a pioneer (:

I want to compile a list of all the forum topics you have entered and given particularly good insight into why something is the way it is with construct. A lot of your posts are pretty much manual worthy, needing to be summed up in a question/answer format.

Just out of curiosity, is there going to be a c3 feature that allows us to make instance functions? Kind of how you would in programing when you make a class and have methods. It would be useful to have a bit more oop in construct, though sometimes, I realize a coding background can make me not see some obvious c2 unique solutions.

zenox98 - It is about that simple.... I open construct, I select open file, and poof, construct is no longer working. It closes it self quite quickly, no lag, or other program crashing problems. I reopen it and it works. It happened in quick succession on several files. I haven't had a problem since. I was also able to open those files with no problem right afterwards.

— - I fail to see why it would be any different than test overlap. As a matter of fact it should be faster to test if an object is overlapping a point than to test if an object overlapping another object. I think. I suppose it may depend on whats happening in the little black box for c2.

The irony here is that you can make a workaround by creating a "point" object. This is simply a sprite with a size of 0,0. It functions as expected when Is overlapping is used. >.>

Tokinsom - ya I think you nailed it, I have a solution that does that but it isn't as easy as I think it should be. It's awkward and still involves alot of work to set up a new character. Wrapping this up in a script and attaching it as a single behavior would be probably be better... but behaviors and plugins don't play nice with each other. You have to sit them down and make them play with each other. I really like the constuct way of solving the whole game engine and global events things... but man, the simple stuff gets to me. I like construct where I hate unity and I hate construct where I love unity. >.<

Colludium - I remember the problem more specifically.

Okay:

Lets say you create a new character. You create a PilotCharacter manager, from the family managers. It then needs to create pilot states, of the familiy states.

But here is the thing, you can't abstract any of this away. If you have generic code in the manager family to handle creating and setting up components, those components have to be an actual type. You can't create a family and send it a type to make from. This makes it impossible for a family to hook itself up with other families. It has to occur at the type level. Which means repeating tons of hookup code, for every character. You can put specific types into a container, so that when you get a pilotManager you get the pilotStates. But again, that automatic hookup means you can't get families to talk to each other generally. A manager needs to talk to states, so then you need uid referencers as part of the family. This sort of means you are replicating code that is already happening at the container level on the specific type.

In the end, families don't solve the inheritance issue. Which is the core of the problem. I can't simply say, this specific type needs to call a function at the family level....

So in the end, lots of code has to be repeated. OOP is meant to make code simple, and need to be only written once.