Week 17 : 'How to' , 'Credits' & final testing

So this is the final week of the project and I needed to wrap everything up and finish off a few key things. The biggest task I had to do was creating the how to section. This has been something I'd been putting off throughout the project, mainly because I kept changing the game but also because it was going to take a long time to plan out and condense all the information I wanted to communicate down to as a few a words as possible.

With the game-play finalised I was finally able to create the guide. First I wrote down everything I needed to tell the player, then I split the information into categories and then split those categories into small sub sections. So, for example, in the Combat section of the how to, I had 4 subcategories : Attacks, cooldowns, combos & overload (static charge).

As you can see I also renamed a few things because they were too long, e.g static-charge and fully-charged.

Next, with all the categories and sub categories defined I then needed to come up with a design to navigate through all this information in a clear a way as possible. This is the template I came up with:

Everything is on layers in Photoshop so creating a new screen was a matter of copying the master template then adjusting the text and highlighted sections. I then proceeded to make all the pages with this template, adding images to illustrate the point of each page as well as colour coding key words.

You can see all the screens in the screen-shot album for this project @ http://picasaweb.google.com/lsmton3s/Charged02#

Once I had all the screens, I expanded the place holder how to system to navigate with sub categories. After testing it on both the 360 and windows builds of the game I moved onto the final changes I wanted to make:

• Added glow to logo screen text
• Replaced main menu screen with shaded in and improved glow version of original
• Added the version display at the bottom left hand corner of the main menu
• Added a credits screen to accredit the sprite animations, button graphics and music

Here's a video of the credits and how to sections:

With everything finalised and tested on the windows build, I went for what I though would be a routine test on the Xbox 360 with version 1.0 of the final game. I'm going through this bug in great detail because it turned out to be a very important fix that may well have gone completely unnoticed.

I loaded the game on the 360, the menus and new assets worked fine and everything was nicely within the tile safe area. Just to be sure that the user couldn't force an error or an unhanded exception out of the how to system (as is relies on two index integers being correct) I spent about 5 minutes just rapidly switching through the menus and subcategories like a mad man. The game didn't crash and everything seemed fine although strangely, the navigation sound click stopped playing after a while. When I noticed this I exited the how to section and the menus weren't making a sound either. Then, when I went to the 'Play' option the game crashed!

This has me in a cold sweat, so I re-ran the game but this time debugging it from my laptop on the windows version. I did exactly the same thing and this time I didn't get an error. From previous experiences with bugs on the 360 and not on the pc I suspected this would bug would be to do with something happening too quickly for the 360 to process. So, I debugged the game via the laptop to the 360. I tried the same thing again and it crashed again but this time it told me what was wrong : There were too many instances of sound effects already existing in menus.

After a little bit of research I found out that the 360 can only store 300 sound instances at once in memory else it throws an exception (crashes the game). This seemed odd as at most my game would be running 20 - 30 sounds at once using the fire and forget system which is when you play a sound effect directly and then it is automatically disposed off once its stopped.

So, to avoid getting this bug I would need to store an instance for every sound I used then delete it myself just to be sure that I wouldn't get this game crashing error. I created a component that has a method that plays a sound effect.

What it does is take the sound effect, make an instance of it, play that instance then add it to a list of all sound effects. That list is constantly looped through, any instances that have stopped playing are disposed of then removed from the list.

Just to be safe I added a condition on playing a sound effect that if there were 200 instances (which there shouldn't be even close to at one time) then don't play the sound effect. I re ran the new build on the 360 and did the same thing as before. What happened this time is that the sound stopped playing , but when I went to play the game it didn't crash because I had stopped it creating new instances if there were too many.

This didn't make any sense, so I drew the number of items in the list to the screen and ran the game again. It was then that I saw the problem. Each navigation click sound was never being deleted, other sounds were being disposed of but not this one. So I used a break point and found that there was a strange error with the click sound. The problem was that the click sound lasts for about 1/10 of a second and the 360 doesn't have enough time to process that it's been stopped so its state is always playing. My list was deleting sounds that had stopped so these clicks were just adding up till eventually there were no more instances left and the game threw the exception.

To solve the problem I edited the sound in Audacity to have 1/2 a second of silence, extending its total duration. When I tested the game with this new sound, it was being disposed of and everything was now working fine. I also noticed that some sounds were taking quite a while to remove so I shortened a few other sounds that had a lot of silence in them.

After that discovery I then spent the next few hours doing every random combination of things I could think of to make the game crash such as going back and forth between menus rapidly, creating and deleting players, d/c controllers etc and thankfully nothing came of it.

This may be my final post as next week is the hand in date however I may be submitting the game to Xbox Live Indie games to purchase for the lowest cost of a game (80p or something like that). Although I'll have to check if I with the music's composer and the rules and regulations of the XNA creators club I'll keep this updated with any Charged! related developments.

Week 16: Play-testing and final changes

This week I managed to do several full play-tests of the game. One was to note down and record feedback, the other to get feedback on what I'd implemented

This was really helpful in establishing what the problem areas were within the game. I managed to get friends/random people in the canteen and even a lecturer to test it out, which gave me some good constructive feedback.

First I'll be covering the big issues that were the most brought up, what I noticed while watching people play the game and finally what I've changed thanks to the feedback.

As always here's the video first so you can see what changes have been made. This is myself and a friend playing against each other on the near-final game play build of the game (I'll try to upload a 2v2 video but that would only take place next week).

The major feedback issues

• People didn't know who they were! This has been brought to my attention by my personal tutor in our previous meeting. Players struggled to keep track of which avatar they were controlling, especially once the game was nearing a winning point as things got a lot more frantic.
• People found the HUD hard to read and didn't know which corner belonged to them. It was suggested the problem was because everything about the level is about going up/travelling to the top, and the HUD bars were going from side to side and this confused them somewhat.
• The different flashing colours for the full charged state on the bar was too confusing, it wasn't clear that having a blue flashing bar meant you were positively fully charged, something universal was needed.
• People didn't know what the AI (Charge burners) were for. Although I hadn't written the how to yet, it needed to be clear in game what there purpose was.

My observations

• The whole map wasn't being used. Once you got to the top of the map, it was very hard to actually fall to the bottom of it. I wanted a player to be kicking their enemy off the top of the level and make them have to climb up it again. The level design needed to be changed.
• Players were 'camping' at the top of the level. Since being at the top was near the scoring object and it was generally the most advantageous position to be in players would often just sit at the top waiting for their charge to go up. This wasn't what I wanted, I wanted the best way of getting charge points to be through combat and a positional strategy, not just waiting for the meter to fill.
• The combo system wasn't effective. I had a x3,x5,x10 multiplier system in place but the reality was that no one can land 5 - 15 hits without being hit or missing (which resets the combo), it was more like 5 - 6 maximum. Also, if someone somehow did manage to gain a combo, the AI would just take it off them.
• Following on from the camping issue, people were playing the game very strategically, often sitting and waiting for the other to move, again this was actually quite fun but not the fast paced play that I wanted.
• The bottom zone that deducted charge points meant that on player spawn from death, they would have to wait till they got to the middle before attacking because they had no Charge. This was quite annoying as people generally want to be able to use at least one attack most of the time.
• Finally, the AI weren't considered as important enough to avoid by the player. Each hit from an AI was a measly 2 charge point deduction that they player could regain in a second just from being idle in the best zone. Also, running away from the AI was hard within such a confined space. The AI moved to fast for the player to react.

The changes

• Add aura around players to make them stand out and differ from the the static level objects.
• Added same aura to AI to indicate to player that is also a 'charged' object.
• Added player number above pointer that appears when player isn't moving or fighting
• Re-designed HUD layout, player information is now located at the sides of the screen and the bars go from bottom to top (1 -100).
• Changed level layout to allow players to fall to the bottom more often. Platforms are no located at either side of the level, with a gap in the middle.
• Changed the fully charged flashing bar colour to the lime green colour that is used for the score object, tubes and fully charged effect.
• Reduced the amount of charge gained in all zones, except the lowest zone which now gives player a small amount of charge instead of removing.
• Reduced the amount of combo points needed for x3,x5,x10 from 5-10-15 to 3-6-9
• AI will now remove a players fully charged power up on hit
• AI now removes 15 charge points instead of 2
• AI movement speed has been reduced
• AI no longer resets combos
• Total AI count has been reduced to 5

When I play tested the game with these new revisions and they made such a difference. Players were fearful of the AI, I didn't tell them about the change but it was very clear now that they removed a big chunk of charge points. With the AI now being something to avoid, players were now moving around a lot more, falling down and trying to get combos off each other to win instead of waiting it out.

Although camping at the top had not disappeared entirely, but its now more of a tactic rather than the best way to get charge. I'd been changing the value of how much the AI removed on hit between play testing sessions, but eventually settled on 15 as it was enough to make you want to avoid the AI but not a huge enough amount that it would make getting full charge impossible.

The only addition I made after this play test was to remove the ability to tele-port down (using left trigger) and have it as a negative effect of the mid attack. This was because no one was using it and by having this effect on it, it would be a cheaper charge cost solution to using the hammer while getting a slightly less good effect.

Now that the play testing is over, I'm in the final phase of the project which involves:

• creating the 'how to' guide and system
• creating a 'credits' screen
• checking the game code for forgotten references
• re-testing the game on the 360
• preparing everything for submission.

Week 15: Mini play-test and more tweaking

In this week I was supposed to be doing the full play-test of the game. However, I had to go away for a good portion of the week to visit a University for a possible masters course. It was all very last minute and threw my schedule for the week into chaos.

Thankfully, due to planning some contingency time within my schedule I was able to move it to next week. This has actually worked out really well as I had a mountain of things I still wanted to address and add in. Before going through the list of changes and additions. I also met with my tutor this week who advised me to make the characters stand out a bit more. To make them stand out I can add a thick stroke (black outline). This I'll have to do next week, time permitting, as it means remaking all the sprite sheet animations.

This is what the latest version of the game looks like, see below for detailed changes and fixes:

I have managed to play test the game this week somewhat informally. I was testing the game on a 360 and asked my flatmate if he wanted to play it. After briefly explaining him the rules we began playing.

This was the first time that I had actually played the game against another person, it was amazing to see what I've spent so much time on come to life. However, there were a lot of issues that became immediately clear to me when we started playing against each other.

1. The level's platforms needed to be bigger, we kept falling off the level when trying to chase each other down and one player could easily sit at the top most single tile and win the game because the other would keep falling down trying to hop onto this tiny platform.

2. The players bounding box needed to be bigger. I had made the players combat bound quite small because I didn't want people hitting each other unless they were directly in-front of them. However, due to the fast paced nature of the game, a lot of the combat is in mid air and so the bound needs to be much larger if anyone is going to hit each other at all.

3. We were only using one attack, the best one (that randomly positions the enemy) because it was the most effective and there wasn't a big punishment for using it. The other two weren't being use at all not to mention the combo system was too unforgiving as you lose it all the time.

4. There's a bug that occasionally resets the players charge to 0 when they become fully charged, this is a hugely game breaking bug!

5. There still wasn't enough telling you what was going on in the game. The HUD needs to be less vital as players should be told things about game mechanics near their point of focus, their character.

Bugs

• FIXED: Players were occasionally losing their fully charge state when they reached 100 charge. Instead of counting down the time to 0 charge points it just set them to the value thus cancelling out their power up state.

Changes

• Replaced logo screen with red to blue logo
• Added main menu graphics
• Removed warning text on player selection
• Removed spectator joining option
• Added sound on press start in logo phase
• Added how to screen (place-holders) + input
• Added back button icon in top left corner during team select to indicate return to menu
• Added combo gain icon above player
• Added combo loss icon above player
• Added test mode for toggling between keyboard controlled and pad controlled players
• Added plus icon appearing on scoring a positive point
• Added minus icon appearing on scoring a negative point
• Added an arrow animation indicating to the player that they can travel up it
• Added full reset of game from team select to main menu
• Added disconnected controller message on game-pad d/c of an active player
• Changed score colours to a lighter shade
• Added left thumb-stick navigation for menus
• Added particle effect for when player is fully charged
• Changed team select 'Press start' message to only appear when a game is possible
• Changed trigger point for falling smoke effect to be further below level
• Increased size of all particle effects
• Added music volume function to pause menu
• Added static charge stun loop sound
• Added charge burner focus loop sound
• Added fully charged loop sound
• Added padlock icon to appear above player when player cannot attack
• Changed level design to include more long platforms and less short ones
• Increased the dimensions of players combat bounding box
• Removed combo loss on charge burner hit
• Increased the charge gain and loss for all level zones
• Increased the cool-down durations of the mid and high attacks
• Increased the cost of all attacks
• Increase the reward of all successful attacks

As you may have noticed, I have yet to create the how to screens, this is because I've made such drastic changes to the game in the past two weeks that it's been hard to finalise the game-play. After the play test, I'll have the necessary data to make the final changes and only then will I be able to create the guide.

So, tomorrow (late post!) I'll be play testing the game with 3- 4 people. I have a feedback questionnaire that I made at the begging of the project but I think I'll be asking their opinions and issues and then making note of what's said instead. This seems to be a much better approach as it allows people to really say what they do or don't like.

Week 14: Bug fixing, phasing and art

This was the week where I needed to prepare for play testing so I needed to wrap things up and sort out a few minor bugs, test things on the Xbox 360 again and add some logic for game over etc.

I received the artwork today so I thought I'd post once I'd implemented it into the game.

Here’s a video of the latest version of the game:




The bugs:

• FIXED: Camera no longer cuts off players when there are three or more players in a level at once. The problem was that I was calculating the central point between 3 or 4 positions. If all players were at the bottom of the map for example then a player at the top wouldn’t be visible because the camera would cut them off. Now when a player is above the half way point in the level, the camera automatically focuses on the mid point of the level instead of the midpoint between all players

• FIXED: Players can longer attack enemies unless they are standing next to them on an equal plane. You can attack enemies when your combat collision box collides with theirs, however, when your enemy is standing above you on a ledge for instance, these boxes were still colliding. By reducing the size of the box and placing it near the middle of the ball of the player the problem was solved.

Changes

• Added new graphics to the team select phase
• Added ‘+’ and ‘-‘ symbols that appear briefly when in power up state
• Reduced the shade of the colour of the background for each new point scored
• Added a gradient graphic to the charge bar
• Added state for game over. When a team has won, their power symbol appears briefly and the whole screen fades in to their team color. The game then resets after a few seconds and goes back to the main menu.

Art

Once I got the separate frames of animation from my artist I was dreading creating the sprite-sheets and logic for the animation but it was actually done within the space of an afternoon:

Re-testing on the Xbox 360:

I got a very unpleasant surprise when testing on the Xbox 360 and it was all to do with my games music. For some reason unbeknown to me at the time, when I ran the game on the console it would play the music straight away when the game started. This wasn’t supposed to happen as it should only begin when the user presses enter at the logo phase. Then, when I started a game, my music player system would infinity change the song causing the game to grind to a halt.

So, I tested the game on PC and it worked fine. After thinking about it for a while I remembered an article I read comparing the 360 to a computer. It explained why there is a common misconception that the 360 should be as powerful as a mid range PC circa 2005, however, it went on to explain the fundamental differences between the power and ability of the Xbox 360 CPU and that of a computers chip, the 360 couldn’t handle a lot of things at once.

So I thought maybe the media player system is the root of the problem, even on the PC it froze the game briefly when loading, so was using a separate thread for it. I went back and looked at my music player component and saw that I was changing states very quickly like from play to pause within milliseconds. It turns out that the 360 couldn’t keep up with this and needed a few seconds to change between states. So, I added in a time delay between the ability that the program selects the next song and the problem was solved.

I also had to reposition the HUD graphics a bit to account for TV over scan, accounting for a loss of about 20% of the picture. I did this by using ‘#if XBOX’ which enabled me to create different positions for the HUD graphics depending on the format.

How to guide:

I’ve gotten rid of a lot of things in my game but when I went to create the how to section there was still just too much that the player had to know before playing the game. After talking to a friend about it he suggested that I just get rid of the ‘Overcharge’ power up state and the whole ‘scoring points against yourself’ idea. This is what I’m going to do before the play test since everything else is simple enough to explain and this is the last relic of the old insanely complex version of the game.

Finally, as the deadline approaches I find myself changing and adding so many things into the program and trying to document it all is taking too much time. A lot of new code is being added and barely commented but it’s the price I feel I must pay to achieve my goal of making a fun game.