GameDevBlog

Tip for working with cutting-edge Chrome features (such as Native Client openGL)

So, that was weird. Suddenly, out of nowhere, the opengl sample I was working on for native client stopped working. So I backed out of my code. Still didn't work. Checked my other samples. They didn't work either. Looked at Assaf's Ogre3D sample. Even it didn't work. Started checking my flags and browser settings. Everything looked hunky dory.

Turns out that when you're subscribed to the Chrome developer channel, your version of Chrome will auto-update to whatever the latest offering in the channel is. And it turns out that to keep up with changes in the API, Chrome changed. Normally useful and good for security, but a problem when I'm developing - if Chrome silently updates itself behind the scenes, with breaking changes, I'm going to assume it was something I did.

So - is there a way to turn it off? No.

BUT - I can use Chromium, the open-source sibling of Chrome - its build history is kept on line here. The version I wanted was here - the file I was looking for was chrome-win32.zip. After unzipping that into a Chromium directory in my root I was able to work again. So I'm going to stick with Chromium builds from here out, until I'm done working with Google classes that have the "_dev" suffix.

Play some indie RPGs at PAX

Hey, if you're going to PAX, there's going to be a room (Room 306) set aside for those cutting-edge indie tabletop RPG's I've been on about lately.

I'll be there most of Saturday & Sunday - come find me and get in on one of my games.

Why are these games so cool, again?

• they emphasize story over tactics; tell an entire story in one session, instead of just a single action scene
• everyone gets to contribute creatively
• no railroading - real freedom of choice
• they play fast and fluently
• and, if you're into that kind of thing, you can get your inner actor on. (But you don't have to.)

I'll be ready to run Geiger Counter (survival horror), the award-winning Fiasco (the "Cohen brothers movie game" - real actors and television producers play this one!), In a Wicked Age (bronze age face stabbing), Love in the Time of Seid (no dice!?!), or Lady Blackbird (steampunk action adventure). Come and join us.

Hey, you web developers: where do I start?

So I'm thinking about doing a small game in Native Client. To be able to support leaderboards and some social whatever and monetization I'm going to have to do some server-side stuff. But I've been a console programmer most of my life: I've never done server-side stuff. So I've been looking at various options until my eyes glazed over. Google's App Engine makes OpenID authentication easy ... Amazon EC2 is easily scalable ... taking my own web-site and bumping up the account type is cheap ... there are lots of samples in php, but I don't know php ... I do know a little python ... and I'm fluent in C# ...

And ... start on my Windows machine?  Run a different OS with VMWare? Or just start coding on my hosted box or cloud instance?

What do y'all think?

Text Rendering in Native Client

This "simple_font.cc" under-development example of using fonts is in the Chrome sources. I'm lucky I found it. It was surprisngly easy to take the image data and make it into a gl texture and continue to do everything with the 3d client - I'm guessing a 2d client and 3d client wouldn't play well together, but didn't actually try it. So far it's slow, though - I seem to be spending about ~20 msec on text alone - not sure how much of that is drawing the text and how much is uploading the texture - I'll do some profiling soon - and I haven't tried glMapTexSubImage2D() yet, from these tips.

http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/examples/font/

 

Another Chrome Native Client Crash Tip

Sometimes I'll write some code that crashes my game in Native Client and changing the code back doesn't help.

It seems that Chrome can be made somehow unstable when a crash occurs - I'm not sure exactly what the voodoo is, but shutting down Chrome and then going into the Windows task manager and ending the GoogleCrashHandler process makes things all better. 

(FYI - I'm doing all my development under Vista.)

 

Chrome Native Client Game Loop

It wasn't immediately obvious how to get my game running at a real framerate - the main thread needs to handle messages from the browser, and it does this by overriding a handle message call in the Instance class - unlike a good old Petzold-style windows app which can process the message queue on its own terms. Bottom line, you need to give up control of the main thread so the Pepper API can do its thing. 

So, I should put my game on another thread, right? Well, so far, the Pepper API isn't happy about being called from other threads. And the GL stuff doesn't seem to support moving the gl context from one thread to another a la wGLMakeCurrent yet. 

To get up-and-running, quick and dirty, I had the javascript regularly call the native client with a "tick" command. That was as slow as I expected.

What people seem to be doing for now is putting their game tick on a callback from the page flip, something like this:

void GameFrame(void* data, int32_t result)
{
    // ... update logic ...
    // ... render ...
    renderSurface.SwapBuffers(pp::CompletionCallback(&GameFrame, data));
} 

And now we've got some speed going!

A little work, and you could start logic updating before the swap is finished, for more more speed.

More Chrome Native Client Productivity Tips

I have a cross-platform build - since there's no debugger for Native Client yet, I made sure to keep the program I'm porting still running under windows, so I can still debug the bulk of my code.

Logging, logging, logging. Printf debugging is nigh-intolerable, but that's what I've got right now. When faced with a bug, I add instrumentation until it's narrowed down. Crash bugs are the worst, because they'll likely crash my logger, too, before all of the old logging messages have flushed - there I often find myself commenting out more and more code until the crash bug goes away...

I haven't figured out the voodoo that makes Chrome decide whether it's going to use the .nexe from the cache or a new one. So the first thing my program logs is __DATE__ and __TIME__, so I can make sure the program it's running is indeed the one I just built. And if it's not I clear the cache.

Version control. If I introduce a bug that has me tearing my hair out, I can go back to a previous version. I have to remember to check in often!

Using --jobs # with Scons. That cut my build time by 25%. (Trying to get precompiled headers to work actually slowed down my build enormously ... I'm considering metafiles at this point.)

Notes on Fiasco

Fiasco won this year's Diana Jones Award for Excellence in Gaming. (The Diana Jones Award, I just discovered, has nothing to do with the author Diana Wynne Jones. Huh.) I'd just like to say, good choice! 

Fiasco epitomizes the new-school of tabletop role-playing game that I've been on about lately, the no-preparation, no-GM school:

• The mechanics are incredibly simple, mostly boiling down to choosing black and white dice (effectively stones, as faces don't matter during conflict resolution) to decide how scenes resolve. The epitome of "rules-light", and the opposite of recent editions of Dungeons & Dragons.
• Where a lot of "game master-less" games actually have a rotating game master, expecting every player at the table to be able to do that nebulous stuff a game master does, Fiasco distributes the role - in particular, with the "scene framing" role of the GM.  Fiasco's main rule is - on your turn, you either frame your scene, in which case the other players get to say how it turns out, or you let the other players frame your scene, in which case you get to say. So somebody uncomfortable with making up a scene never has to do it.
• So with such light rules, how do you decide what happens? I've found when I play it comes down to a mix of voting using the dice, and following the fiction. In other words - "karma" and verisimilitude. Sometimes you want to see a character get hurt because it makes sense for the moral of the story; sometimes you want to see a character get hurt because it makes sense from what's happened so far in the fiction.
• It is great for newbies. I've played it with people who have never roleplayed before (including my dad, age 74), people who couldn't care less about the difference between D&D's standard and full-round actions, and seen them shine as improvisational actors and storytellers.
• The setting and genre gets away from trite swords and sorcery and usually finds itself in the present-day: lately I've found that it's easy to roleplay present-day stuff, because we all know it. (It's easy to roleplay fantasy because anything goes - but it's hard to roleplay, say, historical fiction. Suddenly there's an onus on you to be right about stuff.)
• Borrowing from In a Wicked Age, it has a system for setting up random situations and backstories that start your play. Very quickly you get a pregnant situation from which a story will emerge - so there's not much 'what if?' or back-and-forth at the table as you try to hone in on what your game for tonight will be about. And the constraints breed creativity. (I tried to steal these ideas and put them on playing cards with my own That's Drama, but In a Wicked Age and Fiasco have something that That's Drama is sorely lacking: specificity. Where That's Drama might introduce "Wealth" as a prop, Fiasco will introduce "a mason jar full of gold coins."  Details sell the story.)

The way I see it?  Kind of like Wil Wheaton says in the introduction to the Fiasco Companion, Fiasco is the new "red box" Basic D&D.  A gateway drug to this new school/old school roleplaying - and hopefully it'll have the same sort of success that Basic D&D had in its day. (It's already very succesful as indie rpg's go - but I think is it has a shot at the same sort of mainstream success D&D has. If Fiasco has a fatal flaw in that department, it's that it's not suitable for children, and although the Fiasco Companion partially fixes this (I still wouldn't want my 10-year old reading the text) I'm imagining that a "Fiasco Jr" would be at home on the shelves of Wal*Mart next to Apples To Apples. Jason & Steve: if you're reading this, and you do that, I want a cut.)

Fiasco.

Native Client Productivity Tip

During development, you obviously don't need to build every target every time - so why make your build 4x longer?

There's probably a better way to turn off the other targets - some scons magic, a Remove command maybe, you could put in build.scons - but the way I found was to go edit build_tools/nacl_sdk_scons/site_tools/nacl_tools.py and comment out the builds I didn't want, like so: Download nacl_tools.py (9.2K)

If anyone knows the scons magic, could you tell me what it is? Then I'll update this post.