Is there going to be a feature update in physics?

Discussion and feedback on Construct 2

Post » Mon Jan 19, 2015 7:53 pm

@Ashely : Is the physics behavior going to be updated, ever? Is it in the plans? And I mean a meaningful feature update... ? I simply want a yes/no response. and if yes, what the plan and timeline is? I feel that construct 2 saying it has box2d powered physics support is like saying hot air balloons fly...

The physics behavior is a shell of what it could be. You know this, I know this. Everybody who knows what box2d is capable of knows this.

If you have no concrete plans for expanding physics support in construct 2 then please let me know. You have hinted that it is a possibility, but I can no longer develop under that speculation. I either need to solidly move my project to unity or commit my changes to the box2d behavior and apply it to the objects in my game.


There have been numerous forum postings expressing interest in the features that box2d already has... and that construct 2 could have. It simply is not possible to make a robust physically enabled game without at least a few more joints and kinematic bodies, edge shapes, pre/post solve, and collision filters (even if done manually during pre solve).

Thanks,
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jan 19, 2015 8:02 pm

Afaik they want to switch completely to the asm.js version first, but this was a long time ago, and we did not saw any real hint that this is happening anytime soon (not sure which kind of problem they would have with that).
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Mon Jan 19, 2015 10:11 pm

I would also appreciate info if a box 2d improvement is planned. I recently tested and compared the physics options, using the capx I posted in another thread about physics, and I've summarized the results below to highlight that asm.js offers no performance improvement, in spite of what it says on the tin...

On my Nexus + chrome:
box 2d = 190 sprites, asm.js = 190 sprites

On my laptop + chrome:
box 2d = 950 sprites, asm.js = 950 sprites
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
73
S
19
G
66
Posts: 2,198
Reputation: 42,193

Post » Mon Jan 19, 2015 10:12 pm

@Aphrodite - I was under the same impression... Though I didn't mean to say that @Ashley was hinting that there would be anything anytime soon, just that there may be more features in a situation where Scirra only had one physics exporter to deal with.

I just really need to know if anything is on the horizon. To my knowledge there has been discussions surrounding this topic for a long time. A long time ago, I said to myself, "cool no need to worry about these features I don't have because I just might get them in a future update." So I haven't let it worry me except to post my two cents on the forums here and there. But I am at the point where I actually have to make a big decision. continued development is tied wether i decide:

to commit to my own version of the physics behavior for the next 1.5 years (give or take 6 months), or continue all further development in Unity...

If Ashely does indeed have a concrete plan, then knowing that may save me a lot of work. Knowing there is no plan will also properly motivate me to make a decision as I will know what needs to be done if I stick with construct through this particular project.

It just comes down, "It would be really, really nice to know".

Each decision has its own problems in my project... I have considered going back to simple libraries where I have more control over everything, but that would be equivalent to throwing out the last year's work... and lets face it, I'm not here for the fancy no scripting event editor; I am here because construct is an amazing product that speeds up dev time considerably (I wish one could actually script events... it would take less time than the dialogue window business... anyway...off topic lol)
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jan 19, 2015 10:21 pm

@Colludium - I meant to reference your work from another post. I have since set up tests as well and can't tell a difference between the two. I did it because the regular version is easier to add to the behavior because you can read it at the time of editing.

If there is a dichotomy between full feature set and slightly higher performance... Then I would choose features in a heartbeat. A careful developer can easily work within the constraints of performance considerations, but if you haven't got a tool to use, you can't use. I know ray casting is expensive and shouldn't be done willy nilly all over the place, but I think that the c2 work arounds are much more expensive.

The dumbest part is that I have devised a ridiculous method to determine a collision surface normal on a solid object that involves extra sprite objects, plenty of editor time placing these sprites and setting appropriate variables, all in the knowledge that box 2d can pass this info directly to construct 2. But I don't want to risk making a version of box2d that may become outdated when Scirra adds more features... Then my whole project would be broken.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jan 19, 2015 10:50 pm

ruskul wrote:I have since set up tests as well and can't tell a difference between the two. I did it because the regular version is easier to add to the behavior because you can read it at the time of editing.

If there is a dichotomy between full feature set and slightly higher performance... Then I would choose features in a heartbeat. A careful developer can easily work within the constraints of performance considerations....


At least it's not just me who finds this frustrating! I totally agree with what you wrote - we're always hearing how technology will speed up javascript in browsers, so I have no fears about how box 2d will perform in the future.

Your collision surface normal work-around sounds a bit like some of the patches I had to invent for my sketch book game (that I'm just finishing). Some of the logic is pretty ugly, but it seems odd that a full set of box 2d features are not available when these already exist within box 2d and probably reside within the code that c2 exports.

I've also noticed that we've not had any major new features added for a while - I'm keeping my fingers crossed that what we have isn't considered good enough...
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
73
S
19
G
66
Posts: 2,198
Reputation: 42,193

Post » Mon Jan 19, 2015 11:08 pm

@colludiam -

As it turns out, the box2d code for these features is in the behavior script already. I don't see what version of box2d it is (which I would want to know). I don't fully profess to understanding everything I mess with but adding in more features has been surprisingly simple... I just do it in quick and dirty ways... (for example, I added an action to set the object to be kinematic... I keep the programing simple, and usually work through such manners...) I hate to put the full effort to fully enable a feature. It takes a chunk of time (for me longer, because most of it has been figuring out c2 implementation, and making sure I am not messing it up) but even still, my first feature exposure took under 2 hours. Ashley could probably do it in 10 minutes. I just can't justify permanently changing the behavior until I know for sure Ashley won't...

I figure there must be something I am not appreciating here, or some unknown.
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jan 19, 2015 11:24 pm

@colludium - There are even the little things in the behavior that can easily be changed...

you know how set position breaks the physics behavior? Basically physics sets the velocity to be the difference of the old and new position. Meaning your object blasts through space at an unreasonable speed...

That isn't box2ds fault... it's how the behavior handles it.

Even the fact that the behavior isn't using edge shapes for the tilemap boggles my mind. I told Ashley about internal seams being a source of collisions when they shouldn't and he said it was not a bug but a box2d thing and dismissed it. It is not a Box2d thing it is a Construct 2 physics behavior thing... am frustrated...
Image
B
33
S
11
G
2
Posts: 563
Reputation: 5,141

Post » Mon Jan 19, 2015 11:27 pm

That's even worse - it's like a game show - "look at what you could have won...."!! Seriously, though, I can only imagine that we are waiting for either a) a new physics engine to be implemented (very unlikely) or b) trying to avoid confliction with cocoonjs (which is deprecated - so let's bin cocoonjs physics: I bet no one uses it anyway given the poor performance you get on mobile). If Ashley could implement a full set of box 2d features then the c2 engine will be almost complete....
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
73
S
19
G
66
Posts: 2,198
Reputation: 42,193

Post » Tue Jan 20, 2015 12:57 am

@ruskul - my answer above is out of sync! To your other points - indeed! The only consolation is scirra's box 2d is better than GameDevelop's... I'm kind of hoping that @Ashley is feeling generous this year and pays some attention to making this a rather more powerful feature :).
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
73
S
19
G
66
Posts: 2,198
Reputation: 42,193

Next

Return to Construct 2 General

Who is online

Users browsing this forum: takamoto and 0 guests