Building the Game: Part 5 - Static Level Geometry

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

(WARNING! The live demo for this post will probably take a while to load and will most likely not run at 60 FPS! Optimizations will come in later posts.)


Sorry about the long gap in posts, but this has proven to be one of the more challenging things I've attempted so far. That's primarily been because I wasn't too familiar with how Unity handled things behind the scenes until I started working on this particular post. I've found some surprising (and occasionally disappointing) things about how Unity handles it's levels, and it's forced me to rethink a couple of aspects of this project, but I think I've got a decent handle on it now and at this point the order of the day is progress in small increments.


To that end, we're going to start talking about exporting, displaying, and interacting with levels from Unity, but we're going to do so one step at a time. Today's step is simply going to be getting the level geometry and lighting information exported and rendering brute force. We're not going to be worrying about collision detection, visibility culling, or anything else right now than just getting those triangles out of Unity and into our browser! 

Thoughts on the iPhone after switching from Android

In the last few months, for various different reasons, I've had been looking to upgrade my beloved Droid X. There was a lot back and forth on my part about which phone to get, as I considered Android heavyweights like the Bionic and Galaxy Nexus, but at the end of the day Android was having a hard time really impressing me with it's latest and greatest. I've been pretty vocal in the past about my love of Android phones, and at one point even wrote a blog post about why the thought of me getting an iPhone was pretty absurd. And yet... today I've got an iPhone in my pocket, and I couldn't be happier with the decision!

I don't want to spend a lot of time talking about why I made the switch (I've already ranted on Google+ about that.) But it did want to mention a few pros and cons about the switch, to help out anyone else who's wondering which way they want to go.

iPhone Pros:

• UI Fluidity: I've got the latest and greatest iPhone now (4S), but even going back and playing with a 3GS there's simply no questions that Apple's UI is snappier than Android in just about every way. Android has gotten better, but even the much anticipated Ice Cream Sandwich doesn't quite match the iPhone's effortless interactions and transitions. (And yes, I've played with an ICS device.)
• Better Browser: On a professional level, as a web developer, this was a very compelling reason to switch. Thing is, I use Chrome exclusively on the desktop so I have a lot of faith that Google can make a great  browser. They just haven't on the phone. Once again, ICS makes strides towards this, but it's still not at the "Chrome on your Phone" point that we really want. Apple, on the other hand, has delivered "Safari on your phone" quite nicely. It's a very fast, robust browser that's pretty close to desktop level in terms of capabilities. If you're developing for the mobile web, Safari is what you target before putting hacks in place to support everyone else.
• More Stable: It was rare that I could go for more than a few weeks without having to battery pull my Droid X. Even when I didn't have to reboot though I had to manually kill off rouge apps more that I wanted to. On iOS I've never had to kill a misbehaving app (although my Wife often has issues with Facebook, but I'm happy to blame that one on a shoddy app.) and I've rebooted exactly once, to install a new OS update. Oh, and speaking of which...
• OS Updates, when they happen: On Android, even with the best of manufacturers, you were looking at many months between the time Google said "Here's Android 2.x! Have fun!" and the time that you could actually get it on your phone (in skinned, unstable, bloatware infested form). With iOS, I was able to upgrade to the latests version the day it came out. That's pretty spectacular, from a developers point of view.
• Keep your grubby hands off my phone! I have exactly 0 Verizon apps on my phone, which is the same number that came pre-installed on it. I don't have a Verizon logo anywhere on my phone. I don't have some special, unremovable skin, and I don't have random social networking bloatware that can't be turned off. Obviously this is possible, but apparently Apple is the only manufacturer that's willing to make an argument for the consumer when it comes to carrier installed crud. I appreciate that more than I can possibly express.
• Accessories: Everyone and their dog makes iPhone accessories. Motorola makes Droid accessories. Guess which one yields the better selection? (Oh, and I love being able to buy headphones that actually include a working mic and inline volume!)
• The Screen: This one is a bit love and hate, but first with the love. With every Android phone on the planet (even the almighty Galaxy Nexus!) shrugging their shoulders and says "PenTile is good enough" Apple's retina display really shines. People, this is what a phone screen should look like! No dithered colors, no jagged edges, no funky refresh rates. Just beautiful, high DPI goodness.
• The Camera: I don't even want to try comparing my Droid X's camera to this one. It's cruel.
• The Apps: This, right here, is the big daddy of switching reasons. Look, I love Android. I really do. But let's face it guys: the Apps kinda suck. For one, Apple's store has a larger selection of apps, and far more platform exclusives (especially if you care about games!) But even for those apps that do have an Android counterpart, the Android version is usually the neglected stepchild compared to the iOS app (Pandora, this still means you!) or you may not be able to run the app at all, due to hardware/software incompatibilities (Netflix, anyone?) And then there's the fact that even assuming that you get a great app that works well it's probably already been out on iOS for months before they bothered to port it, and will likely always be behind in getting updates. The fact is: Apple's App selection and quality makes Android's Market feel kinda laughable. Sorry, but it's true.

iPhone Cons:

• The information is in there... somewhere: To be honest, I was never big into slathering Droid X with widgets. I did make use of most any widget, however, that notified me when something within the app was newly available. Google Reader and TweetDeck were my favorites in this regard. This had the very nice, practical effect that I could pull out my phone, glance at it, and stuff it back in my pocket knowing there was nothing worth looking at. With iOS, EVERYTHING requires you to go digging to see what's new. The most absurd instance of this is Reeder (which is all other respects is a great Google Reader replacement). It gives you the option to but an unread badge on the app icon (yay!) but then only checks for new items when you open the app (whatisthisidonteven...) This is also true of the notification bar, which I loved on Android but almost never use on iOS because, well, there's no way of knowing that it has anything in it till you pull it down. And, of course, there's no notification light. I always thought the Windows Phone 7 commercials were clever. Now I understand exactly what they're taunting.
• 4G: I knew that I would be giving up 4G going with the latest iPhone and it wasn't a big deal to me. It's still a bit of a disappointment, though, especially since I don't feel the tradeoff bought me much in terms of battery life (I get about the same battery life on my iPhone as I did on my Droid X)
• The Screen: I could gush all day about the quality of the retina display, but then I hold my iPhone next to my Droid X and sigh wistfully. It's not a huge problem, and the high DPI certainly helps, but 3.5" is really just a bit too cramped. I don't expect (or even want, really) a massive 4.6" beast or whatever is all the rage these days, but is 4" too much to ask?
• Mail: I was quite put out to realize that in it's infinite wisdom Apple has crippled it's Gmail interface. No push notifications. No contacts. You have to go through the clunky Exchange service just to get it working halfway decent, and then there's still weirdness such as "Delete" actually "Archiving". On top of that, I really hate how Apple handle's conversation threads. Google has just recently come out with an actual Gmail app for iOS, which gives me some hope, but it's still a pretty young app and is lacking some critical features, such as multiple profile support, which means I can't use it. sigh.
• Maps: There are many things that the iPhone does better than Android. Maps is not one of them. Android's built in maps offering completely blows away anything the iPhone offers, either built in or on the apps store. Frankly, it's embarrassing to see Apple touting things like "alternate route selection" in their new OS when Google's had it forever. And that route selection doesn't help me one bit because I have to stare at the screen while I'm driving just to use this sad excuse of "navigation." Voice navigation was one of the first things I missed when making the switch, because Google does it so very well. iOS does have a free MapQuest app that will do voice navigation passably, but otherwise it's a pretty horrid map application, and it makes me sad to have to have two separate map apps on my phone.
• Stupid app restrictions: I really don't care to use iBooks when I have a reasonably large pre-existing Kindle library, and it pisses me off that I have to go digging around in the browser to buy new books for it. On the same token, I loved Amazon's CloudPlayer on Android and it makes me sad to know that I'll never be able to use it on this device. These are things I was fully aware of going in, and not enough to sway my decision, but that doesn't stop it from being annoying.
• Syncing: I made the rather "stupid" mistake of plugging my phone into my work laptop to pull a couple of songs off right after I got it. Little did I know that this would form a bond between machines that was eternal and unyielding, to be broken only by the death and rebirth of my phone, like a Phoenix, through a process that shall henceforth be known as "nuking it from orbit."
  All jokes aside, it's patently absurd that you can only sync your phone with one machine. As long as I log in to iTunes with my Apple ID, can you give me one good reason why I shouldn't be able to use that instance of iTunes to manage my phone content? No. You cannot. It's funny, I've heard a lot of people complaining that Android devices show up as just a dumb USB drive when plugged into your PC. In my mind that's vastly preferable to this insanity.

Now that's a decent list of complaints, but honestly when you look at the whole package iOS comes out on top by a pretty wide margin. You have to be Richard Stallman-style fanatical about avoiding Apple's walled garden to actively let it deter you from the otherwise incredibly solid phone that they've created. I'm still going to be keeping a close eye on Android, and I think that eventually it CAN win out over Apple, but in the meantime I've been liking my iPhone very much, and have yet to regret the switch.

Building the Game: Part 4 - Static Model Instancing

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

Today's post is going to be far less involved than the last one, but it's an important subject that we need to nail down the basics of before we move on too much further.

Thus far we've been doing a decent job of showing one thing on the screen at a time, which is great if the game you're building is "Crate in empty space" or "Look at this thing!", but that's not the game we want to build! We want to build games like "Holy crap! That's a lot of stuff on screen!" and "Look at all these things!"

...or something like that.

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.