Just to give a quick update that I am back from GDC and (almost) fully recovered. :)
Even better, though - I am on track to be finishing and releasing neocade's first game this month on Android Marketplace for phones and tablets running Android 2.2!
Stay tuned for more announcements as we get closer to the big day.
That's all for now..
-Tom
Tuesday, March 8, 2011
Friday, March 4, 2011
A little bit of insight from the gods: Part 1 - Chris Crawford
Today, I had the enormous privilege of being able to sit, listen to, and take notes from four GDC sessions that were part of a special series being run in commemoration of this 25th year of GDC (formerly CGDC).
The first one was from none other than the man who literally wrote the book on computer game design (the first one, anyway) - Chris Crawford. I had, at my previous job, gotten used to seeing people in person that I had previously only read about in articles and books for years. Even then, seeing Chris Crawford in person is a real trip. A man who is pushing 60 with a chrome dome AND long hair, a hairstyle I will henceforth refer to as "the Crawford", he is as animated and passionate about games as ever. We were regaled with stories about early computers and games (particularly the ones he designed) - core memory, the 6502. We even got to see some sample output from a very early game of his which represented farm animals as series of digit-LED patterns that would move across the display until you would "name" the animal by pressing its "name", which just happened to be the first character in its representation. He would go through how much these machines cost at the time in todays dollars (ridiculously expensive) and tell us a few anecdotes from each time period. It felt a lot like a grandfather passing lore down to the little kiddies. And, in a sense, that's exactly what he was doing.
A few nuggets of wisdom from the old man:
* learn better game design by playing and studying board games, particularly German-style board games
* read Homo Ludens by Huizinga and Understanding Comics by Scott McCloud
* games are about interaction, first and foremost. everything else is secondary to the interaction.
* his first law of software design: whenever you sit down to write a game, and every moment after that, ask yourself "What does the user DO?", not what they see or what they hear, but what they do.
* the basic structures of games has not changed in 30 years (although the games themselves have gotten way better)
* entertainment is and always has been fundamentally about people, NOT things. many people in the games industry, especially those who believe that games should evolve and strive to be like big budget movies with lots of special effects and highly paid actors, etc., STILL do not get this.
* story is all about character
The Q&A portion of the talk revealed an audience truly grateful for this man's return to GDC (after proclaiming in 2006 that games are dead), with one comment at a mic noting that various tweets has named his talk "unofficial keynote of GDC2011". He seemed a bit humbled by this prospect. Another person asked if he would be willing to release the code to some of his other early games as open source, to which he made a note and said he'd look into it, but wasn't sure how recoverable some of the code was.
What I found most interesting about this talk was that he hasn't really changed his views much at all on how games should be and how the industry keeps not-innovating toward these goals; however, I did not sense much of any disagreement in the room. Quite the opposite, I couldn't help but feel a lot of respect for the guy, even though he hasn't made a game in Although this is my first year of GDC, it is my understanding that there are a lot more indies at the conference this year than in previous years (myself included) due, no doubt, to the recent explosion the number indie game development studios formed by various folks leaving their old jobs to find fame and fortune with something they truly love. Maybe we're at some kind of intersection here - but whether that results in more future games being more "about people", as Crawford insists they should be, is something only time will tell.
The first one was from none other than the man who literally wrote the book on computer game design (the first one, anyway) - Chris Crawford. I had, at my previous job, gotten used to seeing people in person that I had previously only read about in articles and books for years. Even then, seeing Chris Crawford in person is a real trip. A man who is pushing 60 with a chrome dome AND long hair, a hairstyle I will henceforth refer to as "the Crawford", he is as animated and passionate about games as ever. We were regaled with stories about early computers and games (particularly the ones he designed) - core memory, the 6502. We even got to see some sample output from a very early game of his which represented farm animals as series of digit-LED patterns that would move across the display until you would "name" the animal by pressing its "name", which just happened to be the first character in its representation. He would go through how much these machines cost at the time in todays dollars (ridiculously expensive) and tell us a few anecdotes from each time period. It felt a lot like a grandfather passing lore down to the little kiddies. And, in a sense, that's exactly what he was doing.
A few nuggets of wisdom from the old man:
* learn better game design by playing and studying board games, particularly German-style board games
* read Homo Ludens by Huizinga and Understanding Comics by Scott McCloud
* games are about interaction, first and foremost. everything else is secondary to the interaction.
* his first law of software design: whenever you sit down to write a game, and every moment after that, ask yourself "What does the user DO?", not what they see or what they hear, but what they do.
* the basic structures of games has not changed in 30 years (although the games themselves have gotten way better)
* entertainment is and always has been fundamentally about people, NOT things. many people in the games industry, especially those who believe that games should evolve and strive to be like big budget movies with lots of special effects and highly paid actors, etc., STILL do not get this.
* story is all about character
The Q&A portion of the talk revealed an audience truly grateful for this man's return to GDC (after proclaiming in 2006 that games are dead), with one comment at a mic noting that various tweets has named his talk "unofficial keynote of GDC2011". He seemed a bit humbled by this prospect. Another person asked if he would be willing to release the code to some of his other early games as open source, to which he made a note and said he'd look into it, but wasn't sure how recoverable some of the code was.
What I found most interesting about this talk was that he hasn't really changed his views much at all on how games should be and how the industry keeps not-innovating toward these goals; however, I did not sense much of any disagreement in the room. Quite the opposite, I couldn't help but feel a lot of respect for the guy, even though he hasn't made a game in Although this is my first year of GDC, it is my understanding that there are a lot more indies at the conference this year than in previous years (myself included) due, no doubt, to the recent explosion the number indie game development studios formed by various folks leaving their old jobs to find fame and fortune with something they truly love. Maybe we're at some kind of intersection here - but whether that results in more future games being more "about people", as Crawford insists they should be, is something only time will tell.
Tuesday, March 1, 2011
subversion... ..or git?
I was listening to Andy Schatz talk at GDC today about how he created the IGF-winning game Monaco in 15 weeks. The IGF-winning build, anyway - the game still hasn't been released just yet. Perhaps the most interesting thing about these talks is not the actual stated content itself - one can find roughly 80% of the best bits for free by searching on "GDC" on Google. Twitter is awesome right now because of all the news stories that are bubbling up with various sites reporting on the event this week. I was actually able to review a good portion of the day's talks by just reading other people's accounts of them in articles linked to from Twitter. (you can find a writeup of Schatz's talk today here: http://bit.ly/eSi76g)
Where the real value of GDC is coming for me is not from the free Android devices, although I am kicking myself a little now for not attending the Google dev days, but rather in between the lines of the talks. It's what the speakers aren't saying, but is plainly obvious to me as I look at their slides or their mannerisms on/off stage. Andy Schatz did not once mention anything technical about subversion, other than a brief mention that he did in fact use subversion. What got my attention was that he was using it from day 1 of Monaco - and that he hardly mentions it, which would imply that he's been using it so long that it's just stupidly obvious
And it should be. Keeping a handle on the changes going on in a codebase is too much boring to make one's brain go through. Solution? Get a program to do it!
This, surprisingly enough, never really occurred to me before. Source code versioning is one of those things that, if I have the tool to do it around and I know how to use it, then I will be a good little user of that tool and version all my code and everything is good. If do not have such a tool in my possession, or just do not know how to use it, I'm back to hacking out code and manually making backup copies every once in a while, when the mood strikes me. And such is the case here - I don't like to think about source code versioning techniques. Just give me the damn tool. And I hadn't even heard of CVS/SVN until I was well into college, and didn't get into serious code versioning practice until I was working at Microsoft.
When I was at Microsoft, we used an in-house tool/system called Source Depot, which, I'm told, is based off an older version of Perforce. The two codebases are said to have diverged quite a ways back and so are a bit different now. Now that I do not work for Microsoft, I do not have any Source Depot anymore, for better or worse. No Perforce, either ($$$).
As far as the free options go, Subversion is the way to go for a client/server model, which is what Perforce and Source Depot (and many others use). There's also Git, which is what the Android project as well as the Linux Kernel project use for their code versioning, which relies on a distributed model.
After some fiddling around through documentation/tutorials on both SVN and Git, I settled on Git because I can run it without a server on my laptop, get vetted version control system going for my project, and it's quite lightweight. I was able to integrate it with Unity by enabling source control from the editor, which essentially just exposes the previously-hidden asset metadata as files that can be checked in, and then doing the initial create/import/commit like one would with any other project directory.
To paraphrase another Andy Schatz takeaway that I thought was really insightful: make something cool every day that you can genuinely be excited about. Keep a steady pace of goodness flowing into your build tree. Try not to do things that take more than a day to do start to finish. Whatever you do, just make something cool every day.
While I would hardly place source code control systems at the top of my list of cool things, the benefit of having source code control on my project now is awesome. Maybe tomorrow I'll try something equally not-always-obviously-cool - maybe an automated test of some sort... ;)
Where the real value of GDC is coming for me is not from the free Android devices, although I am kicking myself a little now for not attending the Google dev days, but rather in between the lines of the talks. It's what the speakers aren't saying, but is plainly obvious to me as I look at their slides or their mannerisms on/off stage. Andy Schatz did not once mention anything technical about subversion, other than a brief mention that he did in fact use subversion. What got my attention was that he was using it from day 1 of Monaco - and that he hardly mentions it, which would imply that he's been using it so long that it's just stupidly obvious
And it should be. Keeping a handle on the changes going on in a codebase is too much boring to make one's brain go through. Solution? Get a program to do it!
This, surprisingly enough, never really occurred to me before. Source code versioning is one of those things that, if I have the tool to do it around and I know how to use it, then I will be a good little user of that tool and version all my code and everything is good. If do not have such a tool in my possession, or just do not know how to use it, I'm back to hacking out code and manually making backup copies every once in a while, when the mood strikes me. And such is the case here - I don't like to think about source code versioning techniques. Just give me the damn tool. And I hadn't even heard of CVS/SVN until I was well into college, and didn't get into serious code versioning practice until I was working at Microsoft.
When I was at Microsoft, we used an in-house tool/system called Source Depot, which, I'm told, is based off an older version of Perforce. The two codebases are said to have diverged quite a ways back and so are a bit different now. Now that I do not work for Microsoft, I do not have any Source Depot anymore, for better or worse. No Perforce, either ($$$).
As far as the free options go, Subversion is the way to go for a client/server model, which is what Perforce and Source Depot (and many others use). There's also Git, which is what the Android project as well as the Linux Kernel project use for their code versioning, which relies on a distributed model.
After some fiddling around through documentation/tutorials on both SVN and Git, I settled on Git because I can run it without a server on my laptop, get vetted version control system going for my project, and it's quite lightweight. I was able to integrate it with Unity by enabling source control from the editor, which essentially just exposes the previously-hidden asset metadata as files that can be checked in, and then doing the initial create/import/commit like one would with any other project directory.
To paraphrase another Andy Schatz takeaway that I thought was really insightful: make something cool every day that you can genuinely be excited about. Keep a steady pace of goodness flowing into your build tree. Try not to do things that take more than a day to do start to finish. Whatever you do, just make something cool every day.
While I would hardly place source code control systems at the top of my list of cool things, the benefit of having source code control on my project now is awesome. Maybe tomorrow I'll try something equally not-always-obviously-cool - maybe an automated test of some sort... ;)
Subscribe to:
Posts (Atom)