This is really good to know - one tends to brush over the little accomplishments in life.
With regard to the 7 day RPG article, I want to add that participating in the 48h game programming competition was an extreme amount of fun. I thought that it didn't exist anymore, but just found that there was another one in December: http://www.ludumdare.com/
Game hackathons are great. My absolute favorite thing about game design is that it brings together such an incredible variety of people: graphics designers, composers, writers, programmers, interface builders. The best game designers are ones that have some understanding of every aspect of their game, even as they specialize. I'd imagine the same is invaluable to startups.
I only participated in 1,5 48h game programming competitions, but it was really great. Especially with the irc chat going along with it, following real time what the others were doing and getting quick answers to common game programming problems.
The first and the third, which I would guess are identical. What we look for is an incurable tendency to build stuff. And if people have this quality, they'll presumably already have shown evidence of it by building stuff.
I feel like I have that incurable tendency to build stuff, but don't have time to use it. In fact, I'm extremely frustrated with my current job because I can't feed the need. How do others do it?
Joshua Schachter might be a useful example. He built Delicious while working on Wall Street. One of his most useful tricks was to build something every day, however small. I suspect that keeps your brain working in much the same way that running every day keeps your metabolism high.
That is good to hear. It seems that quality (perfection?) is secondary to actually building stuff, making mistakes, improving it, learning. As said in your essay, determination is more important than intelligence. Though "an incurable tendency to build stuff" sounds less depressing.
I'm not American, I don't watch more than 40 minutes TV per day.
Also, I can't imagine how anyone with a full-time day job (40 hours, nothing spectacular) can even manage 4 hours of free time. I don't think I have 4 hours a day.
Really enjoyed this. Hopefully it can be a bit of an antidote to the self flagellating I sometimes see on Hacker News about not working on something important. The beauty of just making something is a joy in itself that shouldn't be made so difficult and angst ridden.
PyWeek is a week long game programming competition for Python developers, and Ludum Dare is all about 48 hour mostly from scratch video game development. Both are just for fun, but the competitive setup makes for good motivation to accomplish something in a short amount of time. It's lots of fun.
Building a Role Playing Game in a week is impressive. Taking an entire week to build one single Rocket Propelled Grenade would be interesting too, but much less impressive ;-)
BATFE (Bureau of Alcohol, Tobacco, Firearms, and Explosives) is the US agency with jurisdiction.
BATFE used to be part of the Treasury Department (because those items were regulated by tax law) but there have been attempts to move them to the Justice Dept; I don't know if any succeeded.
I really liked the "Intermission" where he discussed features that he would cut to meet the deadline. I think that's a very important skill and one I would like to improve on for my personal projects.
I agree. Cuts like that are hard, but doing them honestly and really reevaluating what's necessary at least one per dev cycle is really critical. It reminded me of Spolsky talking about how one of the best things they did on Excel 5 was being forced to cut tons of features: http://www.joelonsoftware.com/articles/fog0000000245.html point 13
Not sure if you sure his aftermath at the bottom (although I do agree that cutting things can be the best approach):
Lesson 9: Cutting features isn't always free
Some of the last-minute changes to Hackenslash really blew the game balance out of whack. The inability of monsters to cast spells, and the lack of need to for the player to 'conserve resources' as he pushes deeper into the dungeon trivialized some of the challenge to the game. If those features were going to stay 'gone,' the game needed another design pass to re-balance it and improve the modified gameplay. In other words, cutting features introduced an additional cost to the development of the game. This made me wonder how many retail games were released in a terrible state because the development team didn't have time to re-visit the game design after features were cut to meet schedule.
Yeah, I saw that, but the key point for me is that making the changes to meet the deadline rather than giving up is a form of practicing persistence that ought to prove useful in the long run.
I love doing projects like this, but I tend to get ugly code, since I'm aiming at getting something working quickly (and experimenting with different approaches).
One barrier for me is that the cleanness of the code arguably doesn't matter in a project like this, so the time feels wasted. But, in reality, I'm creating sample code, that I do come back to later, to see how I did things. Like a personal text book. When the code is ugly and hard to follow, it is less useful as sample code. Thinking of it as sample code removes that barrier (that cleanness doesn't matter).
I've started to spend time cleaning up code, and uncluttering it, as I go - but I find it takes an extraordinary amount of time...
Damn. This is impressive, yes, but when I read "RPG" I was expecting something with a Final Fantasy-sized plot; as a developer who is also a writer, I was intrigued about the idea of developing an interactive story within such a short timespan--something similar to NaNoWriMo, but producing a game design document rather than a book as output.
Think, though: NaNoWriMo gives you a month to develop the story. With game design, that means you'll need at least twice that to produce something of equal length, and that's working with a team.
This was more RPG mechanic rather than RPG. I still find that interesting, though, as the system I used to make RPGs in high school - RM2K, which is still out there - had the mechanics prebuilt and let you focus on detail. This game seemed to be quite the opposite.
I'm more interested in the exclusion of thinking time.
He didn't log the time she spent in the shower, but that's when he says some of his best ideas hit him. Personally, I could spend 2 or more hours thinking for every hour of work I do.
That's normal over a work week. I don't like to take my work home with me, but yesterdays hard problem tends to be quickly solved when I show up the next day. Which is one of the reasons I stopped working late unless I really need to.
That reminds me of a story I read about Michelangelo. He stared at the lump of marble that was to become David for a very long time before making the first cut, when asked what he was doing he said "I'm working"
I think the one I've heard goes, the artist is imagining the sculpture beneath that lump of marble, and they explain the actual creation of it as just removing everything else that's not the sculpture.
I saw David in Florence, and I was amazed to see that they also had on display the prototypes for David. There were 3 or 4 or so. From memory, they were all massive blocks of marble, though some just had an arm or leg sticking out. I guess these are called "studies" or drafts. A bit more heavy-weight than a study for a painting.
If he could permit himself to start over several times, I can too.
If you read about small-scale game development, this is a common practice. Danc (http://www.lostgarden.com/) talks a lot about rapid prototyping. Since games have a clear but poorly-defined goal (they have to be "fun"), it's easy to make a limited product around a proposed method of finding that fun, and then either going along with it or throwing it out if it doesn't seem promising. Thus, you can (and probably will) start over several times before making a complete, polished game.
I agree with your points, though I keep coming across variants of rapid prototyping in different fields; and as Fred Brooks told us "build one to throw away".
Is it possible to have a "clear but poorly-defined goal", or are you having a joke? "Fun" is an emergent property - recognizable, measurable but the creation isn't formalizable (though BTW your link mentioned something about game grammars...)
Clear, meaning: we want our games to be fun. Startups also have pretty clear goals: make something of value and make tons of money while doing it.
Poorly-defined, meaning: one man's fun is another man's boredom, it's hard to pin down what exactly "fun" is. Thankfully, though, there are many good educated guesses, so we can't act like "fun" is impossible to define.
Penny Arcade has a subforum wherein from time to time, a battle of sorts takes place. Players are matched up one-on-one and given a week or so to produce SOMETHING that depicts them beating their opponent. Most folk draw something, some wrote and recorded songs, some wrote stories. I wrote a game.
For the first round, I was able to adapt a work in progress (a shooter where you control the location of the ship with WASD and the direction of your shots with your mouse). For the second round, I started from scratch and wrote the above beat 'em up.
(The graphics largely come from River City Ransom, as do all kinds of touches like the sounds people make as you beat 'em up. The characters are altered to represent various forumers avatars, and the heroes was mine - I use the rat-flail from VG Cats as my avatar.)
All in all, I was able to get it done in a single week after a regular 8-hour job coding. And I had a BLAST.
Before we started doing more complicated games, the early games on Rock Solid Arcade (Stunt Pilot, Dogfight, Planet Cruncher) were all developed in his definition of a week. It's really fun seeing something come alive so quickly.
"Lesson 3: Don't underestimate the art requirements"
I'd add music and script/writing to that as well. Sure, anyone can throw together some beats and chords, and anyone can put words on a page. But doing it well is a lot harder than it looks.
