Building the Game: Part 3 - Skinning & Animation

See the code for this post, or all posts in this series.
See the live demo.

In the previous BtG we got the basics of a model format in place, but it only accounts for static meshes. Now, static geometry is very important and will make up the majority of any scene in our eventual game. But we all know that the most interesting things you see on screen are the ones that are moving, wether it be the player sprinting across the screen or the rocket careening towards your head.

There are many different techniques for creating motion in a game. It can be sliding a static mesh back and forth for a door, running a rigid body through a physics simulation, generating particle effects for smoke and sparks, transforming texture coordinates to fake flowing water, or deforming a mesh to look like waving cloth. We'll end up talking about some of those methods as we work our way through this series, but today I want to talk about the big daddy of animation: Skeletal Animation and Mesh Skinning!

Building the Game: Part 2 - Model Format

See the code for this post, or all posts in this series.
See the live demo.

So, after the previous BtG post we had a bare-bones pile of boilerplate code and nothing terribly interesting to show with it. Obviously it's impractical to hand-code all of our meshes into our game (although that would make it fast!), so the next order of business should be creating a way to get meshes out of the various different modeling tools and into our renderer in a format that's efficient and flexible.

In layman's terms, we need a model format!

Building the Game: Part 1 - The Setup

If you haven't already, read Building the Game: Part 0 - The Foreword to find out what this is all about.

See the code for this post, or all posts in this series
See the live demo.

So, you want to make a game, huh? 

Most of the time when you hit that point the best thing you can do is pick up an existing set of tools or code base and run with it. While you'll probably never find a pre-built toolkit that will fit your vision exactly (and if you DO, why are you building your game? It's already been made!) there is a lot to be gained by picking up Unity or UDK or even something a little less recent like the Quake 3 Source and hitting the ground running. You'll inherit a tested, robust tools pipeline to handle things like level building and model importing. You'll benefit from the experience of veteran developers in the code base. You'll have a large community of people playing with the same tools that you can turn to to ask questions. In short, you'll skip over all the boring, tedious parts of painstakingly tweaking the technology to the point that it's game-ready and focus instead on doing something that makes your game unique.

Essentially: You're going to be very hard pressed to come up with a good reason for NOT building on someone else's work. Save yourself a lot of heartache and try an existing solution first, because you'd have to be insane to want to start your own game from scratch...

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.

glMatrix 1.0 Released

glMatrix has just received a relatively few minor updates, but in order to make my life easier I've decided to relocate the repository to GitHub so that I could manage all my projects in one place. I've decided to mark the occasion by making glMatrix officially Version 1.0!

https://github.com/toji/gl-matrix

There is certainly still room for improvement here, but hopefully GitHub will make it easier to work with the community on features and bugs than Google Code did.

One thing to note, since it's a fairly significant behavioral change: I was notified that quat4.toMat3/4 was producing transposed matricies in older version of glMatrix. I have fixed that in this version but if you were relying on that behavior in older versions you may have to update your code to compensate.

Source Engine Levels in WebGL: Video + Source

Took the time to get the source and video demo for the Source Engine demo online tonight. Have a look!

GitHub Source

And of course don't forget to check out the Tech Talk post if you want to know more of the nitty gritty details!

I stressed for a little while about fixing some of the remaining issues before posting anything (like getting water rendering) but in the end I decided that the demo serves it's purpose in that it shows that we can push a lot of geometry for a complex scene and still run at the speeds that realtime games require. Beyond that, however, I won't be able to make use of the format for any other projects and at this point I want to start working on something that is actually playable, not just looks pretty. As such, spending any further time on the format isn't practical.

I have started on my next WebGL project, and hopefully I'll be at a point that I can start posting about it soon. See you then!