In defense of Construct 2

Discussion and feedback on Construct 2

Post » Mon Jun 15, 2015 7:11 pm

We seem to be getting onto a number of different topics here :T

@NotionGames I would argue that a game like Ubi actually is perfect for the platform behavior. It's incredibly simple in terms of platforming and uses a large resolution which hides or nullifies the issues and inaccuracies I mentioned earlier. Now go make perfectly accurate and bug-free Super Metroid engine and tell me the platform behavior is ideal ^^;
Last edited by Tokinsom on Mon Jun 15, 2015 7:15 pm, edited 1 time in total.
Image
B
242
S
29
G
13
Posts: 1,787
Reputation: 18,685

Post » Mon Jun 15, 2015 7:12 pm

@NotionGames

Good job! Love the game. Did you get it to wiiU? If I may, the game is fairly typical in the "platforming" sense. I mean that, your need for platforming mechanics was fully solved and contained within the behavior. Anything else you needed could be added on top. That is perfect as a use case. There is no reason why you can't get the platform behavior to work in many projects. But if you have a low level problem with something the platformer behavior does, it renders the whole behavior useless to a project. You can't correct what the behavior does with collision detection or resolution... and so on.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jun 15, 2015 7:27 pm

Tokinsom wrote:We seem to be getting onto a number of different topics here :T

@NotionGames I would argue that a game like Ubi actually is perfect for the platform behavior. It's incredibly simple in terms of platforming and uses a large resolution which hides or nullifies the issues and inaccuracies I mentioned earlier. Now go make perfectly accurate and bug-free Super Metroid engine and tell me the platform behavior is ideal ^^;


Haha. Yes, you are definitely correct. It is a pretty simple platformer. It was mostly designed around what could be done with the platform behavior so yes, I don't know the low level problems that are going on. So I pretty much don't speak of them haha. But I do take your word for what issues you are experiencing.

ruskul wrote:@NotionGames

Good job! Love the game. Did you get it to wiiU? If I may, the game is fairly typical in the "platforming" sense. I mean that, your need for platforming mechanics was fully solved and contained within the behavior. Anything else you needed could be added on top. That is perfect as a use case. There is no reason why you can't get the platform behavior to work in many projects. But if you have a low level problem with something the platformer behavior does, it renders the whole behavior useless to a project. You can't correct what the behavior does with collision detection or resolution... and so on.


Thank you! I am actually redoing a lot of things and releasing Super Ubie Island REMIX. Level design touch ups and blah blah..

Back on topic. I couldn't get the game working on the wii. Just too high resolution and stuff going on. I'm just assuming that is the issue. My other smaller games work just fine though. I should probably do like Tokinsom and start making pixel platformers to hopefully reduce the amount of resources needed to run. I went through with a programmer and did a bunch of performance tweaks but the framerate is still a bit too low to properly detection collisions, resulting in unwanted deaths. :/
Image
B
69
S
19
G
9
Posts: 548
Reputation: 13,710

Post » Mon Jun 15, 2015 7:50 pm

@NotionGames - that is a shame. I wanted to release a game on the wii but I haven't bought the dev kit yet. I was kinda hoping to release on steam and then move to wii in funds permitted. I suppose the high res stuff could be a problem.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jun 15, 2015 8:01 pm

Last I heard WiiU doesn't support WebGL so, like, 99% of C2 games are out of the question. Paired with the NDA I don't think C2/WiiU is really much of a thing.
Image
B
242
S
29
G
13
Posts: 1,787
Reputation: 18,685

Post » Mon Jun 15, 2015 8:39 pm

@Colludium Ahh, I didn't realise you were using physics so extensively. When I spoke about making your own physics I just meant faking it so you can cut the behaviour out altogether. I had a quick look at your game and now I can understand the frustration you are having.

@ruskul It does make sense, maybe I am out of touch. While I personally would like development to go towards expanding the multiplayer object, I cant argue that offering more avenues for fine tuning some behaviours wouldn't be in Scirra's best interest (especially considering those who don't know how to code or event will be reliant on them to start with).
ImageImage
B
112
S
23
G
7
Posts: 1,064
Reputation: 12,787

Post » Mon Jun 15, 2015 10:54 pm

Well, when I think of modularity, instead of A'la carte behaviors, I think of the plugin sdk using events.
Pretty sure you'll get all the behaviors you can dream of then.
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Mon Jun 15, 2015 11:15 pm

Why are we even talking about plugins and behaviors, a more important issue is the export options! :(
I have several games waiting to be released. And i have optimized them all for around a half year. Still not good enough for a release... We need a Custom Scirra Exporter or Scirra could buy Cocoon.io and develop it :P

Nah, nevermind. - I'm dreaming :P
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Tue Jun 16, 2015 12:04 am

Talking about exporters is a waste of time, C2 exports HTML5, and it does it well - wrappers are the order of the day when it comes to cross platform support, and Scirra doesn't make wrappers, so it's a null point.

Asking to have more open ended behaviours, or an "unlocked" mode for non-beginners is more reasonable.
B
57
S
19
G
9
Posts: 639
Reputation: 9,533

Post » Thu Jun 18, 2015 12:57 am

@Ashley

The issue is not "cookie cutter" feature or "general-purpose", or event-base behavior.
The issue is "how to reduce programming cost":
- "cookie cutter" means users will program with pure events if they need new feature.
- "general-purpose" means users might add some or a lot of events to match their requirement.
( Some time they will never get it, so they will ask pure event-base behavior, I do not agree official plugins are "general-purpose" already, since users still could not reach their targets. )
- "pure event-base behavior" means a lots of events.

The better solution will reduce events in all cases.
A possible solution is start at pure event-base behavior-- "how does users modify it for new features?" Then breaking it into plugins(behaviors). Finally it will be a plugins-system which left some hooks for users to add new feature by events or by plugins-- It is not a single plugin or behavior, it is a reuse-able architecture.

Do not trapped by "single plugin/behavior", this kind of solution does not have enough flexible. Sprite(plugin) could have behaviors like extending slots/decorators, how about behaviors' extending slots/decorators?
B
108
S
26
G
259
Posts: 4,430
Reputation: 145,679

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Colludium, jefftrier and 2 guests