Eyetoy : Kinetic Combat for the PS2 and the Commodore 128

Today using motion to control games is all the rage, Kinect, Move, Wii, Wii U et al but the PS2 was where it started, Eyetoy was Ground Zero. Deep into the 6th Gen with the 7th Gen licking our heals came the 11th Eyetoy game. I was faced with a seeming impossible task, tight deadlines and the need to push the PS2's pedal to the floor, I needed an edge, something to give me a boost, I found it - a Commodore 128.


The Quest

During the development of Eyetoy : Kinetic Combat, which is a martial arts fitness game that utilises the Playstation 2 eye camera (of which the core systems were developed by Dan Phillips ( and some other people ), yes that Dan Phillips, of Armalyte and Last Ninja 3 fame ) for Sony’s Soho Studio. I was tasked with making a faceless ball with no real features, move randomly around a screen and show emotion. It had to mope, be happy, move excitedly etc. It needed to have ‘levels’ of happiness/sadness etc. It would spit out a challenge for the player, and then if they passed it, the ball would dance happily , fly around the screen and give you another. Fail and it got disappointed in you, and would let you try again, fail too many times and it gave up on you and moped arround before it gave you another.


Normally you would just get artists to make curves for you with splines in something like Maya and use them. Random movement, 10 levels of happy<->sad, way too much work, a real mess, it would seem to fixed, to predictable like the robot it looked like. Plus opening a file and trying to tweak and work with 400 splines all the same colour would be like finding that wrong patch cable in the ‘organic growth’ network room of doom or the wire wrap breadboard that needs to be tilted 3 degrees for it to work just right.

So I had to do it in code, ALL in code. Here is a video of how it looks, no this is not me, and no we didn’t play ‘Eye of the Tiger’ in the game ;)


Step 1. The method

First of all I had to figure out how I was even going to tackle the problem. In my youth I spent a fair amount of time playing with Lissajous curves  on my C64 ( this was before I got a 128D ). They are basically a sin function on the X and the Y to form a continuous curve with a frequency setting. I know from watching them render in basic at 1Mhz that they have slow bits, where they curve, and fast bits where they shoot along straight-ish lines. That you can make them such they start and end at the same point. Making this same point 0,0 I then had a delta curve.  This is handy as I could make a straight heading vector in 3D that is the start and end point then add the curve to two of the axes ( the Lissajous I made and know of are only 2D not 3D ) and still know that it will get to the destination and exactly the destination.


Step 2. The Tool

So a quick wish list of what the tool needs

  • To render the curves in real time so that I can see them draw and move
  • Show me and let me scale curves to be “right” in 320x240 ( the PS2 was running in this res)
  • Have  a scratch pad where I could keep “good” values
  • Not take me a long time to make and debug Harharhar...
  • Export values to the build or PS2 for easy real life testing.

Now what do I develop it in...


Well it is the default choice. I had the dev tools to make for it. But getting it to make and display 320x240 such I can see it, and draw slow enough would be “work” we are talking Win32 GDI WM_TIMER stuff here. I would also need to have multiple copies of VS open to run it and edit it, not a good idea.


The Commodore  64...

320x200 - perfect res, the top and bottom borders of the playfield are out of bounds for the ball to be usable. Also the Z movement needs some space in the Y to be shown. It is slow enough already. But writing the bitmap plot logic( BASIC 2.0 ) and finding screen room for the scratch pad and editor, would need raster interrupts.  


The Commodore  128...


Basic 7.0 to handle the bitmap logic

80 column 2nd screen that I can hold the program , the edit commands and a scratch pad on

Send data to the PS2 or my C++ code. Oh well hand read, type job just had to do, it was only about 30 numbers tops.

The whole editor would be about 20 lines of BASIC. Perfect! .

25~30mins later and the tool was done, with all bar one thing from my wish list. I'm fairly sure this wins the fastest build with highest percentage of features of any tool build at SONY.


Here is a BASIC program to get started with, it is not the one I used, as that is now owned by Sony Computer Entertainment World Wide Studios and it had an editor and extra features in it.

10 GRAPHIC 2,1

20 X=1:Y=1

30 ZX=9:ZY=2

40 PX=160+(50*(SIN(X*(6.28/360))))

50 PY=100+(50*(SIN(Y*(6.28/360))))


70 X=X+ZX:IF X>360 THEN X=X-360

80 Y=Y+ZY:IF Y>360 THEN Y=Y-360

90 GOTO 40

ZX and ZY are the magic variables to change.

SAD : ZX = 8, ZY = 2
VERY HAPPY : ZX = 2, ZY = 12

So should anybody need to read the C++ code they will find at the top in the comments, a Commodore 128 basic program and instructions to download x128.  If only I could have added code that would use the camera to take a photo of their faces and send it to me when it happens.


Which brings me to another neat fact of the 128. Each game is archived all that is need to make it is collected, burned and stored somewhere, such that should we need it again it can be accessed for HD remakes or something. If I made a separate program the Windows code would have need to be put in, lots of code, vs projects etc. Will it still compile in the future, will the Win32 GDI still be there? Will they still be on a Windows pc? A Commodore 128 will always be a Commodore 128 and BASIC is simple enough that any programmer should be able to look at it and see what it does to replicate it in whatever dev environment they are in.

Probably I would have used my

Probably I would have used my Lua Player. The Windows version: http://www.luaplayer.org/luaplayerwindows-0.20.zip and then this script:

	w = 320
	h = 200
	image = Image.createEmpty(w, h)
	image:fillRect(0, 0, w, h, Color.new(70, 70, 70))
	white = Color.new(178, 185, 176)
	x = 1; y = 1
	zx = 9; zy = 2
	while true do
	   px = 160 + (50 * (math.sin(x * 2 * math.pi / 360)))
	   py = 100 + (50 * (math.sin(y * 2 * math.pi / 360)))
	   image:pixel(px, py, white)
	   x = x + zx; if x > 360 then x = x - 360 end
	   y = y + zy; if y > 360 then y = y - 360 end
	   screen:blit(0, 0, image)

And this is how it looks like:


Log in or register to post comments