Game Development Reference
In-Depth Information
many different programming languages, including JavaScript. For example, jQuery is a well-known
JavaScript library that is used to create interfaces on web sites. Then there are tools that combine
libraries with a development environment to create complete games, such as Unity ( http://unity3d.
com ) which has a script engine that uses something very similar to JavaScript called UnityScript.
Another game engine worth looking at is Cocos2D ( www.cocos2d-x.org ). When you want to develop
a commercial game, it's a good idea to consider using such libraries or game engines, because they
allow you to export your game to a variety of platforms as native applications.
Peter: “At Rovio, most of our games are native code for iOS, Android, and so on.
We do have a version of Angry Birds for HTML5 that uses WebGL, but we mainly do
native mobile app development for the time being. We have our own tools that we
have developed in-house over the years, so we can very easily write code once and
then deploy it to any platform. For some projects, we use Unity, which also enables
us to deploy our code to a variety of operating systems and devices.”
Mark: “In large part, we have developed our own engine and write our own libraries.
We do this because it is very important for us that we squeeze every last drop of
efficiency out of our code. We find that there are many libraries that are beautifully
designed and very generic, and because of that they are slow and difficult to adapt to
our framework and way of working. In a few cases, we do use libraries, for example
for game physics. And we do regularly use tools that have been developed by third
parties, such as a code editor or an obfuscation/minification tool such as Closure [see
Chapter 31 for more information about Closure and obfuscation and minification].”
In this topic, you've used only a single third-party library— Lab.js —which you used to load multiple
JavaScript files more easily. You could have opted to use more libraries instead of writing all the
code from scratch. In the case of this topic, my goal is to teach you the important programming
idioms of JavaScript and how they're applied to game programming. I chose to minimize the number
of libraries used, so I could keep the code straightforward and in line with the general approach
to programming games that I put forward in the topic. As a developer, you often have to choose
between using a library written by someone else versus programming everything yourself from
scratch. If the library is well written and does something you need, it makes a lot of sense to use it
in your games. You won't have to do all the work to program the same classes that somebody else
already wrote. Furthermore, if a library has a lot of users, the main bugs in the library code probably
have already been solved. All in all, if you use libraries, your game code may be a lot more robust
than if you program everything yourself. Finally, because libraries are often developed for general
purposes, you may find that the library you incorporate solves a problem that you just discovered in
your game, so you can simply use the extra functionality that is already there in the library.
In some cases, libraries cause more trouble than they're worth. For one thing, libraries are generally
released under a certain license model. If you want to use an open source library in your commercial
game, the license may not allow you to sell the game code that includes the library. Therefore, using a
library puts restrictions on what you can do with the code, because not all the code was written by you.
Mark: “Another problem of libraries is that licenses are not always clearly defined,
especially because you are distributing the source code in JavaScript. Also, in the end
we like to put all our JavaScript code in a single file that is minified and obfuscated, a
process that doesn't always work correctly when using third-party libraries.”
 
Search WWH ::




Custom Search