In defense of Construct 2

Discussion and feedback on Construct 2

Post » Mon Jun 15, 2015 2:11 am

Ashley wrote:
ruskul wrote: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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,163

Post » Mon Jun 15, 2015 2:23 am

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.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon Jun 15, 2015 2:52 am

@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
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,163

Post » Mon Jun 15, 2015 3:37 am

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?"
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Mon Jun 15, 2015 3:38 am

@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.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon Jun 15, 2015 3:55 am

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?
A big fan of JavaScript.
B
76
S
20
G
74
Posts: 2,255
Reputation: 46,484

Post » Mon Jun 15, 2015 4:17 am

@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.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon Jun 15, 2015 5:04 am

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.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Mon Jun 15, 2015 9:28 am

Message: casnova is not yet permitted to post plain text URLS (300 rep required). 1 URLS removed. Why?
Thanks, in advance, for any info.
Very interesting thanks for sharing. :D :D









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

Post » Mon Jun 15, 2015 10:27 am

@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.
Scirra Founder
B
400
S
236
G
89
Posts: 24,546
Reputation: 195,471

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests