I use svn because I'm used to it and it's preinstalled on OS X.

I should probably be using git because I'm basically the test case for why git should exist (I do a lot of development on the train, with no internet access-- I wind up doing pathological things like writing little scripts to copy all hits on `svn status | grep M` into a folder so I can do some basic version management without access to the version control system). However my limited experience with git is that it is unnecessarily complicated, and I'm not 100% familiar with how to use it whereas I'm very familiar with managing svn and its quirks, so I've been reluctant to switch over. However apparently we're switching to git soon at work, so I guess I'll be learning git soon one way or the other.

Something I've been very curious about is "svn-git", which is apparently a simple bridge type thing that lets you use git locally, and then push the state of your local git repository over to an svn master server whenever it's ready. It seems like that would make administration easy, and address one of my big complaints with git (the lack of a canonical 'revision number'-- apparently you're supposed to keep track of different versions using a 32-digit hash value or something?).

What's the license on battleofthebits.org submissions?

Small piece of advice: Instead of OpenGL proper, target OpenGL ES. ES is a subset (more or less) of OpenGL that works on devices like mobile phones. It's not any more work to write OpenGL ES than it is to write normal (you just have to call the ES compatible functions, like use glDrawArrays instead of glVertex), your code will automatically compile as if it were straight OpenGL, and if you ever decide you want to port to an ES device you'll have saved a lot of time porting.

Awesome awesome :D Anyone who didn't play this the first time now has no excuse.

[native iPad support]

Just an update to say, iJumpman 1.1 just went live on the App Store, and it adds native iPad support as well as Spanish, French and German language options.

I am writing in boldface, for emphasis!

Interesting, will there be a mac version?

By the way you may want to look at the website, the video gives an error when you try to play.

I totally showed up to this!

But the security guy said no such event was occurring tonight and would not let me
into the building 

I find most open source game library code seems to come under the X11 or BSD licenses. I think these probably are the most appropriate licenses for the specific circumstances around game programming, and when I release code I do so as X11. Because most people making a game probably want to at least have the option of selling it someday, and selling GPLed products is tricky, I think if you straight up GPLed it would make the code less useful to many people and maybe discourage its adoption. LGPL would not tend to have this problem as much, though in practice the LGPL can be tricky to follow, especially for something like a game.

The real benefit of GPL code is that it encourages large ongoing collaborative development efforts. These do not tend to develop around games anyway. Because games tend to be unique artistic works, it is more likely someone will borrow a few routines piecemeal from your open source code rather than just modify your game and rerelease it. For this reason I think it is good to put as few restrictions on the behavior of the users of your code as possible, because you don't know what it is they will be doing with it. (I think GPLing a game might be a good way to encourage ports of it, however.)

I do not think you should worry about whether you'll be able to enforce open source licenses. The history on enforcing OSS license compliance is good and there may be nonprofits that will aid you legally if you cannot afford to go after a license violator yourself. The worry in this scenario is probably figuring out you've been ripped off in the first place more so than being able to do something about it once you work it out.

It is really cool, I think the graphics work together fine and the concept and music are pretty cool.

I can't get past the first instance of spikes though 

By the way, you might want to modify the intro screen to let people know the press-right-to-run thing is there. I didn't figure it out for a long time.

A rule of thumb, pointers can do everything references can but (see Average Software's post) the reverse is not true. So if you ever find yourself having to ask the question, "which do I use"?, the safe thing is to just use pointers.

When you have more experience the places where references are appropriate will probably start to make more sense.

I don't think that Google would invest $100 million on a whim.

But they might invest a bunch of money in Zynga because they think is a good investment, or to get them to do some work for Android or something. "Google Games" might be peripheral to the Zynga investment, or might not exist.

Okay, so the unsurprising part about this story is that Google's investing a bunch of money in Zynga (the Farmville company).

The surprising part (to me, anyway) is that something TechCrunch's anonymous sources are calling "Google Games" is launching this year:

The investment was made by Google itself, not Google Ventures, say our sources, and it’s a highly strategic deal. Zynga will be the cornerstone of a new Google Games to launch later this year, say multiple sources. Not only will Zynga’s games give Google Games a solid base of social games to build on, but it will also give Google the beginning of a true social graph as users log into Google to play the games. And I wouldn’t be surprised to see PayPal being replaced with Google Checkout as the primary payment option. Zynga is supposedly PayPal’s biggest single customer, and Google is always looking for ways to make Google Checkout relevant.

I've seen some things that gave me the impression Zynga is bothered about being shackled to Facebook's decrepit shambling corpse, so I can totally imagine if this existed Zynga would immediately want to be part of it. And TechCrunch's story as to why Google wants to work with Zynga makes sense as well:

The reason these deals are so attractive to companies like Yahoo and now Google is this – Zynga allows them to rebuild the massive social graph, currently controlled by Facebook. For whatever reason people love to play these games and get passionately addicted to them, coming back day after day. That’s helped Facebook become what it is today. Google, Yahoo and others want some of that magic to rub off on them, too.

...what makes less sense to me is what "Google Games" would even be, or why it makes sense. TechCrunch seems to be acting like it's some kind of Facebook clone, but with only the games part. So... this would be Flash games, then? Would they sell stuff, like Yahoo Games? Would it tie into the Android apps store somehow?

Basically I'm sitting here wondering if this is going to actually turn out to be something that can develop into a useful incubator for indie games, like Kongregate or something, or just one of those projects where Google makes something on a whim or because it was somebody's 20% project and then abandons it. (Did anything ever come out of Google Buzz except privacy violations?)

Or maybe TechCrunch is making this whole thing up. Dunno.

Page 13 of the comic, bottom of the frame where he is holding the blue folder. Look at the text on it.

I bet it's Helen.

This is incredible.

Fullscreen and the ability to change the controls would be nice (I keep reflexively hitting space to jump) but for a beta this is great progress.

And there's a mac version :D

Life on earth developed from a single common ancestor species over billions of years by the gradual accumulation of genetic errors combined with the natural culling of traits which fail to promote their own reproduction. Barack Hussein Obama was born in America. Between 1939 and 1945, the German Nazi regime systematically killed 6 million Jews and 5-10 million others in a series of organized camps. HIV causes AIDS. Human emissions of greenhouse gases are leading to a gradual but significant rise in the mean yearly global temperature. On September 11, 2001, agents of an organization called "Al Qaeda" flew airplanes into the World Trade Center in New York, causing their collapse. Vaccines do not cause autism.

( And to get off topic for a moment, the "grab the fields you plan to use and ignore the rest" thing-- actually it's even funnier than it looks at first: Basically Apple's ibtool can take in translation data in XLIFF format, and use this to generate translated GUI layout files ("nibs"). But it can only use XLIFF files it itself created. It has a flag for generating this highly structured stub translation file, where each window pane has a section and within it each button or label or whatever has an ID that the translation data gets attached to. But if you feed it an XLIFF which is valid but structured in some other way, like as just a set of english string / otherlanguage string pairs, it won't know what to do with it.

So there's a workflow that makes perfect sense here within the context of Apple's tools-- you use ibtool to emit your stub xliff file, you feed it into any of the standard translation editor programs that work with XLIFF, you write out the translation, then you feed the filled-out file back into ibtool and it creates your translated GUI. But it sorta seems like the point of there being something like a standardized container format for translation data was lost here at some point? Meanwhile in addition to xliff ibtool also takes its own internal format-- which is not only easier to parse and generate, but also seems a little bit less brittle, which means it's probably what I'll actually wind up using :/ )

Triplefox, that looks really nice. Thanks for the link!

So maybe I'll make a longer post about my Adventures In Localization later, but here's just a short question for now.

I was looking at Apple's localization stuff, and saw in the docs that some of their tools accept translations in a format called XLIFF. I looked this up and this is apparently supposed to be some kind of standard XML container for holding translation data. It looks like this is a huge deal in Java/C# land (and I saw claims in a few places Flash works with it natively?) and there are supposed to be all sorts of standard tools for working with it. Well, great, I thought.

Except...

Looking around, I couldn't quite seem to work out how I'd integrate it into a project. It seemed a little too tied to Java-land-- there didn't seem to be any C++ libraries for working with it, and most of the gui tools are written using Java (read: they have painful UI). There are no native mac tools at all (there's an out of date project that doesn't work with snow leopard). And like everything that exists at the interface of Java and XML, it seems just a little overengineered. It's got these fascinating  features (things like tracking the translator for each individual line, or storing version information so that you can use one file across multiple build versions of a project) but the feature set is so rich it sort of looks like most tools aren't going to support the whole standard. Like, one of the features is storing multiple language translations in a single file, something that sounds really attractive to me, but apparently most of the tools don't work with that feature.

I'm curious. Does anyone work with this XLIFF thing? Are there real benefits to using it, is there some sort of killer tool that makes it worth it to use it? Or will trying to work with this thing just create more work than it saves?

( I didn't ultimately use it, I wound up just dumping my strings+translations into one long text file with minimal formatting, so that I can just run it through a perl script later if I need it converted to other formats. But I guess that means I could convert it to XLIFF if I needed to :P )

Just don't buy it.