HTML5 Game

I experimented with the HTML5 canvas tag and thought it would be interesting to share what came of that experiment. I ended up building out a blitting engine. Here's an example of a demo which targets iPhones that was put together for a client: Game Demo.

DISCLAIMER: Audio for iOS is horrible. We may end up removing sound from the game all together.

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!