In defense of Construct 2

Discussion and feedback on Construct 2

Post » Mon Jun 15, 2015 10:44 am

I don't really get this talk about all these behaviour limitations? If my project needs something and a behaviour can be used then I use it. If there is no behaviour that suits my needs I make my own logic with the event system. What is the problem?

If you need raycasting you can make your own with the event system. If the platform behaviour doesn't work for you, then make your own or tweak it.

People seems to think that you are limited to only use the behaviours for the whole game. I only use a few and mostly do my own with events and functions that can be reused. I also work in Unity and Unreal Engine and you can download behaviours there as well but just like in C2 they might not suit your project and you simply make your own. So stop thinking that behaviours is a limitation. It's just a tool you can use if they suit your needs.

I'm not saying that C2 doesn't have limitations. I'm just saying that behaviours isn't a limitation.

Saying that you can't make a Super Mario clone in C2 is not true. It is actually pretty easy to make with behaviours and custom events and if you know what you're doing you would be able to make an exact clone of mario in no time compared to other engines like unity.

I think this remake of Donkey Kong by @Ribis in C2 is alot more complicated than a simple mario game and it shows what you can do by combining behaviours with custom events.
https://www.youtube.com/watch?v=WdKo5OZrHhE

So people who are saying that you can't make unique games with C2 are just not experienced enough. If you think outside the box and stop relying on behaviours and use the power of the event system instead you can create almost anything.

And many people say that C2 isn't capable of making big hit games because there are so few good C2 games on the market. The truth is in fact that C2 attracts people without experience and most games released are to be honest pretty bad and the overall quality is really low. But the engine itself is capable of doing almost anything if you use it the right way but as any other engine it has its strengths and its weaknesses.
Last edited by Anonnymitet on Mon Jun 15, 2015 2:12 pm, edited 3 times in total.
B
54
S
23
G
12
Posts: 747
Reputation: 11,910

Post » Mon Jun 15, 2015 11:06 am

GenkiGenga wrote:....to say you couldn't create your own physics with events is not true.


Your earlier point about making Mario with platform behaviour was valid, and I haven't tried so it could not only be possible but relatively easy to do now I think about it.

I disagree about the physics, though. My game uses the physics engine and I find the limited access we have to box 2d api to be hugely frustrating - no kinematic bodies, many joint types absent, no raycasting or slope normal / collision point, even though many if not all of these are in the plugin code, you just cannot access them via c2.

As Ashley says, I realise the engine is a compromise to please the vast majority. IMO it's just that in some cases the vast majority don't stretch these plugins, so the majority are more ambivalent than pleased.... @Tokinson said it very well above; my frustration comes from being limited to what the default behaviors have to offer because there is no access to more complex features like collision point - stuff you need if you're going to code your own behaviour modification using events.

Overall I'm very happy with c2!! I'm just a little concerned that focusing on c3 could put adding features like better/deeper plugin access so far back that what we see now is what we will have in another 2 years.
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,205
Reputation: 43,832

Post » Mon Jun 15, 2015 1:39 pm

Anonnymitet wrote:snip

I agree with all this. Got to say, reading about some problems make me feel like I live in a different universe or something. I can vibe with the sentiment that C2 feels limited because of certain assumptions about what users need and what they don't. The recent parallax discussion for instance springs to mind. But I don't see why we couldn't recreate Mario, or any kind of platformer gameplay we like, with the platform and solid behaviours and some events to supplement them.

It's too much work to try and re-create the Mario gameplay so instead I'll do a shameless pimp and provide a small example of a Metroidvania/old-school Prince of Persia platformer situation in C2:

Image

This is all platform behaviour, solid behaviour, events, and a couple of extra collision boxes to check for types of surface and positions. So I wonder, how complex does anyone need their platforming stuff to be that they can't achieve it with the functionality already in place?
B
39
S
16
G
6
Posts: 542
Reputation: 7,617

Post » Mon Jun 15, 2015 2:03 pm

@Ashley most behaviors are useful even for full fledge games when they are adapted, however it is painfull to see that doing basically yourself (not you, the user) your own event engine is not as easy as it should, I mean with the conditions, and actions, we should be able to create about everything we want movement wise (the only thing being pushing off an object's collision polygon maybe, a direct action for that could be nice but non mandatory of course, that is not the point), but to actually reuse said events, or even share them, well, too bad it is not as easy as using a behavior.

Of course most beginners won't be able to use that to the full potential, but with the current low number of behaviors, most of them won't be able to make their game reach their full potential.


How I see it (could be completely wrong but I do not see how):

  • By plugins I mean both objects and behaviors, effects could also be affected.
  • First off, official plugins update not tied with the C2/C3 engine when it is not needed
  • each plug can have a "stable" or "beta" status, all stable versions are availiable in case of breaking changes, the project retains the plugin number versions to download them as needed
  • Easy to use plugin store, with "official plugin lists" and third party ones, with a sorting by tags, authors, names, etc.., you want the plugin? Just click the version you need and it installs, right now updating third party plugins is a chore, would also help with conflicts of plugin names maybe.
  • Event-based plugins: obvious one, might be impossible but it still should be there if possible, can be shared the same way
  • Main runtime updates being also subject to versionning, so if a plugin is not compatible at all with it, we can be warned beforehand

The end goal being that the editor can slide into a state where we are not tied completely with only "Official behaviors" being used, as we all know no decisions you will take will be good for everyone and that not every plugin you did can be maintained further for long, at least with that, there will be choices and alternatives for everyone, and sharing capx with other plugins can work out if said plugin version is in the store.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Jun 15, 2015 3:01 pm

Just two words to add. I asked about that long time ago, and for some objects it was made. First for the sine behavior and then after many posts to the Fade behavior...

If there is a parameter in the plugin/behavior you can change then you should be able to do the same in events. For every single plugin/behavior.

Simple example: Drag&Drop. What if you want to change/limit the axes movement on the fly? Well you can't.
You can't make event "on something" -> set sprite Drag&Drop to Horizontal only.
You can't for some reason add another Drag&Drop behavior.
You can't spawn/create object instance A with horizontal and instance B with vertical.

You can create two different objects with different behavior parameters - this pointlessly multiplies drag&drop objects * 2
You can create two instances of same object with different parameters settings - but then good look with keeping track what the hell is going on in events.

And that's the only one behavior/plugin to show example.

Because of that simple but very annoying things it's simply better to make your own d&d in events. But same time this denies the point of the behaviors. Instead of using and setting something what is ready to go in few seconds you are reinventing the wheel by creating entire behavior in events just to be able to set one thing.

If you really want you can modify the behavior to suit your needs, but then it creates two more issues.
1. You should not modify original plug/beh because at some point someone might do some optimization or bug fixing and your changes will disappear
2. You can duplicate it, but then you need to keep track of the original plug/beh on every release just to see if nothing has changed. And you are ending up with two almost identical plugins that needlessly makes a mess in plug/beh list.

EDIT: And like we heard a lot in the past. Saying that something may "confuse beginners" do not really apply here or anywhere else. 90% of events are confusing for new users by design.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,598
Reputation: 34,823

Post » Mon Jun 15, 2015 3:32 pm

If there is a parameter in the plugin/behavior you can change then you should be able to do the same in events.


This. 100% this.

The biggest culprit for me was the fade behaviour, which has thankfully been fixed, but the point remains, if there's a number, I want to change it on the fly.
B
59
S
21
G
9
Posts: 641
Reputation: 9,787

Post » Mon Jun 15, 2015 4:35 pm

@GenkiGenga - I agree with you 100% as I understand it. I know for a fact that coding background has hindered my ability to grasp simple event patterns that solve much more complex coding issues. I kinda get those "Oh, right, herp derp moments. And it is really cool that, as Ashley said, event scripting is a new land with new problems to solve. It is unique and some of the paradigms are completely new.

I also like events better than coding, which may seem odd given my remarks. What I don't like is that the event system makes some things take more time than it should, this in turn compels me to code. It's those basic modularity problems that bug me... Like, why can't I define structures of variables and add them any object in any project. Same thing for object specific functions, and so on...

@colludium was metioned in terms of making mario. To my knowledge, mario can be made using events alone, but you can't use the platformer behavior. I made a tilemap based collision detection system for resolving collisions using tile IDs and linear inequalities. Here is the problem though, given the lack of oop, making something like this in construct as far as I can tell, forces some bad programing practices. There are large swaths of events that nearly replicate other large swaths of events. As most would guess, editing this system becomes a big problem. The events are unmaintainable and as the scope of the project increases so too does the amount of time needed to add something new. I have over 2,000 events in the collision detection and response.

It took much less time in javascript making a behavior to do the same thing (construct doesn't have switch statements which is a major problem in tile id collision detection.

The final problem comes with sharing this. It would take a large manual to describe how the user must then use this system. In traditional code, I can force things to be certain ways via properties. In a behavior I can make sure that anytime variable A is messed with, variable B is also updated, but I can't do this in events.

And this is all due to certain features lacking in the event system, like properties, and private functions, and scope for that matter.

It doesn't come down to "You can't do it" but rather that you can't do it because its currently the wrong tool for the job. By and large the best ways to make advanced systems in construct is to bust out the sdk. I would much rather do it via events but... as I said above. Does this make sense?
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Jun 15, 2015 5:03 pm

Tokinsom wrote:Not sure Mario's the best example here...C2's platform behavior is fairly capable of that.


That is where I must say point blank: the platform behavior isn't capable of that. That is what makes mario such an amazing example. You can make a approximation, but you can't make mario with it. And mario is a very old game. So when you make a game using c2 platformer, you are stuck with all it's inherent advantages and disadvantageous. You have made a c2 platformer at the core of your game, whatever the game may be. Now, obviously we want to avoid cookie cutter behaviors, right? Making a mario platformer behavior, would be cookie cutter. But in my mind, it would be no more cookie cutter than the current system. What I want, is to see behaviors boiled down to more basic ideas, and the platformer has to much going on in it that you can't control (ie, collision response).

First and foremost, the mario games in the nes and snes era actually tolerates mario overlapping "solids". When collisions are resolved in a left/right manner mario is only pushed a maximum amount of one pixel per frame, out of the object. when marios head overlaps a solid, it is not resolved at all, but rather his velocity if <0 is set to 0.

The genius of old school mario games lay in the sheer simplicity of how collisions are detected and resolved. The subtleties of how that impact the game are numerous but mostly positive. The collision resolutions often favor player intent rather than mathmatical precision. Its what makes mario a great platformer. Mimicking this system is possible in events alone. But for ease of use I wrote a behaviors because that made it much more extensible and reusable. It also reduced how much work I have to do per object in events in construct.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Jun 15, 2015 5:06 pm

Tokinsom wrote: (insert list of problems with platform behavior)


You nailed it. and this is like you said, just off the top of your head.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Jun 15, 2015 5:26 pm

Rather than a bunch of different platform behaviors, how about a vast choice different behaviors?
Parabolic jump behavior, gravity behavior, tanuki behavior, turtle pounce behavior, etc.
Image ImageImage
B
169
S
50
G
169
Posts: 8,285
Reputation: 108,214

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Artpunk and 6 guests