Skip to content

21. Playing around with a couple of the demo projects

April 2, 2013

There’s a lot to learn in the demo projects, and in other projects that have been shared.

Making a noise

At the right of the demo projects in Codea is a noise demo. It doesn’t look remarkable, being a bit blocky and in black and white, but with very little work, you can make something cool with it.

I’ve added just two lines at the end of the draw function to draw a rectangle over the whole screen to create a filter.


In the video below, I vary the r,g,b and a value of my rectangle to show what you can do with this simple filter. First, I start with a=0, ie my filter is transparent and effectively turned off, to show the original demo project running. It’s not too impressive.

Then I crank up the a value so the blue and green start showing, and as a gets over 200, the filter does a really good job of softening the jaggy edges of the notice. Then I increase the green, to get a turquoise effect, and then the red, to get clouds or fog. Finally, I take blue away and bring red up to get a dust effect.

Really quite nice! Here or here is my adapted code. NB If you run it, a couple of the sliders will be offscreen at the left, blocked by the output area. Just drag the titlebar of the Output area down with your finger to reveal them.

Creating a set of demos, games or…

The physics demo project has a nice trick in it, which shows the value of classes. Each tutorial is in its own class, and has its own draw, touched etc functions. When you choose a new tutorial, one line of code in Main changes the class which is used for the tutorial. A simple example shows this best.

The code is here. You can switch between two game projects by using the slider, and you get print messages on the left to tell you what is happening.

My Main setup function only has two lines. The second is a table of my game classes. Note how they aren’t in quotes.

    parameter.integer('Game',1,2,1) -- game selector
    games={Game1,Game2} --list of game classes

The draw function only has three lines.

    background(40, 40, 50)
    if Game~=currGame then SetupGame() end

The second line checks if the game has changed (because I keep a note of the current game selection in currGame), and if it has, I run SetupGame. Note that when the program starts, currGame is nil and the slider is 1, so they aren’t the same, and setupGame is run. So I don’t need to specifically load Game1 at the beginning, it will happen anyway.

Then draw asks the current game class (g) to draw on the screen.

SetupGame below runs a cleanup function (if needed), sets g to the selected game from our table of games, and runs the init function in that class to initialise the game. You need to do this because the init function in your game class won’t be run automatically when you set g equal to that class, as would normally happen, ie
g=games[Game] — doesn’t run g:init automatically
h=Game1() –runs h:init automatically

    if g then g:cleanup() end

The touched function in Main simply calls g:draw(), and the class code is very simple, just printing messages.

The power of this approach is that it makes it extremely easy to add new games, tutorials, whatever, because each one looks after its own drawing, touches, etc. Imagine if you had to handle all of them in one chunk of code, saying “if it’s Game1, then draw this, else if its Game2, draw that…”.

One Comment

Trackbacks & Pingbacks

  1. 163. 2D platform game #8 – Lighting | coolcodea

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: