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.

Week 13: Making it fun!

So carrying on from the previous week I was still trying to simplify the game and make it as playable as possible before next weeks play test. I also had a lecture in which it was emphasised that alot of projects forget their original goal amidst all the the technical techniques that are learnt during the course of its creation. My goal was to make a fast, fun and addictive multiplayer game, so that's what I'm setting my sights on.

My artist is finishing the animations at the moment, but here's what the character looks like idle.

Here's a video of the latest version:

So, what's changed?

Gameplay changes :

• Removed abilities: defending and all unlockables. These were nice in theory but there are already combos, different states of static charge and multipliers. By getting rid of these abilities, it will take less time for the player to learn the game and avoid the risk of some players not even bothering with it because the initial task of learning many abilities may seem too much effort.

• Player sprite size has been increased by 30%. This was something that has been an issue from the beginning and was made even more so when testing on a TV. The problem with changing the size was that a lot of PVP collision was hard-coded, along with a lot of other animation variables, another lesson learnt.

• All intractable level items now flash. I needed something that set apart the static areas from the ones that the player could interact with (the tubes and source)

• Players spawn at the bottom of the level when game begins.

Design changes

• The main level background now has an increasing gradient from orange to green. I wanted the level to look like a giant battery but also represent the zones that gave you better charge. I uses the duracell ultra batterys as an inspiration (they have an interactive bar on them that displays how much power is left as a gradient.

• The tubes now point upwards. I added this in just to make it more obvious that they can be used to transport players upwards.

• The source and score indicator share the same colour and symbol. I needed to make it clear that the source and the score indicator were linked.

• The hud has been upgraded. All gains now share a circular icon and are placed either to the left of right of the main bar. The bar is now a triangular increase. The player pointer is now next to their section of the hud. The score indicator is represented by a panel.

• Charge burners now have a texture

• The charge burner and static charge scorches textures have been added

Feedback changes:

• Effects added for when player gains and lose charge.
• Effects added for when players charge is being multiplied, the greater the multiplication, the more frequent the spawn.
• Effect added when player hit.
• Effect added when player uses static charge
• Effect added when player is stunned
• Effect added when players falls
• Effect added when player is hit by a charge burner
• Game world background now changes colour depending on the score. For example, the more points blue team has, the darker to shade of blue the world becomes.

So as you can see, quite a lot has changed! Next week I'll be preparing for playtesting so that will mean adding in game over and general transition between states, making a how to and adding in the outsourced sprites with their animations.

Week 12 : More bug fixing and re-thinking

The artwork for the game was being outsourced but taking a lot longer than I thought, so I had to reshuffle things a bit and focus on smoothing out the remaining issues. Once I was satisfied that most of the bugs (that I knew about) were taken care of, I turned my attention to the game play.

Since I was immobilised during the Christmas period I had a chance to catch up on some gaming, after all to make games one must learn from other games. I decided to focus my attention on smaller games rather than epic blockbuster titles such as the new 'Call of Duty' since I was creating a small game myself. What really struck my about titles like Geometry wars and games like Peggle is how little the player actually has to know in order to play these games.

To take Peggle as an example:

All the player has to do is shoot a ball at these circular objects and get combos/points etc. That's all they have to do and yet the game is incredibly addictive and enjoyable. Of course the game is by no means simple and there is a lot of maths/physics etc. but the game handles all that. While I couldn't have that sort of extreme simplicity due to the nature of my game, I could ,however, simplify my game.

The other thing I was beginning to realise is that my game demands too much on the part of the player. They have to learn too much about the game before they can start really playing it. Sure some players might enjoy that type of learning curve, but most won't (including myself).

With this in mind I went about planning how to simplify my game. I first got rid of the easy to remove obstacles, I had two game modes, so I got rid of the free for all aspect completely. Thankfully getting rid of this mode didn't have any knock on effect to the programs structure. This is because when 'getting rid' of something, I just removed the option to initiate it from the team select mode. This meant that it was still within the program but it just wasn't being used.

Once I got rid of a few more niggling/annoying game play elements it struck me that I needed to do more to feedback to the player. This decision though came at a price as I would have to delay my play testing time by a week.

Week 11 : Bug fixing and clean up

In this week I had to make a tough choice.

Because of the nature of the project, things were getting a bit complicated. I had set myself a lot of goals and was moving from week to week trying to achieve them. However, when I looked back at how many milestones were incomplete I knew that it would take way longer than a single week to sort everything out.

So, I went back and looked at my priority list. I'd placed the visuals as the second most important thing but as it stood there were a lot of technical issues that needed to be addressed. This is when I decided to ditch any extra effects and spend the week on milestone completion and bug fixing.

Bug fixing wasn't as easy as I hope it would be because of the scale and structure of my program. When I first created the game in the summer, I was concentrating on techniques and how to do things technically. Unfortunately, this has resulted in the actual design and architecture of the program to be quite chaotic. With hindsight what I should of done was make several small programs to hone and refine my skills rather than jumping in at the deep end. However, it was too late to re-organise everything as there wasn't enough time ,so, I had to make do with what I had created.

As I mentioned in the previous weeks post, I had a game state system that was quite delicate, that relied on a global states and many other sub states using enums. Looking back on it, at the time, it seemed a good idea. Again, however, with new knowledge gained over the course of this project I would now do it with events, delegates and read only properties.

The main problem I had to solve was a bug in the combat mechanics. For some reason, when there were more than two players in a game players weren't registering that they were being hit. They were still be effected by the push-back of the attack but no score was being registered and no sound was being played. As you may have guessed, the problem stemmed from use of a lot of small states (using a number of boolean values that could be modified by anything, NOT good practice!) and it took me a long time to get to the root of the problem. It turns out that some innocuous method was setting a value to false on each update, but this was a painstaking long discovery.

It seems the more I learn about programming and handling a complex system the harder it becomes to diagnose problems. Although, it is a very good learning experience, seeing why things should be done in a certain way really becomes clear when your program is plagued with small errors.