First of all I should probably list some resources that I’ve found helpful so far with some descriptions:

Haskell In Space (pdf) – Has information and examples for moving spatials around and event handling (Haskell)
Purely Functional Retrogames – Has examples about how to handle state; in these articles state is threaded around.
Casting SPELs – Make an adventure game in LISP.

What I’ll present is just very early playing around and shouldn’t be taken as a ‘right’ way to do it as I’m still finding my feet with these concepts. I have a feeling that my keyboard handling code should use a Monad (as Haskell uses an IO Monad), and I’m not sure about using map and function composition in place of a traditional ‘update’, so any comments are welcomed!

This little program, when used in a page with a canvas element #canvas, and an image #image, will make some #images move around. W,A,S and D will affect their movement. Gist Here.

I’m just going to break down the more important parts of it here:

1. Replacement ‘update/render’ loop:

//we return a function here that closes over the initial local variables
//also means we can call _.delay with the same or different args to potentially evolve the loop
function iterate(input,spatials,context,image){
	return function(){
		context.clearRect(0,0,500,500); //still need to figure out where to move this
		var _spatials = _.map(spatials,_.compose(processEvents(input),move,render(context,image)));
		_spatials = _.filter(_spatials,inViewport);
		_.delay(iterate(input,_spatials,context,image),1000/60);
	};
}

In this snippet I’m using underscore’s _.delay, which works much like setTimeout. I’m currently combining updating and rendering for simplicity’s sakes, and so our main ‘iterate’ function takes everything it needs to update and render the spatial list. This is good in several ways, because it means we can modify the parameters to _.delay if we want to during execution, it allows for a neater recursive structure and it potentially allows us to create multiple iterate()’s with differing initial state (eg. var iterate1 = iterate(mouseinput,enemyspatials,otherrenderer,etc)). Further it means we can defer starting this loop if we want to.

So those are my initial thoughts about the structure – the next decision I’ve made is to use _.map on my list of spatials, and then make the functions that operate on those spatials composeable (via partial application in some cases). This makes the operations performed on each spatial clear and easily readable (and a one-liner), which I like. I’m not sure about the use of filter() for culling as particularly it means iterating over the list again. I would also like to move the context stuff out somewhere (a Render monad perhaps?).

2. Event processing and Rendering (but still taking and returning a spatial):

function processEvents(keys){
	return function(spatial){
		if(keys[68]){ spatial.vx += 0.1; }
		if(keys[83]){ spatial.vy += 0.1; }
		if(keys[65]){ spatial.vx -= 0.1; }
		if(keys[87]){ spatial.vy -= 0.1; }
		return spatial;
	};
}

function render(context,image){
	return function(spatial){
		context.drawImage(image,spatial.x,spatial.y);
		return spatial;
	};
}

In both of these cases I’m using partial application to fix two inital bound variables and return a function that uses them, but itself takes only one parameter. This makes these functions composeable since render(ctx,img) returns f(spatial) -> spatial. I would like to make the ‘keys’ object more formally defined, and obviously it shouldn’t have hardcoded keyCodes – I would also like to try and implement some kind of IO Monad that would abstract this (once I’ve understood monads better!). Also this code should really create a new spatial and return that new spatial.

3. Move/Generic update rules:

function move(spatial){
	spatial.x += spatial.vx;
	spatial.y += spatial.vy;
	return spatial;
}

Finally, this bit just moves a spatial by incrementing its 2d position vector by its 2d velocity vector. This part is likely to become far more complex once other rules are considered, but hopefully keeping the interface Spatial -> Spatial should mean that writing composeable update rules should be easier.

So that’s all really for this initial play around with the concepts, I’ll add more posts as I improve upon these initial concepts. Any comments would be welcomed, since material on functional programming in games seems sparse from my googling. So far I’m quite happy with the approach, since just by looking at the four core functions you can figure out what the program is doing fairly easily, and I find it structually and aesthetically quite pleasing

Please note the below takes into account just using python with Terminal IDE, and I’ve not linked anything to /system/bin because not everyone who has Terminal IDE installed will want to have root, so our python script is kept in Terminal IDE’s home, which in turn is added to the path in .bashrc.

So I created the below file as ~/python:

#!/system/bin/sh
BASE=/data/data/com.googlecode.pythonforandroid/files/python
export PYTHONPATH=${PYTHONPATH}:${BASE}/lib/python2.6/lib-dynload
export PYTHONHOME=${BASE}
export LD_LIBRARY_PATH=${BASE}/lib
${BASE}/bin/python "$@"

Then made it executable and added ~/ to my $PATH in ~/.bashrc:

terminal++@127.0.0.1:~$ chmod +x ~/python
terminal++@127.0.0.1:~$ echo export PATH=$PATH:~/ >> ~/.bashrc

And now when you restart Terminal IDE, you should be able to type ‘python’ to get the interactive python interpreter!

Create your key (assumes ~/.ssh exists, it did for me):

terminal++@127.0.0.1:~$ dropbearkey -t rsa -f ~/.ssh/id_rsa

Convert the key to openssh format, outputting to the file my_key in the same directory:

terminal++@127.0.0.1:~$ dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa" >> my_key

At this point, you should probably copy up the contents of my_key to your server’s authorized_keys file (or add to your GitHub keys, for example).

Now we will create a simple shell script as per the first tutorial linked above, but we are going to amend it slightly – if you are using the Terminal IDE one of the benefits to users who haven’t rooted is that, well, they don’t have to root – so we’re going to create our script in ~/sssh instead of anywhere else:

#!/bin/sh
#location is ~/sssh
ssh -i ~/.ssh/id_rsa $*

Finally, we’re just going to change our GIT_SSH environment variable:

terminal++@127.0.0.1:~$ echo export GIT_SSH=~/sssh >> .bashrc

Now you should be good to go!