Introduction
Earlier this year, I wrote an article that gave 4 Tips to Stay Relevant as a Flash Developer. It offers a new perspective on an old technology. However, most Flash developers are set in their ways, so convincing them think with a fresh mind is a challenge. One natural progression from ActionScript is the transition to JavaScript also known as HTML5. ActionScript is again based on JavaScript despite going a separate direction. Even with so many similarities, there were some major hard lessons that I could have avoided knowing what I will share here. In short, here are some tips to make the transition easier.
Libraries and Modules
For the most part, the days of coding everything in a closed system are long gone. First thing you need to know is that the JavaScript community use open source code. There are more modules, scripts, and libraries for JavaScript than any other language. When in the planning stage, evaluate all the options out there. Similar to the make-or-buy decision, decide if it would be easier to use and contribute to an existing project rather than creating something from scratch.
So why use a game engine when you never needed one in Flash? Using an engine will offer out of the box functionality for common tasks like preloading files, managing art assets, managing sounds, creating tweens, and so on. Being able to do a complex task in one line of code is almost magical. However, game engines are not the only option as there are many modules and libraries available in JavaScript. Using common libraries will help connect the different APIs across browsers. Using these libraries can allow more flexible development while providing helpful shortcuts. The pace within the JS community has grown a lot recently. Use and contribute to the tools that are available.
Technology Aspects
The HTML5 ecosystem is quickly reaching parity with Flash. However, there are still some limitations to be aware of before writing any code. Like vector art not being production ready and none of the popular engines supporting it just yet. So art assets can be tricky. Art can be made in multiple sizes. The closest size can then be used depending on the device. Another option is to create large images and down sample them. Otherwise, scaling could be disabled altogether if you really wanted to. Lastly and my favorite, you can try to stay within some middle ground to limit the blurry image problem of scaling images.
Another limitation is text. Of course HTML is the grandfather of text, inputs, and all the things that make the web. But for Canvas and WebGL elements, there are no native text inputs and engines often lack friendly ways to display complex text elements. It is possible to layer text over the Canvas or WebGL elements. However, keeping everything inside the drawn elements will make scaling easier. Flash solved this problem a long time ago and now JS game engines are reaching the point where the issue is being worked on.
Lastly, JavaScript gives developers new access to hardware that was previously only available in low level programming languages. With anything new in the browser world, there are competing browser APIs, performance issues, and many little hacks trying to make things work. It’s helpful to understand what browsers support what features and test how well they perform. Some technologies like WebGL can offer amazing 3D rendering but could require a graphics card to perform well.
Devices
There are a lot of elements to consider during the planning stages when using JavaScript. Some of them we’ve already touched on here. Things like scaling, devices, technology, and generally your audience. We at Y8 have a strong bias for web apps because they work without walled gardens across different device classes. There are other options with JS like native apps and downloads. In any case, choices made during planning will limit who wants to play a game.
The web and consequently devices that connect to it are dynamic. They come in all sizes from mobile, tablets, desktop, to televisions. Figuring out your plan of attack for scaling at the beginning will make your end product work much better. Like most things in JS there are many options to choose from. The easiest solution is full screen. It will ask the player for permission to take up their entire screen. In some cases this is desired and in others it can be annoying. Another option is to scale the game to the size of the parent element. The game will have an ideal size with the option to still fit within sites that want to display it smaller or expand it for something
closer to a full screen experience.
Scaling leads to another important design topic, what is the ideal size for a game? If targeting the web, considering browser top bars and operating system task bars is critical. For our current audience, a game resolution around 900x600 works really well. Each platform will have its own considerations. It will be impossible to make a game that works on a smartwatch and a TV. So choose who you want to target and try to reach similar devices. A simple trick we found to reach desktops, tablets, and phones is to use landscape ratios and big buttons in the user interface. It’s possible to reach a massive audience with some creative game design.
Conclusion
The main elements to making the JavaScript transition an easy one are mostly focused in the design stage. Firstly, choose the best libraries for your project. Having a good engine or set of modules will give you shorter development cycles. The next critical part is to understand what limitations you will have to work around. In the future, some limitations mentioned here won’t apply any more. There are always design decisions that should be accounted for early on. The last section is about devices and audience. Come up with a plan for scaling and decide what devices you want to target during the planning stage.
Postscript
The details about the differences between ActionScript and JavaScript were skimmed over above. Long time Flash developers will find JS is closer to ActionScript 2 as this is when the two languages diverged. One of the big challenges for Flash developers making the switch is to understand scope differences. For a great article, read Demystifying JavaScript Variable Scope as it provides one of the better explanations.
