Five years ago, Build New Games would not have had much to talk about. The only viable option to make web games at the time was Flash. Since then, web browsers have progressed by leaps and bounds both in performance and features; and they are now capable of running pretty complex games. How complex? We don’t know yet, we’re all just getting started really. Someone pushes the envelope and wows the rest of us on a regular basis. You could be the next one to build something impressive and I can’t wait to see it.
We hear a lot about how HTML5 is ushering in a new era, etc… but what does that mean? I think that, beyond the new version number for the markup language, the broader notion of HTML5 is the correlation of three things:
- Significant performance improvements in all browsers.
- Higher level of compatibility among browsers.
The Universal Language
TypeScript is a perfect example of this approach, and it has every chance of becoming widely used.
2. New Languages
3. Existing Languages
If you’ve already been writing games for other platforms, chances are that you’ve been using C++, C# or even Java. If you’re a web developer looking to get started writing games, you may also be coming from the ASP.NET or Java world. Regardless of where you’re coming from, it’s likely that you already know one or more languages and you like your development workflow. Wouldn’t it be nice to still be able to leverage that in your web games?
Some people at Google have apparently felt that way for a long time, since the first version of the Google Web Toolkit (GWT) was released in 2006 and the latest version came out in October 2012. GWT allows you to use Java for all of your development. Having been around for so long, it’s a pretty solid environment and definitely worth a look if you are a Java developer.
One drawback of Script# is that it has not managed to implement some of the features of the C# language, making development cumbersome at times. A solution to this situation came early this year in the form of Blade, which supports most C# 4.0 constructs; we’ll cover it in more detail in the latter part of this article.
4. JS Literally as Assembly
So both projects start with intermediate code which is itself the result of a compilation process from another language. The main advantage to this approach is that many languages are supported out of the box. For example, with JSIL you can use C# or VB.NET. On the other hand, you’re losing a big part of the connection with the platform with an additional level of abstraction. I haven’t experimented with either project myself; but they both link to pretty impressive demos from their home pages, so they are definitely worth considering.
What’s the Point?
Keep in mind that not every language or compiler will bring you the same set of advantages. Take the time to evaluate a few options before diving in and writing a game. Also, my judgment is likely biased by many years of programming in C++ and C#. If you have a similar background then chances are the following points will resonate with you; otherwise you may completely disagree with me and that’s ok too.
Static and strong typing
In short, static typing means you need to declare the type of your variables before using them; strong typing means you have to explicitly tell the compiler how to perform an operation between two variables of different types.
A statically and strongly typed language may feel too constraining, but it has undeniable advantages when dealing with a large or modular code base:
Compile Time Error Checking
Test driven development (TDD) is particularly popular among web developers who use dynamic languages like Ruby, in part because it helps catch some of the issues a compiler would catch. But when writing a game, it’s not as straightforward to use TDD because you’re typically dealing with a highly interactive and graphical program. This makes a compiler that much more valuable.
A statically and strongly typed language enables much more accurate static analysis. This allows the development environment to know a lot about your code without having to run it; and by knowing a lot about your code, it can offer you advanced functionality that will help organize and maintain your code.
A number of developers feel that integrated development environments (IDEs) are slow and bloated and get in the way more than they help; they prefer to use lighter weight tools such as vim. But even vim has language specific extensions, one of the most common being syntax highlighting.
Some features which I find particularly useful in a modern IDE are:
- Code navigation: I can easily go to the declaration of a function or a variable, which not only helps refresh my memory of how my old code works, but also lets me explore someone else’s code.
- Refactoring: it’s important to organize a large code base; but you can’t always get it right on the first try. When your IDE has strong refactoring features, it can help you reorganize your code effortlessly.
- Code completion: a long time ago, I used books a lot when programming, I couldn’t search the web because there was no web; so they were my only reference. After looking for the same thing enough times, I’d eventually remember it… until I stopped using it for a while, then I’d be stuck opening the book again. Now, IDEs are capable of showing us a list of relevant items when we start typing. Making it really easy to use rarely needed functionalities without having to remember exactly what something is called.
Code Organization and Reuse
I’m sure you already know that organizing your code is important. As your game grows and you write more and more code, it becomes very helpful to be able to split it among various files and folders. In C# for example, Microsoft has encouraged developers to place each class in its own file and each namespace in its own folder.
You can also easily organize your code in various libraries that you can reuse between projects.
Share Code with the Server
At some point you may decide that you want your web game to interact with a server. Whether you just want to save high scores or write a massively multiplayer game, you will end up sharing structured data between the clients (web browsers) and the server. Using the same language for your server side and client side code offers some interesting possibilities.
You can place your data structures in code files which will be included in both projects, so you only need to maintain them in one place. And because you’re using a compiler, you can safely make a change in one project and the compiler will let you know if it breaks the other one.
It may even be possible to share some logic between client and server depending on the language and tool you choose.
At one point or another, you’re probably going to want to debug your code and figure out why something isn’t behaving as expected. Thankfully all modern desktop browsers now include very potent debuggers that will make your life easier. However you may have a bad surprise the first time, as the code you’ll be dealing with is not the one you typed.
Keep that in mind as you decide on whether you want to use a compiler and which one you’d rather pick.
Certain languages favor syntax and conciseness: they make complicated things seem simple by only taking a line of code. This may result in a lot of code behind the scene. What makes business applications easy to write may not be as useful to game developers.
What would be a programming article without some code samples? In the remainder of this article, we will go over the creation of a game project using the Blade compiler. The complete code is available on GitHub.
In the first part of this article, I’ve attempted to keep a panoramic view of the landscape. With so many languages available, it’s quite likely that you will prefer a different one than me and I hope I gave you enough pointers to do some experimentation and make your choice. Now that we’re getting into some code, I should explain why I chose Blade.
Below is a simple class declaration in C#:
Blade will compile it to the following:
Note that C# also supports type inference, meaning this:
Generics must be one of the easiest feature to implement, there’s pretty much nothing to do:
The Smiling Face sample
I intended this article to be an introduction. There are many more game programming subjects I’d like to cover, but I thought it was important to explain why all of my code will be C#. Hopefully this is clear now, and we can move on to looking at some code.
As mentioned above, you can find the code on GitHub. I will be using screenshots from Visual Studio 2010, but you may just as easily use Visual Studio 2012 or even SharpDevelop which is free. You will find more detail on the project page.
One of the benefits of using Blade is Visual Studio’s ability to manage large code bases. While it’s a bit early to have that large code base, we will hopefully get there after a few more articles. In the meantime, let’s plan for that to happen.
I’ve divided the code into three projects:
- Framework is a Blade class library project which will contain a reusable game framework. It’s not much right now but we’ll flesh it out over time.
- 1. Smiling Face is another Blade class library and also our first demo. Its only real purpose is to have something we can run that will show the features implemented so far in the Framework.
Another aspect I really wanted to demonstrate is the advantage of being able to use classes and inheritance. If you run the demo, you will notice a little screen icon at the bottom right of the page. Click it and you’ll get a simple configuration menu allowing you to change the graphic settings of our demo.
This menu is built by a hierarchy of classes designed to be easily extended in order to support more configuration options. The Menu class handles both the icon and popup, and then the various settings are built as such:
If you look at the content of these classes, for example StretchToWindowSetting, you will see that the code is pretty small. Of course, I’m cheating a bit here: it took me a few days to come up with this setup. But that’s a benefit of being able to easily refactor code: it’s possible to experiment and reorganize everything very quickly until it’s just right.
With all of these classes, creating a settings menu for a game is very easy. The demo uses the default menu from the Game class, the code looks like this:
But it would be very easy to override this method in SmilingFaceGame and provide a custom menu for our demo. This leads us to another example of using classes: the framework contains a Game and a Scene class which are base classes with functionality that will be useful to most games (or demos).
A game will have a class that inherits the Game class: this will be the main object. Then it will have any number of classes implementing Scene. These will represent things such as a title screen, each level and cut scene. In our first demo, the game is SmilingFaceGame and the only scene is SmilingFaceScene.
You can also look at the whole file.
Take some time to look at the code, build it on your computer, play with it and let me know what you think in the comments!