Python Powered SkyCam

A few days ago, I decided to have a play around with the Twitter API, to see if there was any fun to be had. Python has a few extensions that allow the user to post tweets and read timelines. They're all a bit fiddly, mind. I didn't have much luck with Tweepy, and I wasted some time playing with lots of different packages. In the end I went with this one.

Once that was all installed, I had to get authorisation from Twitter to access the API directly. To do this you need to visit their dev pages and create an application. (Log in at https://dev.twitter.com/apps)

When you do this, you get two important keys called a Consumer Key and a Consumer Secret. Your application uses these to log in and access your twitter account.

The code to log into your account and enable access is:

import os

from twitter import *

CONSUMER_KEY="YOUR KEY HERE"

CONSUMER_SECRET="YOUR SECRET HERE"

MY_TWITTER_CREDS = os.path.expanduser('~/.my_app_credentials')

if not os.path.exists(MY_TWITTER_CREDS):

    oauth_dance("YOUR APP NAME HERE", CONSUMER_KEY, CONSUMER_SECRET,MY_TWITTER_CREDS)

oauth_token, oauth_secret = read_token_file(MY_TWITTER_CREDS)

twitter = Twitter(auth=OAuth(oauth_token, oauth_secret, CONSUMER_KEY, CONSUMER_SECRET))

When you run this, it opens a web page in which you link the app to your Twitter account. This creates a small file on your computer which stores your login details. After that, you can start adding commands which send tweets, read other users' tweets etc. A bog-standard tweet command might be:

twitter.statuses.update(status="Hello World!")

And from there you can start all manner of bizarre auto-tweeting scripts! You can see such things on Twitter all the time, from the classically simple @big_ben_clock to funny and sarcastic meanie bots like these.

I thought I would make something unlike anything I had seen before, so I decided to combine the tweeting script with some of the stuff I had learned when playing with my webcam. Since I can grab a webcam image and analyse the pixels in it, I decided to write a twitter bot that looks out of my window and says what colour the sky is (see here!)

To do this, I needed this videocapture module, which grabs images from a webcam, and this Image processing library to analyse the images. My little script gets a picture from the webcam and crops it down so that it just contains sky (a rectangle of 540*200 pixels). It then samples one pixel in a hundred, and works out the average colour by adding together all the red components, green components and blue components, then dividing each by the number of pixels in the sample (1080, coincidentally).

When it has the RGB average, it does a quick denary-hex conversion to get a 6-character RGB string. Then it uses the handy webpage http://www.colorhexa.com/ to communicate that as a colour in a tweet.

So there you go. Pointless, but fun. It might get a bit repetitive after a while, but I think I might look into getting the program to detect things like sunrise and sunset. Also, I might see if I can get it to generate a colour-chart collage over time and save that as an image. I don't know how you can attach images to a tweet yet, but that would be better than relying on colorhexa.com.

Keep tinkering!


Update: It seems that TweetPony gives me access to an image-uploading API method. I should be able to create an image of the colour block and remove the use of the external website.

God and death

Version 1.9 is now in the source files folder. It was time for the enemies and the player to interact, so I have now added the code for collisions.

When you hit an enemy, if you are higher than the enemy, they die. If they are higher than you, you die. If you're at roughly the same altitude, you bounce off each other. Eventually, a dying enemy will turn into an egg that must be caught before it hatches into another enemy. At the moment you just disappear.

I have also added a God mode, to make testing easier. Press G to turn it on. When god is active, you cannot die. Also, you can prevent the enemies flapping by holding down 1. Take that, birdies!

Birds fly home to spawn

Just a small update here (Version 1.8, available by clicking the Source Files link top right).
I wanted the birds to spawn properly in their correct places, so I added a little routine for this. The birds Update method is getting a little messy. It might be time to start breaking it into smaller subroutines.

I also wanted to see what happens if you get loads of enemies, so I added a spawner routine which creates birds every few seconds. My old laptop can handle lots of birds, it seems.

Also, it turns out I'm quite pleased with the current flight pattern of the enemies. They seem to spread themselves around the screen quite nicely, so I'm not going to bother with the different flight algorithm for now.

Joust: Improved platforms, our first enemy

It has been a busy month at work. Lots of evening working and stressful times. However, there's always time for tinkering, and I have turned my attention to the enemies in Joust.

I started by just cloning the player character class. It takes care of itself pretty well, bouncing off walls, automatically walking etc. The enemies need to do pretty much the same stuff. The only difference is that they need to control themselves. This boils down to deciding when to flap their wings, and when to accelerate.

The initial birds in Joust seem to be pretty dumb. They just fly in one direction, right-to-left or left-to-right , occasionally bouncing off things. I started doing this by simply adding a random chance to their flap. Each cycle of the game it would roll a dice and see if the bird flapped. A bit of trial and error gave a value of about 20% chance of flapping. This sort of random flapping is what you see in the video below.

This actually tended to make them fly upwards so that they clustered at the top of the screen, so I tweaked it lower. Ideally, some of the enemies would fly along the top of the screen, and some would choose the lower tier of the screen. There should be a random element to it, but they should have a "target altitude". The further below the target altitude they are, the more likely it should be that they flap. Sometimes they will drop a fair way below. Sometimes they will go above their target, but they will work it out in the end.

Later enemies are smarter, and have a strategy for killing the player. They will suddenly fly upwards as they approach you. That will be fun. For now I have to make this guy follow the rules, then get some sort of "spawning" animation going.

Incidentally, I'm enjoying using Wingware IDE as an alternative programming environment from Python IDLE. If you're taking Computing at WGHS or QEGS, I can give you a free pro licence. Drop me an email.

Joust continued: Platforms

The source files folder now contains version 1.3 of the Joust game.

I made a few changes to the eel of the flying motion. Previously, the character would slow down when you let go of the control stick. it would do this on the ground and also in the air. More playing of the original version made me realise that the character doesn't slow down when you let go. Momentum carries it onwards, which makes it a bit easier to program. (Before, I had different "friction" settings for the flying and walking movements)

The new version has all the platforms of the original, in roughly the same positions. It also has sounds (you will need to download all the wav files from the folder for this to work)

I had to hard-code some special bits to handle the occasions where the player is walking on the platforms which span the edges of the screen. They're supposed to be the same platform, but I have them stored as two separate halves. The player character was falling down between the two platforms, so I added some lines to check the player's x and y coordinates to see if it's crossing a platform and act accordingly.

The player can still fly vertically up through a platform. That's next. Then we need enemies.

Joust

It has been a while since my last post. Since last time I have been playing around with learning Java and a dash of Unity. I have also installed Coder on my Raspberry Pi (and can't really see the point, to be honest). Mainly, I have been working on resources for my new A Level Computing group. Work has to come first!

However, I have had time for a little tinker this week. I decided to brush off some old sprites and have a go at recreating Joust, an old arcade game from the 80s. I'm doing it in Python/Pygame, using an object-oriented method.

I have the following classes:

playerClass: A class which will only really contain the player sprite

platformClass: a class for platforms, which can have different positions and image attributes. I know the platforms in Joust don't move, but this allows me some flexibility to re-use code if I need it.

I can foresee the need for:

enemyClass: the enemies will need to be able to think for themselves a little. Not sure how, yet.

eggClass: when you hit an enemy, it turns into an egg. It needs to roll around, come to a halt and eventually hatch if left alone.

lavaClass: ? To detect if the player or an egg has landed in the lava?

Anyway, I may not get that far. At the moment I have been concentrating on the control and "feel" of the player sprite. It needs to have momentum, be affected by gravity and respond properly to the player's "flap" command. It needs to detect when it is close to a platform, and switch between walking and flying as appropriate. When flying, it needs to bounce off the sides of platforms. I think I have done most of this so far. At present I have only populated the level with one platform, and the player seems to behave itself around that platform. I haven't programmed what happens if it approaches a platform from below yet.

What?! Harmoniza is evolving?!

It's half term and I have been away. However, I have been tinkering a bit. I made a program that models 2D collisions between balls (link to come) and I have made some significant improvements to Harmomiza, ahead of its proper launch.

Previously, Harmoniza used a big chunk of luck to find the best arrangement of groups. Leaving it running for a long time gave you better results, but only because the longer you left it the more likely it was to stumble upon a good solution. The new version uses an evolution algorithm. It still uses the same semi-random method to find a base solution, but then switches to a system which makes small changes and tests them to see if they make an improvement. If the new form lists are better, they are saved and the process continues from there. If  the "mutated" version is no better, it is discarded. This means that leaving the program running allows the score to "ratchet" up. Already it is giving good results in less time than before, and is much better than the pen-and-paper method.

I think we're ready to go live!

Coupla three things...

It has been a while since the last post, so I though I had better fill you in on some of the cool things I have tinkered with recently.

This post is about new Dudegame bits, my Harmoniza system and a little Logic Gates widget.