Ok, so I have a rough idea for the end result of my game and I started to write up some user stories.
Main Concept:
This is a board game where two players have a set of "pieces" that they can move around the board and attack the other player's pieces. The moves will be turn based: each turn the player gets to move one piece and cause one piece to perform an action. Actions may attack the other teams pieces which will may result in the termination of the attacked piece.
Ok, I'm hoping that with a little modification the game platform can provide the functionality for both a chess game and a Final Fantasy Tactics (great game by Squaresoft fyi for those who haven't played) style game.
User Stories:
User opens the application and sees the game board. Game board is a chess board (8 x 8 - alternating black and white squares) background is a gray. Camera is looking at the center from above and toward one side.
The user has one piece (a blue ball) on the board that is located on one side of the board.
The user can select a square on the board and the ball will move to that square. Movement is shown and not just a sudden change in location.
All movements are logged.
User can have eight balls. To move one, the user must select the ball to move first, then select where to move the piece.
The opponent will have 8 pieces also but of a different color.
User cannot move onto a square that is already occupied.
After the user moves a piece, the opponent will move one of its pieces in a random direction (no piece can move off of the board).
Pieces can move up to three square away.
When a user selects a piece to be moved, the squares that are within range will change color to indicate the possible ending positions for that piece. Attempts to move to a square that is not showing the indication is ignored.
User can choose to attack a piece belonging to the opponent if that piece is within 2 squares from the user's piece. To attack, the user selects the piece that they wish to attack with, then select the opponent's piece that is the target. The attack is logged.
Attacks are logged to the same log that the movements were logged.
Some visual representation of an attack between two pieces is shown.
Pieces have a sense of "health". Each piece can take two attacks before it is destroyed. Destroyed pieces simply disappear from the board.
Add an indicator for the health of the piece.
The pieces can be of different types:
- large, can only move 1 spaces but takes 3 hits to destroy
- medium, can move 2 and takes 2 hits to destroy
- small, can move 3 and takes 1 hit to destroy
Balls bounce in place while they wait their move.
The smaller the ball, the faster it bounces.
The pieces can be loaded in from an external model(s) - maybe spaceships.
When the game starts, the user can choose to play the CPU or play another player.
Network enabled games.
The user's stats are kept from game to game: wins, losses.
When the user starts the game they are asked who they are (username) so as to keep building on their stats.
The user's pieces' stats are kept: number of opponent pieces destroyed
Piece rank based on number of opponent pieces destroyed.
Upgradeable pieces based on number of opponent pieces destroyed.
It's a small backlog and it'll grow. And the stories that are further out are a bit more vague, but they'll become more clear when they start coming to the front.
Starting Development
In the meantime, I decided to setup my continuous integration environment. I am developing this in Java (the graphics done in Java3D) using Maven for my build and Continuum for my continuous integration. Java was chosen because I know it the best and I'm a bit more familiar with Java3D than other 3D programming APIs. Maven was chosen for the use of it's dependency management. I've written a couple of standalone applications in the past and I've refactored out some useful tools dealing with things like error handling and whatnot. And with Maven, it's real easy to include the dependency in the pom and not have to worry about it.
So I got the project all setup with automated builds going and email notifications upon failure. I really think that this is crucial for any project starting up. Get your CI environment up and running. Now I don't have any other developers joining my project at the moment, but non-the-less, it is vital to make sure that whatever you have in your repository is stable (tests pass) at all times.
Interesting bit on the email notifications... GMail has been gracious enough to allow external smtp access to their servers. So it made setting up the mail notifications really simple.
And now I'm all ready to start tackling the first story...
Wait wait! I'm fine with following your thought processes and your project as it progresses. But help me our here! I'm not agile (pun intended). I think I know that user stories are roughly analogous to use cases. You have listed a lot of "things" separated by paragraph breaks. I'm assuming that each paragraph is a user story. But some of them are one-liners and seem to be dependent on what came before them. For example: "The opponent will have 8 pieces also but of a different color." Note the items, "8 pieces also", and "but of a different color". Both of these imply that this is not a stand-alone story. I know this seems self-evident and trivial, but assuming that is correct, then am I correct in saying that each paragraph break starts a new user story which means that it is a new separate iteration of development effort(test/code/test) ? Is this normal agile usage or are you doing your own shorthand for this blog? Just curious.
ReplyDeleteI actually haven't worked a lot with Use Cases in my career except for trying to pull lots of User Stories out of a Use Case. From what I've seen, Use Cases are large all inclusive descriptions of components in a system that becomes the authoritative definition of what the system should do. It includes all the happy paths and error messages when you don't follow the happy path.
ReplyDeleteI've heard User Stories be described as a reminder for a conversation. In the Agile process, a product owner or user proxy is needed to be directly involved with the developers. They usually join the developers in bullpens or war rooms as the development is taking place. Their role in the development cycle is to answer questions and provide background to the stories. So if a developer has a story that sounds a little vague or they need just a bit more clarification here or there, the product owner / user proxy can give them immediate feedback and insight into what they need. One of the other roles of the product owner / user proxy is to maintain the backlog. Stories in the backlog should be reviewed on a regular basis to make sure that the next bit of work to be done is what needs to be done next. And the further the stories are down the backlog, the more vague they are. As you get closer to actually implementing the stories, they become more specific, more concrete.
Some people prefer to hold to a specific format for the stories such as, "As a *type-of-user*, I would like to *describe-behavior* so that *business-value*." Which is great because it gives the developer an idea of who would be using the feature (which could be a role or a persona), what the feature should do, and why they want it. That allows them some insight into the story passed the general description that I gave in my stories. I chose a paragraph format for convenience and the fact that I'm playing the role of developer and user.
In my scenario, to get my backlog I just did what I call a story dump. Just a brain storming session to get some stories out there in a semi-prioritized fashion. As I go a long, I'll review them and update them as I go. I have a bit of unique situation where I'm both the user and the developer and the business value being provided is my entertainment. So stories toward the end of the backlog get real squishy. They might be more of a wish-list right now. And as the product evolves, so do the enhancements. Once I play with it for a while, I'll decide what I want it to do next.
The other issue that you mentioned is that the story seems dependent on previously created functionality, which is absolutely correct. Most of the stories are assuming that the game grid is built and that the pieces will be able to move around on it. And that assumption is encapsulated in the first 3 stories or so. So yeah, the stories have some dependencies but each one should be describing a new behavior that the system should exhibit.
Does that answer your question(s)?
Thanks for reading and thanks so much for the comment!