In defense of Construct 2

Discussion and feedback on Construct 2

Post » Sat Jun 13, 2015 4:40 pm

For 2D Games: Construct 2 rules and Unity3D drools! :lol:
ImageImageImageImageImage
B
56
S
15
G
5
Posts: 852
Reputation: 11,446

Post » Sat Jun 13, 2015 5:09 pm

I believe that part of the fun of developing c2 is just the challenge of adding additional cutting edge features to the editor. I mean: none of the scirra team use c2 on the side to make awesome games - developing it is the reason they get out of bed, and I think that sometimes that diverges from what many c2 users wish for. Not always, but things like having only 1/2 a physics engine are perplexing without explanation. Same for solids collision groups, and so on.
A big fan of JavaScript.
B
76
S
20
G
74
Posts: 2,253
Reputation: 46,480

Post » Sun Jun 14, 2015 1:25 pm

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,535
Reputation: 195,412

Post » Sun Jun 14, 2015 2:14 pm

For one in my opinion the built in pathfinding is made for an RTS type game, its especially bad for grid/board based games, and the move costs just don't work for a TBS. You can probably jerry rig it to sort of work but i believe that was the point being made. Thankfully there are 3rd party alternatives as the event system doesn't lend itself well to that kind of thing, though i know a couple of good examples of it being done.
B
43
S
23
G
21
Posts: 735
Reputation: 12,132

Post » Sun Jun 14, 2015 2:50 pm

All hail Construct 2 and its prophet @Ashley
B
66
S
22
G
4
Posts: 360
Reputation: 6,584

Post » Sun Jun 14, 2015 6:57 pm

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

Post » Sun Jun 14, 2015 11:02 pm

Ethan wrote: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?

Tokinsom wrote: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?
Scirra Founder
B
399
S
236
G
89
Posts: 24,535
Reputation: 195,412

Post » Sun Jun 14, 2015 11:51 pm

Ashley wrote: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 be...so I'd like to expand our options.
Last edited by Tokinsom on Mon Jun 15, 2015 3:42 am, edited 1 time in total.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Mon Jun 15, 2015 12:07 am

Modularity is definitely an interesting area to explore in future


this worries me a bit, :geek: i start to wonder how long c3 is going to take, how far off are we? what can we expect, will the first step be another editor, will this includes all existing features, how far will new features be off, because its seems that any feature we need is all for c3, is there gonna be some form of modularity object, etc.. , i for one are really waiting for improved search & code re-use and some other things that was added on "THE LIST" before i wanted to start a new "serious" project, ... may still be a long time im thinking :?:
ImageImage
B
70
S
21
G
7
Posts: 827
Reputation: 10,052

Post » Mon Jun 15, 2015 12:26 am

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

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: vino7733 and 11 guests