Heroes of Rock: Postmortem

What did I even do?

That is the question I had to ask myself when I sat down to write this postmortem.  Now that may make me sound lazy, but that isn’t the case, I accomplished a lot this semester.  It’s due to the fact that I was working on so many different things it was hard to remember all the specifics.  So here is the list, I decided to cover the 4 systems I was most proud of: AI, Particle FX, the Rock Meter, and the experimental Beat system.

Artificial Intelligence

This semester I upgraded the AI system as follows:

·         Pogo enemies

o   A version of the ranged enemies that jump around the screen using their rocket launcher (rocket jumping). 

o   These jumps are chained together making a pogo effect until the enemy becomes unbalanced and face plants on the ground at the end of the jump. 

o   After face planting he will shoot a few missiles at the player and then return to pogoing.

·         Shielded enemies

o   A version of the weak enemy that takes less damage due to their briefcase that they use as a shield.

o   After the player performs their uppercut move the enemy is disarmed and their behavior changes so that they now run away from the player and cower on the side of the screen.

o   Unfortunately the shielded enemy was cut from the final game because we were unable to get working animations for them.

·         Model Caching

o   At the beginning of the semester the AI system’s performance was awful.  This wasn’t because the code was processor heavy, but because the game would hitch when we would load all the models and animations when spawning a new enemy.

o   To fix this I could have simply pre-cached all of the available models, but I took it a step farther and added pooling for enemies.

§  We have 3 distinct enemy groups, and each group had two types of enemies.

§  I was able to create 3 pools of enemies that we could reuse.  When spawning we would draw from the pool, convert to the correct enemy type (if necessary) and then spawn the revived enemy.

§  This was more difficult with the weak enemy group because we needed to be able to swap between 3 models (weak, shielded, and disarmed shielded) as necessary.

§  Assuming the pool sizes were set up correctly by the level designer, no creation of new objects would occur in the AI code during the entire level.

·         Enemy Spawning

o   After receiving some feedback from Jake, our Level Designer, I made a couple of improvements to the Spawning system to simplify level creation.

o   Wave spawning correctly handles itself such that when all enemies spawned by triggers die, they will all span another enemy (assuming they haven’t met the limit)

Particle System

My programming for the particle system this semester was very similar to the AI system.  As we got closer to finished, artists and designers asked for a few more features in the system.  This including the ability for particles to have variable size in both the x and y dimension, particles fading out for a certain amount of time at the end of their life, and growing or shrinking particles during their lifetime.

I addition to adding new features, the Particle System also needed to be optimized.  Similar to the AI system, particles are created frequently throughout the game and we want to avoid as many new/dispose operations as possible to obtain better performance.  So similar to my AI system, I created a pooling for both the particles and the particle emitters.  When a new particle emitter is created we will grab one from the pool, reinitialize it with the correct texture and parameters and start emitting.  Once a particle emitter has been started it will grab a certain number of particles from the global pool, it will then recycle these particles locally, only asking for more particles when necessary.  When finished the particle emitter will relinquish the particles it used back into the global pool and place itself back into the particle emitter pool.

These optimizations don’t sound like the most exciting thing to add the game but they are extremely important.  The enemy and particle systems, usually the most ‘new’ heavy systems in the game during runtime are now completely self contained and will not be creating new objects while the level is playing.

Rock Meter

Another big feature I added this semester was what I affectionately call the Rock Meter.  The Rock Meter is the dial is the dial seen in the top left corner of the HUD, and while each piece of this system wasn’t technically difficult, it interacted with so many other systems that it needed to be designed correctly to accommodate this.  This included:

·         Health System

o   The Rock Meter served as the player’s health bar, if it goes below 1 the player would die.  So the meter needed to be able to decrement when the player took damage.

·         Attack System

o   To keep the game fast paced we came up with an attack system that rewards the player.  As they perform attacks their Rock Meter goes up; however, if they don’t perform attacks for a certain amount of time the Rock Meter goes down.  Because of this we needed to be able to efficiently modify the Rock Meter when these events happened.

·         Score System

o   The Rock Meter also serves as the player’s multiplier so it needed to help keep track of what the players score would be.  At the end of the level this score needed to be reported so that it can be saved.  We also want to know what the specific portions of their score was (how much was due to the number of enemies they killed, or their highest multiplier, etc.) so that we can make a cooler looking end screen.

·         Sound System

o   If the player is doing well we raise the volume and have a crowd cheering.  On the other end if the player is about to die, we lower the music volume and fluctuate the pitch of the song.  Once again, not something that was difficult to program to the game, but it is my favorite feature in the entire game.

·         State

o   Because the player could die during any combat zone the Rock Meter needed to be able to save its state so that it could restore important values (score, number of kills) in case the player died.

Beat System

Midway through the semester the topic came up about a complete redesign of our game play and whenever you redesign your game extra programming will be required.  In this case we wanted to explore a beat based system based on some feedback we had received during play tests.  It was a hectic weekend, but I built an underlying system that would handle beats and tied most of our major systems (AI, attacking, etc.) into this so that everything would happen on a beat from player attacks to enemies spawning.  We ended up not going with the beat idea so some of the code was thrown away, but I was able to save certain pieces such as a reworking of the AI system that defined how many enemies could attack at a time.

What I would have done differently

I can say that looking back on this semester I wouldn’t have done much differently.  I analysis what I felt I did poorly last semester (not enough upfront oversight of the systems others are working on) and improved upon it.  I knew which teammates struggled with what, and was able to set up basic guidelines when I was concerned.  If I could have changed one thing I would have preferred to have our crunch for release night a week before we did, but team members where so busy with other life situations that we had to cut it close.  We got it done it time, but we came closer to missing the deadline than I would have liked.

Low Fat Scrum Process

If I had to describe the process we used this semester I would describe it as the “Low Fat Scrum Process.”  We had standup meetings, weekly sprints, and tasks, but we didn’t go into the full fledged Scrum Software.  We used a color coded Google spreadsheet to keep track of each weeks sprints as well as storing a list of features that still needed to be tackled, but we didn’t delve too deeply into user stories, bug backlog, or time estimates.  The one thing I did do as lead programmer differently near the end of the semester is that I would play through the game every week and generate a bug list.  I would fix bugs that were in my code and inform others of bugs they needed to fix (both programmatically and in level design).  After smashing bugs for the entire week the process would be repeated with the newest version of the game.

Overall, I would say we were effectively able to use the agile process to adapt resources to where they were needed to accomplish our deadlines.  Scrum is still the best process for game development, as it gives you enough structure to stay on task while also allowing you to quickly switch tasks.  This could especially be seen in the two week stretch in February/March where we decided to prototype a bunch of different features to make the game more fun.

Things that went well

Team dynamic

After working with this team for a semester I can say it is most fun I have had working on a game project.  I loved working with everyone on the team they are extremely talented and are fun to spend time with when not working on the project (as I learned when 4 of us went to San Francisco for GDC).  We had a couple tense weeks as people’s ideas were being cut, but because everyone was so awesome we were able to pull through without any resentment.

Crunch meetings

At the end of the day, the game needs to get finished.  I would have loved to do group meetings outside of class throughout the project that didn’t quite work out due to everyone’s busy schedules.  I was able to set up a couple of key meetings in the weeks leading up to our deadline that was integral to us getting done on time.  Ultimately this lead to one final “stay in the lab until its done meeting” that saw us finishing up at 4:30 AM.  Not necessarily the most fun way to spend a Monday night, but getting a few programmers together to find those last few bugs is what made the difference between us making our deadline.

Artist and Programmer Pairings

I think something we did very well throughout the project is having Artists and Programmers work together.  By that I mean that Artists would create some art assets and then the next time we met they would sit with the programmer working on that section, see how they look in game, and then tweak them accordingly.  Once tweaked they would be placed back in the game so they could be seen again, this process would repeat until we were happy with the results.  Because we did this in person we were able to save a lot of time that would normally be wasted by taking a screenshot, emailing the artist, getting a new asset, taking another screenshot, etc.  Because of this process and our great Artists we were able to make some amazing menus, which in my opinion are one of the prettiest parts of the game.

Things that went poorly

No early prototyping

I actually talked about this in my alpha postmortem, where at the end of the semester I didn’t feel like we had spent enough time prototyping the game and finding the fun.  Well this semester it can back to bite us, after having two play tests we had received a lot of negative feedback and had to change the game at a point where you don’t have time to be prototyping and throwing away code.  This goes hand in hand with another item that went poorly, making design decisions.

Making Design Decisions

While I felt that in the fall this was something that went extremely well it ended up being a weakness for us in the spring.  We still were able to generate plenty of ideas, we just argued way too much about what the correct direction to go in was.  In February a large portion of the game play was reprogrammed over 2 weeks just for it to be thrown away after it was decided that nobody actually liked that idea in the first place.  Part of that is my fault, I heard the feedback and came up with an idea to solve some of these issues, and assigned people to start working on it because it was approved by the team lead.  I just wish the team had come to a consensus about not liking that idea before 2 weeks of work was thrown into it.

Animations

While I still don’t know what the issue was with our animations I can say that they were definitely an issue for us.  Whether it was the exporting or the code (both of which we had working before) we weren’t able to get our shielded enemy to work.  In fact I have more than a dozen test animations on my computer for our shielded enemy that don’t work.  The really confusing part for me is that if I had one fbx file with all the animations I could get those to play, but if each animation was exported individually everything went to hell.  For our animation system we needed a separate file for each animation, so we were never able to get the shielded enemy to work which was unfortunate.

Conclusion

Every time you make a game you are never ready to let it out it to the wild, but with this project I can say I am happy with the final state.  I do feel like we had some shortcomings in terms of design, but I am extremely happy with all the programming our small team was able to accomplish to get our game onto the Xbox Live Indie Games marketplace.

Tonight is the night

By midnight we are going to submit our completed game for approval.  It is going to be a lengthy night but we are right on the cusp of being complete.  We still need to setup all of our pretty pictures for the menus as well as displaying some of our saved data such as high scores.  So while it isn't necessarily anything difficult to program it is still requires work hours to link up the new images and re-sizing/re-positioning so they look pretty.

Over the past week I have been working on revamping the tutorial one last time to match our current game as chasing down bugs across the system.  Nothing super exciting to talk about, but we are at the point where we are no longer adding exciting new features, instead we are working on the not so glamorous but necessary bug fixing.

The downside is that it appears that our shielded enemy will not make it into the game because we haven't been able to get our animations to work properly.  There are also small things here and there that I would love to put more time into, but alas your game will never be perfect.  At this point I am more than pleased with how our project has turned out and can't wait for it to be available for others to play.

GDC postmortem

So I went to GDC last week and after a having some time to catch up on all my work I thought I would post about my thoughts on the convention and what you should do if you go in the future.  I think I learned 3 lessons from my first GDC, and if I go again I will definitely follow these rules.


1.  Forgo HR, find the developers
If you are looking for a job find a developer and talk to them.  95% of the HR people will take your resume and just tell you to apply online.  If you are too afraid to talk to developers then you might as well not spend the money to go to GDC.  You will be just as likely to get the job applying online.  Making a good impression with a developer can get you on the inside track for an interview so make use of that resource.

2.  Go to the parties
Find the parties, when you talk to developers ask where they are going to be that night and see if they can get you in.  I had a good night of networking the first night at the bar designated as overflow for a party, but the all the other public parties were a complete bust.  Devs are even more willing to hand out business cards after they have had a few drinks.  So have some conversations, get some cards, and make sure to find them the next day and follow up.

3.  Don't go for the expo floor
Honestly there isn't anything that exciting to see on the expo floor.  It is a game developers conference meaning that the expo floor is 75% companies trying to sell their hardware or services to a game company.  From a consumer standpoint it is a very boring expo, but that is okay because you are going to look for a job right?

Sweet AI stuff

Spring break, more like spring work.  Unfortunately this is how it goes when you have are trying to get stuff done for both work and school in time for GDC.

Anyways I spent most of the break adding the new enemy types.  A shielded enemy and a pogoing enemy.  I am not going to lie they are both way cooler than the enemies we had before.  The shielded enemy you have to knock up in the air twice to destroy his shield, after which he runs away and cowers on the side of the screen.  The pogo enemy, which is my favorite, rocket jumps around the screen until on his last jump he falls and splats on the ground.  He then shoots a few rockets at you and then goes back to jumping.  The new enemy types add more variation in the game play by introducing enemies that aren't just trying to kill you all the time.  As well as adding more horizontal and vertical dimensions to the game.

This is kind of short post but I need to go fix some bugs and submit our game for testing one more time before I start my grand trek to the foggy city of San Francisco.

Getting Closer

Another week another milestone reached.  In the early hours of the morning on Tuesday Heroes of Rock went up for its first testing submission.  This means that people in the xbox live indie games community are going to spend the next week throwing everything they've got at our game to see if it breaks.

The bad news is that I found one game crash on Tuesday afternoon (5 hours of bug fixes wasn't enough), but that is okay we will get it fixed for our next submission.  On the bright side our compressed game executable is only 40.5 MB in size, which is a lot smaller than I thought it would be based on the size of our content folder.  But hey, I am not going to argue at being under the necessary file size to sell the game at $1 like we would like to.

So, as you could probably tell since we have begun testing of our game that means we wre getting close to the final stretch.  I have a list of AI items that still need to be accomplished, because we came up with some new enemy types at the last second.  Normally, I would say it is too late, but our game needs the variation that they will provide and by my measurements we have the time.  Its looking like we will be finished with all of the pieces of our game after spring break (next week) and can then spend the last month polishing and making it look pretty.

One last huge tweak

So its been a while, but boy has a lot changed.  After 2 testing sessions on our game (one with the masters students, one with industry pros) we received a lot of feedback.  Throughout it all we heard the same thing from almost everyone:

"Gameplay should be more music based since you are using the guitar."

So that is what we are giving them.  We have redesigned the game such that there is a constant beat that the player must follow.  Twice a second an indication will appear, at which point the player can perform a dash or attack.  Each action will take a certain amount of beats to perform (e.g. the weak attack takes 1 beat, but the heavy takes 4 beats).

A second problem we received a lot of feedback on was the discontinuity between the strum to attack and hold the strum bar to move.  To solve this problem, we have removed the move such that when the player defeats all the enemies they will automatically move to the next area.  In addition we switched our dash so that it goes a set distance, and made it so all the attacks will move the player to the enemy in the direction they attack like in Batman Arkham Asylum.  In fact Batman is a game we want to emulate with our combat, but in a 1d space.  The goal is to create combat that flows with the beat and that will have the player moving back and forth across the screen to dispatch enemies.

The question throughout all of this is what I have been working on.  The answer to that question is the the beat interface and the AI.  Since we are limiting the player to performing actions on the beat that means we need to do the same for our AI.  They now only attack on the beat, and we now have the ability to spawn AI's on the underlying beat of our game.  The last piece of our game we need to design is to give our AI something to do besides clumping around the player.  The clumping that our AI is currently doing doesn't lead to the gameplay we desire, but we haven't come up with something else for them to do that makes sense.  Time is running out, and we are going to do a brainstorm today and pick the best option.

NOTE: whenever I say things happen on a beat, that has nothing to do with the music playing, rather it is a beat that happens at a pacing that we have defined.

Feedback and stuff

I said last week that I would be posting the feedback that we got on Thursday, yet I have waited because I wasn't exactly happy with the feedback we got.  I would have liked to get more, but the little we got was helpful.  The biggest point brought up is that people want to see some sort of rhythm infused into the game play.  The implementation ideas of the rhythm suggested to us varied from combat to enemy movement.  As of now, we haven't been able to come up with a way to integrate rhythm (in the time we have left), but I am sure we will discuss it today.

personal progress
This sprint didn't have as many exciting features getting added, it was mostly bug fixes and lower level stuff, but I did add a few high level features.  I have most of a tutorial done, it could use some touch ups, and I need some final art, but it is looking decent considering I had to make the engine does things it wasn't programmed to do.  I resurrected the ranged enemy after 2 months of neglect and he is 90% functional, I still need to get the animations to line up with the logic along with a few other small things.  Speaking of the ranged enemy, I also added breakable platforms to the game for them to stand on.  Unfortunately they don't really work because we don't have enough headroom on the camera, so we will have to figure out what to do with that.

Wired xbox 360 guitars on Windows 7

A problem we have been having throughout the development of our game is that we couldn't get our wired guitars to work on Windows 7, they are supposed to be plug and play, but that never worked for us.  I even broke down and spent $50 to buy a used wireless guitar just so I could have a guitar that everyone could use  on their laptops when we are meeting.  Not to say that I didn't try to find out how to do it, I spent several hours, but was unable to find a solution on the internet.  Now that I have found a solution I thought I would write down what I did, and if anyone else has this problem maybe it will help.

(NOTE: I was able to get the both stock Rock Band 1 and the stock Guitar Hero 2 wired guitars to work with this method, any other wired guitar I cannot speak for)

These are the steps I went through:

1. plug your guitar into a usb slot and wait for the driver installation to fail

2.open device manager

3. find the guitar (should have a yellow triangle with an exclamation point showing that the drivers failed to install)

4.right click -> update driver software

5.click browse my computer for driver software

6.click let me pick from a list of drivers on my computer

7.show all devices (its probably in a sublist but idk which one)

8.chose manufacturer to be Microsoft

9.chose model to be Xbox 360 Wireless Controller via Play & Charge Kit (I know it is a wired guitar but that is what works)

10. ignore warning and click yes.

If you don't have the drivers (you should) I believe you can download them from here (not 100% sure which one is needed):

http://www.microsoft.com/hardware/en-us/d/xbox-360-controller-for-windows

or

http://www.microsoft.com/hardware/en-us/d/xbox-360-wireless-controller-for-windows

Quick update on da crunch

Last week I said I would talk about the feedback we got from the Masters students in this post, but our testing has been pushed back to Thursday.  So instead I will just give a short update today, and I will touch on that on Thursday or Friday.

I programmed quite a lot this week, but rather than going over each individual thing I did I am just going to quickly touch on the thing I am most excited about (gotta get this post done before my class starts).  This week I implemented the new music integration we decided upon two weeks ago.  Previously we had cut the plans to integrate music because we couldn't make it sound good, but Scott came up with a good idea where we just change the volume based on how well the player is doing.  When they are doing poorly we also fluctuate the pitch of the music.  Honestly it was one of the easier things I have programmed all semester (just a simple volume = x, pitch = y) but it sounds so cool and I am excited to see music integration of any form in the game.

Even though I did a lot this week, I still need to accomplish 2 major tasks before Thursday.  First I need to precache our enemeis when the level loads.  This will make it such that the first time we spawn an enemy the game doesn't lag.  I have been having issues with the physics engine crashing when doing this, but I am going have to sit down and get it done tonight.  I also need to update the Ranged enemy, he hasn't been touched in 2 months and we have added more dimensions to our game which has broken how he works.  Once again, I have a few ideas in my head on how to get this to work.  Between the impending deadlines/work/classes it is going to be a couple of sleepless nights, but the engineering will be there (now we just need the levels in the game).

Overdrive mode

Deadlines are looming all too soon in the distance, when you couple that with still changing design decisions it makes for some low sleep nights.  The good news is that we are making progress, our list is down 15-20 items from last week, but we still have ~25 items to go before our deadline two weeks from now.  It is going to be a hectic two weeks, but it is so exciting to see the game finally come together.

From a personal standpoint I got more done last week than I had during the last semester and a half.  I was able to implement the new combat/scoring/health system which required an overhaul of many of the systems we had.  I also was finally able to clean up some bad AI code that was lurking around from our alpha deadline and I should now be able to change up AI behavior easily (if we have time).  Finally, ability to have 2D text 'particle effects' that are needed so that we can have text pop up over enemies when you kill them that tell you how many points you got.  There were other snippets of coding done here and there, but nothing exciting enough to talk about.

Next week I will give an update discussing the feedback the grad students give us about our game.

Its too late to pump the brakes

Team Progress

Currently we have a 32 item list of programmer tasks that still need to be done ranging from small tasks, such as changing the camera distance, to larger items like the menu system.  Our list is accomplish able, but we don't have time to waste.  This means that we need each element to be designed before we work on it, because we don't have time to throw away code at this point.

On that front, things are looking up.  We met as a group on Saturday to talk about animation progress and the art design for our menus.  In addition, today we have one last design meeting with Bob and Roger, which will hopefully end with a definitive decision in regard to all the design elements.

Personal Progress

Seeing as how my blog post was so late last week that I covered some of my items from the current sprint (rain effect), I have fewer items to talk about in this post.  I essentially spent the rest of the sprint performing tweaks to how the enemies work.  

Previously we had decided that enemies should collide with each other, this design decision was mostly made to prevent several enemies stacking on top of each other (such that you cannot tell there are multiple enemies in the same spot).  However, the collisions also mean that they block each other from attacking the player, resulting in a straight line of enemies that the player can just plow through.  To fix the problem we disabled enemy collisions and offset them on different 'tracks' such that there should be enough dimension that they don't appear to be on top of each other.  I also checked off another small feature by forcing our heavy enemy to turn slowly.  The heavy enemy is designed such that he has a shield in the front that blocks most of the damage.  You either need to get behind him or disarm him to deal max damage.  The issue was that the heavy enemy would instantly turn and face the player making it impossible to get behind him.  Overall, I didn't discover some new algorithm or program anything that was all that hard this week, but I was able to check quite a few items off the to-do list.

Its raining blood

Literally.  Not a whole lot happened this week, minor things here and there, but I was able to get a rain effect working in our game.  I didn't have any rain assets to work with, so we are temporarily using the blood assets (hen again it does look pretty cool).  We are also meeting today to go over the character animations and hopefully get a deadline on when they will be in the game.


Until next time.

Making the Combat more fun.

Combat is the crux of our game, I would say it is the mechanic that will make or break our game.  If the combat isn't fun or feels crappy all the special effects in the world wouldn't be able to save the game.  So it is vital that we nail the combat and make it as good as we can; unfortunately we are not quite there yet.  Several people on the team played the game over the break (including myself) and came to the consensus that the combat wasn't fun.  In my personal opinion it wasn't fun because crowd control is impossible, the pacing is too slow, and we haven't figured out the perfect control scheme.  So we quickly brainstormed some new mechanics that should help, mechanics that I implemented this sprint.

The first feature I added is the ability to stun enemies.  It isn't going to be a long stun, more of a quick flinch that the enemy will experience when they get hit.  This is common mechanic in most brawler games and will make crowd control and combos more easier for the player to perform.

The second feature I added was the dash/roll/dodge (whatever you like to call it).  This is another a fairly standard maneuver for brawlers that lets the player quickly move a distance, during which collisions with enemies are usually ignored.  By letting the player move around the environment faster we can speed up combat and give the player the ability to crowd control and engage the enemies as they desire.  This is also a necessary mechanic to kill shielded enemies, because when you attack them from the front the shield absorbs most of the damage (you need to dash and attack them from behind or disarm them with an uppercut).  

The last thing I thought we were missing, a great control scheme, is in progress and we will be playing 4 different methods on Thursday and picking what feels the best.  When it comes to using the guitar controller both our feelings and our play test feedback has been split on whether or not people like strumming to attack.  I personally think that having to strum to attack makes the game much more engaging, but the bottom line is if nobody can figure it out then we shouldn't force them to do it.  Another option is we could just add all the control schemes to the game and let the player pick which one they like.  In that case we stil need to figure out the best option, because if the game feels bad to them to start they aren't going to dig through the options to see if they can make it feel better.

Back into the swing of things

Well the winter break is officially over, meaning a new semester and the second half of development.  I could just talk about how things are going, but I am taking a philosophy class this semester so I figured I should practice trying to make some complex comparison of game development to human life.

If creating a game is like raising a child, the second half of development is the teenage years.  Your kid's attitude becomes more and more frustrating (as programming bugs do).  But at the same time as they grow closer to becoming an adult and leaving to fend for themselves you worry that you haven't prepared them enough (wanting the game to be perfect).  However, every once in a while you take a step back from it all and are proud of what a great human (game) you have shaped. 

Now that I am done trying attempting to make some deep metaphorical comments lets get down to the facts.  We have some rough deadlines this semester, our game needs to be playable from start to finish on February 14th (5 weeks from today).  Its a tight schedule but I of now I am feeling confident.  Jake has 10 levels that he finished the base maya model for and just needs to place the enemies and such in the level editor.  Isaac was a machine over the break, completely changing the art production process, has put out 3 characters, and is finishing the last one over the weekend.

From a programming standpoint we also made some good progress.  Scott was able to get asynchronous level loading along with some other back end features.  I was able to beef up the AI and get several needed camera features into the level editor for Jake to play around with.  We still have plenty of stuff to do, but the pieces are starting to come together for Heroes of Rock.

Until next time...