I've pretty much set my mind on using CreateJS to create an HTML5 game, but I also came across H5CGB, a boilerplate created specifically for creating HTML5 canvas games. It looks very thorough and I believe the developer when he says it would save me heaps of time writing code I would have had to write anyway.
However, looking at tutorials for both CreateJS and H5CGB, they seem to conflict quite a bit, at least in terms of how these specific tutorials implement their respective tools:
http://hub.tutsplus.com/tutorials/learn-createjs-by-building-an-html5-pong-game--active-11845
http://icecreamyou.github.io/HTML5-Canvas-Game-Boilerplate/docs/#!/guide/walkthrough
I'm basically just trying to understand how to integrate these two systems. For example, both come with their own preloader utility, so I'm not sure which to use and if they would cause issues or if it's just a redundancy resulting in unnecessarily longer loading times.
Has anyone had any experience working with these two tools together?
I believe you should probably just stick to using createJS because the two frameworks do have a lot of overlapping functionality. It wouldn't make sense to use both.
I think you should also check out other game specific frameworks like Crafty.js and possibly watch Google I/O Canvas to get a good idea on the total range of your options!
Crafty
http://craftyjs.com/
Google I/O
http://blog.sethladd.com/2011/05/source-code-slides-and-video-for-html5.html
Hope this helps and good luck learning canvas!
Shalom
I created H5CGB. (Just found this question today via the newly-released Github traffic stats.)
The biggest two reasons to use H5CGB are:
You do not have to learn any new APIs to start developing. H5CGB provides a bunch of scaffolding you can use to skip the boring stuff, but you won't get into trouble if you want to implement any part of your app yourself, and you probably can get going immediately just by editing main.js without even reading the documentation.
The code base is intended to be boilerplate, so you can use all the utilities and scaffolding H5CGB provides as a starting point and edit it if you want things to work differently.
This is in contrast to most other canvas libraries, which tend to be monolithic black boxes of no-touchiness with sparsely documented APIs.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Like, can I write a business strength application in HTML5 that mimics our current system that contains many highly interactive grids, custom trees and so on.
We have a good working system written in C# WinForms with parts done in WPF and have recently embarked on writing a custom app for the iPad that communicates through WCF with our main server hosts. We now have a very fast custom grid written in C# that compiles to Objective C through MonoTouch and also a cool interactive pie chart.
Now my boss wishes to build a version for Android and I am thinking if we shouldn't really be spending time creating a single HTML5 app that can run on both iPad and Android equivalents.
Thing is - take a grid - my grid on the iPad is fast (re-usable cells etc) - how would I create a grid from a 'dataset' type source in html5? Do I really have to go down creating lots of tags and then submitting them to the browser? Are third party widgets like jqwidgets the answer??
Thanks
This is a bit anecdotal, but my experience has been that HTML5/JavaScript are just not fast enough on mobile devices yet (in 2012) particularly if you are displaying lots of data, especially and you want fast response times with interactive features. Give it another year, and I wouldn't be surprised if this statement becomes outdated as mobile devices continue to evolve.
Mobile web development certainly has its uses currently, e.g., if you want to target the most devices with a single codebase; if you don't have enough development resources and are willing to settle for a non-native experience; if you don't have experience in the languages required for native development, etc.
Given that you already have done the work for the iPhone app, my humble opinion is that it's probably better to move forward with a native Android application -- you will get a much more responsive application for about the same amount of work at this point.
how would I create a grid from a 'dataset' type source in html5?
Depending on what the grid contains, you can do it with plain old HTML tables or with a combination of other elements styled with CSS. There are really many more considerations though-- e.g., does it need to work on small screens (e.g., phones) or just larger screens (tablets). Often, you can't really fit a whole grid on a small screen, so you end up with UIs that aren't really grids anymore. You can take a look at a mobile JavaScript framework such as jQuery Mobile to see how they've done it and maybe even consider using the framework for use in your own application.
The various JavaScript frameworks (eg. JQuery and Dojo) have mobile device-specific widgets of quite high quality. Have a look at http://dojotoolkit.org/features/mobile and http://jquerymobile.com/
How close do these get to native apps developed in ObjectiveC and Java? Not perfect but maybe good enough. You can also use a combination of native and HTML in the same app, some pages native some HTML. I'm doing that kind of thing with IBM's Worklight, but then I would, I work for IBM ;-) Irrespective of specific products I do see folks taking that approach.
In addition to portability, anoyther of the benefits of having much of the app in HTML is that updated versions can be delivered without going via an app-store - this increases agility of functional delivery.
As evidence, I'd say that a lot of Windows 8's apps are just wrapped JS/CSS/HTML, with a few APIs which Microsoft supplies to allow access to hardware/the filesystem.
I wouldn't think that they've gone so far as to make Excel 2013 JS-based...
...however, with that said, they have gone so far as to allow developers to extend their programs with applet views of the data -- those applets are all going to be built on "html5" (again with an MS-Office JS API).
It's not an easy road to go down -- people look to jQuery to be their saviour for these types of things.
This is exactly where jQuery would not be what you wanted, if you were looking to hack together a solution.
For example:
$(".table_cell").click(function () { alert(/*whatever*/); });
People think that jQuery is assigning a delegator to listen to any click on any element containing class="table_cell".
That's really not what it's doing.
It's looping through each one, and attaching an event-listener to each one, directly.
It's these little things that people miss -- people like Twitter, who didn't bother caching references to elements, because jQuery is so easy to hack things together with.
So then you have JS touching (or acting on) dozens or hundreds of individual elements, at all times.
That's not good for anyone.
jQuery isn't bad at all -- it's quite helpful, as a low-level construct to help skirt around browser differences.
Some of its plugins are also all right.
I can't guarantee that they're all high-performing answers to all things.
But some of the plugin-creators understand how to maintain a responsive and well-performing program.
Which ones are right for your exact needs? Who knows, other than you.
Will they perform perfectly, and quickly?
That depends on a lot of different things, of course.
Coming from C#, you might do to look at something like AngularJS.
Angular, itself, uses an internal version of jQuery, to tackle some of the low-level stuff that jQuery has made a solved-problem.
But it allows for data-binding, and pretty simple view templating.
Hammer.js is also a very decent gesture-tracking library.
From there, though, I'd suggest building your own framework, if you want it done the way that you want it to be done.
Nobody knows what your needs are but you, and trying to stuff things into a shoebox, because it's available, isn't always the solution, regardless of what various companies may think...
You can leave most of the node-work to Angular, you can leave the gesture-sensing to Hammer, you can pull out some other basics from jQuery-lite (the no-frills jQ installed inside of Angular, if you don't have jQ on your site), or jQ, itself...
But they're just tools and not answers.
The web can be very responsive if you cache references to elements, rather than querying for them over and over, delegate events, do large structure-changes off-DOM (on cloned-nodes, if necessary), and don't try to treat JS as a traditional inheritance-heavy language, and you remain mindful of how and when to use AJAX (number/frequency of calls versus size of data -- favour fewer calls).
I want to start a project and I am evaluating the architecture.
And now I am at point to decide the front end components.
I want to use HTML5 + Css3 + Javascript
On Javascript side I don't know what do you recommend. YUI or Backbone. I don't know how to evaluate what can be the best for me. The idea is to create a Browser web app and a Mobile app.
Do you recommend another framework for do that? Or some book, url or something that expose how to organize my front end?
This might be a bit late. But I will say this. I've looked through these so far:
Angular, Knockout, Backbone, YUI
And I read some other comments on Ember.
From what I've seen, Angular and Knockout take the same starting approach. They start out telling you how to interface with the front end. I do NOT like this. They give you a whole lot of rope to hang yourself with if you don't know how to design good architecture. Its completely up to you to build a proper MVC app with them.
From what I've seen of YUI, its EXTREMELY similar to Backbone, which is no surprise because YUI was INSPIRED by Backbone. I have spent a LOT of time looking at backbone and I'm very impressed with it. If you follow its principles and standards, it will encourage you to build a sound framework that won't leave you hanging later.
But I saw another commentor who actually actually moved from Backbone to YUI because he said YUI is more streamlined and all around better. I wouldn't be surprised if this is true. But I need to evaluate it further.
Many folks, including myself, agree that Ember, Knockback, and Angular are rather "heavy handed" in their approach. Like I said, they START with explaining how to interface with the HTML. Right out of the gate, they're wanting you to do things a certain way. This could be very problematic depending on your particular application.. OR it could make your particular application a piece of cake if it fits nicely in their approach!
My two cents!
Backbone is great for creating web apps, both for desktop and mobile. It's strongest point is that it's small and quite simple: you can actually read through the entire annotated source code. Backbone helps you structure your code in a maintainable way, which is the main benefit.
The downside of backbone is that it's not very beginner-friendly: setting up the collections, models and views can be quite challenging if you're not used to it. It also doesn't help you at all in rendering the views, which is a blessing and a curse: it's not as easy or helpful as a widget based framework, but it also doesn't get in your way, which is especially important when implementing the mobile app.
I would recommend you study the backbone todo-example ( http://documentcloud.github.com/backbone/#examples-todos ) to get an idea how the framework works.
I realize that some people think it is crazy to re-implement all the UI functionality of HTML in a canvas-based framework (and there are some stackoverflow questions that suggest this), but is anyone actually working on a library like this?
To clarify, the library would render all UI elements like edit boxes, labels, buttons, combo boxes, list views, etc. on the canvas directly. There would be no HTML or CSS.
I stumbled upon this idea today. Found the library Zebra. Haven't tried it out yet.
https://zebkit.org/
For web apps I think this makes perfect sense. HTML/CSS is just not good enough to create stable apps easily. The DOM and layouts are just too quirky and the performance too low.
What we need is something like Silverlight but without the plugin. Stable components and a great framework.
Canvas apps could be made just as accessible as html web apps. Probably more so even.
Perhaps WebGL is even better, its performance is definitely better than Canvas if done properly.
Thunderhead was a mozilla experiment built along with bespin (now skywriter).
From the project description:
Thunderhead is a Mozilla Labs experiment to explore a JavaScript-based
GUI toolkit that works with DOM elements and canvas to render
components.
The problem is accessibility, canvas just isn't.
I've just reviewed zebkit.com today. Amazing and absolutely not crazy, rather essential. Try running most DOM node trees on a mobile device and you will soon know this is true. Then in contrast run the Zebkit kitchen sink demo and be shocked. You might have to reconsider your projects approach.
Coming from Java to HTML5 I definitely see some nice OOP at play in the Zebkit API, it is needed to provide the simple canvas some powerful structure. Also I really like the JSON support, it acts much like a CSS format for the canvas. Using JSON this way fits well into the Web Component mindset and the practicality of HTML partials. There are a lot of goodies in this API.
In the end all ways of producing graphics for the Web render pixels anyways. Maybe we have just added to many abstractions between the logic we what to produce and the end screen to realize this fact. With Zebkit it feels like your almost working at the native level, plus it adds in all the graces of Javascript and JSON, sweet indeed. Plus your free to mix and match in DOM as desired.
Now there is Flutter's CanvasKit renderer. Google docs is moving to Canvas.
I am having an absolute nightmare trying to build anything of value with Sencha Touch. The docs seem to describe everything in bits in pieces without every tying everything together..
One of my key gripes is that I don't understand how anything is loaded into the browser.. If I simply define an Ext.List in index.js within this method:
Ext.setup({
onReady: function() {
}
})
Then that Ext.List is loaded into the browser for some reason. If I define multiple objects in that method, how does it know which to put into the browser? Furthermore, when I extend Ext.List and put that in the above method, nothing happens. What's going on?
Better yet, where I can find good documentation that explains how this framework works? I've pored over everything on the Sencha Touch site, including the tutorials, and all of it is horribly incomplete.
It does seem confusing at first. What's important to understand is that Sencha Touch different from jQTouch or jQuery Mobile in that you create your interface in a completely programmatic way, os there's no defining the UI in a HTML file or anything like it. The framework is written much more in the tradition of classic widget set's, QT for example. This style isn't something traditional web developers are used to, but I'd actually say the documentation is quite complete. It's just not written in a style familiar to web developers.
This is how it works: one component needs to have an attribute fullscreen: true set on it. This component becomes the root, and all other visible UI components are added to this component using the .add() method. But there all defined in Javascript. That's the most crucial thing to remember.
You have probably already found it, but the main documentation repository is the API documentation (here). If you're going to get anywhere you will have to get used to reading stuff from here quite a lot. Important facts here is that everything in the UI inherits from the Component class, and that Panel is probably
When I was getting started, I found this page a little bit better for starting. I especially recommend Drew Neil's excellent screen casts on panels.
I think this has a lot to do with the fact that Sencha Touch is still a young library, and that it has it's roots in the highly programmatic and OO-centric Ext.js framework. Taking some time to really learn the fundamentals of Ext.js probably helps a lot in the long run when trying to get going with Sencha Touch (tip: Observable is the most important class).
So sorry, you're right that the documentation isn't very friendly. But the UI you get from Sencha Touch still blows the competition out of the water when it comes to mobile interfaces, so I'd say that it's still worth it if you're really want the most slick mobile UI there is.
I recommend you to checkout the conference videos http://www.sencha.com/conference/videos specially the "Structuring Your Sencha Touch Application", I restarted an app from scratch following the MVC pattern explained in the video, in two days I got where I was before plus a ton of fixed bugs but most importantly now I really understand what I'm doing and why it was so hard to get things to work before using this standard pattern.
I found one of the best places to learn sencha touch is this 4 part series on building a simple SenchaTouch1.0 app :-
http://miamicoder.com/2011/writing-a-sencha-touch-application-part-1/
Follow it up with the MVC example :
http://miamicoder.com/2011/writing-a-sencha-touch-mvc-application/
Having completed the above tutorials gives you the comfort and confidence to approach SenchaTouch's own documentation, tutorials and screencasts.
A long time ago (Netscape 4-era), I wrote Javascript-based games: Pong, Minesweeper, and John Conway's Life among them. I'm getting back into it, and want to get my hands even dirtier.
I have a few games in mind:
Axis & Allies clone, with rugged maps and complex rules.
Tetris clone, possibly with real-time player-vs-player or player-vs-computer mode
Breakout clone, with a couple weapons and particle velocities
In all of these, I have only a few objectives:
Use JavaScript and HTML 5 - it should run on Chrome, Safari, or maybe an iPad.
Start small and simple, then build-up features.
Learn something new about game design and implementation.
So my questions are:
How would you implement these games?
Do you have any technology recommendations?
If you've written these games, what was the hardest part?
N.B.
I also want to start from first-principles - if you recommend a framework/library, I would appreciate some theory or implementation details behind it. These games are different enough that I should learn something new from each one.
Depends how much you want to start from scratch. To answer your direct questions:
1) How would you implement these games?
A: JavaScript + Canvas. Canvas is the 2D drawing surface from HTML5. Performance is pretty good on desktop machines, not so great on iOS and Android devices (as of the date of this post). If mobile is your utmost concern, you need to use the DOM and CSS3 3D transforms which trigger the GPU on those devices.
2) Do you have any technology recommendations?
A: This is sort of answered by the first question. JavaScript is a must, but I would ignore jQuery. You are targeting HTML5 devices, so no need to compensate for legacy browsers. As you are probably using Canvas, no need to smooth over the DOM interaction, either. There are some higher level libraries which make interacting with Canvas easier, such as Easel.js. WebSockets are useful for bi-directional streaming communication. And Box2D is useful for a physics engine. Local Storage is simple key/value string data for things like level progress, but for anything complex, you'll want WebSQL DB. For large binary assets you'll want to look at the File System API. Finally, don't be afraid of WebGL, as it is extremely fast and useful for 2D games.
3) What is the hardest part?
A: Almost certainly the hardest part is the debugging. WebKit's Developer Tools can make this easier, so don't leave home without them.
Put simply use Canvas for moving lots of stuff around the screen and SVG for prettier, slower, vector graphics.
One of the first things you should do is write a speed test program to see what can be done with Canvas and then play with it.
I wrote a blog post about Canvas & writing HTML5 games
edit 2019-02: processing.js is old and not well supported. Instead, try p5.js, which is equivalent and up to date.
Don't forget processing.js, which is a pretty well tested full-stack graphics and interactivity javascript framework, which has substantial (if not comprehensive) support for most I/O, sounds, graphics, and even WebGL. If you write vanilla Processing code, which is basically Java syntax compiled to JavaScript, you can use many open-source debuggers out there, including the native Processing environment. Other than that, you can integrate any other JavaScript code you have a mind to include.
Here is a guide for the JavaScript developer, explaining much of what you might want to know.
Check it out. Good stuff.
The hardest part, for me, was that there were no tools to help make the graphics, as there is no Maya export to canvas, for example, so, everything is done manually, with primitives, unless you want to take bitmaps that you will modify as though they are sprites.
At the time there was no real support for text in canvas, so my solution didn't work using excanvas, but worked fine on Safari and Firefox.
So, you may want to look at what HTML5 features you want to support, such as a built-in database, and then decide which browsers you are willing to work on.
How to implement these will largely depend on how you want to create the graphics, and if you want to do 3D graphics, as then the bitmapped sprites would not work.
Tom here from Scirra (Construct 2 game maker). We make an HTML5 games engine called Construct 2, it exports purely to HTML5 no Flash in sight!
Construct 2 uses an event based system to add logic to your games and does tons of the repetitive/difficult legwork for you. For example adding polygon collision to objects without some visual editor is a difficult task to undertake sometimes.
Anyway we think it's worth a look and you can get results very quickly from it as well. It's an alternative to coding the entire game you might want to take into consideration when developing HTML5 games.
Take a look at ChromeExperiments The examples are from around the world using the latest open standards, including HTML5, Canvas, SVG, and javascript.
Maybe this is not what you wanted to hear, but have you thought of starting with a good book?
http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=html5%20game
A good book will save you a lot of time, and start you off right at the basics.
A good question when I also started to learn HTML5 I also came across this question, finally after lot of research I found best way to do is by using some engine or framework. I learned canvas and made my own game but that took hours of logic and 100+ lines of code.
Better go with scirra, it might reduce your work.
I'm currently working on a series of blog posts explaining how to build a Javascript game using EaselJS and Box2D for physics. Here's Part 1.