Is there a Physics API? šŸ¤”

Physics
52

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 :).

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.

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.

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 :smile:

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!).

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.

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

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.

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.

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

1 Like
53

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.

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.

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.

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.

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.

54

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.

2 Likes
55

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.

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 :smile:.

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

56

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.

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.

57

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.

59

Well, this is not looking good...

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.

60

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.

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 :smile: .

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

61

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.

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.

62

Well, it looks like there was no Apple TV announcement today. Although, stand alone Apple Watch apps are on the way. Iā€™m not sure if thatā€™s something for Hype, as Iā€™m not sure if WebKit works on the Apple Watch. I thought I saw a video about it somewhere. If so, some cool retro games might be fun with Hype and Apple Watch.

It seems like Hype would be cool if it exported straight to Swift. Like, not HTML5ā€¦ straight to Swift. Now that Swift is going Open Source, maybe it makes sense. I think the problem with building games with Hype is that itā€™s not going to be as fast as a native solution.

Heh, so now Iā€™m not sure what to do. Although, itā€™s looking better. It seems that Apple is merging Mac, iOS and Watch into one development programā€¦

Apple News looked good tooā€¦

Maybe Hype is useful in that arena too.

At least I can keep busy while waiting for Hype Physics to improve.

1 Like
63

It looks like thereā€™s an update to Hype Reflect. It mentions an update to Physics performance. It seems like I should retry the mobile testing, to see if Hype is suitable for mobile games. The sluggish performance might have been related to Hype Reflect and not actually matter.js and Hype itself.

Iā€™m a bit sleepy now though. Ha ha. So, maybe tomorrow Iā€™ll try again.

64

First off, ah haā€¦ https://itunes.apple.com/us/app/pastime-baseball-for-apple/id989444591?mt=8 ā€¦I knew you guys were gamers!

Secondly, the test was successful. It was Hype Reflect that was slowing down the game on mobile. After setting up the test on my server, the performance was playable. It was a little slow on the iPhone 4, but quite smooth on my iPad Air 2.

This is good news. Itā€™s hard to design games to be built with Hype, as I donā€™t know of all the features that will be available, but it looks like I can get started on some basic games right away.

1 Like
65

We're taking advantage of WKWebview in Reflect, which has much better JavaScript performance. Glad to hear this speeds things up!

2 Likes
66

Well, the speedup was not by using Hype Reflect. I tested the project by loading it from a website.

It seems like the new WKWebview could be used to export Hype projects to mobile ā€“ another way to make Hype more of a game development platform. (Export to iOS.)

I'll have to look more into this. I've been trying to port Hype projects to Xcode. If WKWebview worked for you, it will likely speed up my projects too.

67

Found this article which spells out some of the differences between the two. http://blog.initlabs.com/post/100113463211/wkwebview-vs-uiwebview

The blogger also links to an app in the app store that you can test any sites performance in both webviews.

68

WKWebView is the way to go. Apple says so themselves...

I tried converting my UIWebKit project to a WKWebKit project. It's in Swift, so I'm not exactly sure how to update it. That seems like my project for the weekend. Yet, there is an issue. You can see it in the comments of the article you linked.

Apparently, there's a bug with loading local files with WKWebView in iOS 8. It's fixed in iOS 9. So, my project supports iOS 7. WKWebView is iOS 8, but it's better in iOS 9. So, which platform do I target? (Tumult targeted iOS 8 with their app, and it's sorta loading local files, so maybe they figured something out... but Hype is basically running a local web server for project previewing.)

This all feels so unnecessarily complicated to me. Swift is supposed to make it easier to program, but it's still a lot of lines of code to load a web page in a box. Then there's the Main.storyboard to straighten out. Currently, my project has a blue box with "UIWebView" in the middle. I'm figuring that's not the right... ViewController? ...I'm not sure of the correct terminology. What I do know is that it's pretty annoying to have to drag a blue line from a box to a line of code. That process doesn't seem very intuitive.

The video linked above focuses on the "Safari View Controller", which I'm not sure is the right solution for running Hype generated, physics based, games on iOS/Apple. I'm thinking not because it's more focused on browsing. Games are for playing. I don't need forward-back buttons or a URL bar.

Again, I think Hype should just export to iOS.

69

I moved a post to a new topic: XSS error when displaying document in Wordpress

1 Like
70

Ha, I was wondering what happened here.

So, to recap, I posted B.R.O.O.M. to my website... B.R.O.O.M. ā€“ Photics.com ...which stands for Bomb Removal & Ordnance Obliterating Machine. It's an attempt to create a game without a Physics API. In doing so, it highlights what might be good additions to a Hype Physics API.

As of version 0.1.1, I have WASD and Arrow key controls. By pressing an arrow key to move the main character, the web page itself was moving. Using the "event.preventDefault();" line stops the page from moving with the arrow keys.

window.onkeydown=function(event){

event.preventDefault();

moving = hypeDocument.isPlayingTimelineNamed('x') + hypeDocument.isPlayingTimelineNamed('y');

 if (moving == false) {
  if (event.keyCode == 37 || event.keyCode == 65) {
   if (hypeDocument.currentTimeInTimelineNamed('x') > 0) {
   hypeDocument.continueTimelineNamed('x', hypeDocument.kDirectionReverse);
   }
  } else if (event.keyCode == 38 || event.keyCode == 87) {
   if (hypeDocument.currentTimeInTimelineNamed('y') > 0) {
   hypeDocument.continueTimelineNamed('y', hypeDocument.kDirectionReverse);
   }
  } else if (event.keyCode == 39 || event.keyCode == 68) {
  hypeDocument.continueTimelineNamed('x', hypeDocument.kDirectionForward);
  } else if (event.keyCode == 40 || event.keyCode == 83) {
  hypeDocument.continueTimelineNamed('y', hypeDocument.kDirectionForward);
  }
 }
}

Key Codes:

  • Left = 37
  • Up = 38
  • Right = 39
  • Down = 40
  • A = 65
  • W = 87
  • D = 68
  • S = 83

Basically, I have two timelines. One controls the X movement and another controls the Y movement.

It's a tile based game, so I stop the timeline with keyframes.

Controls are probably a good starting point for a Physics API. B.R.O.O.M. works because minimal collision detection is necessary. So far, I stop the actor from leaving the scene by going too far up or too far to the left.

I have to figure out if I'm going to scale the whole scene or make the level changebased on the screen size. That's where the "view" in Matter.js would be handy. It's probably easier to scale the whole scene. Heh, but I'm not sure what to do with the different ratios... 3:2, 4:3 and 16:9.

71

I was wondering what happened to @jonathan - I posted the example, but I didn't see any feedback. Was the example bad... or perhaps it was helpful and Tumult is keeping the new physics options secret?

I did see mention of something interesting though...

It seems that Tumult does have exporting Hype projects to standalone apps on their radar. That could be another cool Pro feature.

Also, I was surprised to see that @Daniel is in New York. Are you two on different coasts? Does that hurt or help development? I'm in NYC too.

Anyway, there wasn't much progress for me this week. Maybe this weekend I'll make some more progress on my Hype game.

72

Another good idea for a Physics API is collision detection by type.

Exampleā€¦ if you have a tank and a helicopter, the helicopter should fly over the tank ā€“ but the projectiles from the tank should hit the helicopter.

Iā€™m not sure, but I think the terminology for this in Matter.js is collision filtering. The following thread seems relatedā€¦ https://github.com/liabru/matter-js/issues/48

1 Like