AgileGame: Tic Tac Toe Postmortem

11/23/14

So, first session was a success, as far as "finishing" goes.

Here's the game.

I spend the first ten minutes explaining myself and then an hour to make the game.

Interestingly, I have now done a bit of that thing I decided not to do: make an already defined game. I'll probably do it quite a bit if I continue to try to develop using AgileGame. Which I think I will, it went well and it forced me to identify ignorances and weaknesses.

I don't know how I feel about my no reference rule. Maybe predefined reference material? I didn't remember how to do array stuff and for loops in javascript (turns out, you can do the basic c-style for loop in javascript). I do like slowly building a cheat sheet, so having some sort of penalty or defined rule to not leave the repository helps to build that.

I really liked my introduction. Gives the whole thing a good purpose. I wonder, however, if the intro could make a good video on its own?

I'll probably use introductions for every run of AgileGame. Which is good for another reason, in that I forgot to explain why I named it AgileGame.

As for the actual development of the game, I'm really surprised it almost took me the whole hour to make a very unpolished Tic Tac Toe. I don't even remember how to give elements text, so I went with colored squares instead of text.

Which really shows the advantage of what I did. I forced myself to do what I could before breaking down and doing any research. Any problem led me to thinking of a faster way to do things instead of looking things up. There will be cases where doing this is actually slower than proper research, but I think that's not as common as I think it is. Experience doing things, and learning proper ways on the side, will probably be the fastest way to create and to learn.

Not to say people shouldn't care or focus on research and/or doing things properly. With me, however, I already overthink that, and it's good to put me in a situation where if I don't already know how to do it right, to at least have something working before doing any optimizations. Also, the point is to gain experience doing. Thinking and research are for other designated times, and can be a distraction here.

I really like this as a rapid-prototype tool. Both prototype as in an actual game, or prototype as in a tech demo demonstrating some sort of functionality. Learn by doing and all that.

I think I should somehow incorporate asking for help and/or feedback into the game. Maybe as part of penalty for some breaking of the rules or failure to finish? Though, I don't want to associate asking for help with failure....

I definitely don't participate enough in enthusiast communities (like the crafty community or the python community). That'll most certainly be an incredibly fast way to learn and to network. And make really cool friends.

That maybe kinda unrelated to this. Though being a part of the community seems to be advice that's ingrained in being better at any craft, and I'm not quite in any community. And really, this game is an attempt to hack at the things I haven't really been improving upon....

I'll think about it.

So, what I like:

• The focus
  • The time-limit forces me to think make quick actions
  • Recording it probably also keeps me focused
• The building of a cheat sheet
• The building of a "things to learn" list
• Comfortably making throw-away code
  • As a rule, game code must not be copied or referenced

What needs work:

• Community interaction
• Research necessity handling
  • Basic syntax and such needs to be looked up sometimes
  • Complicated ideas should not be researched during sessions
• Iteration on rules in general
  • Better defined rules
  • Unlocking deeper game making sessions?

Hmmm.... That's probably enough thinking now, let's get to doing.