The best way to learn anything is through experience. In this course, my peers and I will be learning the ins and outs of agile management through the lens of creating a board game. Each team member will be presenting their own idea for a game next week in class. Once those ideas are presented, we’ll be setting tasks for one another, swapping out between the roles of developer, scrum lead, and product manager.
A common saying when creating content is that you should always “write what you know.” I’ve been part-time in the service industry for a little over 5 years now. Also consider that I was introduced to tabletop gaming about 2 years into that “career” choice, and ever since I’ve been gamifying every task related aspect of my life since then. With all of that in mind, the game I plan on presenting to class tomorrow will be one based on being a server in a restaurant.
I’ve written up a really short summary of what I want for the game (linked here). I don’t want to flesh it out too much, as I suspect that part of the development process for this game will involve, well.. developing. The gist of what I’ve linked to essentially goes as follows:
- 2-4 competitive players
- Players are closing servers at *insert-a-restaurant*
- Players have 3 stats
- Energy (The ability to do things during your turn)
- Management (The ability to do multiple things during your turn)
- Charisma (The abilitiy to make the things you do better)
- Turns start with drawing from the deck of reservations
- Players compete for highest Tip/Sales ratio
Beyond that, we will flesh out as a group assuming my game is chosen.
After working with the Unity Standard Assets, we finally have animation in our game. An even more exciting result of using the standard assets, as opposed to attempting to Frankenstein code from various sources and past projects is that our seconds per frame have changed back into frames per second. The bad news is that the rest of the project is no longer up to par with the character. I’m going to be retooling the stages to create a more cohesive theme going forward.
One issue I’ve had dealing with the game was getting the running animation to play in the way I wanted. Going through the Unity Asset Store, I found out about the Unity Standard Assets, a package of general items useful for any game, first person or otherwise. What I found handy was the third person character they had premade in to the set. I’ve been studying the scripts associated with the character and the control of him, seeing how I can apply it to our game.
After the first build of the game, a couple issues have risen. Namely the framerate. Normally the speed/smoothness of media is rated in frames per second, but after making an actual build of the game, seconds per frame seems more appropriate. I’m going to look back in the Lerpz tutorial section about optimization to see where I went wrong. As it stands, the game is literally unplayable right now.
Lerpz was a decent intro into what could be done in Unity, but browsing through the Unity Asset Store has shown me a much better slice of what is possible in Unity. I came into this class as a first semester animation student, the idea of creating all of the assets for the game initially. Having such a comprehensive suite of assets to sift through is definitely a major boon.
My game idea may have made it into the top 3, but it was finally beat out by Lucky Cat and the CSG Beatdown. I’m not too upset about the situation, the Lucky Cat game sounds simple enough to complete and it has an interesting spin on the bullet hell shooter motif. Even going off of CSG-110 and the game I’ve pitched for that class, scale seems to be a consistent theme as far as things I need to work on.
In class, we voted on idea pitches for video games to be made in class. I had the idea of an arcade side scrolling beat em up, a la Double Dragon or The Simpsons. The game would have a cast of two playable characters, the eponymous Punch-Boy and Kick-Chick. The player would have to choose which character is the right for the job as certain enemies or obstacles can only solved by punching, and others by kicking. In addition to my own game, Lucky Cat and the CSG Beatdown are also in the running.
Not sure what to work on first? Terrible at prioritizing what’s most important about a project? Need a quick, fun, and easy way to make sure everyone’s voice is heard? Well why not try buying a feature? That’s exactly what happened in class for both groups at the instruction of our teacher, and honestly, I really enjoyed it. So much that I plan on using this idea in projects outside of school, whether for serious matters or just as a helpful decision making tool with friends and family.
Buying a feature essentially has you take each feature you have decided on being important for a product, and writing each down individually on its own index card. From there you pass out exactly one of each denomination of currency to each member of your team. In class we used monopoly money photo copied on white sheets of paper; I’d most likely use playing cards in the event that I used this method again outside of class. Once everyone has one of each currency, each member places a bill face down on a feature until they have voted once on each feature. After votes have been placed, the values of each bill are shown, and features arranged according to initial value. From there, starting with the developers or lowest ranking team members in terms of management, and ending with the product owner, everyone may silently move one feature up one or down one. Then the discussion may begin. Once all features have been voted on, the process can then be repeated for any features of features, and so on, and so forth.
This gives a general idea of where the team is at in terms how important they feel features are, allows each individual team member a chance to affect the results in a meaningful way after the fact, all while still resting final say with the product owner.
In the end, none of this is set in stone and when it comes to actually developing the product, the order very well may change, but this at least gives a starting point to go off of.Below are the results of my teams go with Buying Features for our game Mischief.
All in all, this was a very enjoyable experience, and I’m glad to have had it introduced to me.
One part of the term Game Industry often ignored by many trying to enter it, myself included, is the word Industry. The business of making games is a business just like any other, and a business isn’t successful if it doesn’t make money. How do we make money in the game industry? The same as all the rest, by selling something that people want to buy. But then who are we selling to? How are we selling it? What do we need to do in order to make it? In order to sell it? How much is that going to cost us and how do we expect to make that money back? How do we figure any of this out?
One smart way is to make a Business Model Canvas. In order to create a BMC, you need to think critically about 9 specific topics.
- Value Proposition: What it is we’re selling and why would anyone want it
- Customer Segments: Who it is that we’re selling to and their lifestyle
- Customer Relationships: How do we acquire these potential buyers, how do we keep them, how do we grow them. Essentially how are we interacting with them?
- Channels: Once we find out who we’re selling to, how do we sell to them?
- Revenue Streams: How does that make us money?
- Key Partners: What non-consumer relationships do we need to do what we need to do? These will change as we find success and transition from start -up to a fully realized entity.
- Key Activities: What do we need to be doing right now, to make sure we have a product to present to our consumer?
- Key Resources: What do we need in order to create our product?
- Cost Structure: What is it going to cost us to do everything we’re setting out to do?
Separately, these are all important and essential questions to ask of your own company, regardless of what it is you look to put out into the world. Together, they have the ability to road map and define what type of company you will create, the market you will enter, and the resource you will provide.
An agile ship will raise its anchors and change course when it sees a storm approaching. In this same vein, our Agile managed team should be able to recognize what is slowing our own progress, find solutions, and change our course of action to avoid our own incoming storms.
Just as the sea is full of many storms, this won’t be the last time we will need to reevaluate our thinking in how we self manage ourselves. The idea of Kai-Zen is that we will, and should be, constantly changing for the better.
“Doing the same thing, and expecting different results,” is the oft cited definition of insanity, and with that in mind, it’s time we looked inward at what craziness we’ve been allowing to slow us down.
From easiest problem, to most severe issue
- Commitment: With team numbers dropping from 8 at the start of class, to just 3 in our final weeks, it’s imperative that we hold on fast to what we have. That said if the team we’ve currently got hasn’t been scared off yet, I’d say we’re safe.
- Communication: Keeping in contact with one another has been an issue from the start, but strides have been made on all sides of the table to make sure it hasn’t gone too far.
- Getting Outside: Here we have, in my opinion, our first major problem. As a group of semesters, we’re going to need to rally together in order to shift our development from the waterfall that it is, into a lean mean surveying machine.
- Documentation: There other big problem I feel holding our team back as a whole is the proper logging of work, both completed and needed. I personally feel that tackling this problem alone could greatly increase our team effectiveness, while simultaneously stimulating positive change as far as our other 3 problems are concerned.
So how do we solve?
Well, it is my opinion that, by under utilizing our Google+ team community page, we our simply hampering ourselves. A change in the posting culture on our team page is essential for growth. From getting members more involved to increase commitment and communication to getting that visible and concrete body of work that we desperately need, I feel that the more posts, regardless of the polish they may have, will only benefit the team in the long run. To inspire this change, I’ve taken to posting direct shareable links with commenting privileges of all my work to the G+ page, finished work or not.
Change won’t come without effort, I just hoped that it wasn’t too late.