    
|
|
|
|
|
|
|
A long time ago on a web far far away there was the promise of HTML5 games. Unfortunately, this future still hasn’t come to fruition. In this rumination, I will explore why that is and what hope HTML5 games have for the future.
Back in the late 2000s, new technologies grouped under the umbrella term “HTML5″ promised many things. One of the most exciting applications was the idea of HTML5 games. No longer would games be confined to compiled C++ code and desktop applications. In the future, people would play HTML5 games on their phones, tablets, and whatever other crazy devices would come along the way.
In theory, games in a web browser seem like they have a lot of advantages. For example:
If all of these features are so great, why aren’t there more HTML5 games?
There are lots of game engines to choose from (here’s a list of engines for making HTML5 games), but none of them has reached “de facto” status. Even the most popular HTML5 engines are nowhere close to the heavy-hitter compiled engines like Unreal, CryENGINE, Source, or Unity.
When it comes to software, popularity isn’t always a factor. However, games are very complicated and you will eventually need assistance, so engine popularity is a key consideration. Why? Popularity means there’s more likely to be a community that you can interact with when you need help, along with more people you can work with or hire to build it. If there’s only a handful of other people using an engine and you can’t reach out to them for support, you might be stuck with a time-consuming blend of documentation and experimentation.
Low popularity also means less mature code. If a lot of people are making content for a particular game engine, there will be tons of things that have already been “figured out” for you. Most desktop game engines have many iterations behind them and contain robust tools that dramatically increase quality with far less work. I’d love to be wrong about this, but so far I haven’t seen an HTML5 game engine that can match the tools featured in top-notch compiled engines. If that engine does exist, I’m curious what games have actually been made with it.
There are a few places to distribute an HTML5 game, but none of them has picked up the same momentum as distribution platforms like the iOS App Store or Steam. Google offers games that can be installed to Chrome via the Chrome Web Store, but the content isn’t well-curated and the games are limited to low-quality clones, demos, and ports of mobile games. Probably the best attempt so far has been the Facebook App Center, but even with some additional curation, casual clones with in-app currencies reign supreme. A new contender is the Amazon Appstore, so hopefully its HTML5 offerings will entice more talent.
In the Chrome Web Store, you’ll find a few favorites like Angry Birds and Cut the Rope, but beyond the first screen is nothing more than a content wasteland. Again, I’d love to be wrong about this. If you know of a great HTML5 marketplace with high quality games and up front payments, please let me know in the comments.
Part of the problem is expectations. The free and open nature of the web has produced an environment for games where race-to-the-bottom pricing (i.e., free-to-play) and social features lead to the most downloads. In the current landscape, it would be hard to imagine gamers paying up front for HTML5 games.
The iOS App Store has evolved over the years, but Apple did a smart thing from the start by allowing developers to easily charge for their apps. This set a healthy consumer expectation and it also provided the proper catalyst for developers to spend serious cash making their games. In June 2013, Apple announced at WWDC that developers have been paid $10 billion. Statistics about HTML5 games are harder to come by, but I highly doubt the figures are even in the same universe.
More money doesn’t always mean higher quality, but it’s probably safe to say that a company of talented artists and experienced programmers has a better chance of producing more polished experiences than an individual. Steam is the same way: There’s some very popular free games, but the vast majority of the best stuff has an up-front fee.
There’s nothing close to this with HTML5 games. Why would any serious game development studio or web design firm pour the resources into making amazing HTML5 games and experiences? Sure, they could try monetizing them in the Chrome Web Store or Facebook App Center, but nobody is going to pay money for them up front. That means they’ll have to compete with the endless barrage of free-to-play clones and their game will likely get buried. There’s far more cash to be made elsewhere.
Right now, HTML5 games are stuck in an infinite catch-22 loop. There’s no great marketplace, which means there’s no motivation to make great games. Conversely, there’s no motivation to make games because there’s no marketplace. If HTML5 games are ever to break outside the wasteland of cheap clones and tech demos, then something has to change.
Fortunately, I think this will change soon. The gaming industry has completely exploded lately. Indie games are more popular than ever, the distribution for smaller games is readily available via digital distribution, and capital comes in the form of crowd funding. In fact, games are now the most-funded category on Kickstarter, totaling more than $200 million, and 30 of those games have cleared $1 million in funding.
Just a few years ago, this seemed a complete fantasy, but now it’s conceivable a team of one or just a few could muster the programming and design bravado to pull off a killer HTML5 game. Exciting technologies like WebGL are finally receiving strong browser support, which opens up new audiences to developers. The formula isn’t quite right yet, but there’s hope.
If this mythical beast of a web game is popular enough, developers can charge money and distribute games on their own websites without a marketplace. Minecraft is wonderful example of a game that was distributed in this fashion, sparking public interest in indie games. Today, even big distribution platforms like Steam are moving to self-publishing models.
It should just take one killer HTML5 app for other indie developers to notice. After that, a website that curates the highest quality games could evolve into a common marketplace where consumers know they can go for the highest quality content.
Does such a future seem possible to you? Or will HTML5 games be forever doomed? I’d love to hear your thoughts in the comments.
The post HTML5 Games: A Land of Broken Hopes and Dreams appeared first on Treehouse Blog.
]]>Facebook’s new AI research group reports a major improvement in face-processing software.
Asked whether two unfamiliar photos of faces show the same person, a human being will get it right 97.53 percent of the time. New software developed by researchers at Facebook can score 97.25 percent on the same challenge, regardless of variations in lighting or whether the person in the picture is directly facing the camera.
]]>
Yay! More free pictures! We can now use millions of Getty-owned photos for free on our websites, blogs and social media channels (as long as it’s not for commercial purposes).
Getty’s new offering is promising at first glance. Their description of “commercial purposes” is actually pretty lenient. However, a closer look at the program brings up some other, rather serious implications.
Anyone who needs images to persist indefinitely, even designers posting newsy (here today, ancient history tomorrow) stories, are encouraged to take a long, close look at Getty’s terms of use before proceeding.
Don’t be alarmed by the dry and lengthy legalese; there are really only two paragraphs (at the moment) that refer to the embed feature: just scroll down to the subhead, “Embedded Viewer”.
My first question was, “May I resize or crop an image?” There was no mention about resizing or cropping, but I discovered a couple of other interesting items.
For one thing, “…availability may change without notice.” So an image in a post on my blog may suddenly vanish, and I won’t be aware of it unless I check back. Nice to know.
Then there was:
Getty Images (or third parties acting on its behalf) may collect data related to use of the Embedded Viewer and embedded Getty Images Content, and reserves the right to place advertisements in the Embedded Viewer or otherwise monetize its use without any compensation to you.
It seems fair that they don’t have to compensate us, since we don’t compensate them… but the fact that they can (and apparently plan to) place advertisements in the Embedded Viewer further limits where and how one would want to use the feature.
Getty’s Embedded Viewer could be a useful tool when you need images and don’t mind the branding, but not for anything you expect to persist for more than a very short time.
A little below the bottom line: expect a likely undercurrent associated with use of the viewer; peers (and even some normal humans) who spot the Getty Images branding below the image may regard it as a “budget photo”, possibly degrading the value of your site, and of you.
The core population to whom Getty seems to be targeting the feature is those who have been knowingly or unknowingly abusing intellectual copyrights.
The feature is a fabulous boon pretty much only for those posting newsy stories to the web who don’t mind the Getty-branded copy, and who have no interest in evergreen content.
If you do decide this feature is right for a project, make sure to search only for images that Getty has indicated are ok to embed. From Getty’s Embed Images landing page, I clicked the text link, Search images available to embed. The parameters didn’t show a specific option to search only embeddable images, but rather had the Rights Managed and Royalty Free options checked (which may be, at least for now, how they are grouping available images).
Also, contrary to rumor, the photos do resize if you mess about with the height and width tags in the embed code (as mentioned above, there was nothing in the terms of use forbidding this). They actually resize rather intelligently. Reducing just the width value by half caused the entire image to resize proportionately inside the resized iframe. In that way, Getty are my kind of design nazis: no way is anyone going to mess with their photo’s aspect ratio. Period. Cropping, on the other hand, is not recommended for a variety of reasons.
Featured image/thumbnail, uses editorial image via Shutterstock.
| 6 Professional iOS7 App Design Templates – only $29! |  |
Man has long envied the avian ability of flight. Wings offer the opportunity for flight, yes, but also for exploration and a different point of view. Now, three UMBC alumni are working to borrow that vantage point through the Robo Raven project at the University of Maryland, College Park. We spoke with Meyerhoff alumni Ariel Perez-Rosado ’11, M19, mechanical engineering; Luke Roberts ’12, M20, mechanical engineering; and Alex Holness ’13, M20, mechanical engineering, about their continued connection in graduate school and what it is like to work on this amazing micro air vehicle.
Q: Why did you decide to study robotics?
Ariel: I never really intended to study robotics. I was more interested in materials and structures. However, when I started at College Park, I started working with the wings of a small robotic bird. When it came time to run more experiments I had to rebuild the same robot from scratch. No one else was working on the small bird so I had to figure things out on my own. I slowly started learning what it takes to make a robotic bird. I really enjoyed the project and in order for the project to grow, design changes needed to be made. By the time it came to make Robo Raven I had learned enough robotics to know what we needed to do to make a successful flying robot.
Luke: I decided to study robotics because I wanted to be able to make complete systems that integrated concepts from mechanical engineering, electrical engineering, and computer science and robotics utilizes each of those. I knew it would be challenging, and it definitely is, but I really enjoy what I am working on.
Alex: I have been fond of innovation and technology. Additionally, as cliché as it might be, I liked to build with Legos, K’nex, wooden blocks when I was a child. My parents encouraged and enabled me to explore my curiosities. I became a mechanical engineer because I liked to create things, understand processes and mechanisms, and applicable theoretical concepts. I ultimately decided to be robotics because I experienced a number of other subject topics at internships and didn’t find myself fond of them, and I am able to build things regularly. Robotics covers a variety of topics, which keeps the work interesting. Additionally, it is a cutting-edge field, which does make it viable for a future career.
Q: What inspired this project?
Ariel: Our lab has worked on Micro Air Vehicles for years, but recently the research took a new turn. We wanted to look at controlling each wing independently. This is something that birds do but has not been studied in robotics yet. In order to do this, the wings needed to be powered by independent motors. This means that the wings needed to be larger than ever before and calls for a whole new robot. So basically in an aim to study what actual birds in nature can do, Robo Raven was made.
Q: What are the applications of a project like this?
Luke: There are many applications for this platform. Robo Raven has the potential to be used in the future to monitor farms as a mobile scarecrow or crop inspector, fly at higher altitudes and track weather, or serve as recon for soldiers on the battlefield while looking like a normal bird to the eyes of the enemy. It could also give a push to the FWMAV hobbyist community because of the aerobatics it can perform.
Alex: The project could be used in disaster relief situations, such as gathering video and sensory data (such as chemical sensing). It could also be used in educational programs–bio-inspired robots cover so many disciplines. I remember my best educational experiences being tangible. I am in the process of arranging a visit to my high school to show Robo Raven to a robotics club as a teaching tool.
Q: What’s it like, as alumni of the Meyerhoff Scholars Program, to continue your work together at UMD?
Ariel: It is great to have other Meyerhoff Scholars to work with. I know exactly what they have gone through in terms of classes and experiences. This allows us to hold each other to higher expectations than other students.
Luke: It was really helpful to me that Ariel, whom I already knew, was in the lab when I first got there and helped me get settled in and just have a friend there. I was really excited when I heard Alex was coming because we were in the same cohort and actually roomed together during Summer Bridge. We also worked on a lot of projects together during our undergrad years.
Q: How has your time at UMBC helped you in your work and studies now?
Ariel: UMBC’s Mechanical Engineering Department gave us a great education and foundation in mechanical engineering. The transition from undergraduate school to graduate school was effortless and seemed like an extension of what was already being taught. The Meyerhoff Scholars Program did a great job in preparing us for the research side of graduate school. Thanks to their guidance, I knew what to expect when coming to graduate school. They prepared me and showed me the work ethic necessary to be a good researcher.
Luke: My time at UMBC helped me to learn to push hard, even when classes are ridiculously tough and life is difficult, because there’s a light at the end of the tunnel. I couldn’t see that light very well till the end of undergrad, and now that I’m in grad school and working on this project I see the light more clearly. Sometimes it pops out of my field of vision for a bit but that’s when I put my head down and push on. It comes back.
Alex: The strength of my graduate application and research skills are a result of applying to and completing internships at the admonition of UMBC staff, 5 in total, and, naturally, the academic content I learned at UMBC. UMBC taught me the importance of group collaboration for generating ideas in addition to management of personal assignments and tasks.
]]>|
|
The following is a guest post by Bryan Jones, the creator of CodeKit. I've been using CodeKit for a couple of years now and I've talked about it plenty. In my opinion it changed the game in front end development making it easy to use advanced tools that, while powerful, felt out of reach for many. Now CodeKit 2.0 it out, which has followed the landscape of front end development, bringing us more powerful tools that are tough to pull off otherwise. Bryan is going to introduce it, and I'll interject here and there to share my thoughts as I've been using 2.0 the last month or so.
CodeKit is an app that helps you build websites faster. It compiles all the cutting-edge languages like Sass, Less, Stylus and CoffeeScript. It live-refreshes your browsers. It combines, minifies and syntax-checks JavaScript. It even optimizes images. All stuff that speeds up both your website and your workflow.
There are other ways to do these things, but CodeKit's mission is to take the pain out of the process. You drop your project folder onto the app and get to work. No JSON files to edit, nothing to install or download. No commands to memorize. It just works.
For starters I hired a designer (Guy Meyer) so the UI no longer looks like it was repeatedly beaten with a DOS 5.1 manual. The new version is also 1,400% faster thanks to a bunch of optimizations and works a lot better in team environments.
But what you really care about is how it can make you faster. So instead of listing every new feature, here's the top four that will make a difference right away:
Your website has to look good on lots of devices. You pull it up on an iPhone, an iPad, a Galaxy S3, Chrome, Firefox and even IE 11 on a PC. That's a lot of refresh buttons to click. CodeKit can do that for you.
CodeKit will now live-refresh all of these devices and more. Make a change to your code and a split-second later, every device updates to show those changes. No plugins, no complex configurations. It works even with advanced sites like WordPress and Drupal. Just click the Preview button in CodeKit and then copy the URL to your other devices. Once you see this in action, you won't work without it ever again.
Note from Chris: Not only does the page literally refresh when you change something like a template or JavaScript file, the page will do style injection for CSS changes (whether they came from a preprocessor or not). Meaning designing for interactive states is a lot easier.
CodeKit 1 could do style injection too, but now CodeKit has it's own server built-in (which can forward to MAMP or anything else if you prefer) meaning that literally any browser gets the refreshing and style injection.
Bower lets you quickly install over 7,000 components: jQuery, Modernizr, Bootstrap, even WordPress. Bower is now built-in to CodeKit, so all those resources are just two clicks away. Open the Assets area, select the components you want and click the cloud icon. CodeKit grabs the latest versions from the web, along with any required dependencies, and puts them right in your project.
CodeKit also saves you a ton of work when it's time to update components. Just open the Assets area and choose the Installed tab. It'll show you the version of each component in your project and what the latest one available online is. Update them all with a single click, or pick and choose.
Note from Chris: while I haven't had a chance to use Bower a bunch yet, keeping front end dependencies up to date is the #1 reason I want to.
Vendor prefixes: the CSS rules that only an IE6 Engineer could love. Autoprefixer makes them painless and it's now built-in to CodeKit. You just write standard CSS and Autoprefixer adds all the necessary vendor prefixes based on the latest information about each browser. It works seamlessly with Less, Sass and Stylus. It's also totally configurable: just specify which browsers you need to support and it does the rest.
Note from Chris: I think Autoprefixer is almost as big of a game changer as CodeKit itself, and they are a perfect match for each other. While I'm still a big fan of preprocessors, I'm no longer a fan of using them for prefixing. Autoprefixer is a much better way to handle it. You can learn more about it from it's creator here.
You're reading CSS-Tricks, so you probably write Sass. It takes a few seconds to compile, right? Not anymore. Flip on Libsass in CodeKit and your Sass compiles instantly. Libsass is a new Sass compiler written in C instead of Ruby, so it's like Justin-Beiber-tanking-his-billion-dollar-singing-career fast.
Now, Libsass is a beta, and some advanced Sass features (like namespaces and the new 3.3 syntax additions) aren't supported yet. But Libsass is advancing rapidly and the goal is to reach complete parity by this summer. Unless you're doing really complex stuff, you can probably use it today and drastically speed up your work. (We used it on CodeKit's site and that one has some really bleeding-edge CSS going on.)
Note from Chris: While Bryan correctly joked I prefer Sass, I don't care tremendously much what you use, because there are things that are very likeable about all the CSS preprocessors. One of the few strikes against Sass is that it's slow to compile compared to the JavaScript-based preprocessors. Libsass makes Sass the fastest as well, so that's pretty awesome (if you can use it).
OK, I lied. There's way too many new features to stop at just four. Here's four more features you'll love:
CodeKit can create source maps for Sass, Less, CoffeeScript, JavaScript and TypeScript files. (By the way, CodeKit compiles TypeScript now.) Source maps let you see your original source code in the browser's web inspector instead of the compiled output, which makes debugging easy.
There's now a "New Zurb Foundation Project" command that pulls down the latest version of Zurb Foundation from the web and sets it up automatically. This was a really common feature request.
Need to run a custom AppleScript or Bash script when files in your project change? Maybe tell Transmit or Coda to sync to a remote server? Gzip some files? No problem. Just set up a Hook and CodeKit will run whatever you need.
Note from Chris: It would be interesting to see it run Grunt or Gulp. Part of the beauty of Grunt is there are a zillion things it can do - things that can be super specific and probably aren't a good fit for a core CodeKit feature (e.g. the SVG stuff I described here). I'm not sure if mixing multiple build tools is a good idea or not, but it's worth thinking about.
If you write CoffeeScript, CodeKit has two new features you'll like. First, you can now prepend JavaScript files (like jQuery) directly to your CoffeeScript files. Do it with a drag-and-drop in the app, or an in-file statement. Either way, CodeKit combines it all into one minified JavaScript file.
Secondly, CoffeeLint is built-in now, so you can syntax-check your CoffeeScript files before they ever compile. This is also handy for enforcing particular styles, like how many spaces a line should be indented.
The short answer is, "Whatever Chris Coyier asks for." The long answer is that I completely overhauled CodeKit's architecture so that adding new features no longer requires major surgery. I plan to move quickly and keep iterating. Jekyll support is at the top of my list. Scaffolding and templates are up there too. HTML minifiers. If-else and loops in the Kit language. As Tim Cook would say, "We have some exciting products in the pipeline."
I love hearing from people in the industry, even if they don't use CodeKit. (Grunt FTW!) Come have a look at our new website. I can't take credit; Guy Meyer designed and built it, but we'd really like to hear what you think, one professional to another. You can find me on Twitter: @bdkjones
On CodeKit 2.0 is a post from CSS-Tricks
]]>
