Running a little behind

Well, we have officially completed our first sprint.  Everybody did great work, but we may still be a little behind.  We got a new feature requested (triggers for events/spawning) for the level editor last week and went straight to work on it.  However, we got this request right before the weekend break so we didn't get much time to talk about implementation.  This could be an issue because there are certain aspects of the games(spawning, music, etc.) that haven't been defined yet that the trigger needs to tie into.  So, if we decide to take a different approach the code may need to be redone and we will be slightly behind schedule.  We will need to slightly restructure our second sprint to make up for this.  Other than that, it was a good first sprint and we are making good progress.

Learning from previous mistakes and Scrum

Every time you start a new project, it is a good opportunity to look back on your previous projects and figure out what went well and what didn't. This is my third project as Lead Engineer, so I have a couple of previous experiences to reflect on.

The first project I was lead on was a game called Fat Knight, it was a great little base defense/hack and slash mixture that was worked on in a 6 man team. We didn't use scrum software but we kept and organized list of tasks that needed to be done. In addition, we also kept a reasonable scope throughout the project, cutting when need be. The final project, while not having all the features we wanted originally was polished, fun, and something I am proud of.

The second project that I was lead on was called National Photographic. This game was supposed to be an educational game created as if we were a client for National Geographic. The concept of the game was free roaming Pokemon Snap. You would travel to an area (in our case Yellowstone) and would wander throughout the environment trying to take pictures of animals and learn about photography and animals at the same time. We even had National Geographic interested in coming to see the game, but the final product was nowhere near good enough for us have National Geographic come look at it.

On this project we had a 9 man team to start (with 2 extra artists coming on at the end), with enough talent to actually make a good game, but it went wrong along the way. The project was over scoped from the start, and with something as ambitious as our original idea, we needed to be really organized (but we weren't). I am not here to blame the other leads, but to learn from what I did wrong to make sure it doesn't happen again.

I started off with the right ideas, I created a scrum spent 4 hours populating it with what needed to be done from an engineering standpoint, invited my team members, and even put in some example tasks that the art lead could start with when he started using it. Things were going great for the first week, the engineers were all marking the tasks they were working on and when the finished them, but by the second week nobody was using it anymore, at which point I made a couple of mistakes. The first that rather than forcing people to use the scrum tools I asked if they were interested in using it, to which they replied no. I should have said we were going to use the software regardless, but I really didn't like how time consuming it was (free software is unintuitive at times) so I put it up to a vote. So the scrum software was out and I made my second big mistake, rather than keeping my own physical copy of tasks and progress I just kept it in my head. In hindsight, I should have kept my own spreadsheet of tasks, it doesn't take as long as setting up the tasks in the scrum software we were using, but it still would give me an estimate on how much still needs to be done.

This early mistakes hurt us later on in the project, because we had no list of what needed to be done and what had been done, it was hard from a management standpoint to make sure everyone was moving at the correct speed. It is easy to make the argument that people weren't getting their jobs done so that is why our finished project wasn't that good, but the reality is that it was my job to make sure people were getting them done, and I did a not so great job on that front.

Now that I have made myself look like a horrible leader, lets look at options to make sure both yours and my future projects go along without as many bumps along the way. I am going to talk about Scrum for agile development. If you look up on scrum on Wikipedia it says, “Scrum is an iterative and incremental method for managing software projects and product or application development.” Scrum tools allow you to create tasks (user stories) of a given priority with an estimated time till completion. At the beginning of your sprint (A short period of development time ranging from 1 – 4 weeks), you pick unaccomplished tasks and assign them to people on your team. You are able to use the previously mentioned time estimate and priority to make sure everyone has reasonable goals and that you are working on the most important features first. Recently scrum tools and agile development have caught on and now there are hundreds of software suites that you can spend a decent chunk of change on. These suites provide a lot of nice tools, that on a indie or student project, you will most likely not use, so don't spend the money. Burn down graphs and all the fancy stuff are nice, but when you boil it down the really helpful parts of scrum tools are:

-A list of what still needs to be done for the project (tasks).

-How much time it will take to complete each task.

-Who is working on which part.

-The priority of the task.

There are a lot of free ways to do this: a google spreadsheet, a whiteboard, sticky notes, etc.  Even if you are the only person working on the project I suggest you do some kind of task list. The reality is that you can't keep everything that needs to be done in your head, and if you are working with a team that can't see the list in your head. When people get done with their job early and want to work on something else you want them working on something that helps you make your current deadline, not working on a main menu you don't need for another year. Another thing that the prioritized list helps with is scoping/cutting. Cutting from your project is always a somber moment, but it will happen with most every project. If you have a prioritized list it become easy to figure out what features are not integral to the game and cut those. Even more important is that if you are cutting items that are of lower priority, and you have properly assigned tasks, you may be able to cut items that haven't been worked on yet. The only thing that sucks more than cutting a cool feature, is being the person who has been working on that cool feature for several weeks (I know, I have been on both sides).

When your working on a project you need to be organized from the start. The longer you wait the more difficult it becomes to get back on track (believe me). I know populating the list isn't as fun as programming, but in the long run the time you spend organizing will make for a better finished product than getting the AI system done 30 minutes earlier.

All Aboard, next stop awesomeness

So it is Fall Break, which is why this blog post is a little later than it normally is.  However, that doesn't mean we have stopped working.  Our new team has been together a week and already we have changed the game drastically.  It was pitched as a music infused platformer (see BIT.TRIP runner), but we have decided that we want the game to be more combat based.  There are a couple of reasons for this, the first is that we felt that it would be more fun to rock out through combat than through platforming.  The second is that the guitar controller isn't precise enough to make a non frustrating platformer experience.

At the same time, we are still in the first couple stages of the project in terms of art and code.  Artists are hard at work concepting characters, and the engineers are still reading through the massive code base that Scott had from the prototype (the man is a machine).  This was a slow week, but it will be picking soon.  Get ready for more news in the near future.

The next step

The adventure game didn't make it past the panel, so the new hot project that I am working on is called 'Heroes of Rock'.  Currently we are still trying to figure out what we want the game to be.  We know that the core concept is a game that involves music that you play with your guitar, but other than that a lot still needs to be decided.  The previous team prototyped it as a platformer, but we are playing around with some other genre ideas as well.  

The other major decision that needs to be made is what music we want to use.  That is do we want to generate our own original tracks that go with the levels we create, or do we want someone to be able to plug in their own music and play.  There are pluses and minuses to both options, in fact they actually correlate with each other.  If we come up with our own music we can correlate them with our level design and make some beautiful set pieces.  The downside is that the replay value will be low because we have to create both a level and a song and tie them together; furthermore, we want to do different genres so the art style changes every level as well.  On the other side of the coin if we have the player generate the tracks with their own music the replay value is only limited by the number of songs the player has.  However, the down side to this is that the art can't be as distinct as we discussed before.  The set pieces can't be as amazing, and the art style can't tie in to the music as closely as if we picked the genres ourselves.  A cool balance in my opinion would be if we generated the levels based on the song and were also able to identify the genre.  We could then apply different skins and such to the levels and characters to match the genre.  For example if a rap song is picked all the characters get chainz, but if a country song was picked they all the characters get overalls and cowboy hats.  Its a pipe dream, because it would be extremely difficult to define the genres, especially considering how rapidly they are becoming similar to one another.

I have wanted to work on a music infused game for a couple of years now, ever since I played Audiosurf, but since then the idea has really caught on fire.  It has been a while since I have played most of these games so I thought it would be a good time to replay my favorites and see if there are any new games using music as a mechanic.

BIT.TRIP RUNNER

We actually talked about an auto running platformer on Thursday where the player would play the guitar to jump,attack,etc.  But, I don't want to be the game that is bit.trip with guitars so I think that idea would need to be changed heavily to make it more unique.

Gameplay: The music syncing with the level is done so well.  The music is all upbeat and fun.

Art: Fun, colorful retro style graphics that go very well with the chiptune music.

Final thoughts: If we are going to make a game of any genre where the level flow is based on music that we compose this is the high standard that we will be held against.

Audiosurf

You can't talk about music based gameplay without bringing up Audiosurf, this was the game that got the mechanic going.  Even though it came out in 2008, it still has the best gameplay generated as generated by a players music.

Gameplay: The game mechanic is so simple, collect blocks of the correct color.  Any one can understand it, but it is something that is easy to generate based on music provided to the engine.  The track generation is so good (once again the high mark to aim for if we do something similar).

Art:  Generic futuristic sci fi Tron like graphics, they look good, but more importantly they aren't highly stylized so they don't look wildly out of place with some genres.  The difficulty we will have is that as soon as you add characters it becomes hard to make them generic enough for all genres without making them bland.

Final thoughts: Similar to what I said for BIT.TRIP BEAT, if we go with player generated levels this will be the standard that we will be held against.

Beat Hazard 

(warning lots of flashing lights if you are stroke prone you may not want to watch)

This is game combines two music generated content with a twin stick shooter.  It is also on XBLIG and is usually around the top of the best sellers list (20 or so).

Gameplay: This took the very popular twin stick shooter genre and added gameplay generated by your music.  I don't think the levels are actually generated by the music (I am pretty sure they are just random), but they match the gameplay pace to the pace of the music extremely well.  That is when the music is playing slower enemies are less aggressive and you shoot slower.

Art: Just like with Audiosurf we see sci fi themed graphics (it is a common style for twin stick shooters), but their presentation is completely over the top with all of the insane particle effects, explosions, and strobing lights.

Retro/Grade

I have never had the opportunity to play this game because I don't have a Playstation, but I heard about it in the spring and thought it looked cool.  In case you couldn't tell by the gameplay video, Retro/Grade is a side scrolling shooter with a twist.  You play each level in reverse, rather than shooting all the enemies you have to collect the bullets that were shot to kill them as they return back to your ship.

Gameplay: This is such an interesting idea, but the bottom line is that it is essentially Guitar Hero.  I know that it is essentially Guitar Hero, but the idea is unique enough that I still want to play it.  It is all pre generated levels based on music that they had created for the game.

Art: Yet another well presented, flashy game with space graphics (standard for side scrolling shooters).  This game does the best job of having the ridiculously over the top, epic set pieces defined by the games music.

Rayman Origins

The first 4 games I went over were all indie titles, but Rayman is most definitely not, this was my favorite game that came out last year and there is a reason for it.  For all the other games that I have covered, the music defined the gameplay, but with Rayman, the gameplay defines the music.  Every little action you do layers some music onto the score, but it feels so natural that it seems almost as if it was meant for you to jump off that creature at exactly that time.  They don't actually play the sound when the action happens rather they 'predict' when the action will happen and play the sound slightly before it, which makes for a more natural event.

Gameplay: The gameplay is so smooth, everything just flows and feels right.  The controls are some of the best I have felt for a platformer, they feel tight and you never feel like the controls made you die.

Art: The art in this game is amazing, it is probably the most stylized of the games on this list and it fits the music and the humor of the game.  This was a game that had an art style that defined the music rather than the other way around.

The standards have been established for music based games.  However, if you look closely you can see that there are a lot of ideas that haven't been done with music yet.  Some of them are bad, but we just need to find that one gem to make the game great.