Week 8: Art & sound

This week I have been able to do very little as I had to have an operation and spent the week in hospital. I'll see with my tutors what sort of leeway I can get with time missed but I doubt there will be any given so I'll have to make up for time lost in the coming 3 weeks of vacation.

I did manage, however to research the music style that I wanted for the game. The music had to be royalty free and I knew of a great place to find loads of it @ www.jamendo.com

I found an artist that makes electronic music. What I like about one of his albums is that all the songs share a similar pattern which would make for good transition, menu and game loop soundtrack:

http://www.jamendo.com/en/album/17669

Week 7: Art asset list & progress report

This week I had to:

• Create an art asset list
• Write the progress report

Unfortunately I wasn't able to do the asset list this week, but it should be done by this coming weekend, a lot of deadlines were for this week so I'll have time to catch up by the weekend.

Last week I mentioned that I might be able to outsource the games artwork and I can now confirm that I'll be doing this. After having discussed it with the university, it is well within the 'rules' to outsource aspects of individual projects as long as they are properly referenced and credit is given where due. The artist is also a 3rd year ISVG student, Kwame Bannerman (in return, I am doing the coding element of his project).

Here's some early concept art he's come up with for the characters head:

The idea to outsource my games artwork isn't a new one, in the early stages of project planning I had tried to get artists via forums/the internet, but I considered it too great a risk. Now that I have an artist that I know and can meet, I feel a lot more confident about entrusting him with the task.

While I was confident that I could pull off the game-play that I wanted I was relying a lot on my (non-existent) artistic skills. Hopefully now I can have a game with a good balance between both the technical and visual.

Week 6: Paricles & hardware testing

This weeks tasks were to :

• Revise the existing particle system that was in place
• Add some more effect types
• Test the game on an Xbox 360

The problem with the existing particle system was that it was using a lot of memory and causing the game to slow down. So while it did work, it didn't work well! I went back and scrapped the particle system manager that I had written and took a different approach. This time around I used lists and queues with simplified things and added in checks for when things should be created or deleted. The problem I had before was that some particle systems were being created constantly and there was too much back and forth between several arrays that was creating a lot of calls to the garbage collector (which was slowing down the game).

However, once I had solved the problem I realised something. I planned to add in effects without really thinking it through. I would first need to have an asset list of all game art(next weeks task) along with an idea of what my characters were going to look like. For this reason I've postponed creating extra effects until I know what I want. This will take place during the Christmas break, during which most of the art will be created.

Moving onto hardware testing. I was able to get a free 12 month trial account with Xbox live thanks to the university MSDN scheme so that was no problem. When I tested the game on the console it gave me mixed results.

While the performance was good and there were no major bugs compared to my tests on pc, the tv screen does cut off quite a bit of the image. I had looked into drawing all my games graphics during the summer (the 'tile safe area'). Although I actually had the code set in place, I forgot to implement it! This will be something that I will have to amend before the play testing session.

The other thing was that the characters were very small, and generally, the whole scale of the level seemed to big in comparison to the characters. This is something that's been at the back of my mind for a while, but technically speaking, this would be a nightmare to change at this stage. I might find a compromise with creating bigger characters, but this change may not happen due to time constraints.

On a final note, I may have the possibility to out-source the artwork for this project to a very good 2D artist so I'm investiagting that possibility and would make changes to the time spent on artwork in the schedule should that happen. At this stage it's a possibility, I know out-sourcing is permitted for individual projects but I just want to make sure that my tutors sign off on it before going ahead with anything.

Week 5: Re-organising/Re-thinking

This week, I had a lot of things to do for this project...none of which involved touching the game engine at all! Here's a video of the current version of the game, it's just me messing around just trying to show the different systems & mechanics.

The tasks

1. Re-evaluate my project and goals by adjusting my schedule and creating a Gantt chart to better communicate how I'll be spending my time.
2. Produce a narrative for the game-play
3. Research fighting styles , character design and design a new playable avatar for the game.

Completing tasks : The how and why

1.

As I mentioned last week, meeting my personal tutor was the catalyst for me to rethink the way I had organised my time. I'm not suggesting that it was the only motivating factor, as over the first four weeks of tasks I was definitely paying the price for some over ambitious planning.

So, before I changed anything I went back to my pitch presentation and supporting documentation to get the list of my original goals for this project.

While I had to make changes, I didn't want to contradict or betray what I had said I was going to do originally. What I was able to do was prioritise the aspects of my product that I wanted to be as polished as possible:

1. The technical side : Since this is my main focus (programming & system design)
2. The visual quality of the product : This is, after all, a show-reel piece that needs to look and sound its best
3. The game play : While originally this was a higher priority, I realise now that I won't have time to do the extensive game testing that I had planned, but I can still do some at least.

What I got rid of was one of the two game testing sessions along with the bug fixing sessions that proceeded and followed them. I also have removed the use of the 'Microsoft Game state management' sample from my project. I originally planned to use this as a menu system for this game, however, having used in recently for another module I realise now that it follows a completely different program structure to my game engine & would require a lot of time to implement. So, instead, I've opted to make my own simple menu. This is scheduled later on in the project phase since due to its low priority.

What I added in was a much needed week to create a full art asset list along with an additional week to create game art. Generally, I've tried to spread things out a bit more realistically where possible, as I've found that I've often too many tasks for one week.

I also had to make an unexpected addition for next weeks tasks as the particle system that I implemented last week is quite a resource-hog. I hadn't noticed until I played around with all four players emitting particle effects that it actually slowed down the whole game which could potentially crash the whole game & is a huge risk.

While I've tried to mention everything that I changed/moved I'm sure I'll have forgotten something so here is both the updated schedule and new Gantt chart to see the changed for yourself:

(Note*: The Gantt chart was a downloadable template which automatically greyed out weekends, however I DO work weekends!)
Apologies for the poor quality of the Gantt image, its a long chart so I had to scale it. The downloadable excel sheets of both charts can be found in the sidebar.

2.

I was asked by my tutor to come up with some sort of narrative / incentive for the game. While I did actually have a loose idea of why these little characters were fighting, I never committed to my documentation :

You play as a small atomic being whose goal is to power up the dormant world you inhabit with your own type of energy. However, you aren't alone as other beings are after the very same thing ! Only the toughest and smartest will manage to gain the power to reach their goal, do you have what it takes?

3.

One issue that more than one tutor raised when I first pitched the idea for this project was that the characters were a bit boring & unoriginal. After discussing this with my personal tutor, he suggested that I move away from a human-like fighting style and look at the animal kingdom for reference.

So, I went and looked at the way that mammals, reptiles & insects fight, and what I found the most interesting were the animals (and sometimes people) that used their heads as their attacking instrument.

While I don't have access to a scanner at the moment (sketches will be up asap), what I came up with is a character that has a spherical base (with a rotating atom inside it) with a human-ish head on top of it. The character will only use its head to attack! Heres the rough idea (images stolen from google)

Week 4: Particle System (80% Complete)

This week I met my individual tutor which has changed my overall plans somewhat. Originally I was going to carry on with my schedule till week 6 (implementing the menu system), however, after the meeting, I needed to re-evaluate my priorities

It was suggested that I rethink some aspects of my project:

• Come up with an original character
• Research styles of combat within games
• Focus more on the artistic side
• Create a Gantt chart of schedule

The above tasks need to completed before next weeks personal tutor meeting. With that in mind, the rescheduling and reorganising of the project will have to be moved ahead a week to project week 5.

With a possible change in combat moves & mechanics coming up due to character redesign I've delayed the creation of the 'how to' section.

However, I stuck to the plan for this weeks task in ,modifying the sample particle system and effects and a system to manage them. What I actually found the most difficult was managing the different types of particle system, and not creating and implementing them into my game.

Week 3: Level design & negative player effects (90% Complete)

Leading on from last weeks post in regards to the changing of the time table, I'll be sticking to the current plan up until project week 6 (the menu system).

This weeks task again demanded more than I expect it, but this time, it was a manageable demand. I looked at the level I had and one thing was clear, it was too big! This would cause the game play to be too spread out and the opposite of what I wanted, fast paced & action packed. Resizing the level was relatively painless since most of systems that depended on the levels size (e.g where the AI patrols) wasn't hard-coded, so all I had to do was change the values.

With that done I could then lay out the tiles (platforms) that players will be jumping on and fighting over. I mentioned in the brief that the general idea of the game level is that the player will always want to be as close to the source as possible (they will gain the most charge over time and be able to score more quickly). So, that meant that the tiles had to be spread out so that the higher up the player was, the more difficult it needed to be for the player to move around. The only issue I had was with the player not being able to jump high enough, so I had to modify the physics properties somewhat.

Lastly was the task of creating the levels textures. I wrestled with what to do with the look of the level for a long time. On one hand I wanted it too look very sleek and metallic/cold, on the other, I wanted something that was very simple and almost child like.

I began creating the more 'realistic' looking textures, however they didn't fit in at all, and in fact, the place-holder art looked better!

When I went back to my original ideas on how the game should look like I found that my early ideas suited it much better. I set off wanting creating a very simplified almost Lego/childlike look to my game. Also, after having played many 'indie' games over the course of the week, I found that the simplest looking ones were always more fun & easy to play.

While the the look of the level may be revised during the scheduled sprite creation week, this level layout looks energetic and colourful as well as being practical for the purposes of game-play.

As for player feedback, I added in a rumble effect on the game-pad when a player is under the effect of a static charge stun. What I noticed when adding in the physical force knock back of being attacked by another player was that the PVP system has a major bug in it. The problem is that within the code that determines who the player can hit and if they have been hit, there is a bug that makes one or more players hit more than one target (even if those targets are out of range).

Therefore I have deducted 10 percent from this weeks milestones completion so that I can revisit it in a bug fixing week. While this is a pretty big problem, luckily, I know all the details of it thanks to adding the knock-back effect which should help me solve it rapidly.

Week 2 :Player feedback (60% Complete)

Having completed week 1's task fairly quickly, I was feeling pretty confident about adding user feedback to the game.

By user feedback, I'm referring not only to the HUD but also things like the screen shaking when a player falls off the screen & the player changing colour/flashing when they are hit.

I had a rough list of what I needed to add to the game to make the player visually know what was going on during game-play.

Firstly, I set about changing the colour of charge-burners to one colour(colour is subject to change). When a CB is chasing a player, it takes on a darker shade of colour. When 'focused' chasing one specific player, its colour will change to that of the player indicator (the small arrow above the players sprite).

Next I went about creating a system to add effects to a player when they are:
- Hit by an enemy (they flash)
- Hit by a CB (they blur)
- Stunned by SC (they glow)

Then it I added a global shaking effect for when a player falls off the world and when any SC stun is initiated.

Lastly I added HUD elements:
- Icons indicating:
- If a combo is active
- If unlock-able abilities are ready
- How much charge is being multiplied by

The problem was that all this took a lot longer than I thought it would. While I had some HUD elements created, the whole HUD system needed re-organising as well as re-thinking. Once I had created many of the elements, I wasn't very impressed with them either (since they were just static), so I spent time adding in interpolation/small random movements.

Due to the amount of time spent on the user feedback, I didn't have time to modify the existing character design either.

The basic shader effects that I had added to the player didn't look that great which has made me re-evaluate my priorities.

While I still want to play test the game, I think I have to put the presentation of the game above the gameplay. This might even lead to getting rid of the latter game testing session.

By the end of week 3 I'll have a revised schedule along with a priority list of things that I want in the project.

Week 1 : Ai (100% Complete)

This weeks task was all about the game’s Ai (‘Charge Burners’ and the ‘Burner emitter’)

A Charge Burner

A small enemy object that wanders the playable area of a level. Its purpose is to collide with players resulting in a 'hit'.

Burner Emitter

A large object that patrols the outer edge of the playable level. Its purpose is to spawn CB's and seek out players to apply CB focus to. The emitter is fitted with a spot light that sweeps a small section of the playable game level that it is currently paroling near. Should a player enter the beam of this light then they will be the focus of every CB in the game for a short amount of time.

What I had already set up was a system which made any CB chase the nearest player to it.

What wasn’t in place yet was: where the CB's had to patrol, the 'focused' state & the emitter.

1. The CB’s now patrol all three charge zones.The zone that is patrolled is determined by a percentage chance : high zone 50%, mid zone: 40%, low zone 10%.Each zone position definition has a fixed centre point along Y but a random point along X, which will help spread out the CB’s.In case the CB’s happen to bunch up in one area (due to a lot of random values being similar), the CB’s will each randomly switch which zone they patrol every x amount of seconds.
2. The focus state has been implemented for both modes but has had its requirements changed. The player in the lead will now be the target of ‘focus’ when they have at least 50 charge points. If no player has 50 or more points, then the CB’s will patrol as normal.
3. The emitter & searchlight weren’t added as described. When I added an emitter that patrolled the perimeter of the map, it really became overcrowded and I felt that adding another Ai element would probably confuse gameplay rather than make it better.However, since I had already made the code for the emitter to travel around the level, I used its position to spawn CB’s but kept the emitter as an invisible object. CB’s now fade in when they spawn.

It begins!

'Charged' has been an ongoing project that was started around the begininng of August 2009. I created most of the games backbone / essential systems.

For the purpose of this blog, I'll try to keep things simple since the documentation has covered most aspects of how the game works & what I hope to achieve.

The basic summary of what's left to do over the course of this year is as follows:

• Finish the game mechanics
• Make it playable
• Make it look & sound good