cdoral in another post mentions node.js. I have been following this project for a while so I thought I’d write a little blurb about it and include a few links for further and more in-depth information. Coincidentally, the Node Summit was held this week in SF, so there may be interesting and fresh material coming from there soon.

First things first: I have played with node.js for little experiments but haven’t yet found an opportunity to put it to real, production use. Version 0.6 addressed some of my questions about its capabilities and performance, and it is already being used on production servers for many traffic-heavy sites like eBay or LinkedIn, so it’s clearly gone beyond the experimental stage. If you are building a web service today, node.js is a technology you should consider.

Node is a stand-alone executable that will run a JavaScript file passed on the command line:

node app.js

Your JavaScript program can use the standard JavaScript libraries (Math, etc) and a bunch of node-specific libraries. In most cases, your program will enter an infinite event loop and start receiving, processing and responding to network requests.

And it includes a fancy exporter to Flash11 / Stage3D. All of a sudden, the best way to author advanced Flash content is Unity, not Flash. Considering that Adobe makes their money from Flash tools rather than the plugin, it’s a really odd situation. With the current outlook of Flash after the ‘Flashmageddon‘, it’s hard to say how relevant this will be in the long term, but it’s an impressive feature! And the obligatory cube to celebrate it:

Our little one loves to grab anything shiny, but is especially attracted to LCD screens of any type. He loves the netbook, the MacBook, my desktop’s dual monitors, and of course the big TV, but most of all he loves the iPhone. I often activate the camera in reverse mode and let him play with it, but there’s always been a problem: while he manipulates the phone, he will push some control or other and stop the camera, go to the desktop and start pushing random icons. I was wishing for some sort of ‘baby mode’ where something neat would be happening on the screen, but controls would be disabled.

I decided to use the Sunday morning to dust off my Canvas, CSS and JavaScript skills to code, with Alba’s design input and feedback, a little BabySaver that could keep his attention with bright colors, and be impossible to quit for him. Click here to see its current form. Click on the “Endless” button to enable interactions, otherwise any clicks will take you to my homepage.

Programmers spend most of our time in front of a text editor. Whether it is a standalone editor, or one integrated in an IDE, that’s just what we do.

Back in MS-DOS days, my editor of choice was QEdit, later renamed to The Semware Editor. I loved its configurability, and remapped pretty much everything in it to suit my preferences. Around that time I was also working on Unix systems and used vi there, although only for short editing sessions. I had been exposed to Emacs multiple times (starting with MicroEmacs on the Atari ST), but I could never get comfortable with its crazy keyboard combos.

After Windows 95 came and became my regular environment, the best choice was Ultraedit. Very soon, Microsoft Visual Studio became the compiler and IDE of choice for Win95 development, and its built-in editor proved quite powerful, so I would use Ultraedit for editing files that were not C++.

In a couple of Gamasutra blog posts, Adam Saltsman (of ‘Canabalt’ fame) ranted against what he feels are ‘evil’ game design systems. I characterized his arguments as ‘hysterical’, which is perhaps a bit unfair since rants are meant to be hot. Anyway, at some point I felt compelled to write a long reply, and I’m reposting it here. I’ve edited it only slightly, so it’s possible that some of it is confusing outside of the context of the original discussion.

My guidelines are not for gamers; they’re for humans. My guidelines are not about styles of game or difficulty of game; they’re about treating players with a modicum of respect.

Now, we agree that all players and all humans should be treated with respect. But there is no inherent lack of respect in ensuring that your game encourages players to pay if they like the game and want to enjoy more of it. If anything, you are asking players to respect YOU as a creator by paying something for the enjoyment they derive from your work. Short of a pure donation model, this encouragement must affect the product you create in some ways. That doesn’t make the creator greedy, which seems to be Adam’s characterization of the monetization process.

If you played with the Stage3D spinning cube sample I linked in the previous post, you will notice one thing: the vertex colors in the vertex buffer are given as 3 floats (red, green and blue). This is rather wasteful in most cases because color components often vary between 0.0 and 1.0, and it’s more efficient to specify vertex colors (including alpha) as a single 32-bit value. For example, in hexadecimal notation, 0xFF800040 would mean alpha of 1.0 (0xFF), blue 0.5 (0x80), green 0 (0x00) and red 0.25 (0x40).

If you look in the Stage3D docs, you will find the constant Context3DVertexBufferFormat.BYTES_4 to use in the call to Context3D.setVertexBufferAt(). But if you naively just change the vertex buffer array to turn each vertex color’s set of 3 components into a single hex value, make dataPerVertex = 4 instead of 6, and use BYTES_4 for va1, then you will find that the colors are coming out wrong. Why? Because the function VertexBuffer3D.uploadFromVector() always stores the values from the Vector in floating point format. Of course! This is the most common situation for the components of the vertex positions, normals, texture coordinates and such. But we need our BYTES_4 color value to be stored verbatim as a 32-bit uint.

Vector. and uploadFromVector() do not give you control over the byte format of value. How do you solve this?

A couple of days ago, Adobe released to the masses a new version of their Flash Player, and an updated SDK. The biggest change (for me at least) is the inclusion of hardware-accelerated 3D, known as Stage3D. Here’s a quick tour of what I did to compile and run my first Stage3D program (Windows 7 PC but should be applicable everywhere). Useful because the Adobe site is not really clear about this.