In defense of Construct 2

0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • 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.

  • For one in my opinion the built in pathfinding is made for an RTS type game, its especially bad for grid/board based games

    You can use pathfinding without the movement, and just get it to return a list of the nodes in the found path and implement your own movement or use for the path. You don't have to use its own movement. So doesn't that help it cover other kinds of games?

    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

    Behaviors are intended to help beginners get started quickly, and also provide shortcuts. For example the bullet behavior is pretty convenient if all you need is something moving in a straight line, saving you having to set up the events to move it with x += cos(angle) * speed; y += sin(angle) * speed etc. They're not intended to cover every possible genre of game - how would that even be possible through the behavior system? Only events can implement custom logic, or custom Javascript coding with the SDK. I think hoping for behaviors to cut it for everything is hoping for too much from them.

    Modularity is definitely an interesting area to explore in future, but I can tell you the platform behavior has some very complex and subtle logic to cover a couple of year's of edge cases reported via bugs. 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. Then the question is which do you choose, why, and can you change your mind later?

  • 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 I'd like to expand our options.

  • [quote:35hx5wka]Modularity is definitely an interesting area to explore in future

    this worries me a bit,

  • 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

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

  • Let me start by saying it is not my intention to be antagonistic, quite the opposite. I personally find the event system to be liberating and am all for helping others see the light. I would much rather Ashley and co focused on adding features that can't be achieved with events rather than spending additional time working on tweaking the built in behaviours (especially as they have been designed for general purposes).

    Ethan, what troubles are you having making TBS games just relying on events alone? I wouldn't say that the event system doesn't lend itself to that style of game.

    Tokinsom, what genres of 2d games are missing that couldn't be handled with events? Also who is frowning upon event based logic replacing behaviors?

    What I see happening is that people who go down this road will sometimes run into problems and are just not willing to share the project to be debugged (probably because of the time it took to put it together in the first place OR because they would rather it not be open to prevent others making similar games).

    Modularity is great and all but do we really need to wait for C3 to create event based behaviours to share with others? I am willing to help if others want to get in on a community effort.

  • GenkiGenga - The problem with trying to create reusable events now is that it takes a long time. Not to make the events, but to get them copied into a new project. I use stub projects where whne I get a particular framework where I want it, I then strip it of its specifics and save it as a template. But inevitably I find I am always reinventing the event sheet wheel in multiple projects. and that gets annoying.

    Similarly , I am not trying to be antagonistic, but If you haven't found the behaviors to be lacking, then you haven't pushed them very far. Or, you have pushed them with the greatest flexibility of expectations. I know I don't compromise, and being able to do so is important when you use other peoples code. However One post up from yours, I make the claim that you can't make mario with the platform and solid behaviors.

    I don't want more behaviors though. I want better ways of making my own. And I would very much poo poo using events to recreate marios platform behavior and collision resolution. It's more efficient to code it in light of events being very much tied to the original project.

    On a final note: I love the events. I love the visual nature of it, but in the oop department, extensibility department, and scalability department., it is hard to beat code, atm

  • Modularity has been in the todo list forever, but it's a buzzword that needs to be defined.

    As in "htf is it going to allow me to make plugs?"

  • Ruskul Sorry I didn't mean to avoid your points I just started to write the post before you added that in .

    I get what you are saying but in my opinion your problem relates to how you think about game design in general. I'm not saying you are doing something wrong (you seem very knowledgeable), I am just saying where you have trained yourself to think in code - I think in events instead.

    It is true that you can't make a perfect replication of mario with platformer + solid behaviour alone, the behaviours are lacking if you think about it that way. My point is though that the behaviours haven't been designed to allow you to make mario with only the platformer and solid behaviour. If they were then we would be stepping into cookie cutter land. When I build games I use the behaviours if they will save me time but I go into it knowing the limits (and when I reach them I just fill the gap with custom events).

    I agree that it's not always a simple process of porting over existing code to a new project (I mean it's not hard, it is just tedious at times). This could be lessened by being consistent with template object names (for example the player object is always called player etc).

    I think we are comparing apples and oranges, for me the event system beats traditional coding in terms of speed and ease of use. Again, just my opinion but I think once you are more familiar with the event system you would feel the same.

    Maybe Mario would be a good start for a community template.

  • The physics and platform plugins are woefully limited - yet there is no way of achieving the effects of these plugins by using the event system. This forces a dedicated user to have to accept frustrating limitations... there is no way to do raycasting, slope normal, kinematic, solid collision filtering and so on. All have been mentioned many times, and I am aware that this is the slippery slope into another c2 deficiencies thread. But these plugins are awash with missing attributes that, if c3 doesn't contain the fixes, then I am not sure who will genuinely use c2/c3 for anything other than prototyping. I would love to see a community Mario template - the reason why there isn't one is because it's not possible to do without serious 3rd party plugin work. As said by Ruskul, then you're into using c2 in the same way you would use Unity - so why be here? No kinematic bodies.... really?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Colludium What is it about Mario that you think is impossible to achieve with events?

    The phsyics behaviour isn't great (this is especially true if you are making a mobile game) because it is taxing on the system and very easy to misuse. I try and steer clear of it to be honest. But to say you couldn't create your own physics with events is not true.

    Normally I stay away from these type of topics because I know that people come into it with their own frustrations and I am not trying to make enemies. Please know that I only have good intentions in calling you out.

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

  • Thanks, in advance, for any info.

    Very interesting thanks for sharing.

    คาสิโนออนไลน์ ในรูปแบบใหม่ล่าสุดจาก ปอยเปต คาสิโน รีสอร์ท ได้ที่นี่

  • Tokinsom - some of those issues you list sound like they are probably deliberate alterations made due to bug reports. It's hard to see how we can win here: either we leave one user with a bug which we don't fix, which will frustrate them (and probably end up with us being accused of never fixing bugs), or we fix the bug and in other circumstances it materialises as a "quirk", which frustrates someone else (and ends up with us being accused of leaving in quirks forever). I guess you are right: the only way to make something that works for everyone is to provide a simple base engine for users to modify themselves. However this would mean a radical re-think of the entire way behaviors work, and is not something that we can just patch in to the next beta release. I'm definitely interested in addressing this in the long-term with C3. However I can tell you getting a bulletproof movement with no difficult edge cases is extremely difficult even as an experienced developer working with a traditional programming language. Implementing movements in events and leaving it for the user to fix to their purposes probably just shifts this difficult problem to the user, which may be suitable for expert users, but probably is not much help to the majority of less-than-expert users.

    However (mostly aimed at other posts in this thread) I don't think it's fair to say that the behaviors are useless if they don't serve your purposes or they are missing your favourite feature request - as far as I can tell, they are very useful for the majority of users, and we frequently hear positive feedback about how effective the behaviors are for many users.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)