Full PDF Hand-In

Blog Posts

The original pitch was a PG game in which you have a little AI pet. Scoped for a year development and a 3-5 person team. Well I did it solo in 3 months (see below).

Learning my lessons from Dungeon Delve project I chose to use XNA. Knowing a lot of the marks were software engineering based I decided to go for a full engine approach. So Frank mostly ended up being a tech demo.

• State Manager (expanded from MS Sample)
• Animator (expanded from MS Sample)
• World and Object Manager
• Full Scene Shadows with PCSS filtering
• Basic Scripting System
• Sky Sphere
• Water Simulation
• Partial Cloud box

Meant to be a group assignment, but due to issues unkown I did it as an individual piece. Seriously I was removed from my team and not given a reason, talk about open and due process. But I didn't fight it because honestly it left me better off, what with my working fulltime.

AI Notes

All my notes can be seen in the above link. A cool idea, each person would build an AI and then we would have a competitive leauge. Sadly the client and API were horribly broken.

To say we were provided an extremly simplistic rule set and buggy client would be an understatement. The client API didn't even implement half of the documented functions, but did not throw errors when these functions were called. The rest of the API was buggy. The AI module could change the game state directly (event without hackery). AI could chomp cycles and delay the program. The project linkage was horrible setup.

We were provided some client and server code. Written in Java using TCP. All simulation of the ball was done on the server. We were then asked to add another dimension of movement (forward and back) and one additional feature. I chose to add ball spin.

YIKES! The lecturer has never written a networked game before. The clients (one in Java & the other in C) were very poorly written. They basically spammed the ball, and bat positions every frame and used a dedicated host. There was no predicition or even lerping. The graphics update even depended on the network tick. The assignment specification was broken as originally we were told the clients were not to be altered but it turned out they had to be altered for the assignment to be possible.

Second year project for university module. We basically had to write a game on the Gamecube. However as I was working fulltime getting into the labs during office hours was an issue. So I got permission to do a Wii Title instead.

Basically it was put-put. The level was generated from a heightmap, and textured. Simple system kept track of score. Basic graphics, motion controls and sound in place.

Full PDF Hand-In

1. Analyse and use Python to develop a simple application.
2. Analyse and use the data captured by a motion device.
3. Define and use the motion device to recognise gestures.
4. Develop a simple application using skills gained.

The choice of platform and device was a well made one. The device is well suited for rapid prototyping and Python is still flexible. The libraries are well structured and light weight enough that minimal effort is required to start. The amount of feedback a mobile platform can provide while doing these motions is limited. This coupled with the limiting processing power means as a motion gaming platform it is limited. The use of motion in other applications however is still a valid.

The motion sensor is a limited device which does not do what sales teams claim. The processing of motion is several degrees more complex than traditional controllers. This is compounded if a neural net is used. The range of motion detection is very limited. This is due to both the low range of the device and lack of absolute positioning.

If a game is made with the limits in mind a successful game mechanic can be achieved. The gaming audience is more likely to notice the limited patterns of this style of motion controller as time passes. This receptiveness could have a strong negative affect on games which could turn unique control systems into simple formulaic inputs.

Originally a conversion of Descent the board game. Looking at how the rules converted and boiled down. I was very interested to see how the automation of the rules would speed up the game. The project project was badly formed as I was learning the API and language.

The project got off to a good start. The main problems involved doing ISO metric rending the traditional way and the controls. While the classic rock-paper-scissor mechanic works the pace of the game seems to confuse people. In the end from a gameplay perspective the project was not a success but I feel in terms of control and isometric art I learned a lot.

Not wanting to spend hours in the real-time lab before I understood the language I used Easy68k to familiarize myself with 68k ASM. The project slowly built up. I had to remember the old way to draw sprites and I had some creative whitespace and memory stomping errors. In the end the project was a success. I didn't add sound simply because the Easy68k sound was not old school or anything like the real thing.

The next project was Pong on the real target machine. This project has helped me loads but it is more fun on the real hardware where I can use a pedometer and timer interrupts.

This was a simple maths project to simulate the car crash problem. I added some functionality to our program by drawing the graphs, being able to adjust the variables some real-time and others in the config file. Our simulation also had a data mode which outputs to a CSV file. The project was with Emma Morton and Jason Earl. Jason did some Ruby simulations and Emma did most of our documentation.

The project was a quick and simple demonstration. One of the key concepts I was illustrating was keeping your game separate from the API. To this end there is a second console version see console.cpp which works as well as the PTK implementation.

The first weekend of code was a bit crazy. The weekend is something I run for Northumbria and others to make a game in a weekend. This theme was randomly selected but it did let me draw from 72 Magnets failures and make a better project. The concept worked but I lost some valuable time on organising the competition. The Ready State is also map editing mode which I left in. This is the current prototype being used from my Game Cube project.

AI is possible the thing that gets me most excited with computers. Emergent behaviour is why magnets, physics, simulation, and simple games fascinate me. Anything where I can see behaviour not intended by the creator is a joy. The code for this project was trivial but the project itself focus on my passions.

Programmed in Flight 68000 Assembler as a method of learning low level game architecture. Made use of low level timer interrupts and interface to potentiometer. Display through Mini-com on Linux terminal.

The second weekend of code shows the competition can improve and get more people involved. I made a edgy call in deciding to learn and use chipmunk (a 2d physics simulator) in a weekend. I had never used a physics API before thinking they are too big for little games but this was the perfect match. The goal was making a game where you navigated around by stick to things.

The failure of the game in two parts, firstly using a new tool in "crunch" and secondly fixating on a little problem involving going around corners and the lack of ray casting tests in chipmunk. While it impacted the game I learned a lot from it and I'm currently using chipmunk more and plan on looking at 3d physics simulations such as bullet I the near future. I learned a lot from this little project.

I hope to revisit the idea at a later date.

A simple class exercise. I used it to test some different methods of controlling the ship.

My first use of PTK a 2D API I have come to love for its simple reliability. The game was also my first limited time development entry into a competition like LD48 or GDC72. I focused on getting a complete entry and succeed. In retrospect the idea would have worked better in 3D as I could have used surface deformation to make the worms.

A little test written shortly after the Sand Trap game on a different way of doing swarm behaviour.

The project was around design patterns and was boring. So a Rheno Lindique and I decided instead to make a game which would generate an n-th dimensional maze and use design patterns. The algorithm works for single solution n-th dimensional mazes but we limited it to 2 for the game. The design patterns needed to be shoe-horned in but we found a valid use for most of them. The project however did not finish despite large amounts of coffee. Despite the lecturer failing us, we managed to later over turn it for an A. One of the few bits of code I managed to retrieve (through a friend) from my South Africa days. Uses SDL as it needed to demo on Linux.