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.
Anyway, as Iām playing this game, Iām thinking in my head about Hype. If there was a physics API, could this game be made with Hype? The one feature that really stood out was the ābullet-timeā. Whenever Pac Man is about to collide with a ghost, the game slows down. Itās a lot of fun. Iām thinking Matter.js could do this, as it has something called āTime Scalingā.
Wow, that would be interesting with Hype. Of course, thatās probably not easy to implement, as how would that work with the timeline? Yet, it if did, a whole project could be sped up or slowed down with a global āTime Scalingā setting.
I recently saw mention of Hype 3.5 by @stephen in another thread. So, maybe this thread will see some action again. Is Hype working on better Physics settings?!
Also, while not quite Physics related, I think Full-Screen view should be a default option in Hype ā a way to toggle between regular and full-screen modes. If Hype is going to have video game like features, full-screen is a great way to show that off.
ā¦and supposedly an SDK for third-party developers is on the way. If thatās true, one of the first things Iād probably look for is if āWKWebKitā is available. Iād be able to create a game once, but port it to so many different platforms.
It looks like things are about to get interesting.
Ha, that is an interesting way to do top/left movement with timelines! You'd probably want the general collision detection to be in javascript based on tiles and just allow changing direction based on that.
Sorry, the new forums are harder to track than our old ones and if I'm off the radar for a little bit I can lose posts to see or respond to!
We used to all be in SF together, but earlier this year Daniel's fiancee got a job in NYC and so he moved out there. It is nice having everyone in one office, but we have tools that help us collaborate and so it has gone pretty smooth.
Time scaling is indeed a cool feature; it'd be easy to implement (simply change the wall clock time by a multiple), but the Hype app interface would be confusing (since there'd need to be top-level keyframes for the "time" on the animation timeline!). Also for keyframe animations there's less of a need since animators have it within their control to do whatever they want.
Don't hold your breath for much difference in Physics in 3.5, sorry! The release is more focused on making lots of small improvements and Physics is a bigger item than we wanted to tackle in this specific version.
Iām working on the āInspector: Physicsā section in āA Book About Hypeā, and Iām noticing a few thingsā¦
Gravity (both force and angle) should be timeline properties
Density, Bounce, Friction and Air Drag can be set to negative. Iām thinking it probably shouldnāt be able to do that. Itās not logical and the results are weird.
Density, Bounce, Friction and Air Drag donāt seem to affect elements with a āStaticā āBody Typeā. What if I wanted to make a trampoline or an icy walkway? I suppose there are other ways to do that. This is more of clarification. Is that intentional? If so, perhaps these four settings should be grayed out unless āDynamicā is selected.
There should be another setting for rotation ā Allow Rotation / No Rotation. Sometimes I just want a ball to bounce up and down. With rotation, the results can be erratic.
I noticed that @jonathan mentioned this thread in another thread by @Franeko. The question was actually related to real world physics, like the accelerometer.
Itās actually really easy to get accelerometer data and use it in a Hype projectā¦
event.accelerationIncludingGravity.x
Maybe that should be part of the Hype Physics API too, but it seems too simple. This thread has been about accessing Matter.js. Iāve had success working with Accelerometer data in my Hype projects. Matter.js in Hype is different. Thereās so much potential there, but I canāt access it.
What's odd is that I thought I saw something about a web browser being shown on the Apple Watch. I'm not entirely sure, as I don't have an apple watch, but I think it might support webviews. Why Apple would allow that for a watch, and not a TV, is strange.
The argument I've been hearing is that Apple wants high-quality apps for the Apple TV. Naturally, I disagree.
Anyway, I saw something interesting. I'm not sure if it was discussed...
As a detail: we do use the fromPath API already for the round rectangles and ellipse shapes. The version currently included in Hype didn't have support for concave polygons so that limited a lot of what we could do, but it has since been implemented so the door for shapes is quite open in the future .
A lot of projects become possible with Hype if SVG and custom (convex) collision shapes are available ā especially if an image can be embedded into the SVG.
Update: I noticed something interesting in the SVG example. By clicking the āshowInternalEdgesā option, it shows that the collision shapes arenāt really convex. Instead, itās just a series of concave shapes grouped together.
I noticed something different today. The keyCode numbers are different from Hype's "On Key Press" event than manually using the following JavaScript...
window.onkeydown=function(event){
I was working on getting Fullscreen mode to work, which is ideal for gaming, when I noticed the "F" keyCode was "70" when I used "onkeydown", but "102" when using Hype's "On Key Press" scene event.
It took me a while to realize what's going on. "On Key Press" appears to be case sensitive. It doesn't register the shift key right away. So if you've been following along in this thread, wondering why the keyCode numbers don't work, it might be the difference between onkeydown and onkeypress.
We feed a lot of small straight edges to matter.js; they take a "path" that is a series of points. We do the math to figure out a close approximation of roundness.
Note that this isn't related to Hype; it is just a difference between the keydown and keypress event. Hype does expose both, since they are (unfortunately) quite different. I'd recommend reading the post mentioned in here:
I think I might have landed on that page when trying to figure out what was going on.
I must have been really tired last weekend. I looked again and I can see that both are available. That's cool, because the difference is important for game development. An example would be pinball ā where shift keys are great for flipper control.
Note to self... use event.location for detecting the difference between the shift keys.
This may be unrelated to the current thread but since finding out this thread Iāve been trying to analyse matterjs since itās extremely fast on ipad but itās documentation is really bare bone compared to something like physicsjs. Do you have any source of documentation apart from the docs page there you could share? Like any experiments youāve found or experiments youāve created using that library? Iād be very much interested in either of those to see it in use by others!
I mainly read the source code. At the time the documentation was good (at describing the APIs, not necessarily as tutorial material), but there were a few parts out of date.
While Hype still needs improvement with a Physics API, two new JavaScript APIs create lots of potential with game development. The āBounceā project would have been a lot more difficult, if at all possible, before Hype 3.5. Good stuff is on the way!