I didnāt know what the x:0, y:1 was about. Whatās Ub? So, I searched for āUbā and thatās apparently set to āgetElementsByTagNameā. This is what I mean!
If I have a main character, say heās called āTANKā. If I want to move him right, then the code should be something likeā¦ If right arrow key is down, set TANK X to X+1. I should be able to change the physics values of an element (such as force or location) based on its name.
Clearly, itās not so straightforward. There might be loops, arrays and all sorts of other JavaScript going on. At least I seem to be on the right track. Force has to be in there somewhere, as the elements can have inertia. That value has to be stored somewhere.
If youāre wondering about what kind of games Iām trying to build, hereās an example of my previous workā¦ https://photics.com/bot/
Did you build that one in Stencyl or Gamesalad Very nice!
Also maybe just maybe you could integrate Gamequery.js into Hype.
Might be an easier route for Hype based Game development with controls. http://gamequeryjs.com
I built it with GameSalad, but then I tried porting it to Stencyl. I didn't complete that project, but I did port Annoyed Tomatoes to Stencyl... Annoyed Tomatoes ā Photics.com ...and it was running in Flash for a while, but then it stopped working. I wasn't sure if it was an issue with a recent update to Flash or a problem with switching my website to https. Either way, I realized that Flash was dying.
I'm not really into app development either, as Apple's review process is annoying and I'm not a fan of Google. That's why I'm looking at HTML5 game development. GameQuery looks interesting. I'm not ready to give up on this Hype project just yet though. It seems like I should be able to do what I want to do with JavaScript.
My first approach was to try and trace the code to the physics engine. That hasn't been so easy, so I've been trying a reverse approach ā looking at the variables stored in the browser.
That exposed a weakness in my skills. Apparently, I'm not good with the console. HA!
I seem to be underestimating the complexity of this project, as I realized something... how would I print the value of "Ub" inside a div? I might not know where the force values are stored, but I do know that "Ub" equals "getElementsByTagName". What if I wanted to use Hype's shorthand in my own code. It's not that I need to do that, but it is a good test of what I'm trying to accomplish.
That's where I'm at right now... finding where the Hype variables are stores and then printing them to the screen. If I can print them, I should be able to edit them. Then, it's just a matter of finding where the other physics values are stored.
The good news is that I probably could port Annoyed Tomatoes to Hype.
I have run through the tutorials but have not tried to integrate it into Hype.
I am thinking that since Hype can handle jQuery this might be a nice add on.
The biggest piece of help I could see with Gamequery.js is a solid collision set.
I almost mixed gameQuery with Hype, but then I stopped. The development seems to have stalled. I'm not quite sure where to begin and I don't feel like learning another JavaScript library / game engine. Plus, there are only a few features missing from Hype that would make it a great HTML5 game development platform.
Today, I started using the developer version of Firefox... Firefox Developer Edition ...I know there's something going on that I can't see, so maybe this software can be used to dig deeper. So far, I did see something interesting...
Ha ha, black boxed. That might not mean what I think it means, but it does add to the allure of this project. It's like a secret. I'm trying to find it. Even if I fail in my search, I've already learned some new things about web development.
I decided to try a different approach... compare an old Hype.js to a new Hype javascript file. By finding the new additions, it probably leads to the physics code.
Md = '%c [Matter] ',
That definitely wasn't there. I was wondering of these are new...
Xa = ' translateX(',
Ya = ' translateY(',
Za = ' translateZ(',
...but they were there before. Both files have that code. Although, the variables are different in the new one...
I think that's what the problem is with Hype. I can slide an element from a dynamic starting point, but the end point is not dynamic. Otherwise, I could just add controls with different timelines. (In other words, I can move an element to a location, from a previous location, but I can't move an element by a specific amount... such as X = X+1)
Also, I'm not sure how a "Z" translate would work, so maybe I'm thinking of something else. Would "Z" be zoom/scaling? I'm not sure, as new scaling terms were added...
vd = ' scaleX(',
wd = ' scaleY(',
This is right next to the translation related variables. I suspect the scale variables are related to responsive theming, as the box itself can increase and decrease in area.
I'm not sure what the benefit of that might be. Speculation ā maybe it's a way to take existing HTML data for an element and give it physics properties? I don't know for sure. I might be seeing what I want to see. The next one though, that seems closer to physics...
nb = 'speed',
The word "speed" does not appear in the older Hype JavaScript. The comparison is from more than a year ago, so I might be missing some features that were launched before Hype 3 / Pro. Although, I'm not sure what else "speed" could be related to than physics. Velocity is speed with a direction. That would be a prime addition for the physics api. If Speed and direction (Basically the X & Y speed values) can be changed dynamically, then that's the beginning of building a control system, adding artificial intelligence and other critical parts of game creation.
I'm not sure if "force" is the Matter.js or Hype way of managing velocity. I didn't see the word "force" in either Hype.js document. But while on the subject of popular words from Science Fiction movies, "Matrix" was in the newer Hype JavaScript.
Oe = '.Matrix(M11=',`
This seems to be part of de-minifying the JavaScript. I'm not sure what the variables are, and they do seem to change between major Hype versions, I'm thinking the variables are the same between projects. Here's an example...
mj = 'World',
That was mentioned earlier in this thread. It's a new one, as it's not mentioned in the older JavaScript file. It seems probable that "World" is Physics related.
This next one could be huge...
il = 'collisionActive',
jl = 'collisionEnd',
kl = 'collisionStart',
Once the controls are working, collision detection is important. That's how the main character can stop moving when it bumps into walls, take damage when hit by projectiles or gain bonuses when collecting power-ups.
If Tumult is not sure what to add to the Physics API, being able to move elements dynamically... or being able to do something when collisions occur (like run JavaScript or play timelines) seems like pretty basic stuff.
It still seems that it is possible for this stuff to be accomplished with JavaScript. Although "dramatic hacking" does seem correct. I know the existence of these variables, but I can't do anything with them yet. Even the most basic of using "mj" to display the word "World" in "Hello World" is out of reach right now.
The future looks bright though, as I saw this...
ql = 'controller',
rl = 'controls',
Perhaps Tumult is already playing with advanced game development. Those two variables are new.
I think opening up the API is more work for Tumult, but it makes the software more useful. Here's another example.
ul = 'deviceorientation',
That seems like it could be incredibly useful for mobile development. Also, here's another new variable...
Wa = 'timestamp',
If that means UNIX Timestamp, That's an excellent one for game development. If these values are already in the code, why not let developers access them? If that does happen, it would be nice if Javascript minification/shorthand never changed ā like "T" for timestamp.
Anyway, the two JavaScript files were too big and too different for a precise comparison. (I used TextWranger and it listed lots of differences.) This is a bit of progress. Here's what was learned...
Using developer software, such as Firefox Developer Edition, or the Inspect in Safari, can easily de-minify JavaScript code.
Tumult might already be experimenting with advanced physics settings and/or game development features, as some interesting phrases are already in the code.
This isn't just beneficial for game development. Apparently, handy code snippets exist in the code that could be beneficial to developers in general, such as timestamp and device orientation.
Officially, I should tell you that anything you do or we discuss from this point on is COMPLETELY UNSUPPORTED. It might change in future versions. If you hack the runtime you're gonna be in a world of pain. It isn't something we as a company want or should spend time on.
But since you seem quite curious, I'll elaborate a bit more.
The easiest way to get a grasp on how the Hype runtime works is to get an unminified version of the source. We ship a version for debugging purposes. It still is heavily pre-processed and has some custom minification steps applied, but is much more legible. You can get to it by right-clicking on the Hype application and choosing "Show Package Contents" then navigating to the Contents/Resources/HYPE.full.js file. You'll even find some comments (for our benefit when developing, not yours) in it .
It should be much easier to find Matter.js in this version, as it occupies most of the bottom third of the javascript file. Do note that we use a custom build from our own fork, so it isn't a 100% match with what you'll find in their repository.
I believe the unminified version can be swapped into an exported document and used instead. You'll need to change the filename to match the version HYPE.full.js would become HYPE-466.full.min.js. Now you can have more fun debugging. Ultimately we run this code through google closure compiler to produce the minified version.
This is the result of the minifier, it extracts strings that are used in multiple places and assigns very short names to them. Don't rely on these variable names, as any re-compile will likely result in new ones!
It is used for the Swap scene transition - you can see one scene moves in front of another in the Z direction.
haha! concat is a standard function for concatenating two arrays together; Matter.js simply uses it.
Matrix mathematics is heavily used in graphics programming. It is the general basis of CSS3 transforms which allow translation, 3D rotation, scaling, and skew. We use the specific named functions for these, but IE6-8 does not support CSS transform syntax. They do however support matrix operations, so we use this instead and you're seeing it in the code.
The ultimate problem you're running into is our encapsulation. We try to be a very good citizen and do not leak our variables into the global javascript namespace. Hype only exposes a few top level variables on the window object. We also don't want people mucking around too much with our internal code, as we'll wind up in a situation that does not allow us to make internal changes without breaking people's animations.
Basically, to do any modification you need to figure out a way to break our encapsulation - this can't be done outside of the runtime, you'd need to change the javascript itself. At least, if you can access these variables without changing our code, then our code isn't working right!
I'm surprised these would show up as new, but it might just have to do with minification changes. These are not as exciting as they sound, they simply have to do with the controller of video and audio elements .
99.9% of anything in our runtime is in active use; for file size concerns we don't ship unused code. As you can tell by the minification we take file size of our engine very seriously!
While I don't think it's so dire, it does discourage me from continuing with this project.
I figured that all of those two-letter thingies were probably generated automatically and could change. I didn't know what software was doing it though. This thread is full with knowledge.
I tried swapping the JavaScript files and it worked. With access to the source, I probably can do a lot, but that's not the point of using Hype though. The idea is that I don't have to code. HA!
I'm not sure what to do next, but nice reply! It's a lot to think about.
Why is this a good thing? I did some quick reading on encapsulation and it seems that there are strong arguments against private variables/functions.
The current situation certainly makes it challenging for advanced game development. I've already seen some grumbling about the limited use of the new physics feature. Hype can't be everything to everyone, but opening up the code might attract more customers and make the software more flexible. Hype is often referred to as a replacement for Flash. One of the main attractions for Flash was gaming. It started numerous online communities. Developers could make games and people could play them.
I'm not quite seeing the Tumult perspective. How would accessing Matter.js or Hype functions/variables be bad? Sure, the software can change, but isn't it healthier and more exciting for the community to be tinkering? When I saw the raw JavaScript, it reminded of me of the guys from the 50's and 60's working on their muscle cars. While cars (and even Apple computers) are becoming less and less common for tinkering with hardware, web development is a place where people can create.
I'm thinking that if Hype did open their functions or variables, and something changed with a major upgrade, it probably wouldn't be as dramatic as HTML4 to HTML5 or Drupal 7 to Drupal 8. Have you seen what it's like to go from Drupal 7 to Drupal 8?
Yes, I'm one of the few developers that misses the blink tag, but I'm not about to write stern letters to the World Wide Web Consortium, Google, Microsoft, Apple and the Mozilla Foundation. Ha!
Here's an example... what if "collisionActive" is actually a way to detect collisions. The community gets together and adds advanced code. For some reason, the new attribute is now called "cActive" in version 4.0 of Hype ā or perhaps Matter.js is replaced with something else and collision detection is completely different. Wouldn't just the community pull together and make suggestions on how to fix the problem? That makes this a more popular place. Wouldn't seeing what people build with their customizations show you the best areas to automate and improve Hype?
You don't need a degree or a certification to be a web developer. Learning by doing seems to work best. I think web developers are fairly resilient regarding changes. That's what keeps us employed.
This JavaScript is more complex than I usually have to work with. I decided to read the comments, to better understand what's going on.
var getElementById = function (id) { // public, do not change signature without wrapping in _hype['API']!
Public... is that us?
Signature?!
I did see the phrase, API. That seems encouraging. Also, I'm wondering, what's the license on this code? Since it uses matter, is this automatically MIT licensed? If it's open source, that's exciting. It means that developers can contribute code.
I'm thinking not, as I saw this interesting comment...
// HypeAudio.js
// Hype
//
// Created by Jonathan Deutsch on 7/17/12.
// Copyright (c) 2012 Tumult Inc. All rights reserved.
Anyway, that hype[API] comment appears multiple times in the JavaScript file.
It's like a work of art to read this code. Seeing how cross browser issues are handled is what makes HYPE useful. With Flash, it just worked across multiple operating systems and browsers. With HTML5, it's a bit of a mess. The extra work to straighten out this issue is impressive.
Also, I have a story, if you're still worried about adding additional Physics features or expanding the API. Stencyl had a major change from version 2.x to 3.0. They dropped ActionScript and switched to Haxe / OpenFL. For those sticking to the core blocks, it was a non-issue. For those doing custom coding, it created a big problem. I'm surprised at how well the community survived that. It's so polite over there.
return { x: origin.x, y: origin.y, angle: angle };
};
// returns an { x, y } point
// cannot calculate width/height as these are dependent on proportionality (we'd also need the bounding width/height, but I don't think we'll ever be in a position to supply this)
// generically useful function, but I'm keeping in PhysicsTemplate so it doesn't bloat the runtime
That's an interesting comment. This seems like part of the gaming trinity... Position, Velocity and Collision Detection. The origin of an element is important. If the top left corner is know, and knowing the width/height of the actor is also nice, elements can be moved dynamically. The words, "I don't think we'll ever be in a position to supply this" is interesting. What isn't being supplied?
When I tested the demo and scrolled the whole scene with the mouse wheel, I was happy. I knew it could be used to solve problems like this... Scaling content together - #5 by MarkHunte
The view could be used to create scrolling games or scrolling scenes. It could also be another way to handle responsive design.
My JavaScript coding doesn't seem to be up to the challenge of the Physics API project. But if this thread changes the views of Tumult, showing how adding a Physics API is important to Hype, then it was successful. I still felt like trying, so I kept reading.
// if there's been no width/height is likely a text box without explicit dimensions. We still need to know what it is
if(widthValue == null) {
widthValue = currentElementSize.width;
}
if(heightValue == null) {
heightValue = currentElementSize.height;
}
"We still need to know what it is" ...those words alone makes a strong argument for exposing variables. Where's the harm in making the width and height variables accessible in Hype? Where's the harm in making the origin (X,Y) accessible? Where's the harm in letting developers change that information dynamically with JavaScript? Hype will likely grow, but origin, velocity and rotation seems fairly consistent.
By swiping, the gray ball can be moved up, down, left and right. The problem is that itās using Hype tweening for movement. While in this state, physics are ignored. That makes me wonder ā what was the goal of adding physics in Hype? Itās close to being useful, but the lack of physics options makes it limited.
Keyboard Controls (āOn Key Pressā should let you specify a specific key.)
Read / Write physics element data (X/Y Location, velocity, rotation)
Collision Detection events
Dynamically Create / Delete āBodiesā (Elements)ā¦ gamers call this spawning. This would probably work well with Symbolsā¦ hypeDocument.createSymbolById(āidā, X, Y)
I was looking at a list of HTML5 game enginesā¦ https://html5gameengine.com ā¦and there are so many alternatives. The problem is that I really like Hype. I like the interface, itās really good for creating interactive banners and it seems to have potential in game development.
I think Iām starting understanding the perspective of Tumult. Perhaps additional physics settings were not added because they conflict with the tweening.
Seems like your are in a technical tarpit.
You want an app that is a game development app that is not a game development app.
Good luck with your quest.
I was fine with Hype until the Physics feature was added. Realistically, that's the main reason I got Hype Pro. In the promo video it showed very game like examples. I realize that Hype isn't exactly game development software, but it's really close.
Actually, thinking back, Hype didn't do that much when it was first released. It wasn't until relative timelines were added that I could actually build stuff with it. I think that was version 1.6. Now, it's the same with Physics. It's a neat toy, but a few changes would make it better for production / game development.
The way the code is structured is generally meant to discourage (more on that later), but it is hard for me to personally want to discourage the type of hacking and exploration that you're doing. So it is kind of the "that's awesome... please don't do that." mentality that I have!
There are many reasons for the encapsulation:
Provide a stable platform developers can work with that has 100% forwards compatibility (or as close to it as possible)
Do not expose items which may require specific knowledge to use correctly or should only be used by the implementation
Allow us to make major under-the-hood changes without worry to the consequences, thus being able to be more innovative
Do not allow rogue scripts to interfere with Hype and not have Hype be a script that interferes with other items on the page (some of this can be done with proper namespacing, but the point holds)
Specifically in the case of Matter.js I'd like to mention this is our first release with Physics. Matter.js is a very promising project and becomes more so each day, which is why we chose it. But there is always the risk that the developer may stop working on it (we may or may not have the bandwidth to pick up the torch), his priorities in the project may change to something incompatible with Hype, there may be massive issues that we only find out during a public release, or other projects become more promising. In this case, we do want the freedom to potentially change Physics engines. If Matter.js were exposed then we'd be stuck with it.
Our attitude is "An API is forever." This is conservative, but we believe adds a lot of value in knowing a Hype upgrade won't break your documents.
After a period of time, when we've assembled enough use cases and confidence, we open up APIs.
This type of reputation is what we're trying to avoid .
Some would, which is great. However not everyone has the same access, motivation, time, or money. Also projects get handed off to clients or other designers. They may suddenly find themselves in a boat where they don't have the technical knowhow to make required changes anymore.
To give a more specific example, let's talk about Apple. Apple forces changes on developers. I'd say 20% of our company's time is dealing with Apple-forced changes, typically that do nothing which improves Hype for our users. It has gotten much worse as OS X updates have gone on, it took months of effort to comply with their sandboxing. This isn't helped by new OS releases coming out on a yearly schedule now. Had I known about this ahead of time, we may have not chosen to develop Hype at all.
In this regard I like to follow the golden rule of "do unto other developers as you would have them do unto you."
Absolutely agree this is a great thing. But it does bring up another reason of our conservatism - support. Hype is a very difficult tool to support, and users expect free support. They work with all different types of browsers, devices, servers, CMSes, code, and so forth. We have to be experts on it all. JavaScript support is some of our most difficult and time consuming.
Yes, public is you - very specifically this method is used both internally and externally in the hypeDocument.getElementByID() API! To save space we use the exact same method instead of having a wrapper between the external/internal versions.
Signature in this case means the name of the method and the arguments. The reason for the comment is a word of warning that if I need to change the internal version, I must preserve the name/arguments for the external version to maintain backwards compatibility. That comment is thus just some protection against unwanted changes.
We've never explicitly defined a license on the un-minified code (sorry, there are a few business complications for this), but clearly the minified exported product needs to be able to be used and modified by anyone.
So that's funny for two reasons. The "All rights reserved" just comes from Xcode boiler-plate, and probably shouldn't be in there. But it is funny because I did originally intend for the HypeAudio.js file to be a full open source project. It is some nice wrappers to preloading and playing audio in a cross-platform manner. However close to shipping v2.0 I discovered there was one area where it needed to interact with the Hype runtime for some browser bug workaround and so didn't go any further with open sourcing it.
I think there was some issue in taking an element that is flexible, converting it back to its canonical sizing, doing transformations, then re-converting back to flexible sizing. It isn't an impossible operation, but one that would not be performant (performance is generally really important for this method) and also would bloat the runtime. So I don't think we'd ever be able to do the conversion for width/height even though it would improve the correctness when dealing with flexible layouts and physics.
We do want to open these up! The reasons we haven't thus far are:
We probably would prefer if users could simply modify the natural CSS properties so there's no extra learning curve, but this would require potentially impossible/impractical changes for Hype
So instead we could provide access to the wrappers and allow users to use an API to make the changes. The wrapper names are now all minified, so we'd then need to have non-minified versions with nice names for users. This would bloat the runtime. If you haven't yet figured out, runtime size is very important to us
That said, at this point I think the pros outweigh the cons, so you may see this soon .
The general goal is to help make animations which would otherwise be very difficult with keyframes. Natural motion/physics is in this category.
We do realize it is limited, but as similar to the API, wanted to be very careful at first since (especially when we started) the engine choice and how people would use it were a bit up in the air. Now that we know more of what people want to do, we'll probably take it further. I'll also mention that we cut some Physics features short because the new UI simply took longer to implement than I expected. Gotta ship!
They are definitely two different worlds of animation. We've bridged the gap a little, and hopefully can bridge it more.
I think there's a bit of a rabbit hole we go down when we started playing with Physics... it was so much fun so we wanted to see how far we could take it with interactivity - and this lent itself to game demos.
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.
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 .
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.
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.
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
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ā
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
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!
.
haha! concat is a standard function for concatenating two arrays together; Matter.js simply uses it.
.
