Building my Browser Game Part 4

At this point in development I was pretty committed to building a browser based game. I had decided to do things in ASP.Net because I could in theory host the game on Linux servers via Mono. The earliest versions of the code were simple HTML forms stuff. It didn't look pretty but I was able to make quick progress in trying out ideas. 

My game design calls for a randomly generated galaxy of stars. Originally I wanted to place the stars in 3D space, and when I was still kicking around the idea of a 3D client program it would have been easier to implement a UI that allowed the player to view different parts of the galaxy. However I had decided against a 3D UI, meaning that a 3D game world would be difficult to pull off in a user friendly way. At the time I was playing Sword of the Stars somewhat frequently. It has a random map generator in it that can make stars arranged in a variety of shapes. Despite all the interesting shapes available to me, I kept finding myself using the 2D shape to generate my games. That was a pretty big clue to me that a 3D map made things visually interesting, but it didn't actually make it any more fun to play, or add any tactics. A 2D map was easier to navigate and interact with, and you could still go around obsticles or flank your opponents. I decided my game should just stick with a 2D map. It would be simpler to code and I wasn't sacrificing anything I felt was important. 

To implement a UI in the browser that allowed the player to navigate the galaxy would require me to be able to place stars where I wanted on the screen. A first thought was to generate images on the webserver and send them to the client, but this is an embarrassingly bad idea. You need some kind of caching for it not throttle your servers processor, but it also sucks up a whole lot of bandwidth. What I really needed was a way to send position data to the browser and let it do the work of drawing things. 

Now in retrospect I might have made my game in just HTML and maybe some Javascript in the browser if I had a better understanding of span tags and style attributes being used to set position, but I didn't and I still don't. I'm going to rationalize and justify this retroactively by saying that an HTML Javascript client wouldn't have gotten me the animation effects that I wanted (although this statement is probably also untrue.) What we are looking at here is the conflict between using the tools you know and learning another tool. In the end I would choose to learn another tool but somehow it didn't feel like it at the time.

What it really came down to was that I wanted a google maps style pan and zoom kind of effect to let the player look at different parts of the galaxy map. I had a choice here, I could either learn to do this with some kind of web kit, or apply knowledge I had learned doing earlier hobby projects with 2D graphics. Guess where I went with this?

I knew that Flash could do the kinds of visual interactions I was imagining, but I had a bad taste in my mouth for it from years ago. I had attempted to use it to craft a little something back in 2001 or so and I just fount it confusing. I think the version I played with was Flash 4. It felt like an animators tool, and I've got a programmers brain. I just didn't understand how to use it. Without much investigation I hadn't even considered flash.

It wasn't until a few years ago that Silverlight reached a level of ease of use that made it attractive to me. Whats odd here is that I didn't want to learn to use HTML style attributes, but I was totally willing to learn XAML. Strange I know. I don't know what the hell I was thinking. I spent a good deal of time learning how to use Silverlight as a client for my game. To be honest I found XAML frustrating, and to save myself a lot of aggravation, I tried out Expression Blend since it had a WYSIWYG XAML editor in it. Expression Blend has its own set of issues to work out. I really feel like Blend is targeted at Designers and not Programmers. To be fair Visual studio is for programmers, but here is the thing the programmer must be able to build a functioning prototype first. Then a designer can come along and add chrome and eye-candy on top of that. I spent a lot of time making an Silverlight client for my game. It worked, but it was god awful ugly. 

There was one upside to starting a silverlight client. It forced me to make the game server itself a web service. The good thing about doing this was that if forced a strong seperation from the game code and the interface code. This meant that I could in the future develop a more sophisticated client for the PC or perhaps make a client for smaller devices like the iPhone without completely redoing everything. It may end up making it too easy for people to make third party game clients, but so long as the server takes precautions to not trust the client (which all servers should do anyway), it shouldn't be a bad problem.

Now if any of you have read my previous blog entries you might remember my friend R. R introduced my to P. P is a designer and is currently heading a new social media division. Before that he'd worked on some AAA game titles in a variety of capacities. This has made P something of a professional role model for me, and when he not so subtly hinted I should look into AS3, I did. 

For those who don't know AS3 is Action Script 3, and its the programming language inside recent versions of Flash. I got my hands on Flex Builder 3. Flex Builder is an interesting product. It offers functionality similar to creating desktop applications in Visual Studio, but the compiled product runs in the Flash runtime. Meaning Flex builder lets you drag and drop GUI components, write code to handle UI events, and run that code in a browser. I was pretty blown away by this since It was basically letting me do what I had been trying to do with Silverlight for some months, but with a lot less hassle and much more visually appealing result. Initially I was concerned with learning AS3, but the syntax isn't that different from C# or Java so I picked up the language pretty fast.

I've stopped using Silverlight, and expect to finish this project in Flex Builder. I don't expect I'll consider Silverlight for future projects unless they make some huge advances in usability and reducing its learning curve. I feel like a gained a level of proficiency in Flex builder in just a couple of weeks that I didn't get in Months of self training on Silverlight. 

There is also the problem of many computers not supporting Silverlight. I know Microsoft will do its best to push it out to all the windows computers out there, and that market is huge, but I do believe in what the open source community is doing, and I want them to play my game too. Flash has the added benefit of working for Linux and Mac users too. Supposedly Silverlight runs on Linux via Moonlight, but moonlight is in a perpetual state of catch-up that makes in nearly impossible to make something actually run in Moonlight.

So to sum up: on the client HTML and Javascript didn't offer the bling factor I wanted. Silverlight proved to be difficult to learn and use. Flash (and Flex) turned out to be just what I was looking for even though I avoided it at first.

Next time I'll review some of the design changes I've made while working on the implementation.