Back in September 2010, I spoke about some of the projects I was working on and mentioned a 2D game engine. This year I decided to focus on this project as my main project for the year. Here is a brief description of my plan and how I'm getting on with it.
System Metaphor - Interactive Play
I started by thinking about a metaphor to describe what it was I was trying to create. When I thought about 2D point-click style games (especially Role-Playing Games) I realised that they were all telling a story of some kind so I started thinking about other ways in which people tell stories. Eventually I settled on Plays. I then started mapping some of the terminology of a play with the terminology of a game e.g.
Theatre = Computer
Stage = Screen
Prop = Interactive Sprite
Stage Directions = Events and Actions
etc.
I used a mind map tool to visualise my ideas around the metaphor and to help lead into a high level design. The mind map tool I used was freemind - http://freemind.sourceforge.net/wiki/index.php/Main_Page.
Three-year Plan
Before jumping into the design I tried to roughly plan out my strategy for the next three years of the project.
Year 1 - Build interactive play engine
Year 2 - Build first game using engine
Year 3 - Build follow up game and distribute first game
I also looked at the amount of spare time I would allocate to working on the project, how long each sprint was going to be and what my ideal timebox for the first year would be.
Again I used the mind mapping tool to visual my ideas around this plan.
Sprint 0 - High level design
Using the mapping of terminology I produced whilst drawing up the system metaphor I put together a rough collection of classes in a UML class diagram. I then took each in turn and tried to think of roughly what responsibilities and interactions they would have. As this was sprint 0 I did not want to go into too much detail on the design. I decided that I would build an XML based language that would describe the interactive plays to the game engine with a future project being an editor that would allow visual production of the XML file.
I used a freeware UML tool called Violet to produce the high level design diagrams - http://alexdp.free.fr/violetumleditor/page.php?id=en:home.
During the sprint 0 I put together the user stories that I wanted to tackle first and epic user stories for the rest. I detailed user stories that I felt would cover about 2-3 sprints and kept the rest vague. I planned out the release roughly by placing the user stories and epics into sprints as rough place holders (to be detailed more accurately during the sprint planning for each sprint). I set my initial sprint capacity to the number of days I would be working on the project per sprint and estimated the user stories and epics in number of days to begin with. I used the community edition of Rally to manage my user stories and epics - http://www.rallydev.com/index.php (the main reason for this is that I am familiar with Rally from using the commercial version at work).
I also looked at all of the tools I would need and invested some time working out how to piece them together. Here are a few examples:
* Visual Studio 2010 Express Edition
* Rally Community Edition
* Gendarme and Stylecop for static code analysis (Had to figure out integration with Visual Studio so that they were run on every build)
* NUnit for Test Driven Development and Automated Acceptance Tests
* MoMA for portability checking (Mono compatible)
* InkScape for building Artwork
* Krystal recording studio for music and sound effects
etc.
I also figured out a backup strategy so I wouldn't lose anything.
Sprint Planning
Initially I started by estimating in days (or more to the point evenings) but after a few sprints I started to have a good indication of my velocity which allowed me to see clearly how much capacity I have to fit user stories into. My estimates then became story points using typical small, medium and large user stories to compare a new user story to when estimating.
I continue to monitor my velocity using Rally's velocity chart and work out my next sprint capacity based on the worst 3 sprints. At the moment my velocity and capacity has dropped considerably due to having less time to work on the project through the week.
As I approach an epic that I have not broken into smaller user stories I try to break it down as much as possible and estimate each user story. I then attempt to release plan the user stories by putting them into future sprints as place holders for where I would like to start tackling them.
During this process I am able to see how good/bad my progress is on the overall release and can start thinking about how to adjust the release to meet my goals. In my case I can only extend the timebox because I don't have any more people who can work on it and the scope is reasonably fixed as there are a lot of mandatory user stories to provide a viable release.
Sprint Implementation - TDD and Acceptance Testing
During implementation of the user stories I take a Test Driven Development approach:
* Write a failing test
* Implement only what is needed to make the test pass
* Refactor
During the refactoring step I make heavy use of the static code analysis tools as well as looking for opportunities to make use of design patterns.
Once I'm happy that I have created tests that cover everything for that user story I generate an acceptance test for the user story and ensure that it passes.
I will also take a look at the code coverage of the tests to ensure I have a high coverage (I currently have a test coverage of 91%). Whilst this test coverage shows me the amount of code I am running during the test it does not mean I am fully testing the code being run therefore I only use it as an indicator of potential problems. I make use of a tool called partcover to get this information - http://partcover.blogspot.com/
Sprint Review
At the end of each sprint I look over what I have achieved and what I have missed. I will update the backlog of user stories and may even revise some estimates. I also spend some time doing some manual testing to make sure I am definitely happy with accepting the user story.
Current Progress
I am just about to finish sprint 7 and have another 8 sprints to go before the end of the timebox as it currently stands. My velocity has dropped considerably over the past couple of sprints and I'm currently averaging at 2.5 points. At this velocity I will not complete the mandatory user stories in the current timebox so I will need to revise my overall plan and decide how to improve my current progress.
I currently have 108 unit and acceptance tests all passing and 91% code coverage from my tests. I'm working on Animated Scenery at the moment.
My sprints cover 3 weeks but I only have 9 hours per week to spend on the project so essentially my one sprint is only 3 days worth of capacity so I only have two options to improve my current progress - Increase the amount of time I spend on the project each week or extend the timebox. Currently I'm leaning towards extending the timebox.
Posts
