My main goal in converting it to WPF was to learn about WPF and XAML; I also wanted to get all the features I originally planned for such as all 88 keys of a piano.

I am pleased with the outcome and have achieved more than I thought I would. I am glad I got the 88 keys in and can zoom in and out. WPF has a very steep learning curve and did cause a few problems it wasn’t as easy a process as I first thought, I ended up starting a new project and transferring the logic over. Along the way I fixed up some bugs and added more new functionality, I also put the database online rather than local offline.

Features:

• 88 key piano
• Every key can be mapped to a keyboard shortcut
• Dynamic zooming of the keyboard and auto scrolling
• Colour customisation
• Displays the actual musical note you play and animates and fades away
• Previewing a song now plays a note at the right time
• Online database to load other peoples performances, offline database to store locally
• Audio no longer uses DirectSound but now uses Bass.net for more instant, reliable sound
• Settings such as key mappings and colour can be saved and are automatically loaded in on application start

Windows Presentation Foundation

The piano application loads and saves to an SQL database with the pre set songs and also the user recorded songs. Below is a video of it in action:

Internal
Text effects, Quest System, Hint system, Snapshot, Time of Day, Camera system, String database, Inventory system

External
Text to speech (SAPI)
DirectDraw video player
FMOD

Here is a video of the game in action it shows a complete walkthrough and shows the functionality of all the middlewares.

The task we were given was to create a piece of middleware which could be used in any game engine. The piece of middleware I wrote was the Navi Hint System, this gives the player a hint in the form of a string if they are struggling, it also has the option to display an image to further help the player. The system allows up to 3 hints per quest and comes with a easy to use visual hint editor which outputs to an XML to be read in by the system.

The rest of the module is about integrating other peoples middleware and forming a game out of it. The engine we are using to create the game is the Gamebryo engine.

Below is a screenshot of the progress made in my game

Here it is my finished particle engine in OpenGL, The project has been a success I have hit my 60FPS and 60,000 particle goal, infact I can get double 120,000 particles with around 87 FPS with optimisations, The first 5 weeks of OpenGL were tough, I had problems with it not displaying things on screen due to calls being ordered wrong, I would be swapping two calls which were above and below each other around and it would suddenly work, I found the OpenGL support to be very limited, I had to really think about how to set things up I couldn’t find any sort of standard framework to build off which made me think I was doing it wrong a lot of the time, I did see some similarities in the draw calls that are found in DirectX, setting up the view and proj matrices, the popping and pushing of the stack was familiar to me when I developed on the Sony PSP. Setting up a window was surprisingly very easy compared to directX, literally only one or two lines of code, the lost and found device was also simple, the most time consuming thing was setting up OpenGL, I used freeGlut which provides a lot of helper functions and GLEW.h, setting these up and getting them linking was quite painful experience as it never just worked, I had spend a lot of time searching for extensions an fixing linker problems, It wasn’t a simple case of dropping them in the system folders, I needed to link to them within the project so it would work on any machine.

After week 5 I had points drawing on screen, I decided to look at shaders, I had a lot of trouble getting openGLs shaders working in fact I’m sure it was something to do with my graphics card not supporting something, I switched to NVIDIAs CG shader language and this worked fine, I went on to develop my particles, on researching particles they are very much implemented the same way, they each have a life, they die and respawn again, they have a position and a velocity, the container is often an array to hold all the particles and gets updated and drawn by looping through each individual particle.

I got drawing points working so one vertex coloured for each particle, I then went on to look at quads which are 4 points in each corner which makes a rectangle which you then put a texture on it to make it seem more realistic, for each particle there’s now 4 verts and a texture to render, this wasn’t very efficient and quite an old technique my frame rate dropped a lot, I looked at optimising this with something called a point sprite, this is going back to the single vert or point but applying a texture to this point, so your cutting out 3 of 4 points but still having the texture, once I got this working and the frame rate went back up again, however I now had a big problem, point sprites don’t scale.

To fix this I looked around the forums and found there to be a point sprite ARB extension, I found there to be an attenuation value which I could find the distance between the camera and the sprite and scale the sprite based on this value, This solved the issue and now the particles scaled the same size as if they were quads. Other optimisations were code refactoring, by unravelling loops and looking at using quad lists I got some of the GL calls down which were the main bottleneck, Overall I’m pleased with the way it turned out, Its more graphical than I thought it would be but behind the scenes I’m pleased my code layout and the efficiency I got from the CPU, my only regret is not having the time to work with the shaders as I could of put the position and velocity vectors onto the GPU and calculated them there, increasing FPS and particle count. After getting past the setting up of OpenGL I actually like programming in OpenGL more than I thought I would, I will be using it again the fututre but aslo will be using directX I think it all depends on the project and what you want to achieve. It was refreshing to use something other than directX however I have more experience with directX and would probably have achieved better results using it as I would have had the time to work with the shaders, I still dont regret chosing OpenGL and please with the end result.

TCP – for the game data, sending and receiving data so it’s reliable and guaranteed delivery for uninterrupted game play.

UDP – for the chat room.

Chat room – for players waiting to go into a game, Users can send a challenge to another user and get put into a game with them, multiple users can challenge each other to get in the same game.

Admin/Server panel – Can see all game related messages which are hidden from normal clients, and also chat messages, with the ability to kick players out of the game. Admin also has forced commands such as entering everyone into the same game of battleships; this was used for debugging purposes.

Swear filter – to prevent user’s from disrupting other user’s experiences.

Threading – used for listening for connection both UDP/TCP, receiving messages.

Application layer protocol – used for the game logic and interfacing with the server messages, a state machine was used to control the flow of game play and structure the logic easier.

Objects such as movie clips may be dynamically created therefore the application needs to make sure these are ready for frame 1 as it doesn’t know when you are going to use them. This is why the game does not show the progress bar until 80% because assets need to be loaded before frame 1.

Solutions to this problem are:

1.      Create another blank SWF file only containing the assets needed for export, and then load this in to the load bar pre loader. Refer to moved assets using the _root. Or _level01 depending on how you are loading them in.

2.      Quick solution go through library and go into the assests linkage properties and untick “export in frame 1″, Note this solution will not work for Sounds using the attatchSound to embed them into the SWF.

3.      If the asset is a sound/music which its most common problem of the preloader and you are using attatchSound to embed the sound into the SWF, then add new layers for each sound and place the event for that layers first frame to be the sound you want, add a stop all sound() so it won’t play straight away. This will allow them to load on frame 1 but not before frame 1 allowing the preloader to work correctly.

Having worked with DirectX for 2 years now I am a little biased and do enjoy using DirectX to create games, I could of chosen to use directX for this project but I want to see what OpenGL has to offer and would like the experience, One thing that worries me is the amount of learning resources, DirectX and Microsoft are very good at documentation and providing learning platforms such as the XNA for allowing anyone with programming experience the opportunity to develop small arcade 2d/3d games on Xbox 360 live platform. A quick look for OpenGL support and I can’t really find much support yet, I have found one or two very good tutorial websites, I think I will be relying on forums mainly however I could be totally wrong and the support could just be as good.

The project

I have 12 weeks to come up with a particle system which could be used in real time games, which means an interactive frame rate is a must, this means either 30 frames per second or 60 FPS, I will be aiming for 60 FPS and 60,000 particles rendered on screen at the same time, This is quite a modest estimation as I’ve seen some particle engines doing millions of particles, The reason I am aiming for 60k with 60fps is because most of my time will probably be spent with learning openGL, I don’t need to really push it I just need something stable and workable, then maybe later on I can optimise and squeeze more particles out of it.

Example particle engine

The AI agent will have sensors which it needs based on its type, such as a guard would have a tactical sensor which scans for ambush points and good spots to hide or use for combat, An environment sensor to detect walls and obstacle, a beacon sensor to detect dynamic objects or sensors.

All the information that gets detected by the agent gets processed and acted upon it is important to note the agent is trying to simulate human behaviour and sensors, Games which make full use of AI perception tend to be of the stealth genre, these perceptions have to be very fast, reliable and quite complex, splinter cell for example the AI has to seem intelligent and life like by responding to events the player causes such as, throwing a bottle near the AI it should detect a noise and work out roughly where it got thrown from,  The AI won’t need to fully sense like humans it will reject sensing something humans cant, for example it won’t detect noises far away unless instructed to, it also only cares about agents and players close to them, even the sense time is not realistic in speed and reaction but is good enough to fool the player and free up more CPU cycles for other areas such as physics calculations.

In my demo I use an environment sensor for walls and barrels, various beacon sensors for detecting footsteps, gunshot sounds, dead bodies and enemies

Fruit Frenzy is a flash game built on my previous flash game buster, It does just look a lot like a Reskin but there is actually a lot more to it. The main feature I wanted buster to have all along was a dynamically resizing grid, The reason I couldn’t manage this the first time round was due to time constraints, work and just general lack of experience with flash and action script. This time around I’ve managed it, I am very pleased with the way Fruit Frenzy has turned out Its still very much experimental and a learning exercise for me to get more familiar with flash and action script. It suffered quite bad feature creep which was fun and challenging, but a real headache because it created so many new bugs some as severe as crashing the game, most of them were quite rare and hard to track down, a lesson learned the very hard way luckily I had the time to fix them.

So what are the main features of Fruit Frenzy:

• Dynamically scaling grid – The grid will add extra rows and columns on remove rows and columns in real time, this changes the gameplay a lot allowing more fruit and eventually making it harder as more different types of fruit gets introduced depending on your skill level.

• Skill Level – The game features 8 levels of skill, at each level a new type of fruit is added to random pool of the game, This makes the game harder or easier for the player.

• 5 random events – Theses take place randomly throughout the game, The random events are as follows:
  • Bird – The bird flies over and marks some fruit bad meaning you can’t swap it for a certain amount of time.
  • Monkey – The monkey will throw 3 bananas and randomly tag 3 sets of cells making them un swappable for a certain amount of time making it very frustrating for the player.
  • Blackout – The fruit gets darker making it harder to see the fruit.
  • Underwater – The game board gets submerged making it hard to see the fruit beneath similar to blackout.
  • Swaps – get 3 or more swaps signs and the board randomly swaps the fruit about, can be very useful if used on a big grid, can also get in the way.
• Day/Night cycle – A nice transitioning background fading from day to night and back, very sutle but nice touch to give the game some atmosphere.

• Frenzy Meter – Gain frenzy by quickly matching fruit and gaining combos, Fill the meter to the top to activate frenzy, Frenzy allows the player to speed up swapping and animations almost like a reverse adrenaline effect, The player will be able to match and score faster while frenzy is activated, The player will be constantly battling the meter as it loses frenzy every few seconds.

• One click swap – swapping fruit now only requires one click for the fruit you wish to swap and then a mouse hover over the other fruit to activate the swap, This takes away some of the repetitive clicking and makes it more fluid gameplay

• Dynamically adjusting difficulty – This has been the real challenge, developing a way to scale the difficulty to the player, The way I achieved this or have come very close to is by dumping out statistics about the game, exposing variables to a debug panel to see values changing in real time has helped me gauge how well the player is doing or responding, I used various calculations to come up with a way to measure success which is all based around timings and so far has been pretty excellent. The grid will scale up/down the skill level also increased/decreases

• Stat logging server side – This has been a real frustration from the start, After learning flash doesn’t like http/ftp or any type of connection without the support of AIR, I did manage to find another way which is loadvars, This required me setting up a web server and brushing up on some php. Essentially the flash communicates with the php which in turn takes vars sent and outputs it to a text file stored on the server. This was all working great until I tested the flash game in html suddenly it wouldn’t log anything, on further investigation it looks like it’s coming up as a security threat and the browser is blocking the communication. A real shame as this was going to dump out scores and various stats at the end of the game, this data would have been invaluable and could have been averaged out and be sent back to the game as the default variables making the players balance the game on others experiences.