iBonsai: Social Game Design Concept

A few years ago with the success of FarmVille, I had an idea to create a social game that revolved around the care of plants. There are plenty of isometric farming games!! I know, I know but mine is different. I've killed many bonsai trees in my time but it's not for a lack of trying to keep them alive. I'm also a fan of procedurally generated patterns or designs. My game concept marries the two.



I created that mash-up of trees above with the prototype that a few developers and I put together back in January of 2011. I think it's safe to say that we're not actively working on the project, though we had a blast iterating on it back then.

I wanted the game to feel like something put together by the Wii Sports team. Those games do a fantastic job of rewarding the player for very small achievements. It was also important that, though the game was 2D, the trees needed to feel alive with human-like qualities. We made it so trees would droop when the were undernourished or lacked the proper amount of attention. Alternatively when happy, the branches would playfully bounce after being fed or put in good light.

Since I'm not doing anything with the idea, I thought I'd share the quick design document that I put together to get the team on the same page. It's really just the skeleton of a game based off of a few brainstorming sessions. See what you think:

Replacing Waterfall with Agile

“We cannot change anything until we accept it. Condemnation does not liberate, it oppresses.” - Carl Gustav Jung

The Waterfall model is rigid and doesn't deal well with new parameters, especially when they're introduced late in the game. It also doesn't empower our team members to self organize. Run a few projects with it and you'll certainly agree. Agile methodologies, on the other hand, were designed to iterate and adapt to change efficiently. They also obliterate micromanagement.

I've been asked about best practices in transitioning to agile project management a few times in the last two weeks so I figured I'd drop a few ideas out for general consumption. Agile methodology utilizes the most powerful tools that I've come across for getting my projects out the door on time and underbudget. And, it's easy to implement once you get the basics down. Of course, you must be open minded for this new system because it is drastically different from the sequential model. I started off with that Jung quote because it's important to be positive while trying something new and it's equally important to, at least while testing, set aside what you currently hold to be self evident in order to have the best chance for success. In this article, I'm going to give you some pointers on how to get the agile ball rolling in your company. I'm going to assume that you're currently using the Waterfall model and I want you to remember that...

“There is nothing wrong with change, if it is in the right direction.” - Winston Churchill

First off, you should have a cursory knowledge of agile before you read this. I'm going to go out on a limb and assume that you're already familiar. If not, no problem! Try this post to get the basics.

A company that has a long history of sequential development will, most likely, have a hard time transitioning away from the rigors of upfront documentation and copious Gantt chart updating. Companies steeped in these traditions need to be gracefully guided into agile production. Anything less than a slow merge will end in failure or, worse yet, misgivings about agile itself.

You can always tell when a team has had agile forced down their throats without an experienced coach to see them through. These folks don't want to touch anything new with a ten foot pole but can you blame them? It's not rewarding to modify your workflow only to have to go back to what you were doing previously. This is wasted time, annoying, and can be demoralizing.

There are many reasons that an agile transition may not work. Mike Cohn is one of the best agile coaches in the business and has a great insight to share regarding a major stumbling block that many new agile teams will face.

"I've personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an "Agile Office" to which new Scrum teams could turn for advice. The company's failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating the supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started."- Mike Cohn, Succeeding with Agile

We all need to be on board to make a new style of management work. This includes our stakeholders. My first suggestion to those that want to attempt agile is to get a coach and have that person start by educating your stakeholders on how they can best play their part. Change comes fastest when it starts at the top.

A coach may not be financially viable for your situation. There are plenty of fantastic books out there. If you go the book route, then read it cover to cover twice and feverishly take notes. Once you feel that you're ready to teach the concepts in the book, then you're ready to implement them.

You may even try banding together a community of practice (CoP) with others interested in crossing over to agile before you go full bore. With a CoP you would share ideas on how to effectively integrate new ideas as well as come to a consensus on what a good kick off project may be. I'll talk more about picking that project in a bit.

Here are a few recommendations on books that I really enjoyed. First, you've got to read Cohn's Succeeding With Agile of which I already quoted once above. This is a great book because it deals with introducing agile into an environment that has preexisting frameworks.



The Art of Agile Development

This book is equal parts about Extreme Programming and Scrum. It's very different from Mike's book in that it sometimes gets its point across by telling fictional tales of possible situations.



Agile Game Development with Scrum

Finally, this is the holy grail of Scrum books for Game Development. Clinton Keith was mentored by Mike Cohn who wrote the first book that I mentioned. Clinton was originally from High Moon Studios and could sort of be credited with popularizing agile for the industry.



Now that you have a coach or are armed with the knowhow, pick a project that isn't in the limelight. Yes, a low priority project that isn't going to have the eye of Mordor on it. The reason being is that a limelight project already has enough pressure as it is. And, heaven forbid, you don't have a clean execution your first time out, then you'll be joining the misgiving crew mentioned above.

A good first project should not be time sensitive or you'll surely default to your old system at the first sign of trouble. I prefer a first project to be a new feature, ideally something void of legacy code. Also, try not to pick a project that has a lot of dependencies or that relies on shared resources/talent.

Make sure that everyone shares a common lexical structure for what you're trying to achieve. For instance if you're going with Scrum, then be sure that all of the stakeholders understand what it means to be a stakeholder. If they don't get what Pigs and Chickens is all about, then you're not going to be happy with the outcome. So, get the definitions for all roles and responsibilities defined up front and be sure that there is mutual buy-in from all parties.

Buy-in, Mike Cohn talks a bit about this in Succeeding with Agile. I believe Shane Warden, of The Art of Agile, does as well so rest assured that I'm not the only one who abides by this stuff. Find someone in each camp to champion agile for their respective discipline. The more open minds, bonus points if they're respected influencers, you have will only result in a smoother adoption. Respected colleagues that support the effort are more valuable than gold. They help people that are on the fence about agile to give it a shot.

Be sure to give the whole metamorphosis some time to play out too. Rome wasn't built in a day and neither was effective project management. Agile enables you to fail fast which implies that you may fail at some point. This is a good thing because we're getting the data on what isn't working while we still have time and resources to do something about it. And as you know, the retrospective process is there to help us evaluate and modify accordingly. Allow for a few blunders when you schedule your test run. How to schedule is a much longer conversation and out of the scope of this article. However, all of the books above have solid advice on the subject.

Quantitative data is important and it goes a long way in convincing the nonbelievers. You'll want to record your results and compare them to what you were doing previously. Sure, you'll want to start tracking velocity; but, if you're new to an agile process like Scrum, then you won't have anything to benchmark against. So pick a few basic stats. Try tracking number of meetings, duration of those meetings, number of bugs found/fixed, etc. You'll know what is most important to your company. Select five or six pain-points and get ready to optimize. Done correctly, agile will blow the doors off of sequential for reliable release planning, stable tested code, steady customer feedback, and time efficiency in general. Dr. Jeff Sutherland, a co-creator of Scrum, has even gone on record in saying that:

“If you look at most corporate meetings you will see 50-80% excess overhead. These are the meetings that Scrum eliminates on day 1 if done properly.” – Dr. Jeff Sutherland

My last tip is to avoid using any fancy agile software solutions to start with. There are wonderful tools out there but why increase your learning curve? You can add those tools into the mix later. Remember the first declaration from the Agile Manifesto:

Individuals and interactions over processes and tools - Agile Manifesto

Scrum can be run effectively with nothing more than a stack of index cards and cork board. Do yourself a favor and only add solutions that truly save you time.

That's it. So to recap:

• Understand the rules before you play
• Allocate enough time for a proper test
• Get everyone on the same page
• Seek out influencers in each discipline to champion
• Pick a project that isn't in the limelight to start
• Prove your point with quantitative analysis
• Individuals and interactions over processes and tools

Hopefully these suggestions will aid you on your way to making game development fun and efficient!

JavaScript 30 day Retrospective

It's been about a month since I began my javascript deep dive. I'm ready to take a short break from the subject but I thought it would be fun to write up a retrospective and then post a demo.

Pre-Production

My prior experience with JS was one of cut and paste. I had never really needed to build anything substantial with it. However like many developers, I naively felt that I could just jump into scripting with it. I found that brute force was definitely not the way to go. Before jumping in I, at least, picked up a copy of JavaScript the Definitive Guide:



I'm fluent in AS3 which is held to the same ECMA Standards as JS. However, the languages are far from similar. They both include the basic structures that you'd expect from any language (arrays, objects, variables, etc.). But one stark contrast is that AS3 has classes built in whereas JS doesn't. JS uses prototypal inheritance instead of classical. At one time back when I was using AS2, I knew a thing or two about the subject but those days have long since passed.

An odd thing about JS is its lack of block scoping which ends up resulting in the use of closures to maintain references to data. Suffice it to say that it takes some getting used to.

Rapid Prototype: first iteration

I skimmed through the aforementioned book but still didn't feel that I had a grasp on JS best practices. It's a great book that covers the language as a whole but doesn't really go into detail on how to use the it effectively. Regardless, I took what I learned and started production on a simple game. I went with the card game High Low. I figured that it was a good choice because I didn't need much art. Via Google, I found a spritesheet similar to this:



Where to start? That's what you always ask yourself when you start a project like this. Well, I wanted to start blitting as quickly as possible so set about building something ( __ click here to see!!__ ) that would do that. It didn't take all that long to get that working. However, during my research on how to emulate class construction, I ran across some musing about best practices in JS by Douglas Crockford. Which inspired me to read his book. He wrote JavaScript the Good Parts:


Rapid Prototype: second iteration

Armed with Crockford's take on JS. I decided to refactor everything that I had built. Among Crockford's many contributes, he's credited with popularizing the Module Pattern in JS. I used a slightly more advanced version of this for the core of my application. Here's the psuedocode version from Crockford's book:

 
 var constructor = function (spec, my) {
  var that, other private instance variables; 
  my = my || {};
  
  Add shared variables and functions to my 
  
  that = a new object; 
  
  Add privileged methods to that 
  
  return that;
 }

The pattern basically creates an object that allows for private and public access to methods and variables. It also gives you a unique way to implement inheritance. This is good because javascript doesn't give you this functionality out of the box. Everything in JS is globally scoped and accessible by default. My research project definitely didn't require this sort of structure but I'm just used to thinking with private and public members and it was some good practice.

Of note, I was put off by the void of a proper namespace, such as I'm used to in classical langs. So, I used a solution similar to this (see below) to create a single object that I could use to keep my code separate from other JS that may end up on a page:

/***************
* Call this at the top of a file and pass in your desired namespace
* Example: NS.provide('GAME');
* this will give you the ability to add to that NS
* Example: GAME.gGameObject = function () {};
**************/
NS.provide = function() {
    var a=arguments, o=null, i, j, d;
    for (i=0; i<a.length; i=i+1) {
        d=a[i].split(".");
        o=window;
        for (j=0; j<d.length; j=j+1) {
            o[d[j]]=o[d[j]] || {};
            o=o[d[j]];
        }
    }
    return o;
};

This also allowed me to separate my JS files and maintain a unique namespace. I'm not sure if there is a better way to handle it but it worked for my needs.

After all that, I knocked out what you'll see below pretty quick. My goal was to build a game with multiple states, a dynamic UI, programmatically generated animation, and some basic sprite sheet handling. The main menu state has 200+ animated entities with a stable framerate which is pretty rad.

The code isn't commented very well but it's functional. Here's what I ended up with:



It's definitely not anywhere close to finished but I learned a great deal by building it!