I suppose technically this isn't the first O3D game since there are a few in our samples but this is the first O3D game created by a 3d party.



The developers said it took them about 5 weeks with no JavaScript experience and no O3D experience. They've clearly got some smart people there.
2009-06-03
 
 
I gave a presentation at Google I/O about O3D. In it I show getting started creating a small game in about 20 minutes.

(the sound cuts out for 30 seconds at 16:48)

You can download the a PDF for the slides here.
2009-06-03
 
 
You want to know what I've been working on for the last year? This is it!



You can learn the details and try some of the demos at http://code.google.com/apis/o3d/

I think it's incredibly awesome but then I'm bias. For me what makes it awesome:
 
 
I skimmed this post on Brainy Gamer about Little Big Planet and Creativity.

That and some of JC Barnett's comments got me thinking, ....

As amazingly cool as LBP's level editing is, does anyone except game creators and game creator wannabes care?
 
 
Just a random thought but I seriously wonder, does Emacs cause repetative strain injury?
 
 
I found out a couple amazing artists I had the good fortune to work with have websites.

The first is Paul Sullivan who goes by Pencil Primate. His gallery is here

http://www.pencilprimate.com/

and he runs a blog as well.

The second is Josh Tiefer. His site is here.

http://tempsketches.blogspot.com/

Josh needs some encouragement to post more stuff.

Both of them are extremely talented.
2008-07-18
 
 
My friend Omar has been working on this game forever and it's finally out.


 
 
You might have known this but I just found this out yesterday.

I knew std::remove doesn't actually remove anything. The way it is used goes something like this.

std::vector<int> int_array;
 
int_array.push_back(1);
int_array.push_back(1);
int_array.push_back(1);
int_array.push_back(2);
int_array.push_back(3);
int_array.push_back(4);
 
// call remove to remove all the elements that equal 1
// remove reorders all elements so that the things you
// want removed are at the end of the vector
std::vector<int>::iterator erase_from = std:remove(int_array.begin(), 
                                                   int_array.end(),
                                                   1);
 
// actually erase the elements at the end
std::erase(erase_from, int_array.end());
Those comments are how I understood it to work. But that's not the entire story.

It turns out if you actually check the contents of the vector after the std::remove above but before the erase it will be

2,3,4,2,3,4
In fact the stl docs state that the contents of the range between erase_from and int_array.end() are undefined!

Why is this important? Well, a couple of things

 
 
This topic seems almost too basic to even discuss but I've run into these issues fairly often so appearently they do need discussion

When coding somethings to keep in mind, how can we code both efficiently and defensively. In other words, how can we get things done faster and with less bugs.

Here's a few ideas. They might seem obvious but like I said, I see lots of code that doesn't follow these ideas and so I'm bringing them up.

#1) If you do something a lot, figure out a way to make it easier to do.

 
 
I was searching for photos on flickr and I stumbled on these images by some guy who goes by the name of Skinny Coder

Click for larger image