Is HTML5 Ready for Prime Time? (Part I)

In Part I of this article, game developers Raymond Jacobs and Tom Novelli take a look at HTML5's capabilities and dispel common misconceptions about JavaScript.

I will make the assumption that you, the reader, have already come to the conclusion that writing a game in a single language and releasing it on multiple platforms without porting or even recompiling is a benefit to your business, through greater visibility and empowering the player.

There has been a lot of misinformation floating around the web concerning HTML5. The most important question is, “Is HTML5 ready for prime time?”

The short answer is yes, you can write polished games in HTML5 and have them run across a myriad of browsers, platforms and devices with consistent results.

The longer answer - the subject of this article - is that HTML5 is still young, and there are real-world pitfalls which should be avoided whenever possible.

Beyond the Buzzword

So when we’re talking about HTML5, what we really mean is Javascript (JS) coupled with graphics and interactive APIs exposed to JS by the browser. Like any mature technology, Javascript comes with its own set of dogma and misinformation.

Here is a short list of common misconceptions:

• "Javascript is slow!"

This was true until the browser makers started pouring R&D into JS optimization, circa 2005. Nowadays, according to this list, it's generally the fastest dynamic language - on par with static languages Java and C#, and only about half the speed of native-compiled C. That's not bad - it's awesome.

• "Javascript doesn’t have classes!"

We hear this one a lot, and it just isn’t true; the prototypal inhertiance in JS delivers all the basic OO features you’d want in a game: member variables; member functions; sub-classing; static members; polymorphism; reflection; function/constructor overloading; type identification (instanceof).

Check out the object-oriented section of Tom Novelli’s JS reference for more information.

• "Javascript isn’t secure because it isn’t compiled!"

The use of minification and obfuscation (if reflection isn't needed), turning your code into a whitespaceless, commentless heap of nonsense to the human eye is as effective as native code compilation. Remember, anything run on the client, be it Javascript, Java or C++ is not secure, and obscurity is not security.

• "Javascript isn't a real programming language!"

This is just silly; look at http://en.wikipedia.org/wiki/ECMAScript. From a language design perspective, Javascript is pretty nice. It's a pared-down version of Scheme Lisp with a C-like syntax and Smalltalk-style prototypal objects.

By the way, the next version of Javascript - ES6 - is going to be sweet.

***

Now that we’ve addressed some dogma concerning Javascript, let’s talk about HTML5. HTML5 simply adds to the existing HTML specification we all know and love, and as game developers we only really care about a few choice bits. So here are some exciting things you can use today with HTML5, and some pitfalls.

Canvas

It’s the feature we’ve all heard about concerning games in HTML5. The Canvas creates a 2D drawing space on your web page. You can control the frame buffer size (pixel width and height) and set the screen size of the canvas element; it will automatically stretch or shrink the buffer to the element size. You can even create off-screen canvases and copy one canvas to another, giving the potential for powerful effects and/or performance enhancements.

With a simple setInterval timer (or better yet, the requestAnimationFrame API) and a canvas, you’re ready to start drawing things in less time it would take to install a typical IDE.

“Pitfalls!” 

Besides blitting bitmap images at lightning speed, canvas includes a robust API (based on PostScript) for geometric lines and fills, and rudimentary text rendering facilities; use these sparingly however, as they tend to sap frame-rate.

Also, canvas likes to draw from a small number of source images and would prefer that you keep your drawImage calls down (this is probably a reality of underlying drivers/API which are 3D in nature). So, atlas those tiny images (you’ll want to anyway to reduce http load calls), and use offscreen canvases to cache unchanging parts of the scene (turn those 6400 drawn tiles into a single drawImage call).

Raymond Jacobs is the driving force behind Ethereal Darkness Interactive (EDIGames), a western Massachusetts indie developer focused on the Action/RPG genre. Their most notable game is Morning’s Wrath, a fantasy RPG released in 2005. 

Tom Novelli is a game developer and musician in western Massachusetts. He is currently porting Morning's Wrath to HTML5.

Left Hand Meet Right Hand: Advantages of Distributed Development and Work from Home (Part III)

In Part I, developer Judy Tyrer discusses the disadvantages and disruption caused by mandatory colocation. In Part II, she demonstrates how distributed development can be more productive but cautions that team building is still necessary. In Part III, she lists the benefits of working from home in a distributed development environment.

Work From Home

Studies have shown an increase in productivity when workers are allowed to work from home. One reason for this is how people view their time. When a person is in an office, they view all the time in the office as time worked. This includes gabbing with co-workers, playing ping-pong, mid-day power walks, etc. When people work from home, the only time they view themselves as working is time actually spent working. Breaks to do the dishes, take the dog for a walk, etc. are not considered work time.

Working from home also helps reduce the person's carbon footprint, unless they are the rare individual that commutes by bike or walks. For companies in urban areas such as Los Angeles, where programs to discourage individual commuting are in place, this improves the company's score card. Commuting can also take up to 3 hours of a person’s day. Those hours can be split between the developer’s personal life and the work with gains in each.

Working from home allows parents to be more involved in their families and less dependent on outside care takers. The result is less time spent making arrangement for the children while at work, less anxiety on the part of the parent, and a result in higher concentration and higher quality of work.

Innovation

But what about Ms. Myers’ assertion that people need to be in the same office to innovate? As I know of no studies verifying or denying her hypothesis I will address it with questions about innovation rather than with data.

How much innovation is needed?

Does every single employee at a company need to innovate? Do you want your build system to be innovative or would you prefer a tried and true system that has been doing its job for 10 years. Do you want innovative accountants thinking outside the box on your tax returns? I contest the idea that everyone in the company needs to be innovative.

Do we have to be in the same room to innovate?

Often meetings where brain-storming and innovation take place are dominated by the same loud voices. When one or more members of a team are dominant, others are often quiet and their input gets lost in the noise. While this can also happen in on-line meetings, the ability to type text into a chat field during the meeting allows people who may not be as verbally assertive to still ensure their input makes it into the meeting without having to develop skills in interrupting others. And the record of the meeting allows review which can facilitate greater innovation.

Do we want to innovate for the sake of innovation?

Innovation is the hot new buzzword. But is innovation for its own sake necessarily desirable. Just because no one has ever made an FPS where bullets travel a player defined path rather than a physics defined trajectory does not mean that particular innovation will increase sales, provide a better experience or is in any way a good idea.

Benefits versus Risks

The risks for developers in a distributed model mostly fall on the shoulders of middle management as it requires more than just showing up at the office and delegating tasks. Managers have to be willing to work with their team based on work results alone. No more can a manager say “if I don’t see you working, you’re not working” (a fairly ridiculous assertion in a creative medium as dependent on inspiration as on hard work). The manger must actually look at and evaluate the work of the employees and this takes time.

In addition, since managers don’t casually pass their employees, often giving them the illusion they are aware of what that person is doing, in a distributed environment managers must actually schedule time to sit down with their direct reports. Having worked for 2.5 years at one studio before ever receiving feedback from my manager other than a yearly raise, the value of regular meetings with direct reports cannot be over-stated. Managers and direct reports need to communicate regularly. The processes necessary for a distributed team are those which would help all teams, but the distributed nature of the work requires those processes be in place and be followed.

The benefits to allowing work from home can also be found in talent retention. Better communication, autonomy over work environment, and being judged by the quality of your work and not arbitrary measures are all benefits that help talent remain satisfied with their position. And while all of these can happen in a single location, they can also be easily overlooked in such an environment. Distributed development, when it works, puts these things as top priorities and they become integrated into the corporate culture for the benefit of all.  

Judy Tyrer began in serious games with PLATO in the late 1970s, moved into distributed operating systems and enterprise software before rejoining the game industry in 2005. She worked for Ubisoft, Sony Online Entertainment and Linden Lab before branching out to start her own studio, 3 Turn Productions LLC which is coming out with the virtual world of Jane Austen for Kickstarter this summer.

September 2013: Teaching Game Design

Hello! 

Two weeks ago, I presented, "What's in a Name? Serious Games vs Gamification" at the Serious Play Conference, held at DigiPen, a college focused on game development.  At the conference, there were numerous presentations on how to use games to educate children in topics such as math, science, and history.  Dr. James Rosser, Jr.spoke about how video games could improve the skills of laparoscopic surgeons while Professor Mihaly Csikszentmihalyi unveiled an application to help managers facilitate flow states for employees.  The research indicated that companies actually make a profit while employees achieve flow!

During my time there, I did get to talk to an instructor at DigiPen.  There was not much discussion about teaching game development at the conference, although Lee Sheldon's book, The Multiplayer Classroom: Designing Coursework as a Game did come up during my Q&A period.

When I went to college, there weren't schools like DigiPen dedicated to game development.  Now, it's not odd to see game design offered in various departments, in colleges big and small.  I noticed that while GDAM has covered Game-Based Learning and Game Designer Skills, we have never had  a topic about teaching game design.

As it is the month children traditionally head back to school after the summer break, I think it's fitting that September 2013's topic is Teaching Game Design.

I invite readers to submit an article on this topic. Please read the submission guidelines first. Thanks!