Is there a Physics API? 🤔

[MrAddy (Andrew)]

It is worth remembering also, Hype is still itself new, like HTML5.

I have no doubt this will surpass Flash in all areas as it evolves, and community spirit, like this thread shows, is an important part in achieving such a goal.

I can code, I love it, but I cannot design for the life of me, and even when I try I am never happy with it. Hype just makes the process that much shorter in realising it lol!

Plus, you can actually learn something new, and see new possibilities every day, which I find amazing to be honest!!

[Photics]

I was working on a different project when I started getting frustrated. It’s been an uphill battle on every scene. It’s been getting annoying. So, I decided to revisit the physics issue. Even though I wasn’t very successful with my other project, my understanding of JavaScript improved. So, I decided to try some different techniques…

On Key Down…

hero.style.left = (parseInt(hero.style.left) + 1) + "px" ;

The theory was that I could move the elements with JavaScript. And yes… I apparently can do that. But unfortunately, it doesn’t work with collision dedication. It’s just another way to make an actor pass right through another actor.

I felt so close to adding game controls to Hype. Unfortunately, the result was not quite what I expected.

[nick]

I wonder if you could deconstruct a simple HTML5 Canvas Game and apply that within Hype?
Just a thought.
http://jlongster.com/Making-Sprite-based-Games-with-Canvas

or

http://www.lostdecadegames.com/how-to-make-a-simple-html5-canvas-game/

[Photics]

@nick

I wonder if you could deconstruct a simple HTML5 Canvas Game and apply that within Hype?Just a thought.

I think the problem there is that those examples use Canvas, while Hype uses DOM.

If I start bypassing a lot of what Hype uses, then it might be more efficient to just code the whole project manually. As an example, I think a turn based game that moves actors by tiles could work, but any collision detection would have to be done with JavaScript.

[h_classen (Hans-Gerd Claßen)]

Hi,

hype caches its own history of elements. This may be not identical to the current dom. So if you change elements properties with custom js (which is not part of the hype API) you’ll run into trouble reactivating it with any further hypeanimation …

[Photics]

@h_classen

hype caches its own history of elements. This may be not identical to the current dom. So if you change elements properties with custom js (which is not part of the hype API) you'll run into trouble reactivating it with any further hypeanimation ...

I'm not sure it's just custom JavaScript. If I try moving the actors with the Hype Timeline, it's a similar result – the elements pass right through physics actors.

That's another reason why a physics API could be useful... movement could be done entirely with physics instead of with the Hype Timeline.

[h_classen (Hans-Gerd Claßen)]

as long as physics can’t be controlled - you are right - there’s no chance to built a game around it.
But it’s new, it’s freaky and hypeteam is top. Just let them take deap breath after this big update and they’ll walk further…

Just hope hype won’t be bought by the bigger player, though this would surely be nice for jonathan

[Photics]

@h_classen

Just hope hype won't be bought by the bigger player, though this would surely be nice for jonathan

I wonder if Flash would be in better shape if Adobe hadn't gotten their clutches into it. I used to like Adobe software, but their Creative Cloud is a non-starter for me.

So, if the goal of Tumult is to cash out for a big payday, I'm not seeing any other suitor besides Adobe. Google? That doesn't seem like a match. Microsoft? That might have potential, but Hype is Mac only. Apple? They don't have to bother when they already get a cut through the app store.

[Photics]

@jonathan

I'm not very worried, it is under very active development and has seen some new contributors lately.

I was a bit concerned about this. I looked at the changelog and it seems that the newest version is from over a year ago. Although, it does seem like there has been a lot of activity lately. The Monthly pulse shows that a lot of issues are being closed. There's also a familiar face here.

I think that maybe I should try building a game from scratch with Matter.js and see if it's difficult. That seems like a good next step.

[Photics]

Wow, every project I work on lately feels like such an epic uphill struggle. Even to just get Matter.js running, I have to decide on what to use as a renderer. It seems that pixi.js is an option. So, I was wondering if Hype also uses Pixi.js. I went back to the Hype JavaScript and it looks like no. A search for “pixi” does return some results, but those lines are commented out.

[Photics]

Here’s another note…

Hype has a problem with continuous collision detection. That’s because matter.js doesn’t support it. At least, not yet anyway…

Issue: Prevent object passing through walls / tunneling (implement CCD)

It’s one of the few open issues with Matter.js. I think Tumult picked the right physics engine. The problem is how game development features will be added to Hype. Is opening up the API enough? Would something like crafty.js… Crafty.JS…Potential Game engine for use in Hype …make sense? I’m not sure, but it was pretty easy to add crafty.js to a Hype project. The problem is getting all of these pieces working together.

[jonathan (Jonathan Deutsch)]

@Photics

Like, instead of having a full/thin or separate Matter.js files, one JavaScript file would be created by the Hype application.

Minification takes a lot of time (~10 seconds for the full build on my hw), so we really need to minify the javascript when we build the Hype app otherwise exports/previews will be a bit ridiculous :).

@Photics

Basically, aside from download speed, does it really matter to keep the JavaScript small?

It matters to certain market segments we sell to! But you're right in the above comments, the generated data can be quite large; we don't work quite as hard to optimize that but we probably will take another pass in a future release. A lot of the bloat comes from long floating point numbers.

@nick

We are at a spot in the creative professional history where the artist MUST learn more about the underlying technology for digital content.

I also like thinking about Hype from the creative/artist perspective. I don't want our app to limit creativity by any means, even if the artist needs to get their hands a bit dirty with code. That's why we provide an API! Of course, this needs to be balanced with long term goals and not backing us into a corner. Discussions like this our useful because it helps us understand what we should be exposing in our API.

@Photics

The theory was that I could move the elements with JavaScript. And yes... I apparently can do that. But unfortunately, it doesn't work with collision dedication. It's just another way to make an actor pass right through another actor.

Yeah, Hype doesn't read back the DOM/CSS and has its own view of the world, so unless that is updated this won't work as you want it to. As I mentioned, giving these APIs is something I'd really like to do

@Photics

If I start bypassing a lot of what Hype uses, then it might be more efficient to just code the whole project manually.

I love folks using Hype as much as possible, but I'd agree this can be the right way to go about it. Not every task is well suited for being built in Hype (so far!).

@Photics

I'm not sure it's just custom JavaScript. If I try moving the actors with the Hype Timeline, it's a similar result – the elements pass right through physics actors.

This behavior is a bit different than the direct DOM manipulation. When you move via a timeline, the timeline is taking ownership of those properties. You can think of Physics as another timeline. When one timeline has ownership, another timeline will not be able to manipulate it. So when timelines run they take ownership. Typically timelines will own the properties (even after animations have stopped), but since physics keeps trying to own the properties, it will nearly immediately take ownership back after an animation is complete.

@h_classen

Just hope hype won't be bought by the bigger player, though this would surely be nice for jonathan

@Photics

if the goal of Tumult is to cash out for a big payday

That's not our goal; if it was we would have sold out long ago! (and no, I can't elaborate)

@Photics

I was a bit concerned about this. I looked at the changelog and it seems that the newest version is from over a year ago.

He hasn't had an official release in a bit so the changelog file hasn't been updated. He just wrapped up a large slew of changes, so I'd expect a new official release soon.

@Photics

I was wondering if Hype also uses Pixi.js. I went back to the Hype JavaScript and it looks like no. A search for "pixi" does return some results, but those lines are commented out.

Correct, I built our own "renderer" which basically interacts with the Hype runtime under the hood. There's about 1,200 lines of code responsible for integrating Hype and Matter.js together. It has to do things like manage transformations, groupings, symbols with different engines, obtain velocity information to feed to physics, etc.

@Photics

Hype has a problem with continuous collision detection. That's because matter.js doesn't support it. At least, not yet anyway...

I agree this is one of the common bugs people run into!

[Photics]

@jonathan

Minification takes a lot of time (~10 seconds for the full build on my hw), so we really need to minify the javascript when we build the Hype app otherwise exports/previews will be a bit ridiculous :).

Is it ridiculous though? I'm imagining developers presented with a prompt...

• Quick export
• Compressed export

If the compressed version was 10 minutes long, developers would still probably use it though. With most of my Hype projects, they live on the server for years and rarely get updated. Even if compressed exporting took an hour or a day to run, that still makes sense to run as it saves server resources, while increasing performance and download times for visitors.

Currently, I'm building an iOS app with Hype. Excluding a lot of extra junk in the app basically translates into more sales. That's because lots of customers will likely skip an app if it's too large. I have to wait about a week for Apple to review my apps. Now that's ridiculous.

The good news is that I can dramatically reduce the size of the app by excluding some of the exported files. There is some low hanging fruit here. Perhaps Hype should do that automatically. Why create the "thin" JavaScript if there's physics involved? Why create the "PIE" file if old versions of Internet Explorer are not supported? On a server, that file space might not matter too much. But in an app, that can be huge space savings.

@jonathan

A lot of the bloat comes from long floating point numbers.

That line makes me nervous. 3.14 Is not the same as 3.14159265359. I actually like the way frames are truly numbered in Hype. I was a bit surprised to see so many numbers after the decimal. It seems so precise. Rounding numbers seems like a bad way to save space when there are so many options. I've actually used JavaScript code that runs calculations based on a timeline's time position.

@jonathan

As I mentioned, giving these APIs is something I'd really like to do

I believe you. I'm still waiting. Ha ha. I think you said it's not going to happen before the WWDC. That's unfortunate as it's looking like the Apple TV will be getting an SDK. If the rumors are true, and the Apple TV supports WebKit like other iOS devices, that's huge potential for Hype. It could be like a game development platform. This is like Nintendo / XBOX / PlayStation stuff - Hype games on the big screen in the living room.

Maybe I'm dreaming too big, but I see Hype as more than a way to build brochure websites and flashy banners.

@jonathan

You can think of Physics as another timeline. When one timeline has ownership, another timeline will not be able to manipulate it. So when timelines run they take ownership. Typically timelines will own the properties (even after animations have stopped), but since physics keeps trying to own the properties, it will nearly immediately take ownership back after an animation is complete.

It doesn't seem to be doing that. If I move an element with JavaScript, and it stops at a location that overlaps another physics element, there's no reaction. Note: this is when Gravity is set to zero. If the physics "timeline" took over in between JavaScript intervals, that might be a workable hybrid environment for many types of games. But right now, it doesn't even take over after a controller key is no longer pressed.

I've been using JavaScript interval set to roughly 33ms, to mimic a game running at 30 FPS.

Anyway, it's nice to see that you're still posting replies in this thread. There is some good news. Even though I still can't make twitchy types of games with Hype, there are plenty of other types of games that I probably could make with Hype.

@jonathan

much as possible, but I'd agree this can be the right way to go about it. Not every task is well suited for being built in Hype (so far!).

I like the "so far" addendum. I think Hype is capable of being an even more useful web design/development application. I'm glad to see that you seem to agree.

[gasspence (Greg)]

This is one great thread. It’s really enjoyable to see a dialog between the developer and a customer that goes into such detail about the issues both see. Many Thanks.

[jonathan (Jonathan Deutsch)]

@Photics

Is it ridiculous though? I'm imagining developers presented with a prompt...

Well, the default should be the slow one (smallest sizes are the best default), and if we kept adding all the options that were wanted we'd end up with an interface like this. Tradeoffs.

@Photics

That line makes me nervous. 3.14 Is not the same as 3.14159265359.

There are different representations that could lead to smaller space and more precision. Times are one of them - if you consider a "3.19" (3 seconds and 19/30 frames) representation, it is much smaller than the decimal "3.63333333333333" representation of the same number and technically more precise while using 25% the amount of space. We already do this in some cases, but there's more we could improve. So while truncation may be an option, don't get too nervous .

@Photics

It doesn't seem to be doing that. If I move an element with JavaScript, and it stops at a location that overlaps another physics element, there's no reaction.

To clarify, I meant moving via timeline, not moving via javascript.

[Photics]

@jonathan

Well, the default should be the slow one (smallest sizes are the best default)

Ah, a new export option screen isn't even necessary. If the Hype project is being previewed, it can work like it does now. If it's an export, then the slower processing could be done. That way, developers won't get annoyed while creating content, but get ultra small exports for the website.

@jonathan

To clarify, I meant moving via timeline, not moving via javascript.

I tried triggering a timeline after the JavaScript was complete, wondering if it would reenable the physics settings. I couldn't get it to work. Even though the beginning of a timeline can be relative, the end is static. So, the element just snaps back to a previous position, even though I'm not trying to change the actor's position with the relative timeline.

[Photics]

After looking at the Comprehensive Physics Tutorial… Comprehensive Physics Tutorial …I realized that my previous experiment might not have worked because I was looping the timeline between frame zero and 0.01. So, I moved the experiment between frames 0.05 and 0.06.

And then…

…nothing!

I still can’t get physics to restart after an element has been moved by other means, such as JavaScript or using the Drag element option in Hype.

I’m also not happy with adding 1 pixel or subtracting 1 pixel to move actors. It should be more fluid. I was wondering if I could do tweening. At least, that’s the Flash terminology. I’m not quite sure if it’s the same thing for JavaScript. I looked around and my preliminary search suggests that this is not common with native JavaScript – but their are libraries for it. That’s when I started to wonder, “Is Hype using jQuery?”

I searched the “full” JavaScript file and saw this…

// better form of eval(scripts[i].text) for IE and Firefox (taken from jquery)

I’m not quite sure how Hype handles their transitions / tweening, but it seems that more than just the beginning of the timeline should be relative. I think I might have mentioned this before in the thread. Elements should move relatively. Move X to X + 10, not just move X to 10.

The WWDC is less than a week away. I’m excited to see what happens with the Apple TV. If Hype gets better with Physics, a game could be created once and then released to many different platforms… web, Android, iOS.

[Photics]

@Photics

The WWDC is less than a week away. I'm excited to see what happens with the Apple TV. If Hype gets better with Physics, a game could be created once and then released to many different platforms... web, Android, iOS.

Well, this is not looking good...

• Redesigned Apple TV Not Ready for WWDC Debut - MacRumors

Also, I played around some more with Hype. I realized something last night... which should have been more apparent, as it's common with Physics engines... static elements behave differently than Dynamic elements. Using static elements are not as responsive. They need to be moved to restart collision detection with a Dynamic element – if that element has been moved by other (non-physics) means.

OK, so what... I can make lots of other types of games, right? I tried creating a simple ball game, using gravity as the control. It ran horribly slow on the iPhone 4. It seems that Hype is the wrong software for what I'm trying to do.

[jonathan (Jonathan Deutsch)]

@Photics

I still can't get physics to restart after an element has been moved by other means, such as JavaScript or using the Drag element option in Hype.

It could be that the physics engine is asleep at this point and didn't wake back up or there is some other issue; I'd be happy to take a look at your test document and try to figure out what might be going on. Please email it to support@tumult.com.

@Photics

That's when I started to wonder, "Is Hype using jQuery?"

We're not for all the file size/bloat issues listed previously. However, from time to time I'll steal snippets of their code when they discover a cool technique .

@Photics

it seems that more than just the beginning of the timeline should be relative. I think I might have mentioned this before in the thread. Elements should move relatively. Move X to X + 10, not just move X to 10.

Totally agree this would be an awesome feature! The trick is to do it without making a confusing interface or a non-obvious one.

[Photics]

@jonathan

It could be that the physics engine is asleep at this point and didn't wake back up or there is some other issue; I'd be happy to take a look at your test document and try to figure out what might be going on. Please email it to support@tumult.com.

There's a game I have in mind, but right now I'm just testing the limits of Hype. At first I thought my project would be simple enough, but there are a bunch of physics issues...

• No easy way to add controls - You mentioned you're looking into adding additional physics features. Controlling elements with Physics seems like a good place to start.
• No Continuous Collision Detection - This is one of the few open issues with Matter.js
• No collision detection events
• Not able to leverage the Matter.js APIs - Being able to spawn actors dynamically, control the view, speed up / slow down time, those are Game Development features. Again, I think you mentioned you're planning to add them. You're just not sure yet.
• Static elements are sleepy - This is likely a setting to maintain performance
• Slow on Mobile - I'm not sure, but isn't there a separate version of Matter.js for mobile? Maybe I just need to upgrade my pokey iPhone 4. HA!

I probably could make lots of games with Hype, such as a turn-based RPG, trivia games, board games, photo games, but the "twitchy" games are tough.

Anyway, here's an example that might explain the problems...

example.hype.zip (13.8 KB)

There are a few things going on.

Sleepy static elements – The white circle can be dragged. Notice how the actor can be dragged right on top of the Static elements. The ball doesn't bounce off unless the static actor is moving. This makes it difficult to create game levels.

I tried to add game controls with JavaScript. This jams when elements are being moved by the timeline. If all of the timeline events are removed in the project, the ball can be moved with arrow keys. I'm not too worried about this part. You mentioned that you're looking to adding controls.

@jonathan

Totally agree this would be an awesome feature! The trick is to do it without making a confusing interface or a non-obvious one.

The point of this thread is "a Physics API". So naturally, I'm not too worried about having to use JavaScript code. Basically, if right arrow is down, set velocity to X. If left arrow is down, set velocity to negative X. That's effective, but not elegant. It seems this community wants to code as little as possible. That probably describes me too. HA!

So, here are a couple ideas.

• Perhaps the gravity should be controllable by a timeline, changing force and direction.
• The same idea could then apply to elements themselves. They would have a direction and a force, which could be changed with timeline keyframes.
• Relative notches on the timeline shouldn't just be at the beginning. They should be able to be created anywhere on the timeline. By double-clicking a keyframe, the keyframe could be made dynamic and a value could be changed by an amount that's entered.

You know how the "Timeline Action" balloon pops out when a Timeline keyframe is clicked... why not do the same thing for regular keyframes? It seems like a nice design approach.

That little blue dot down below... double-click... make relative... +10 to the Left Origin. So, whenever I want to move a character to the right... On key press, right key, continue timeline "Right".

It might be a good idea to let Hype users specify the key when the "On Key Press" event is used.

I don't know how difficult these changes are from your perspective, but perhaps this is the start of a second golden age of Online web games. Looking back at Flash, it's not as intuitive as this. It didn't come out-of-the-box with a Physics engine or easy way to add game controls.