Facebook’s IPO has been announced, and this means lots of details on Facebook financials have become public. The most interesting bits for social game developers (in VERY broad terms):
- Almost all revenue from Facebook Credits is generated by games.
- Zynga makes up 80% of the total Facebook Credits revenue.
- In broad numbers, on Facebook, Zynga has MAU equal to 1.5x all other game devs combined. But Zynga’s FB Credits revenue is 4x. That’s an idea of how much better Zynga is at getting players to pay.
- Most of Facebook’s revenues come form advertising.
- Facebook mobile gaming is in its infancy.
- Half of Facebook users use the site via mobile, and this percentage is growing very quickly, but Facebook does not monetize them with games nor advertising.
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.
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.
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++. Continue reading
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.<Number> 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.
I have been playing around with HTML5, Canvas and WebGL. Not a lot to show for it, but at least I forced myself to write a bit again. Check it out here if you’re curious, and good luck reaching a score of 150 on Lesson 5!
By the way, for some reason Firefox has started to run Lesson 5 rather slow in both my PCs. I’m pretty sure it used to be a rock solid 60 fps back when I wrote the game, but at some point either upgrading past Firefox 5, or upgrading to Windows 7, has made it slow. Other Canvas or WebGL stuff (for example Hello Racer) show similar slowdowns. Chrome and Opera run everything silk smooth, so it’s definitely not a hardware or drivers problem.
I’ve been slowly moving away from Firefox and using Chrome more and more. Firefox was really my favourite, but it’s got so many problems, it’s so bloated and slow (even 7.0), Chrome has become my browser of choice.
I may be getting interested in writing stuff again with more depth and detail, appropriate (even if small) audience, and with clearer ownership than social networks provide. Twitter is cool as a sort of RSS aggregator; Facebook has become intrusive, annoying and just generally inadequate for anything but on-the-fly photo and YouTube sharing; and Google+ has flatlined. In preparation for more writing, I have added a WordPress blog to my site, because my old blog system was fun to write but boring to maintain and extend.
I imported all the old content, converted the markup with a php script (destroying a bunch of stuff along the way) and deleted most of the old spam comments I could find (over 700).
Lots of settings, style and layout still to do, but it’s a start. Update your RSS if you are a subscriber!