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.

Week 10 : Menus & more music

With the music system in place it was time to create the games menu systems. For another module I had been using the Microsoft Game State Management sample @:

http://creators.xna.com/en-GB/samples/gamestatemanagement

This is a very well thought system that handles the games menus but also the game state. I would have used this from the very beginning, but in the early days of this project I wasn't comfortable enough with polymorphism,inheritance & events to risk using it. However, while it was too late to use it in this project I could still replicate some of its structure when making my own menus.

Like the music player, my menu system reads the state of the game and determines what to display and make of the player input at certain states in the game. There are two different menus and two screens , all of which read input from any connected game pad.

Here's a video in which I play around with the game menus and music system:

- Logo screen : Displays the games logo and then displays 'Press Start' once the game has been loaded

- How to screen : Displays instructions on how to play the game, 'B' or 'Back' can be pressed to return to the main menu

- Main menu: Has three menu entries that allows for the game lobby to be run, a how to screen to be displayed and the game to exit.

- Pause menu: Has two menu entries, resume and quit(which returns to the main menu)

The menu transitioning and effects could be improved upon but creating the system took longer than I expected so any additions will have to be made during polish & contingency time.

Week 9 : Music & game state

Apologies for the lateness of this post, but everything is very much on track and I'll try to get back to my normal posting routine.

Since I'm outsourcing the games artwork, I had more time to do other tasks so I rearranged the schedule slightly:

Now that I had chosen the music for the game, I needed to create a system that would play/pause/stop the music at the correct time. Since inner game classes are deleted whenever the game is reset it didn't seem a good idea to include them within the core game code. So, I created an external component that monitors the global game state, accepts input and decides when to play music.

I didn't have any problems with the creation of the component but most of my problems stemmed from my existing game state system. This was created in the summer and is the base of all game phase logic and execution. I wouldn't call it a very good system, and I had I written it today, I would have used events rather than having one global game state that everything depends on.

I thought about re-writing the game state management with the use of the knowledge gained since the summer but it would be too time consuming. I decided I'd stick with what I've got and created an internal state system for the music player so that it wouldn't have to change the global state (which could be catastrophic for the game as it's main systems are fragilely balanced on the current state).

So my basic plan was to have one song play when in the menus and lobby mode and then have one looping track during the game. Once I implemented this successfully it hit me, having one song is going to get very annoying! So I added more songs to the games soundtrack but this presented me with a challenge.

I didn't want the same song to play twice in a row and I didn't want there to be a set order of songs, so I wanted them to play randomly. To achieve this I stored which song was played last then got a random number that was inside a loop that would finish only if that number was not matching the song that was last played.

Since I managed to do this pretty quickly, I decided I'd add some more functionality to the music player, letting the user change the song and go back to the last played song. I also created a small graphical panel that momentarily displays information about the song and then fades out.

Ok so what does the music player do?

- Loads all the songs and objects and tells the program its ready

- Plays songs at a lower volume than the game SFX

- Plays and loops one song during the menu & lobby phases

- Plays one song from a playlist of music during the game phase.

- Allows users to change the song to the next random song

- Allows users to go back and play the last song that was on.

- Displays a small graphical panel with information about the track that appears briefly when a new song is played.

I won't add any screen shots to this post because I'll be uploading a video next week to show how the music player works with the menu system.