Monday, October 24, 2011

Building the Game: Part 0 - The Foreword

See the code for all posts in this series

While at onGameStart this September I had a chance to talk to a lot of great developers, many of which were either building or marketing their own web games. A lot of them knew about the demos that I was doing, and I got a bunch of compliments, but I also got one question over and over again that I had honestly never really thought much about:

"Where are you going with all this?"

I was truly surprised at how many times the question came up, and I realized very quickly how silly it was that I couldn't really point to any sort of end goal to it all beyond "Make a cool proof of concept."

The truth is, I've been doing the WebGL demos primarily because, well, they're a hell of a lot of fun! Also, I've enjoyed the opportunity to contribute to the dev community in some small way through the code I've made available. And those are great reasons, to be sure, but given the demos that I've already done and the time that I've sunk into it I could be half way to a working, playable WebGL game by now, not just some static scenes. So... I figured I would give it a go!

I've got some reasonably modest goals for the game itself, but ones that will push the capabilities of a Web-based game. Obviously it will be WebGL based (I mean, it would be a bit of a letdown if I decided to do a 2D game in flash, right?) and right now I'm thinking it will be a very simple, multiplayer only, 3rd-person shooter. This automatically dictates a couple of the development focuses going forward:
  • As a multiplayer game, I don't have to worry about AI at all. (At least not at first)
  • Being multiplayer also means that I need to develop a decent server and set up the basics of realtime communication. (Hello Websockets!)
  • Third person games tend to play well with both mouse and joystick based controls, so while I am dependent on the browser manufacturers to get one or the other implemented it's probably a safe bet that one of them will be available by the time I reach that point in development.
  • We'll need to have systems and formats in place for Models, Maps, Materials, Animations, etc.
  • We'll need to establish a tools pipeline for getting content into the appropriate formats.
  • And since this content in being delivered through your standard web connection, it would also be great to have some asset management on the client side.
None of these are what you would label a simple problem, but as long as we keep the scope nice and tight and don't try for anything crazy it's all within reach. Being just one programmer, "not trying anything crazy" means making use of a lot of freely available tools, libraries, and art, with a healthy dose of the ever dreaded programmer art thrown in for good measure. What I'm getting at is that this will probably not be a stunning looking game, but I'll be working to ensure that the engine is at least capable of supporting nicer art should an actual artist want to use the code that I create.

Which brings me to a very important point: I'm still very interested in giving back to the community, so everything I do for this project will be open source. The code will be done with an eye towards encouraging others to take it an run with it, either as a whole or in parts. I'm not interested in making a "framework", the code will designed specifically for the game I'm building. But that doesn't mean that it can't be built to be "mod-friendly". I would love for other devs to be able to build on the base game that comes out of this.

I'll also be writing blog posts and putting up demos as I hit various milestones. The posts won't be tutorials, nor will they be simple progress updates but probably something in-between. I'm more interested in talking about the high level decisions that go into the process and how my experience with the previous demo's that I've done influences the choices I make for my own game.

Now, I'm not a professional game developer. I can't promise that everything I do will be a "best practice" or completely optimal. I'll probably re-invent a few wheels along the way, and it's very likely that from time to time I'll have to admit that one choice or another didn't work out so well and code will be scrapped and redone. It's basically a grand experiment on my part, but that's what makes it fun.

The first couple of posts worth of code are already done, and I'll be putting them up over the next few weeks. Wish me luck, and let's hope that this doesn't fall flat on it's face.

Next post in the series: The Setup.


  1. Art is going to give you a headache... Anyway, keep up the good work!

  2. be careful about websockets for game programming. Since they're tcp based, the overhead is quite big. I tried a few times for some games and it is good for local network gaming. For remote gaming, the lag made the "real time" gaming a pain.

  3. Rolando: I can totally understand your concerns, but the real question is "What is my alternative?"

    I'm not willing to introduce Flash or other plugins into this project. (After all, if you're going to use Flash then just use Flash! It's great for games!) and while I've heard that there's been some talk of doing a UDP-based websocket I have no idea if and when it will materialize. Yes, TCP is not the most lightweight of protocols, but it's miles ahead of everything else the browser has to offer.

    Not to mention in my experience most people take the "easy way out" and send JSON or (shudder) XML across the socket, which probably does a lot more to kill efficiency than the TCP overhead does.

  4. You're right. Last time I tried (almost 1 year ago) it was 4 remote clients, 1 server located in US (we were in South America), and we got a delay of about 300ms, which was about right... not excellent but good enough. Local server (in Chile) gave us MUCH better experience, less than 100ms, that and using some predictions (extrapolations/interpolations) gave a pretty decent result (we were using a binary protocol). Having said that... this looks like the future way to do it:

  5. Æ!!

    I think websockets will be good enough for your project. We all know its limitations, but it will work reasonable.

    Keep going! :)

  6. I've been waiting for news like this. Eagerly looking forward to reading your blog posts and seeing the actual progress!

  7. TCP sockets have virtually no limitation, unless you are seeking out HPC solutions. PC's are much faster now than they were in John Carmacks times, the limitation seems to be the implementation in the web browser, and to some extend now with the latest draft, the forced TSL layer.
    I got pings >50ms with Opera and no TSL @localhost.
    Brandon will encounter a lot of other troubles though, if he is to push the boundaries.

    Good Luck.

  8. Sounds interesting and a little encouraging at the same time, good luck!

  9. Quote: "Being multiplayer also means that I need to develop a decent server and set up the basics of realtime communication. (Hello Websockets!)"

    Please go to and checkout my free websocket server i'm developing, you might get your work cut our for you. :)

  10. I think that you should check out this blog for some information on how to write good essay. All the best students are using the stuff like this in the in work