I’ve been most impressed with the collision detection and response (i.e. “physics”) tutorials provided by Metanet, creators of N. They explain some fairly robust 2D collision detection and response in ActionScript, in particular their grid-based and raycasting solutions. Definitely check out their slides from their FiTC 2005 presentation.

There’s also the Flash Dynamics Engine, which uses some proper physics algorithms (Verlet integration) to do a more general physics solver, though it’s more expensive (but more realistic) than Metanet’s stuff above.

Okay, I’m going to make this quick and to the point. I’ll leave digging up all the details to the interested reader, but that shouldn’t be a problem with the likes of Google, etc. I’ll go into more detail about each element of Flash Game Development in later posts, but first for some basic concepts…

• The Flash IDE — by this I mean the original/traditional Flash authoring tool released by Macromedia (now Adobe). It’s a fully integrated development environment for Flash by definition as it essentially represents the official feature set. The software is primarily targetted at artists and designers, with programmers (and larger application-like development) being a secondary concern.
• The Flex IDE — this is the most recent offering from Adobe in the Flash line and is targetted at rich internet application (RIA) developers (programmers). It’s more similar to something like Java or C#. It’s still al of the same Flash technology (well, Flash 9 technology) just packaged for application development. This is a very interesting development, but it’s a little early for web-based games because of the lower version penetration than Flash 8. But this is changing rapidly as MySpace “officially” requires Flash 9 now for security reasons, and the Flash 8 player can update automatically (and very quickly) to Flash 9 as well. As a result, Flash 9 will probably achieve the necessary 85%+ penetration by this time next year (based on past Flash version pentration trends).
• SWF — ShockWave Flash, the output of the Flash IDE, and what runs in your browser (or technically, it runs in the Flash Player plugin in your browser or on your desktop). SWFs is a compact, streaming file format that is somewhat documented by Adobe/Macromedia… their documentation is usually just bad enough to slow down efforts to replicate their Flash IDE’s full feature set. And it is not an open standard, though it practically is because it has been so often reverse-engineered with a high degree of accuracy (and Adobe has no problem with this). Many non-Adobe/Macromedia Flash-related projects operate with the term “SWF” instead of “Flash” as “Flash” is a trademark of Adobe/Macromedia and they don’t take kindly to folks incorporating it into their product names (they prefer folks use “SWF”).
• ActionScript — the programming language for Flash. ActionScript was originally a very stunted language used for some rudimentary scripting, but was soon morphed into a real language (EMCAScript, i.e. JavaScript). It’s a full-blown object-oriented language that supports both strong/static typing and weak/dynamic typing. It is executed by a virtual machine in the Flash player, thus it is not as fast as native-compiled code (C++) and Flash currently does not have a JIT (just-in-time compiler) like Java or C#. But, Flash Player version 8 and version 9 both made significant strides in improving virtual machine performance. One caveat of the VM is that the Flash Player will allow the user to kill any long-running (i.e., a few seconds) loops. The most commonly discussed/used version of ActionScript is ActionScript2 (AS2); ActionScript3 (AS3) was released as part of the Flex/Flash 9 package.
• MTASC — the Motion-Twin ActionScript Compiler is what really blew open the open-source Flash community. Initially a replacement for the Flash IDE’s slow (and buggy) compiler, it has turned into the gcc (Gnu C Compiler) of the Flash universe. It can compile raw ActionScript (text files, just like every other programming language) into SWF’s. These SWF’s can then be imported into the Flash IDE or used directly.
• SwfMill — an XML to SWF to XML processor, this tool serves as the “linker” in our open-source toolchain. SwfMill can take a list of images, SWF’s, and sounds and convert them into an SWF file. Combined with MTASC one can go from a directory full of text files, PNGs and WAVs to a stand-alone SWF game that runs in practically any web browser.
• FlashDevelop — the open-source IDE for Flash. Written in C#, open-sourced, and actively developed, this is one of the best IDE’s available for Flash (or rather, ActionScript). It uses MTASC and SwfMill under the hood and provides a great editor on top. Includes all of the features one would expect: auto-complete, projects, plug-ins, integrated help, library browsing, etc… Highly recommended.

Okay, now to ramble a bit… sorry for the poor organization of this post, but I’m wanting to just get some of this information out there in one place and I’m trying to do it quickly (while at work!)…

There are a few tutorials that nearly all Flash game developers have seen, and they discuss Flash game development from a “traditional” perspective using the Flash IDE. They don’t really cover how to develop using only the free tools. But, they are useful for understanding the basics of Flash as they relate to games. TonyPa’s tutorials on tile-based games (and check out his games they’re quite a bit of fun!). Kirupa also has some excellent Flash tutorials. Flashier Flash has some excellent tile-based games tutorials as well.

In general, I’d suggest aiming to do Flash development very similar to traditional, 2D sprite-based development. With Flash 8, there are raw bitmap structures that you can access. And bit-blits are fast in Flash (from one bitmap to another), so you can implement sprite-based stuff just as you would in a traditional language. You can then take advantage of Flash’s extras, such as fast custom filters and great font support.

Like I said, I’ll speak about all of this in greater detail in a series of future posts, this is just the start.

Mitch Walker, the Program Manager for XNA, has a good explanation of what XNA actually is: Managed DirectX plus a games-oriented framework plus games-oriented content pipeline tools. Not the YouTube of Video Games… but that’s a good thing!

Socialism (or Communism?) is famously a political system that works, in theory. When I previously used the redundant metaphor of Manifesto Games as socialism, I think I may have given the wrong impression — I blame it on my exposure to Slashdot groupthink — that I somehow thought indie games being sold through fair and equitable channels was a bad idea. I clearly do not.

What turns me cold to Manifesto Games is the attitude that surrounds it, the “Fuck the publishers!” writ large in every message, memo, ad, logo and interview. I understand the sentiment, and I appreciate that most of these folks have some sincere experience that justifies their feelings. I just feel as though the image this portrays to those folks beyond our current audiences is one of brash, juvenille angst — in other words, exactly the negative stereotype we regularly defend ourselves against.

Ironically, these are exactly the creators who call for innovations in gameplay that lead to broader appeal. And they largely delivers on the call, at least in a raw indie film kind of way. The problem is that they then go and wrap it in a public image that accomplishes the same goal.

Sugar attracts more than salt… even if the bitterness is not directed toward your audience, the result is the same: when people who don’t live and breath games get a snapshot of this they get that same chill you get when your best “couple” friends have an argument in front of you. Coincidentally, the same feeling I got when I played Facade.

Jeff had an excellent write-up addressing the doubters of XNA Studio Express. And he’s go into an excellent example of exactly what I’ve been trying to explain in all of my recent defenses of the idea. Perhaps his words are a bit more convincing? Let’s hope so…

Well, like it or not, the Manifesto Games website is open to the public. And Slashdot is already knocking on its door. The comments on Slashdot are a little low on the supportive side, but actually very similar to my thoughts as well. In addition, some of the comments over on Greg’s blog are serving to point out some obvious technical/aesthetic/usability issues.

Of course, as Greg points out, it should be considered beta. But one lesson everyone should learn from “Web 2.0″ is that you often only get one shot at a first impression with “the masses,” even if it is your beta. Folks like Google and Flickr have really upped the ante on what quality people expect in a “beta.” (Beta, the new 1.0.)

I hope Greg listens to some of the initial complaints. I agree that the site design and aesthetic aren’t competitive with other online shopping portals, nor is the usability. The registration requirement for downloading a demo is a killer that I’m sure he’ll have to change if we wants any success; these are already “high risk” titles to dedicate any time to — asking the user to jump through one more hoop is easily the nail in the coffin.

And, as I expected, the whole “sticking it to the man” attitude wears thin very quickly. I find it hard enough to swallow all the open source machismo I get from the Linux crowd, et al, and this utterly won’t work for gathering a larger audience for games. It may work for street culture like music, fashion or art, but that’s only because there’s some sincerity behind it (and some deep roots) — this feels shallow and parroted (though I do know that Greg’s hatred of mainstream game development is pretty sincere). As I described it elsehwere, it’s just your classic emo/angst/rebel shit that only serves to attract the least desirable (i.e., pennyless) customer. Do you think folks with $20 burning a hole in their pocket and some spare time are looking to stick it to the man? More likely torrenters and folks like myself satisfied with just a demo…

Like most angst-driven aesthetics, it will wither under its own pretenciousness. It happened to socialism, it happened to the grunge scene, it’s happening/happened to emo, and I’m guessing it’ll happen to Manifesto. But, there was one comment that was absolutely on target: Greg is absolutely putting his money (and time and effort) where his mouth is, and I applaud that.

Just finished reading GBGames’ latest blog entry, Facing Reality. In it, he speaks about his guilt for once again having nothing to enter into the IGF, and in general laments the fact that he’s accomplished so much less than he expected in regards to indie gamedev (though he has gotten a real, full-time job in gamedev, so he’s obviously been doing something right).

I see myself in a similar situation. I’ve been a judge for the IGF for the last four years, and will be returning as one again this year. Every year I have told myself, “next year I will submit something.” And each year passes with nothing to show.

I call myself a “game developer” or “game programmer” because that’s what I do professionally, and it’s what I pretend to do as a hobby. In fact, professionally, I don’t spend any time developing games. I work on game technology (RenderWare, et al). But I don’t even develop technology, I support it. So, in reality, I’m a “game technology debugger,” practically nothing more than a post-release QA specialist. Sure, I’ve got a spiffy title (Solution Architect), but that just reveals that I do even less programming and more planning, which just serves to move me ever further from actually making games!

So, while GBGames is lamenting his inability to finish a game, I find myself reminded of how I have utterly failed to start one.

In fact, I used to be more in GBGames’ shoes… I started many a game that never was finished. And much like GBGames, what I really was doing was starting a game engine, not a game. I think this is a problem affecting the majority of our community, i.e. indie gamedev, amateur gamedev, hobbyists, etc. In a community largely dominated and driven by programmers the goals (and their solutions) are often framed in terms of technology. I guess it’s simply a matter of having a hammer and seeing only nails.

I’ve tried to break myself from this technology focus as evidenced by my recent forays into Flash and Game Maker. I’ve forced myself to step away from the 3D that I stare at all day (and arguably have the most expertise in) and limit myself to 2D technology. Even before then, I accepted the fact that I personally was not going to be crafting the next Doom or Source engine, so why participate in that age old arms race? I’ve also long accepted (and been very vocal about) the fact that technology really means zilch at the end of the day if the game isn’t finished. In other words, I am more impressed by a finished game running at 5fps than a tech demo running at 60fps.

Like GBGames, we all underestimate the time requirements. He’s made a huge step forward by tracking his personal time with the detail of a professional game producer. At first glance, the 170 hours devoted to his personal gamedev project sounds like an admirable accomplishment. “If only I had devoted that much time to my projects…” But when you break the numbers down, it works out to a little over 3 hours a week. In other words, it’s very likely that myself (and most others) are already spending that much time on this hobby of ours (if not much, much more, for those without family obligations — I’m looking at you, students!). Besides, many decent titles have come out of less time than that, and given the out-of-the-box tech we have to leverage these days, many “classic” titles could be recreated in that amount of time.

One comment in particular hits the nail on the head: “the biggest issue is you’re still working on an engine, not a game.” Programming is hard enough when the end result is an executable that someone runs. Programming is even harder when the end result is something you have to turn around and use to do more programming. Most people who call themselves “game developers” or even “game programmers” are neither; they are “game technologists.” If you pick up a book on gamedev, 9 times out of 10 the end result after completing the entire book and working through all of the sample projects is a half-assed 3D game engine that would have been crap 5 years ago and will always look crap. While this may be an accurate representation of the work of many in the professional game development circles, it certainly does not represent the ideal (or even the good).

In my book, if you’re working on a game engine you’ve not yet started making a game. You’re making middleware. And, as someone who has had their bread buttered by the middleware industry for the last five years, I can say that’s there’s absolutely nothing wrong with making middleware. It’s needed, by everyone in the game industry, and by everyone in the indie scene, and there needs to be more of it. But, don’t tell yourself that you’re making a game — at least not yet — or you’re simply going to be disappointed.

A few days ago, EA announced that they were adopting Unreal Engine 3.0 for several titles. Now, that is someone wanting to make a game and not wanting to make game technology. It’s the best decision they could have made, and honestly, they probably should have made it a year ago (or two). If you’re making a shooter (first- or third-person, the tech is essentially the same these days), you should not be writing the tech. You should be using Source, Unreal or Crysis. They’re all cutting edge, and they’re all better than anything your team will be able to produce given any amount of time. The same goes for indies: go out and grab Torque, or Ogre3D, or CrystalSpace, or whatever… there are plenty of groups whose only goal is to produce game tech. If your goal is to make a game, then don’t make tech.

I’m tired of tech. I tired of fighting it. I’m tired of writing it. I’m tired of debugging it. I’m tired of finishing a piece of tech and having no actual finished product because all I did was build a better hammer (or more likely, a worse one that only works on brass nails and not steel ones, and no, it can’t pull nails out, only hammer them in). I’m tired of failing to finish my tech when all I’m really doing is failing to start my game.

Last spring, I decided that the next game I work on should have user interface metrics. By this, I mean I would gather metrics on how the user interacts with the game (where they move the mouse, where they click, when they click, etc.). Given a deterministic game engine (which is how I generally like them to be), one could theoretically playback the UI metrics log to reproduce the exact game session. While I hadn’t spent a lot of time thinking about specifically what information I would gleam from this data, it sounded like a useful (and interesting, and lightweight) metric.

A few weeks ago, I saw this cool utility of TechCrunch: Clickdensity. With just some simple JavaScript inserted into your web pages, Clickdensity builds heatmaps for your web pages. Very cool. I saw another bunch of script earlier today (can’t find it now, though), and just now saw a mentino of CrazyEgg, which does the same thing as well.

And to complete this meme, today on Gamasutra was this fine article on RTS interfaces, Too Many Clicks! Unit-Based Interfaces Considered Harmful. Around page 5 or 6 he makes the suggestion of user interface metrics, describes weighting them, and even provides some references on prior research in the topic.

How’s this more broadly useful to games, particularly the heatmap tools? Well, first of all, games are all about interface design. A game’s UI can make or break its usability, and by extension, its fun (as opposed to it becoming a chore). A heatmap can reveal those parts of the UI where the players consistently click with some expectations but are left wanting. They can also indicate organizational problems: if you have a big cold spot in the middle of your UI, then it’s a likely candidate for simplification. Or, if you find a stray UI element that is consistently as hot as your main UI elements, then perhaps the two need to be better integrated (or at least brought spatially closer).

Given the proper UI metrics, one could look at them plotted over time, specifically their frequency. The developer would want to closely investigate any spikes (or valleys) as they are potential indicators of pacing issues, or confusion on the part of the user.

[Update: I found the other clickmap/heatmap site I mentioned above: The definitive heatmap.]

I’m really surprised by some of the negative comments on Microsoft’s decision to open up Xbox 360 to indie development. I would have expected a great fanfare from the indie crowd, but most of what I’ve heard has been suspicion and derision.

For example, Greg’s thoughts on the subject. Sure, it was basically what I expected, but that still doesn’t mean I wasn’t disappointed to hear it. I realize that his bread is buttered these days by indie *PC* game developers, but he does seem to miss the f*cking point… as do many of the commentors on that post. Here’s what I had to say (carried over from my comments on his blog):

First, Greg attributed the Net Yaroze to Sega. Of course, it was actually Sony. And it was an incredible pain to work with. And it was basically like having a cheap-ass devkit. And it severely limited the resources you could access on the machine. On, and your game had to run completely in-memory. Details @ Wikipedia.

Second, several folks suggested that the service should be completely opened up, truly a “YouTube of Video Games.” Of course, MS (and the media, hook-line-and-sinker) loves a soundbite like that, but what they’re offering really isn’t YouTube (yet). The obvious caveat is that MS has to keep the quality bar high for “official” titles (as I explained in my previous post on the topic). Folks pointed at Amazon.com as an example of an “open system with filtering,” but they are being disingenous (or naive) if they think the barriers to getting a book listed on Amazon are equivalent to me uploading some random code to a website (or a video to YouTube). Perhaps, with the recent growth of on-demand publishing, perhaps the barrier is a bit lower, but there’s still an incredible amount of relative filtering that happens.

Besides, how do you make money off of that? There’s several, several orders of magnitude more videos out there on YouTube and they still don’t have a clear path for monetizing that. Do you really think it’d be easier on the Xbox with code?

Oh, and I really like the excellent point someone made: “Greg, will Manifesto be publishing any title that comes their way, regardless of quality?”

Of course, Greg’s (and some commentors’) perspectives are very different than that of the consumer MS is targetting. MS is targetting that high school kid who knows some programming and wants to do some stuff on the console in his living room. They’re targetting hobbyists who want to “play” on a console. Of course, these same people already know (and already do) this stuff on PC’s.

Craig Perko echoed this misconception I’ve seen elsewhere (which demonstrates GarageGames’ very effective marketing surrounding this):

I had the same reaction as Greg, especially since the actual software you get to use is literally a port of GarageGame’s existing middleware.

GarageGames is offering the Torque X package on top of MS’s XNA framework. It is a separate purchase, just like if I sold you a C# class library for you to use. Users are welcome to use Managed DirectX and C# to their fullest (and basically have full access to the hardware).

Unbelievably, someone actually raised the “but C# is crap” objection:

XNA Express only works with C#. Whilst it isn’t a bad language it certainly isn’t going to go up against C++/asm for performance. [...] You have to create your game on a PC first, erm, at that point you can either distribute it to lots of ppl on PC, or a few ppl on the 360. This is much less 360 development then PC development with 360 development tacked on. But then WTF you develop games with C# and managed directX when you could just develop with C++ and directX, with only a tiny loss in your potential audience? [...] XNA is a solution looking for a problem IMHO.

Let’s dispense with the whole C# vs. C++ crap. I applaud finished product, not the tools used. I could give a flying fuck if some kid in his bedroom (or the guy in the office next to me) used VisualBasic or assembler to craft his Pong clone (or his WWII FPS or his epic fantasy MMO). We’d all be so lucky as to be able to use a nice high level language like C# to make all of our games. Besides, the performance is as good or better than most programmers can do in C++ anyway. I only wish that the performance difference between C# and C++ was the barrier to indie gamedev nirvana…

I was excited when I heard about this, but that’s because until I read this post by Greg, I didn’t realize that the developers wouldn’t be seeing a cent of the game’s sales. Why couldn’t M$ just split the profits 50/50 with the developer? (Of course any such arrangement is probably confused by the fact that the games will be bought with M$ “credits” or whatever they call them, rather than with any real-world currency.)

Which is utterly, completely false. While you can’t make any money off your games, neither does MS. Folks pay a flat fee to have the opportunity to download and run managed code on their console. That’s the only financial transaction. You can’t charge for your game, MS doesn’t charge for your game. If they like it and want to distribute it on XBLA, then count your blessings, because you just got a spectacular calling card for your next title. Oh, and some steady income (based on the current conversion rates). (BTW, credits have a linear exchange rate with US dollars, so there’s absolutely no confusion there even if they were in play.)

I think that if M$ was mostly staying out of the revenue side, and letting people just use XBLA as a market to sell their games at whatever price they wanted, and M$ was just taking a relatively small cut, then Greg would have an extreme positive positive reaction to this. Instead the pricing is still screwed up, and he has an extreme negative about it. (If you haven’t figured it out by now, he’s very rarely lukewarm about anything.

As I mentioned in my previous post on the subject, there’s no way that it would be fiscally sensible for MS to open up the Xbox like this. Not yet. There’s not enough high quality software to stand out from the crap. They make money off of software sales. If there’s a huge market for software that they don’t get a piece of, then they’ll have to shift their profit to the hardware, which would mean consoles would become even more expensive than they already are. If they just took a fixed percentage off of each sale (like eBay, for example), there’s a whole bunch of responsibility that lands in their lap in regards to quality and support. Basically, opening up the Xbox as requested at this time would be a huge liability and money sink for MS, and would really gain very little for the indie gamedev crowd.

And finally, to sum up Greg’s (notably biased) opinion on the matter:

Whoop ti fuckin doo.

Be fucking happy for this new opportunity for indies, hobbyists and amateurs! No one is forcing you to make Xbox games, no one is focing you to sign-up for the Creator’s Club. But previously, it wasn’t even an option. Now, there is another door open, another platform to develop for, one that is significantly different in context than the traditional PC. This will only make the indie gamedev community stronger, and will serve to increase the numbers of game developers out there with some decent skills.

Why waste the effort on tearing it down? Why all the hate?

People would think strange of me if I failed to mention Microsoft’s new XNA Studio Express and Creator’s Club. I’m excited to see DIY gamedev brought to the consoles, and it looks like Microsoft is doing everything right.

Sure, folks will say that Sony did it first with the Net Yaroze. But if you think they’re the same thing then you just don’t get it. XNA Studio Express will allow C# developers to target the Xbox360. Retail Xbox360’s. That’s the first big difference between this and Net Yaroze (which required a custom console). The second is the XNA toolset is a really high quality toolset (unlike the usual half-baked Sony developer tools). Visual Studio is arguably the best IDE (undisputed for C# in my book). The C# language is a wonderful compromise between C++, Java and higher-level dynamic languages like Python. The Managed DirectX API (which is the hardware API for XNA) basically eliminates all of the irritations of the traditional C++ DirectX API (which is already orders of magnitude better than any API Sony has ever released), leaving you with an ideal system library to work. The .NET Framework is very, very full-featured (much more so than the STL, and more appropriately so for games than something like BOOST).

In fact, I’m already in line to get this beta, and look forward to writing C# on the Xbox360. I think we’ll see a spectacular influx of indie gamedev. Seriously, the only drawback for C# for indie gamedev on the PC was always the client machine: fluctuating hardware specs and the requirment for a bulky framework download (potentially). Lots of barriers on top of the built-in indie gamedev barriers (for distribution). But C# on the 360 eliminates that: guaranteed hardware. And with the addition of automatic resource management in C#, you’ve practically eliminated all of the low-level programming worries. All of the focus is on creating the game.

Bravo, Microsoft. Bravo.