I put up there some of my old C/C++ code, and a few experiments I’ve toyed with in my (now scarce) spare time, mostly related to JavaScript. Feel free to check them out!

Another Game Developers Conference I miss, but I’ll try to track as many presentations as I can:

• GlassBox, the new SimCity simulation engine and some clips of the demos, by  Ocean Quigley, Dan Moskowitz and Andrew Willmott
• Good, Bad, Great Design by Raph Koster
• The 5 Domains of Play by Jason VandenBerghe
• Core Games, Real Numbers by Kongregate
• Math for Game Programmers: Dual Numbers and Physics for Game Programmers: Collision Detection by Gino van den Bergen
• The Dysfunctional Three-Way rant by Chris Hecker
• Cutting the Pipe: Achieving Sub-Second Iteration Times by Niklas Frykholm
• Flexible Rendering for Multiple Platforms and Practical Particle Lighting by Tobias Persson
• Deferred Radiance Transfer Volumes: Global Illumination in Far Cry 3 by Mickael Gilabert and Nikolay Stefanov
• Frames, Sparsity and Global Illumination by Robin Green and Manny Ko
• The Bleeding Edge of Open Web Tech by Vincent Scheibn (video)
• Ambient Occlusion Fields and Decals in Infamous 2 by Nathan Reed
• Porting your game to Native Client, Best practices in developing a web game and DXT is not enough! Advanced topics in texture compression by Colt “MainRoach” McAnlis
• When The Consoles Die, What Comes Next? by Ben Cousins
• Practical Physically Based Rendering in Real-Time by Yoshiharu Gotanda
• Light probe interpolation by Robert Cupisz
• Terrain in Battlefield 3: A Modern, Complete and Scalable System by Mattias Widmark
• Stable SSAO in Battlefield 3 with Selective Temporal Filtering by Louis Bavoil and Johan Andersson
• Modular Rigging in Battlefield 3 by Johan Ramström
• From Console to Chrome by Lilli Thompson (video)
• Math for Gameplay and AI by John O’Brien
• It Stinks and I Don’t Like It: Making a Better Engine Experience At Insomniac Games by Sean Ahern
• What You Don’t Know IS Hurting You: How Aggressive User Research Improved Resistance 3 by Drew Murray
• Data-Oriented Design for Math by Mike Acton
• Understanding Rotations and Fluid Techniques by Jim Van Verth, who also maintains an archive of math and physics materials from this and past GDCs.
• Computational Geometry by Graham Rhodes
• Lots of stuff from or sponsored by NVIDIA
• Diablo 3 Ragdolls by Erin Catto
• Advanced Procedural Rendering in DirectX 11 by Matt Swoboda
• Controls You Can Feel by Zach Gage
• Dynamic Global Illumination from many Lights by Wolfgang Engel, Igor Lobanchikov and Timothy Martin
• Fundamentals of Grassman Algebra by Eric Lengyel
• AI-driven dynamic dialogue by Elan Ruskin
• Faster C++: Move Constructors and Perfect Forwarding by Pete Isensee
• A bunch of stuff from AMD
• Portal 2 Postmortem by Erik Wolpaw and Chet Faliszek (video)
• Fez Tech Postmortem by Renaud Bédard
• Trainyard: A level design post-mortem by Matt Rix
• …
• plus many excellent writeups from Gamasutra and Dave Sirlin
• Technical Summary by Adrian Boeing
• and hopefully soon, lots of this and much more will be available in the GDC Vault

This list is being updated all the time, so I’m not organizing the links yet, I just add them at the end to make it easier to find new additions since your last visit.

In general, there is value in having a single language available for all your needs and platforms even if it’s not 100% portable (look at C/C++). JavaScript is the most widely available language today and, while ugly, the popularity of runtimes like NodeJS and the myriad HTML5 mobile app wrappers like PhoneGap prove that it is viable.

But what’s the value for Microsoft? Is this WinJS effort going to encourage devs to port their web apps easily into native Win versions? I think that’s just not very likely, most devs will settle with just a web app (e.g. Trello), and very successful web apps will get native versions regardless (e.g. Evernote).

I can’t help but think that the effort would have been better spent developing a hassle-free PhoneGap-for-Metro kind of wrapper rather than a close-but-not-quite web-like native environment that developers still need to treat like a port and a separate platform.

• 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.

This means that the first game developers to jump on board for Facebook mobile gaming have half of the entire Facebook userbase all for themselves, and Facebook will be more than willing to help them succeed. This was reflected in Zynga’s shares soaring after this information became public – it turns out that Zynga’s dependence on Facebook is matched by Facebook’s dependence on Zynga.

Of course, the problems associated with Facebook mobile as a gaming platform are huge:

• Screen real estate on a mobile platform is extremely limited, there’s just not much room to show ads or games inside Facebook mobile without severely reducing the amount of actual content the user can see.
• Phones already have gaming (and app) and platform integrated
• On-the-fly game downloads and persistent server connections are a staple of desktop Facebook games, but on mobile the connections will be less reliable, much slower, and capped.

So, Facebook mobile gaming will be a very different beast from Facebook desktop gaming. Many lessons will carry over, but many established patterns like the neighbours bar, notification popups, crammed isometric views, and Flash programming will go away. The nature of social interactions, gameplay design and UI in Facebook mobile is still full of unknowns, and whoever solves it first has (for now) a big shot at a pretty large pot. The sooner you start, the better.

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.

Pros:

• Uses JavaScript, the same language you are likely using (in part or in full) on the client side of web sites and applications. This is a great opportunity to reuse code and expertise across both sides.
• It’s based on Google’s V8 engine, which is being actively developed and keeps getting better, faster and more robust with each release.
• Its asynchronous, event-based nature makes it easy for node applications to support hundreds or thousands of simultaneous connections with great performance and low resource consumption, compared to thread- or process-based solutions. Many modern servers, both standalone servers (nginx) as well as server application frameworks (Hellepoll, Tornado), have gone this route.
• Node libraries and extensions use a standard distribution method called the node package manager. It’s incredibly easy to use and makes managing your external dependencies a breeze.

Cons:

• All I/O in node programs (files, databases, other servers, etc) is asynchronous and usually offered in continuation-passing style. If you are not careful with the way you write your code, you may end up in callback hell. Some libraries like async will help a lot there, but do not underestimate the cost of getting used to code with this paradigm.
• node is event-based, and that’s it. It’s easy to get great performance, but sometimes you need huge performance or scaling even if it’s not easy (note – it never is!). If your concurrency or scaling needs change in the future and other approaches (multithreaded, distributed) would serve you better, you will have to engineer around node (balancers, proxies, routers, hybrid services), or entirely rewrite your code using another technology that allows other solutions (C++, Erlang).
• Many classic hosting providers do not support node.js out of the box, and require renting a virtual server. Recent contenders in the platform-as-a-service space like heroku do offer node.js support out of the box.

Node.js really is an application platform, not a plain web server – you can use one of the popular node frameworks like express to build a fully featured web server, and it will have almost the same throughput as dedicated servers like nginx or lighttpd. In broad terms, I look at them like this:

• Node.js if you’re developing a web application (and its pros/cons are ok for you). Node may also serve the client web site, but its strength is in handling the server-side logic.
• Nginx if you are serving a single, custom web site that includes an application backend. Nginx configuration is simple but powerful for both static files and cgi modules, and it can also fill other roles (reverse proxy/load balancer or mail proxy) in your infrastructure.
• Apache if you are serving multiple sites, each may be built using different technologies (PHP, uwsgi, etc), and/or each may be managed by different people or clients. Everyone and everything knows, understands and/or is compatible with Apache configuration files.

I hope to be able to talk more about node.js in the future.

The good side is, Unity is incredibly easy to use (these tutorials were my starting point). The bad side, the generated SWF takes a hefty 2Mb (the unity web player object is just 41Kb). Anyway, Grab Unity and start playing!

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.

The conclusion? He is much more interested in the iPhone’s back, the plastic cover, and trying to eat them, than in watching the flying colors. And he still manages to open the iOS Notification Center pull-down, and from there go to the Message Center or some other app, in effect leaving the BabySaver. In typical “we know better than you” Apple style, the pull down can’t be disabled, not even inside native apps or as a global configuration setting.

As usual, getting the CSS and scaffolding to work properly across browsers (including mobile Safari) was much more time consuming than programming the actual effects. Particularly disturbing was when the iPhone didn’t like the ‘Style’ button in the upper left corner: it worked fine in the beginning, but after adding the other buttons and the button style, it became unclickable (almost! With lots of trying, I could manage to click it). I have no idea why, and I couldn’t figure out how to revert this behaviour. This, along with the Notification Center issue, is the reason the buttons are at the bottom.

I haven’t tried it on any Androids or Windows Phones, but I have high hopes. Now that all the boring pieces are in place I’ll probably try to write more effects and sounds to see how he likes them.

Feedback is welcome!

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++.

The big annoyance with Ultraedit was that, being a paid product, it was not readily available everywhere I could go. At work, at someone else’s computer, etc. And it seemed to become more bloated with each version. I started looking for alternatives, and settled with SciTE. SciTE is the editor built around the Scintilla text-editing component / library. It’s a very powerful and extensible text editor, but the default installation is rather barebones and lacks many useful text manipulation tools. I was also bothered by the way it implemented rectangular block selections. So I started looking for alternatives again.

The next editor I used was Notepad++, another editor built around Scintilla. Free, lots of features, and lots of free and easy to install plugins. I was completely comfortable with it, no major complaints. Ok well, yeah, one major complaint actually: the “Find in Files” dialog box was fixed in size, and the space available for the listbox of folders to search in was rather short. It was annoying to work with long, descriptive paths. I changed the dialog size and recompiled the editor, but it sucked to do that for every new version of the editor. The other issue with Notepad++ was that I was using Linux (Ubuntu) both at work and on my netbook, and Notepad++ is 100% Windows-only. Oh, and some of the settings are really awkward to configure. Yeah, a great editor, but a number of annoyances.

In text-mode terminals on Ubuntu I had been using joe for quick edits, but for any significant amount of work I slowly started using (and getting used to) vim again. Since I was restless with Notepad++, I tried getting used to gvim on Windows, but despite its many good points, I just could not stomach it. When working in a GUI, sorry but I need at least decent multi-file support with tabs, Ctrl-N to quickly create a scratch file, and of course my Ctrl-C and Ctrl-V and common GUI shortcuts; gvim’s UI is at odds with everything else in the GUI world.

Then someone pointed me to Sublime Text 2. Great editor, lots of tools, features, and neat details. Works on Windows, Mac and Linux. Supports the notion of projects. Scriptable in Python, awesome! I have been using it on and off for a while to see if I really want to switch to it. It is a commercial product, and I suspect that some of the old ghosts with rectangular block selections and Find in Files will come back and deter me from ST2, but for now I’m enjoying it. I wrote a little plugin to add basic Perforce integration:

# Simple Perforce plugin for Sublime Text 2
# (C) 2011 by Javier Arevalo
# Free for anyone to use, distribute and modify

# Copy this file to ST2's Data/Packages/User/perforce.py
# Add the functions to the Tools menu with the following in a file named
#   Data/Packages/User/Main.sublime-menu:
#[
#    {
#        "id": "tools",
#        "children":
#        [
#            { "caption": "-" },
#            { "command": "p4_edit", "caption": "P4 Edit" },
#            { "command": "p4_revert", "caption": "P4 Revert" },
#            { "command": "p4_add", "caption": "P4 Add" }
#        ]
#    }
#]
# And/or in Data/Packages/User/Context.sublime-menu:
#[
#    { "caption": "-" },
#    { "command": "p4_edit", "caption": "P4 Edit" },
#    { "command": "p4_revert", "caption": "P4 Revert" },
#    { "command": "p4_add", "caption": "P4 Add" }
#]

import sublime, sublime_plugin
import os, stat

def UpdateViewWriteability(view):
	if view.file_name():
		if os.access(view.file_name(), os.W_OK):
			view.set_read_only(False)
		else:
			view.set_read_only(True)

# Detect readonly / writable files
# These are both false for non-file buffers
def IsWriteable(view):
	return view.file_name() and os.access(view.file_name(), os.W_OK)

def IsWriteProtected(view):
	return view.file_name() and not os.access(view.file_name(), os.W_OK)

# Event to catch buffer activation and check readonly/writeable
# Note: Running the commands doesn't de- and re-activate the view focus,
# so the ReadOnlyCheck event doesn't fire. We call the function manually
# for each command.
class ReadOnlyCheck(sublime_plugin.EventListener):
	def on_activated(self, view):
		UpdateViewWriteability(view)

# Commands

class P4EditCommand(sublime_plugin.TextCommand):
	"""P4 Edit"""
	def run(self, edit):
		os.system("p4 edit \"" + self.view.file_name() + "\"")
		UpdateViewWriteability(self.view) 

	def is_enabled(self):
		return IsWriteProtected(self.view)

class P4RevertCommand(sublime_plugin.TextCommand):
	"""P4 Revert if unchanged"""
	def run(self, edit):
		os.system("p4 revert -a \"" + self.view.file_name() + "\"")
		UpdateViewWriteability(self.view)

	def is_enabled(self):
		return IsWriteable(self.view)

class P4AddCommand(sublime_plugin.TextCommand):
	"""P4 Add"""
	def run(self, edit):
		os.system("p4 add \"" + self.view.file_name() + "\"")
		UpdateViewWriteability(self.view)

	def is_enabled(self):
		return IsWriteable(self.view)

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.

In the section ‘As Long As It’s Fun, It’s Ok,’ Adam says:

if the gameplay was more important and more compelling than the checklist, then it follows, I think, that no one would actually pay money in order to be able to achieve more checklist progress with less gameplay.

Adam is talking about ‘the gameplay’ as if it were a single, indivisible unit. Nothing could be further from the truth. Most modern games, and particularly most successful games, are not reduced to a single element of gameplay, but rather support and combine a wide array of experiences, mechanics and play styles.

Different players are interested in different mechanics and playstyles. Equally important, even the same player will be interested in different mechanics and playstyles at different points in time, depending on mood, available time and other factors external to the game.

Let’s take FarmVille, which I assume would be a good example of what Adam calls ‘predatory’. People play that game for different reasons and in different ways: to build and decorate a pretty farm (gardening without the dirt); to compete with others (without the stress of a direct confrontation); to relax with a mindless passtime (where you click things and nice stuff happens); to figure out the optimal strategies (and probably move on afterwards); as a collector / completionist (sometimes even obsessively so). I’m sure there’s more.

Most games mix and combine the mechanics that support all their different playstyles; a player can’t ONLY play the mechanics she is interested in and skip the rest. I can’t ignore the loot in Diablo and only play the combat game; I can’t skip boss battles in Bayonetta; I can’t skip the exploration in Shadow of the Colossus.

Freemium games by definition must embed their payment encouragement elements within regular gameplay. One of the ways they do this is by asking players to pay if they want to skip or ignore some of the aspects of the game that are not of interest to them. To characterize this as ‘the checklist is more important than the gameplay’ is a terrible, terrible simplification.

Doing this embedding without ruining the integrity, value and fun of your game is a very delicate design and balancing process. Most games that try get it wrong, and among those that get it right, some can reap massive benefits if they are aimed at the right audience.

Player power curves, and defined goals, are age old mechanics in a designer’s toolbox. A common trend is for sophisticated players to mock the distilled versions of these (leveling up, and explicit lists of goals / quests) as simplistic. And I guess they ARE simple! That’s why they are so successful: because they work as mechanics that a less sophisticated player will enjoy, understand and want to work with.

Same goes for randomness: it’s an incredibly easy way to create uncertainty, variety, anticipation, and similar feelings that are pervasive to most play experiences.

An evil designer may try to create an evil skinner box using these mechanics, but that doesn’t make the mechanics themselves evil or unethical in any way (just like in the original skinner box the lights, the electricity or the cheese are not evil). And outside of gambling, I don’t know of a game that consist purely of a skinner box.

The fact that most successful freemium games derive their revenue from a small % of the playerbase to me means that these games must contain a lot of unadulterated, not-evil, absolutely ethical value for their players. If that were not the case, any players that evade the skinner mechanism that forces them to pay, would simply not play at all. Therefore, the evil skinner component that worries Adam so much must, in fact, do not exist or be minimally present, buried under all that value. Most designers will call this presence simply ‘understanding basic human behaviour’.