Monday, September 28, 2009

More AngelXNA (documentation) to Come

There are a few reasons why my attention to AngelXNA has picked back up lately:

  • Jeff has been actively developing AngelXNA
  • The Global Game Jam is coming up in just a few months! (more on that very soon)
  • I was asked to give a presentation on game prototyping and AngelXNA at WPI for the Game Development Club’s New Developer Track (which I’m very happy they still put on), and… I did.

The talk itself wasn’t stellar. I made several “newbie speaker” mistakes (like not introducing myself and not explaining more of the background of AngelXNA) and I didn’t have a chance (I was asked to give the talk very last minute) to get to know my audience better, so the emphasis and aim of the talk may have been a bit off.

Regardless, it was a good experience, and it demonstrated to me that AngelXNA could really use some more love in the documentation and specifically the “getting started” departments before it’s ready for Prime Time (Global Game Jam 2010).

AngelXNA_logo_3b

So I’ve decided it’s time for me to revisit the ol’ girl and see what I can do to help. Immediate tasks are:

  1. Go through the existing documentation and clarify some of the particularly unclear parts
  2. Write up a few significantly more detailed pages on some of AngelXNA’s key features (Actors, Messaging, and Input come to mind)
  3. Create a few one-week games to test out just how well AngelXNA meets its goal (of making such a process easy and fun) to jog my mind through new ideas for AngelXNA and new insight into how to make it super-easy to pick up

As always, I draw inspiration from Ruby on Rails, which is the web development framework that completely reinvigorated my love for web development and made it fun again. In particular, the official community Rails Guides are, in my opinion, a Gold Standard by which to judge all other documentation. I’d love to have just a few guides to AngelXNA that approach a Rails Guides-level of quality.

If any of you have used AngelXNA, I’d love to hear your feedback on how we can make it easier to pick up or just friendlier in general.

Thursday, September 03, 2009

GameLoop 2009: looping it up like it's 2009

GameLoop 2009: looping it up like it's 2009

First, some thoughts and observations about GameLoop...

Traveler's guide to GameLoop. You can recognize GameLoop by its:

  • Game developers and similar with wide variety of interests
  • Highly-engaged conversations
  • Extreme nerdiness
  • Total awesomeness

Things that I say I did at GameLoop, but without pictures, I can't prove it

  • Attended some great talks including ones on
    • Player trust
    • Prototyping
    • Successful side-projects
  • Met some really cool people including


Oh wait, I do have pictures:




Photos by Vincent Diamante


So now that you believe me that I was there, I'll tell you how it went: IT WAS AWESOME.


No, really. It was even better than last year, and that's saying something, as I still think about some of those conversations when I'm designing games and otherwise thinking about game design.

Of course, it helped that attendance was more roughly doubled this year from last year. Microsoft's NERD center was a great location, too. We had a good number of differently sized and designed rooms, which helped foster a nice diversity of formats for the meetings.

OBLIGATORY SESSION HIGHLIGHTS
(you know you want them)
 

Prototyping:

This was one of the best game talks I've ever been a part of. I think every single person there (there were about 15 of us) contributed, the conversation flowed naturally, and a lot of great ideas were shared.

Highlights from my notes:
  • Some companies use GameMaker to prootype a game design that is then handed off to (hardcore, C++) programmer(s) to create in full
  • The value of prototyping
    • to programmers:
      • Get to see the big picture
      • Get to explore some of the key details
    • to designers:
      • test out the little details of a design
      • can focus a prototype on one key, risky design idea to test whether it's feasible
  • Shane: look at prototypes scientifically: test one thing and treat the process as a true experiment
  • Sandboxing: this is apparently a technique used at Bungie where they can "sandbox" out a part of the game engine to experiment. The code is easy to hack inside the sandbox, and "hacking" is embraced as a philosophy for such a project
  • We talked about "what kind of questions can we answer with a prototype?"
    • Technical question: e.g. will free-flowing water break our physics engine?
    • Design question: e.g. can players fall in love with a dog that's powered by modern AI techniques?
  • Often a prototype is best when it's designed to focus on the intersection of key technical and design questions. This allows a team to make informed decisions about whether to keep or cut big and/or fundamental features early on in a project.
  • Prototypes are good for UI experimentation (Microsoft and others have practically mastered the art of measuring UI usability)
  • Prototypes can be a very powerful communication mechanism: it can help get everyone on the same page and tease out differences in peoples' visions of the game
  • Prototypes can be great for helping team members learn about each others' jobs via cross-disciplinary groups. They can also help determine what role a new hire should take within a team (and see how they work with others).

Successful side projects:

This get-together was a great example of the kind of kick-ass, super-casual exchange of ideas that can happen at an un-conference like GameLoop. We started with quick introductions on what brought us to the session. It turned out that most people choose the session for the same reason I did: we wanted to share what we've learned about how not to succeed in side-projects and possible, just maybe, pick up some good tips from those who've actually been successful with their side-projects.

It turned out that I had more successful side-projects in mind than most, though, so I ended up contributing more positive ideas than I expected I would, which was nice. I also learned a lot from what everyone said, so here are some highlights from my notes:
  • It helps to have someone or someones you care about who expect you to finish
    • Even mild, self-imposed social pressure can be very motivating!
  • Time-box the project so that you're encouraged to push on towards finishing before the project looses steam
  • Working in teams is great, but keep the team as small as possible
  • Also keep the project as short as possible
I need to break away from bullet format to effectively share what I felt was a critical part of the conversation.
In talking about the virtues of limiting project length and team size, I found a few ideas gelled very strongly in my mind...

The problem with a project team that's too big is that it's easy for team members to loose interest in the project. The more people in the project, the more likely it is that someone will lose interest, thus harming the project greatly. The longer the project, the more likely it is that someone will lose interest, including you! So schedule and scale your project so that it will not overstay it's welcome, so to say.
someone please let me know if this made sense...

Also:
  • Focus on activities that are not what you do at work!


One more session, for good luck...

Player trust:

Highlights from my notes:
  • The running mechanic in Mirror's Edge was all about managing players' expectations
    • The red-items-are-for-actions mechanic was there to offset what could have been a crushing lack of confidence in a player's mind that taking long jumps, etc. was worth the risk
  • Sometimes games explicitly develop the expectation that they will betray the player's trust. See: Super Mario Bros.: The Lost Levels
    • (I Wanna Be the Guy is another good example of this)
  • Conversely, surprise is also important to a lot of good game design
  • Portal is a good example of balancing surprise and trust successfully
    • Like Mirror's Edge, it develops a strong visual language to communicate with players
  • Having a regular reward schedule can help a lot
  • Consistency is important: e.g. a random green turtle will not explode (in Super Mario Bros)
  •  Breaking the 4th wall can also be a part of player trust
    • In Donkey Kong Country, the game teaches players that where there is a banana, there is something to keep you from dying while jumping or tumbling to grab it
  •  We inherit trust from past games we've played
    • But as designers, it can be tricky knowing what games your players will have played and what they've learned from those games
  • Advanced examples:
    • Far Cry 2 teaching players to say "fuck it" and accept a high level of chaos is a really great triumph of player trust -- when it works (which for many, it doesn't)
  • It's important to let players know why they failed -- or they may stop trusting the game to be fair and understandable
  • It can help a lot to give players an explicit "out", for example: time-rewinding in Prince of Persia and Braid

Wednesday, May 13, 2009

Independent Game Conference East (IGC East) Wrap-up

This was the first year the Independent Game Conference East has been held, and I think it was a great start. My hopes for IGC East were to do some good networking and see a few interesting sessions, and I feel I got even more than I bargained for. I’d like to recap a few personal notes on the experience and then share some notes and highlights from a few especially outstanding sessions.

igc-east-bjpg

Getting lost in Boston

I had the honor of being Scott Macmillan’s (Macguffin Games) ride to Northeastern University both days. This was an interesting experience for me not only because Scott is, well, and interesting guy, but also because I have very little driving experience in Boston. I expected it to be quite a learning experience, and it certainly was.

We got lost several times (we even asked a man for directions, at one point) but always quickly corrected ourselves and made our way to our destination eventually. Unfortunately, some last minute coding along with difficulty finding the parking garage (we drove right past it, geniuses we are) meant we missed the opening keynote by Vladimir Starzhevsky (Creat Studios), which I heard was pretty good.

In the end, I’m glad to have some more Boston driving experience under my belt (I even learned where the super-secret detour entrance to The Pike is!) and ultimately Scott was happy to have the extra computer which necessitated the use of my car to get to the event. In fact, we enjoyed the experience so much that we opted to drive there again the next day. (Nothing like an adventure!)

Demo Night, networking, tapas

One of the big highlights of IGCEast was Thursday’s Demo Night. Demo Night was a great community event. Besides the joy of getting to see so many interesting games shown off, it was nice to be able to show my support for my Boston indie friends and meet some interesting people who had come by to network and learn.

IGCEast_2009 (25) (Small)

After Demo Night finally ended (for real) at 7:30, we headed over to The Savant Project tapas bar, where Mike Cavaretta of the New England Gamers SIG was hosting a nice, casual get-together. I really enjoyed the food there, and the atmosphere made for some good, casual hanging out. You can find some pictures from that event on the NE Games SIG blog here.

Sessions of note

The rest of what I have to recap from IGC East is session-specific. I will point out in particular the last session highlighted here, which was Dallas Snell’s keynote from Friday morning. Snell’s talk really inspired me and amped up the flames in the fire that’s been burning for me lately to make a true social game.

Standard disclaimer applies: these are simply my notes from the sessions, and any errors are mine and mine alone.

Rapid and iterative prototyping

Eitan Glinert and Ethan Fenn from Fire Hose Games talked about “Rapid and Iterative Prototyping”. Some pearls of wisdom they shared:

  • make friends, and then ask them for help and advice
  • deadlines are critical
  • take advice with a grain of salt
  • test all the time (they tested with “outsiders” once a week, every week)
  • (as a result of testing) identify and remove bad ideas
  • “do it now, get it right later”
  • don’t argue about design ideas: implement, then test
  • have playable builds all the time
  • don’t pay testers: messy business liability and food can actually work better

Eitan also recommended that you start your prototyping by working full-time, because you can get so much more done that way. That said, he admitted at the end that these days the company is making ends meet by doing contract work, so clearly there’s a careful balancing act there.

Game design panel

This was a powerhouse panel made up of five highly experienced (some even legendary) game designers. The panel was made up of:

  • Steve Meretzky (Playdom)
  • Linda Currie (Creat)
  • Chris Foster (Harmonix)
  • Christopher Zirpoli (Auto Assault)
  • Cardell Kerr (Turbine)

The discussion was broken down into ten “Really Important Topics” (RITs), so I’ll break my notes down by topic as well.

1.) Project Goals/Vision

  • Meretzky: “one person should be the “keeper” of the vision
  • Foster: “Harmonix has “The One Question” (ex: “Is it an authentic band experience?” for Rock Band) that helps them make design decisions
  • Kerr: “Your vision is the razor with which you focus your game”

2.) Balance

  • Meretzky:
    • playtest with many different types of players
    • balance frequency of rewards
    • know when to balance
    • Sometimes players ask for a game to be easier, but then find it’s too easy
  • Zirpoli: Perception is everything – the game must feel balanced to players
  • Kerr: if you don’t understand the game’s balance to begin with, you won’t be able to understand how players are breaking it after launch

3.) Interfacing

  • Zirpoli: know your platform: “How do people play games on this platform?”
  • Meretzky: putting even one click between the main UI and an action provides a barrier to users; try to make every interesting action one click (or one immediate action).

4.) Collaboration

  • Foster: “you won the design process, but you don’t own the design”
  • every voice on your team represents part of the game’s audience
  • the designer must act as a sort of arbiter [my paraphrasing]
  • Foster: unravel arguments to integrate the essence/hidden wisdom within every idea

5.) Meaningful Choices vs. Joy of Discovery

It was hard to take notes on this as it was a frantic, unstructured conversation, but the essences is this: it’s important to explore for your game the right balance between making it clear how your games works and allowing players to experience the joy of discovery through discovering as they go.

6.) Communication (and follow-through)

It’s way, way better to communicate 105% of the information than 95%. If you only give 95% of the information, people will stop trusting you and communication will break down.

7.) Constraints

Constraints help focus a game’s vision. Sometimes a game’s best and most unique elements are born from constraints. “don’t be afraid to follow your situation to its logical conclusion” and think creatively about how you can embrace your constraints.

8.) Don’t overdesign

Foster: No one reads design docs.

(I interpreted this part as: remember to keep the design simple and the product of the team’s communication and exploration – do not write the “Design Bible” for your game and expect everyone to live and die by it.

9.) Iteration! (You Will Guess Wrong)

Zirpoli: As game designers, we don’t build with stone, we build with clay

“Great tools enable iteration”

Foster: Iteration is about learning what you don’t know [love that one!]

10.) Research & QA

This conversation largely retreaded what was discussed in the “Don’t overdesign” part, and Damien Shubert’s GDC talk about building better design docs was highly recommended.

Foster: Remember to keep design an “active conversation”

Nothing casual about social games

This was Dallas Snell’s keynote from Friday morning. Fortunately for us, and unfortunately for those who couldn’t attend it, it was the kind of presentation that loses a lot if you can’t be there to experience it as it was delivered. However, I will summarize his key points that he came to at the end.

Essentially, the point of his talk is that human beings are wired such that our social connections are primary to our well-being and sense of wellness; thus, we should be making games that help people develop social connections.

He referenced a scientist’s great work (I really need to look this up some time -- I believe it was the same work that inspired Malcolm Gladwell’s book, “Blink”) about how people, when interacting, have what are called “bids”. Bids are mostly-subconscious attempts to connect with someone else. Often they’re as innocuous as some small bit of body language that must be reciprocated by the other person in order to strengthen the relationship.

Snell proposed that the popularity of Facebook and Twitter may be largely due to the fact that they facilitate bids between people. So, he suggests, we should make games that also facilitate bids. And he also recommends that we tap into player’s social graph, as it’s a powerful part of our lives. This is exactly the way I’ve been thinking about how to make a meaningful social game, so it was really great to hear.

Conclusion

IGC East was a really great experience. The best talks were edifying and inspiring, the networking was solid, and the sense of community was palpable. This event helped show that there really is a substantial Boston game development community. Between the Boston Post Mortem, GameLoop, and now IGC East, it’s clear that Boston is really maturing as a development scene, and it’s awesome to be a part of it.

Friday, May 08, 2009

BarCamp Boston 4 Wrap-up

BarCamp Boston 4 was the first BarCamp I’ve attended, and it certainly did not disappoint! I’d heard great things about it, and last year’s BarCamp-inspired Boston GameLoop set my expectations even higher.

BarCampBoston4_event_board_sm

What was great was that there were people with so many different technical and personal interests there. We had lots of people with computer science backgrounds (duh), but also many with electrical engineering backgrounds, as well as backgrounds in business and design. It made for a great environment where you never knew quite what you’d get, but there was always an interesting voice to hear from.

The informal nature of sessions is great, and all the good session leaders knew this: they always encouraged us to chime in and start the “real” conversation going throughout the room.

Session highlights

Here are some notes from a couple of the many stand-out sessions I attended.

Co-working

betahouse_logo_sm

The co-working session was run by the two main guys who run Betahouse, a co-working facility in Central Square. They intended for the session to be a group discussion, but not surprisingly we all seemed to be most interested to hear about what co-working is like, how they maintain a good culture, and what lessons they learned.

Interestingly, several attendees were planning to start or were about to start up co-working facilities of their own, so it sounds like the co-working community is growing quickly (but hopefully not too quickly!) these days. I enjoyed the talk, and I think it gave everyone a lot of interest in co-working and confidence in its future in Boston.

Rails tools

rails

 

 

I haven’t had the chance to check most of these out yet, but here were a few tools that people mentioned several times and/or raved about at the session:

  • RubyMine (allegedly buggy in its pre-release state, but it’s now in 1.0, and it seems pretty neat to me, from my short use of it)
  • rakeweb (testing via “faking web requests”)
  • httparty (easy http, esp. good for consuming REST)
  • auth_logic (auth)
  • clearance (auth)
  • ar_mailer (oldie but goodie?)

Here are some hosts that were recommended:

  • heroku
  • linode
  • slicehost
  • I’m still pretty happy with Dreamhost, especially since they now support Passenger

Stata Center

Stata_center

I think the Stata Center was a great venue for the event, and I’ll be happy to do it there again next year, if the organizers are for it. Its quirky is a great match for the BarCamp atmosphere.

Conclusion

BarCamp Boston 4 ruled: can’t wait for BCB5! Also, you can read what people tweeted about the event here.

 

 

[Photo credits: Steve Pomeroy and faz the persian, respectively. Post inspired by Matt Wiseley’s great Edit Your Web blog]

Friday, May 01, 2009

AngelXNA spreads her wings!

Jeff Ward and I are proud to announce today that we’re officially presenting AngelXNA 1.0 to the world.

AngelXNA_logo_3b_sm

AngelXNA is a game prototyping engine built upon Microsoft’s XNA framework. It offers all the power of XNA, plus several key features including:

  • In-game interactive Console (ala Quake/Half-Life)
  • Super-simple Logging (to system, Console, and/or files)
  • Basic Actor framework
    •   Layers
    •   Texturing with transparency
    •   Data-driven Actor generation (Actor templates + “level” files)
    •   Interval-based transitions, such as color, size, rotation, and positio
    •   "Animations" (texture swapping at defined intervals)
  • Messaging system (global switchboard)
  • Config file processing
  • Event-driven input from a mouse, keyboard, or Xbox 360 controller
    •   Binding inputs from a config file

What’s a prototyping engine?

The idea behind AngelXNA is to provide a game prototyping framework that will help amateur and professional game developers alike with prototyping game ideas. With AngelXNA, we’ve tried to take away a lot of the boring, unnecessary work that goes into making any game, even a small one meant merely as a proof-of-concept or prototype to explore a single or small set of game ideas.

Ready to get started?

For you brave hackers, here’s the 1.0 tag for the project. You can grab the project using Mercurial or just grab a zip/gz/bz2 file from the “get source” dropdown in the menu.

The documentation is hosted on the project’s wiki.

Version 1.0 is, of course, meant for true early-adopter types. We’ve written up high-level documentation that is commensurate with that of the original Angel engine itself.

For version 1.1, we plan (so far) to have pathfinding working (possibly in addition to some other simple AI routines), but more importantly, we’re hoping to get feedback from our early adopter users on how to improve the documentation of AngelXNA and of course the engine itself.

Have fun and please let us know what you think.

Wednesday, April 22, 2009

This weekend: BarCamp Boston 4!

I’m really looking forward to attending BarCamp Boston this weekend. This will be my first BarCamp, but I’ve heard great things about it.

barcamp_boston

Last year’s BarCamp inspired Darius and Scott to run the very first Boston GameLoop un-conference, which really rocked. I still think about the topics discussed there and the ideas we shared about multiplayer game design, what true “viral” marketing is and isn’t, and more.

A few of my ex-coworkers and some people I’ve met during some great interviews recently will be there as well, so the crowd is already showing signs of excellence. BarCamp seems like the kind of experience that’s almost completely defined by who you interact with, so I think I’m justifiably optimistic.

I love the casual format of the BarCamp concept, it seems to practically guarantee that people will be talking about the topics that get them fired up. I’m sure there will be lots of great idea sharing and that the experience will be very inspiring.

Wednesday, April 15, 2009

Rockstar web-games integration with GTA: Chinatown Wars

I’ve been thinking a lot lately about how games can integrate with the web and provide players with a natural connection between the main game experience and the meta-game, where progress tracking, further exploration, and competition with other players can often become enriched in significant ways. So when I noticed that Rockstar now lets owners of it’s recently-released GTA: Chinatown Wars track their rampages on their Rockstar Games Social Club website, I tried the new feature out right way.

chinatown_wars_logoRockstar_Rampage_Tracker  77987-rockstar-social-club

I love the idea, and the implementation is very well-done. It has me going back to Chinatown every few days to do a few more rampages, which are one of the most fun parts of the game for me. It seemed to me that originally, the game intentionally forced you to hunt for the rampages or assumed you’d enjoy stumbling upon them randomly. But this new feature shows you pretty much exactly where each rampage is and, also significantly, shows you how well you’ve done on each one.

Rockstar_Rampage_Tracker_picture

It also has me reflecting on how well they integrated the Nintendo Wi-Fi Connection support into the game. Basically, once you’ve initialized the connection between your Nintendo Wi-Fi DS account and Rockstar’s Social Club site, you just click on your computer from any safe house (which is where you go to save your game, manage your drugs, etc.) in the game and press the sync button.

It feels very natural, and in my opinion it strikes an almost perfect balance between immersion and natural meta-gaming. The laptop makes a lot of sense in Chinatown’s world, and the idea that it would track your crazy antics in the game seems very consistent with Chinatown’s old-GTA feel of zaniness and embraces the fact that it’s a game. The laptop connection asks for no more suspension of disbelief than anything else in the game, and provides a natural bridge to the meta-game.