Sponsored By

Building my Browser Game Part 3

In this post I discuss some tools I decided to use for my game and why I selected them. This covers the decision process that meant 3D was out and browsers were in. Making a browser game meant I had to choose tools for writing the server code.

William Leader, Blogger

April 5, 2010

5 Min Read

In my previous blogs I revied how I came to decide to make a game and what tools I used as part of the design process. What I want to cover in this post is more technical in nature but that shouldn't be a reason not to read on.

My game has a sci-fi space theme and has some 4X and RTS play styles to it. While I was still playing around with the designe I wasn't sure If I was going to go with 2D or 3D gameplay. I really liked the way the map in Sword of the Stars was done. So there was a time in the design process where I kicked around doing things in 3D. 

I played with a variety of 3D Libraries such as Irrlicht.Net, Axiom (a .Net port of OGRE), and MOGER (Managed OGER), and even Microsoft XNA. Readers that are even slightly familiar with .Net should be noticing a pattern here. What can I say. I like .Net. It is probably because I'm one of that generation of programmers who started with BASIC in elementry school, Moved on to VB, and later VB.Net. These days I write a lot of C# code. So I was looking for a way to use the tools I'm familiar with and like to use to make my game. 

I'm going to go off on a tangent for a moment here. I know all you real game programmers out there are wondering why not just use C++. Its a legitimate question and it has a perfectly irrational answer. While I can write C++ code, I've just never gotten to like it as I have with C#. It is not a critique on C++; it is just that if I am going to write code for personal enjoyment, I am going to do with with tools that I enjoy using.

Without going into too much detail about all of the 3D libraries that I played with Irrlicht, and OGRE derived systems all worked reasonably well. I could load meshes and get what I wanted onto the screen. There was no technical reason for me to not use them. XNA was attractived because of the idea that I could run the code on an XBox 360 and Windows which meant a potentially larger audience. While XNA (at the time) had pretty good support for 3D visual elements, it is quite a chore to do the needed 2D elements. At one point I got it in my brain to make my own GUI library for XNA. Once I realized that Microsoft had intentionally made internet connectivity from inside the XBox 360 an extremely limited option, I knew that as a single hobby developer I could never reasonably expect to run my client on that platform. XNA was suddenly a lot less attractive. In the end my lack of skills in creating my own 3D assets was what killed that option. I could load and use textures and meshes, but I couldn't make anything that I would be proud to publish. Worse than that, I couldn't make a case as to how the gameplay would be improved by 3D.

Once I decided that 3D was not right for me or my project things started picking up pace. If I was looking at making a 2D game, why not target web browsers. As a player I like browser games because there is nothing to download or install. I can play from anywhere. What I don't like about browser games is the lack of quality in the game design. From my perspective a great many of them get by on fancy graphics or the peer pressure from publicizing them via social networks. Really, the reasons I don't like browser games are not the fault of the platform so as the person creating a game they weren't reasons for me not to make a browser game. 

So my next technology choice was for server programming. I know there are lots of options for running Java code on web servers, but I lack serious Java skills so those choices were out for me. PHP falls into the same language group as C++ for me; I can do it, I just don't want to. I've done some work using Delphi to create ISAPI dlls for web service coding. That could work for the service parts of things but it wouldn't help create the HTML user interfaces. Given that I'm already proficcient at C#, there was really one option for server code staring me in the face: ASP.Net. 

I'm not about to say ASP.Net is superior to other server side programming tools, but for me personally being able to use C#, and an acceptable WYSIWYG html editor it meant that I could build a web application even if it turned out to be nothing more than a prototype with relative ease. What sealed the deal for me was finding out how far the Mono Project has come. It turns out that if you can resist the calls of using the latest version of the .Net runtimes in creating an ASP.Net application, you can fairly easily host it using Mono. The notion that if I wanted I could target Mono so that someday my servers could be LAMM (Linux + Apache + MySQL + Mono) meant should I become sucessful I could avoid having to buy Windows Server licenses. The math was simple: Tools I like + Zero software licensing costs = Win.

Server technology was decided. ASP.Net C# targeted to run on Mono. At this point I expected to make my client pure HTML (and probably some Javascript) but it turns out that while I could make functional HTML that displayed information and recieved user input, I was not up to the task of making something that was visually appealing. I would need something to help me build what would be displayed to the user.

Next Time: Silverlight to the Rescue?

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like