90. Let’s play pool!

I’m going to build a fairly simple version of pool (you know, the table game with sticks and coloured balls). I’ll show all the stages from building the basic mechanics (getting balls to bounce around), to gameplay (how do you aim and set the power of a pool shot with finger touches?).

But this isn’t just about pool (a game I suck at). It’s about building a game in several stages, programming techniques and more. And I’m going to try using the iPad tilt capability.

First, I expect to build this in a series of steps. I don’t want to do it in separate projects, but all in one, so I’ll do each one in a separate code tab (that does restrict me to a single tab for each version, but I’ll live with that for now).

So I’ll use the same approach as the Physics Lab demo project. I’ll have a parameter that gives you a choice of version, and a separate tab for each version. All the code for each version will be in its own table. It’s not as complex as it may seem.

Here is the setup function for Main

function setup()
    V={P1,P2,P3,P4,P5,P6,P7,P8,P9,P10} --allows for 10 versions
    parameter.integer('Version',1,10,1,function() setVersion() end)
end

So the setup function defines a table with ten items numbered P1, P2, etc. These will be the names of the tables containing the code for each version. So P1 will be a table, so will P2, etc. The user chooses which version they want.

This is how the code for the first version, P1, might look.

P1={}  --define a table called P1

function P1.setup()
    --code to set up the pool table
end

function P1.draw()
    --code to draw the balls
end

function P1.touched(touch)
    --code to handle pool shots
end

So P1 has a setup function (I don’t have to call it that, but it makes it easier to know what it’s for), a draw function, and a touched function. I can add any other functions I want to. I’ve prefixed all the function names with “P1.” so they are part of the table called P1.

If this isn’t clear, please have a look back at my post #85, where I carefully explain how you can use tables to hold functions.

Let’s go back to the rest of the Main code.

function setup()
    V={P1,P2,P3,P4,P5,P6,P7,P8,P9,P10} --allows for 10 versions
    parameter.integer('Version',1,10,1,function() setVersion() end)
end

function setVersion()  --user has chosen a version
   ver=V[Version] --make ver = the chosen version table
   ver.setup()  --run setup for chosen version
end

function draw()
    ver.draw()
end

function touched(touch)
    ver.touched(touch)
end

So when the user chooses a version with the parameter, setVersion runs. Suppose we’ve chosen the first version. Then setVersion makes ver=V[1] = P1, ie ver is now pointing at the table called P1.

The next line, ver.setup(), will run P1.setup(), because ver is the same as P1.

Similarly, when Codea draws or there is a touch, the ver.draw and ver.touched commands will run P1.draw and P1.touched.

So all of this code is just a way of saying “when anything happens, run the code in my chosen version”. Later, when we add more versions, we’ll be able to choose any of them and run them. It does mean, however, that all of my versions will need to have a setup, draw and touched function.

I might clarify one thing. You’ll see in setup that the parameter is defined like this

parameter.integer('Version',1,10,1,function() setVersion() end)

The last part – function() setVersion() end – tells Codea to run setVersion whenever Version changes. Note that because defining a parameter is treated as changing it, setVersion will also be run when setup runs.

In the next post, I’ll get some coloured balls to bounce around.

I won’t share the code yet, because it doesn’t do anything.

Advertisement