python

Sydewynder is an open-source SMS receiver and sender application written in Python for the Nokia S60 phones. It can automate the responses of messages and can be used as a mobile application server in areas where setting up a traditional server may be difficult or illegal. It also is very useful for prototyping mobile applications, such as games, without the burden of expensive hosting. As such, it works very well in educational settings. It even includes an emulator for developing scripts off of the phones.

The Sydewynder Logo

Sydewynder requires the latest version of Python for the S60 (>= 1.4.0). If you are using earlier version of PyS60, please update your phone with the latest software.

To install Sydewynder, copy the contents inside the "sydewynder-x.x" directory into the E:\Python\ directory on your S60 phone (this should be the memory card). Sydewynder comes with "Pig Latin", "Ask Tom Cruise", and "We Feel Fine" as example scripts, as well as arcade.py, which will run all of them from a single server instance. Feel free to look at how the files are constructed and modify them for your own purposes. Pay special attention to the comments, as they will make developing new apps for Sydewynder much easier.

Scripts developed off-phone can be run like any other Python script if the syde_emu.py module is in the same directory. When you run your script from the command line, a crude emulator will appear and guide you through a typical interaction between cell phone users and the Sydewynder app you have created.

This project was featured on the front page of the CDT department website.

It was also part of Paul Notzold's Ask Tom piece, which was on display at the Chelsea Art Museum for the Parsons 10 Years Running show. Participants were asked to text a question to a number and received back a random (or is it?!) quote from a famous celebrity whose name rhymes with Bomb Booze. The phone "server" running Sydewynder stayed up for about two weeks straight without much of a problem.

If you're using Sydewynder, be sure to drop a comment on the Sourceforge forum and let us know what you've done with it. And be sure to post there if you need help or run into any bugs.

Sydewynder is copyright 2007 Mike Edwards and is licensed to you under the GPL version 2.0. "Ask Tom" was developed with Paul Notzold. "We Feel Fine" uses the amazing wefeelfine.org API to work its magic.

Since I'm still on winter break, I took the better part of today to mess around with my new (well, secondhand) Kinect. I used the excellent freenect library and its Python bindings to whip up this simple little demo.

There's a lot here that is very similar to how we work in SMALLab, especially how we deal with a "buttonless" interface. Using the Z-axis (forward and back on the Kinect, up and down in SMALLab) makes for a pretty nice way of changing from active to inactive state.

I'm looking forward to playing with this some more in the future. It's not the most response system in the world, but I can see simple and casual uses for this kind of interaction in schools, public displays, etc.

Kyle and I have made a lot of progress since the install went up for SMALLab. To date, we have the beginnings of Render Engine Managers for Python, Processing, and Flash (via XMLSocket).

The Python version, PyREM, can create engines and pass properties based on responses from SCREM. I still need to get it to destroy engines, as well as accept and display media library files, but it's moving along pretty well.

The ASU folks put together a really nice and flexible system. I'm really encouraged by how quickly we've gotten up to speed now. I'll post pics once more interesting work gets rolling.

The latest version of Sydewynder, our mobile application server for the S60, has been released! With Sydewynder, any S60 phone, like the Nokia N80, can become an automated SMS gateway. You can grab version 0.1 off of the SourceForge site.

This new version features:

scripts can now connect to WiFi, making Internet-enabled responses possible!

emulator for off-phone development. Now students don't need to have a phone to develop mobile apps for it

two tabbed pane view for logging and status indicators

start up screen -- very pretty!

a much better UI

a new example application using WiFi - "We Feel Fine". It taps into the wefeelfine.org API

And these bugs were fixed:

recipients in the address book could not receive text message responses

unicode text problems

Much thanks for Sven, Colleen, Chuck, Eric, Albert, and Chloe for their support, ideas, and code.

Take a peek at the fifth file. All that's been added is a new window title at line 191 ("Lincoln Versus Kitties"), creating a few sound objects starting at line 201, and few calls sprinkled around the file that play those sounds at the right time. I'll leave those for you to discover, but their placement should make sense at this point. Also, note how easy it is to add sound effects here in just a couple of lines!

And that is that... for making space invaders. But what about other games? Using other languages?

First off, the basics are always the same. Collect input. Make decisions. Wipe away the old drawings and paste on some new ones. Repeat.

Wuh? All that does is ask that a new laser sprite be added to the board every time we hit the spacebar. And we ask that it appear in the area of the player_sprite... at the middle top of it, to be exact. Once we've added the sprite, it just goes, passed on its own rules established in "update." Bang!

If you look in the update function for the EnemyClass, you'll see that is does the exact same thing for enemy laser blast, except that it does it randomly instead of at every press of the spacebar.

Now we've added three new sprite classes. Heavy! Well, not really. They do the same thing as the PlayerSprite class, they're defining new "stickers" that we can place on our screen.

What are the differences? Well, they load up different images and, therefore, are different sizes. The area that each takes up is called its bounding box--that will help us figure out how they will react to each other. More on that later.

They also have different update functions. The enemy will move around in a given direction until it hits a boundary, then it will bounce back in the reverse direction. It will do this for every frame--keeping moving one way until it can't, then move the opposite. Dumb AI, but it works.

Okay, keep looking at that third file. In the main function, we've added a couple new variables called player_sprite and player_sprites. player_sprite creates a new sprite, or "sticker" as we've been calling it. It does this by instatiating the PlayerSprite class. All this means is that we use the PlayerSprite class, which is just a definition, to create an actual sprite that we can move around on the screen. Since this is a one-player game, we just create one sprite and add it into the player_sprites (note the plural) group.

Now let's move it around! If you look in the event loop, you'll see we've added a few more key commands. These new commands set the velocity for the player sprite. It does not, however, move the sprite! This is important to remember. The keys are changing values of the sprite, but we leave it to the sprite to move itself! Let's see how this happens.

Okay, we're in control, but so what? This is boring! So, let's start blitting a few more things on here.

Open the third file. Near line 71, you'll see a line like this:

class PlayerSprite( pygame.sprite.Sprite ):

This is a class, the chief concept in object-oriented programming. DO NOT PANIC! Object-oriented code is designed to make your life easier, not harder. This class is a sprite, and you can think of it like a sticker or one of those animated Monty-Python characters. All a class does is define what makes a sticker a sticker. In this case, the sticker represents a player on the screen.

Ok, now open the second file. The first thing you'll notice is that we've added to functions, loadImageFile and loadSoundFile. Don't sweat these. They're just handy wrappers around a few functions that help us load up files that are located in the data subfolder. Feel free to use these as is in your own prototypes. They work well, and you almost certainly won't need to modify them.

Next, in the main function, we use the loadImageFile function to pull in the background image. Then we use the screen.blit function to blit that image.

Wait, blit? Wazzat? Blitting is like pasting an image onto the screen. Everytime we update graphics on the screen, we "blit" them. Think of this like a Monty-Python clip art animation. Right now, there's just the background, but we'll be pasting a few more things on here later.