Is there a Physics API? đŸ€”

Physics
37

What's the important word there... SOON ...that sounds exciting. Physics APIs to change origin, rotation and velocity moves Hype into Game Development land.

So, is this soon like before the WWDC or before the end of 2015... or later than that? You seem to be on a six month development schedule.

It seems like the Thin / Full javascript should be more dynamic. So, if someone doesn't use the Physics APIs, then the extra code needed to access them isn't added. If someone doesn't support IE8 and below, then all that extra Microsoft junk can be eliminated too. The JavaScript that's generated could be optimized based on the project. That would lead to fewer and smaller files. Heh, that's easy to say, but I imagine it's a bit involved.

Wow, that would be a bad day in the land of Tumult. Although, I think basics like X/Y, origin and velocity should translate to a new engine. Also, so what if Matter.js development stops. Where are the pitfalls? Is it future browser compatibility? Is it new features like convex collision shapes? It seems like if SVG shape creation/editing was moved into Hype, kinda like vector shapes could be created in Flash, then that would make Hype a complete replacement for Flash – especially with a built-in physics engine.

Wow, that's brutal. No Hype!

I used to create apps for the Mac App Store and iOS, but Apple's walled garden got quite annoying. Articles like this...

...seem to confirm the bad situation. Sandboxing was a big issue. That caused a lot of developers to leave the Mac App Store. Plus, if the sales aren't so great for a top ten rank, it might not be worth the trouble. Apple did give you great exposure though, so hopefully that 20% of frustrating developer time translated into good sales.

I actually called the Mac App Store the home of the new Creative Suite...

For the work that I do, Hype, Pixelmator and iDraw are almost full replacements for Flash, Photoshop and Illustrator. The Physics API for control elements (and Matter.js views for controlling the size of the scene) is the only remaining piece to eliminate Flash from my toolbox.

I'm surprised that you support JavaScript. It seems like it wouldn't be covered. Although, even this dialogue is also surprising. I've chatted with a lot of founders. I don't recall an open and honest exchange that would rival this one.

38

We don't publicly comment on our release schedule, but I can say it won't be before WWDC. Hype 3/Pro was a much longer release (13.5 months from 2.5.0) than we like doing and than we ever want to do again :smile:.

This conversation has re-ignited my desire to do the per-property API, which we were just discussing today.

I would love to have it be more dynamic (and think fundamentally this makes complete sense). There's a few hurdles which is why we do the thin/full split now:

  • If the functionality is broken up into pieces, that means more connections which would be bad on mobile
  • Our programming process and getting everything right becomes much more difficult (extra QA/fix times)
  • The minification process is actually a significant portion of our build times, so minifying more would drive us nuts during development!
  • If there's multiple files (whether pieces or different full runtimes) then it makes the export folder big and ugly
  • There are some cases (for advertisers) where the runtimes can be cached across different documents and this would make it harder

There's not a strong pressure currently for us to do this, but if a customer like big advertiser (who often has size constraints) needs it then it may be more of a priority.

Matter.js itself is pretty vanilla javascript, so it would never really break. Being open source we could always carry the torch for things like compatibility fixes, but physics isn't quite our expertise at the moment. I'm not very worried, it is under very active development and has seen some new contributors lately. Also I'll point out that Liam is about to merge in a compound/concave branch!

This is a big feature, but you're right it is one of the few remaining pieces of Flash that is unaccounted for.

We make a nice amount of money from Mac App Store sales.

Great article!

Well, we do want users to become successful using Hype. And we get excited by their projects too, so when someone turns to us for help it is hard to say no!

I love when users like yourself dig so deeply (to the point of hacking) into a technology! The code is all there, and I also enjoy talking about our decisions/tradeoffs since you bring up excellent feedback.

39

That's not a problem. You don't need to comment publicly. You have my email address. Ha ha!

But basically, it's somewhere between June 2015 and less than 13.5 months from the launch of Hype 3.0. That's not terrible. I can focus on a different project while waiting.

Ah, breaking up the JavaScript into pieces seems like it would make it more manageable, but I was imagining a single JavaScript file. Like, instead of having a full/thin or separate Matter.js files, one JavaScript file would be created by the Hype application. Obviously, that's difficult programming, but that would create the smallest files possible.

I'm not so obsessed about minimized JavaScript. Personally, I think a little JavaScript bloat is probably OK if the Physics features are more useful.

Although, I am working on a Hype project that is getting quite large. I'm not sure how big is too big. You guys fight to keep the JavaScript down to double digits. I'm only 3% into my new project and the generated JavaScript is already quite large. I don't know if it matters since it's an app and the files will already be local. Maybe that's the difference in philosophies. Hype seems great for banner ads, where small file sizes matter. But for games... players probably don't care about waiting a few seconds longer.

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

That's good to hear. I've been debating if I should try the App Store again. I haven't decided if the reward is worth the frustration.

Ha, I'm tempted to make a new post with all the JavaScript issues I've been having. Although. I can figure them out. Heh, I think it's better if you're busy working on the Physics API.

I think I'm feeling inspired to keep working on my current (not so Physics related) Hype project.

40

I am glad that the Tumult team is in constant improvement mode and that the community is there to push for improvements.
I applaud @photics for taking such a deep dive. I am learning a lot from his journey through the API. It has been very helpful :smile:

However, I wanted to add another perspective to the discussion.
Not a criticism in any way.

There are 3 distinct types of users in this community.
Those that come from the coding background, and those (like me) who come from the design/illustration/lite coding background, and those that are purely visual artists.

I worked with Flash from the time it released and loved it until the HTML5 standard became available and saw the potential of creating some great stuff without forcing my users to install a plugin.

I can see how there are still some areas where the physics API and the javascript support could become more robust.
For instance an easy collision method would be huge. But HTML5 for a few years was a code pro’s landscape.

Visual thinkers and visual problem solvers would much rather draw a rectangle than build one in code.
They would rather apply a slider to attach a Physics movement than write the javascript for it.

If you have a purely creative background, the update from 2.0 to 3.0 is pretty significant and has allowed many folks the ability to spread their wings even further in the HTML5 content creation space.

I have always taught students in the digital creative space that the tool you use is only as useful as what your creative ability can do with it.
One of the nice things about the physics engine being in it’s infancy is that it is teaching creative pros how to problem solve with what they have while learning about digital physics.

And that is a positive outcome.
We are at a spot in the creative professional history where the artist MUST learn more about the underlying technology for digital content.
It has always been the joke that “artists became artists because we hated math class” :wink:
Hype is one of those tools that allows the non-coding artist to ease their way into subjects that scared the you know what out of them a few years ago.

They are expanding their knowledge of the new creative content landscape with this tool. I have student’s that have been stuck in the world of “just print” and have been suffering because they did not think they could ever make an ebook or an app.
I encourage so many creative professionals to join these forums after they have found that A-HA! moment when they publish their first Hype project online.

So I hope you all find the magic Physics bullet that will make this tool even better than it is today. Maybe in 12-13 months :wink:

But in the end these discussions and the tool itself are changing a lot of peoples creative output for the better, and I am grateful for that effort.
Thanks Tumult and the Hype community!

5 Likes
41

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

3 Likes
42

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.

1 Like
43

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/

44

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.

1 Like
45

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 


1 Like
46

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.

47

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

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

2 Likes
48

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.

1 Like
49

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.

50

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.

51

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


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.

1 Like
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.