• Thomas Chung’s photo essay from SCALE 6X.
• Here is another SCALE 6X trip report from Fedora Engineering Manager Tom “Spot” Callaway
• Mary Lou Jepsen’s (the former CTO of the One Laptop per Child project) keynote at the Greener Gadgets conference: How green is the XO?
• Top 10 Linux distributions for audio
• Check out Gobby on fedoraproject.org. For those not in the know, Gobby is “a free collaborative editor supporting multiple documents in one session and a multi-user chat. It runs on Microsoft Windows, Mac OS X, Linux, and other Unix-like platforms.”
• More One Laptop in the news: A comparison of sub-$300 laptops
• Dave Eggers, winner of a 2008 TED prize, wants 1,000 people to engage with their local public schools through onceuponaschool.org. They need domain hosting, developers, and non-technical people. A perfect opportunity to combine open source’s benefits with education…
• Love. As in the love of game development. Check out the amazing graphics in this multiplayer first-person shooter game that was created entirely by one person.
• You’re going to have to pull yourself away from the screen sooner or later. When you’re looking for something to eat this weekend, may we recommend bacon cups? (Because here at Red Hat Magazine? We like bacon.)
• Neil Gaiman’s giving away books and name-checking Cory Doctorow. Trent Reznor’s up to much of the same with NIN’s new album, Ghosts. Yay for major artists getting on the sharing bandwagon.
• And speaking of Cory Doctorow, check out this list of 20 science fiction novels that will change your life. Down and Out in the Magic Kingdom is a particular favorite and shouldn’t be missed. But what’s your favorite that didn’t make the cut? For us? Madeline L’Engle’s transformative series about the Wallace family, starting with A Wrinkle in Time.

The mission of One Laptop Per Child (OLPC) is ambitious: to empower the children of developing countries to learn by providing one connected laptop to every school-age child. To accomplish this ambitious goal, the project needs supporters who believe in this goal. Until November 26, OLPC is sponsoring the Give One Get One program in the United States and Canada. During this time, you can donate the revolutionary XO laptop to a child in a developing nation, and also receive one for the child in your life in recognition of your contribution.

Beyond idealism, there’s one great pragmatic reasons for doing it: it’s a great value. The purchase price is $399 plus shipping and handling, but $200 of that is a tax write-off. Also, everyone who gets an OLPC will also receive free wifi service from T-Mobile for one year.

Do the math: for a little over $400, you get a revolutionary laptop (value: $200), free wifi service for a year (value: $350), a tax write-off (value: a few bucks, maybe more depending on your financial situation), and the knowledge that a child in the developing world has a chance that he or she would never have had otherwise (value: priceless).

It’s the best Christmas deal out there. Go take advantage of it. Right now.

Pure Distortion suggests consolidating some of your hardware to reduce your environmental impact.

Running all of my servers on one large piece of hardware is seeing my household have a 10% saving on the amount of electricity that we use and that could be potentially more depending on how mch hardware you are running at home.

For simple things you can do to save the planet, Distributed Information suggests:

…work on or support the use of open source software.

Closed source is based on restricting access to software, which inevitably leads to pointless, non-innovative duplication of efforts. I’m not talking about the duplication of competitive features, or key differentiators that make your business a success either. There are a myriad of tiny internal tools written in every company or project, to just get stuff done, which if shared could improve your bottom line, just by sharing the code amongst all the other companies in the world that do a similar thing.

ComputerWorld UK discusses the idea of a green API with four examples, including:

2. Connecting people to other people and useful services. For example, there’s now a Facebook Carpool app which “makes sharing a ride safer and easier by using Facebook to find people going in the same direction.” Boston-based GoLoco is pursuing the same ends with a stand-alone web service. Both are perfect examples of leveraging the web to connect people towards a greater environmental good.

Finally, here’s a post on OLPC and the environment.

Did you post for Blog Action Day? See a great open source/truth-related Blog Action Day post? Let us know in the comments.

Author: Jeffrey D.Sachs
Publisher: Penguin Press
Publication date: October 1, 2006
http://www.earthinstitute.columbia.edu/endofpoverty/

Last weekend I finished reading this book and watched Al Gore’s Inconvenient Truth, all in the span of 24 hours. Thoughts of global warming, the threat of a permanently altered planet, and extreme poverty killing thousands every day were swimming in my mind. While I felt a sense of urgency, I also felt conflicted. Because it’s hard to feel urgent about both. In fact, history shows it’s hard for the US government to give urgent attention to more than one crisis at a time. So what to do in the face of such cultural monsters?

Interestingly, and perhaps the deeper cause of turmoil, author Jeff Sachs lauds the industry that the film Inconvenient Truth condemns for polluting our planet. And I fear they’re both right. Industrialization and widespread globalization are contributing to global warming, especially as previously agrarian laborers move to cities and create more epicenters of activity. Working in more skilled jobs (industries that are often culprits of polluting), these laborers eventually purchase cars and add to the carbon dioxide the human race collectively emits. And yet, this is a success story. A human being has climbed out of extreme poverty and, as their children grow, and their grandchildren are born, the generations that follow him will enter the world on a higher rung of the the socioeconomic ladder. Further removed from the extreme poverty that afflicted their ancestors.

In fact, a ladder is the analogy Sachs uses most to describe extreme poverty and its escape. He explains that people living in extreme poverty can’t grasp even the bottom rung of the ladder. They don’t have the basic necessities to sustain life: food, clean water, shelter. Without basic sustenance, it’s impossible to pursue education or consider means of income beyond than subsistence agriculture.

Sachs cites Malawi as an example of the “the perfect storm” of extreme poverty. All of these characteristics culminate, compounded by AIDS and Malaria epidemics, into a “horrific maelstrom.” And unfortunately, “the world community has so far displayed a fair bit of hand-wringing and even some high-minded rhetoric, but precious little help.”

“Currently, more than eight million people around the world die each year because they are too poor to stay alive.” Sachs gives us the newspaper headline that we will probably never see: More than 20,000 people died yesterday because they couldn’t afford the basic necessities required for human life.

The situation Sachs addresses in The End of Poverty is a tragedy that’s occurring as I write this review. It was a crisis when I got up this morning. And as you poured your coffee in whatever corner of the world you’re reading this, people were dying of hunger, thirst, and disease. By the thousands, every day. This is not an impending crisis; we’re in the climax. Though a grave problem and one of great consequence, global warming is still mounting. Nature is showing the effects, and scientists are predicting the consequences that will be felt by the human race in as little as ten years. This is not a trivial matter or one to be minimized. But if the United States is to mount an immediate offense against one crisis or the other, I think millions dying senseless deaths takes precedent.

Is there hope? Sure. If Macroeconomics 101 put you to sleep in college, give Sachs a second chance to teach you some basic economics. Does the name John Maynard Keynes ring a bell? Keynes wrote around the time of the Great Depression and fathered Keynesian theory, which asserts that both the state and private enterprise play important roles in developing a healthy economy fit for long-term growth. Important for Sachs is Keynes’ emphasis on scientific and technological innovation as a means to long-term economics growth. He predicted this kind of growth even in the throws of the Great Depression in America. His predictions came true. Technological and scientific innovation has for the most part eradicated extreme poverty in America and the rest of the developed world. We’re not talking about computers or the Internet, either. Scientific and technological advancements as basic as paved roads, which allow goods and services to be traded freely and with ease, are impediments to economic stability and growth in underdeveloped nations in Asia and in Sub-Saharan Africa.

The remedy? Unfortunately there’s no one-size-fits-most panacea. Sachs emphasizes the importance of grassroots programs and small-scale initiatives tailored to specific needs and demographics. The rest of the world often imagines Africans as one ethnicity, facing similar challenges. When the truth is, more than a dozen countries make up Sub-Saharan Africa, an area widely-regarded as one of the most needy. It’s no surprise that small-scale operations aimed at specific countries, even specific towns or subsets of towns, are most effective.

And this is where open source comes in. Specialized aid efforts, targeted at specific regions, using the expertise and know-how of those involved. Now imagine all these how-tos and that information gathered by aid organizations is documented publicly, available for mass distribution. Even mass reproduction.

When knowledge is shared, and intricate mistakes and successes are made public, the world can take real steps toward the end of poverty.

  Episode 04 takes us on location in Porto Alegre, Brazil. Where the first batches of XOs have been delivered and deployed. Meet the teachers using the laptops in the classroom. Where besides doing daily assignments on the machines, some students have already learned programing. Local culture has permeated the project, and as a veteran school principal explains, an improved education is set to equip a new generation of Brazilian citizens. Watch past episodes.

Since piloting this video series, we’ve received lots of questions about the XO’s mesh network. How can these laptops “talk” to each other even without widespread internet access? How is the network they create different from the network at your home or office? Episode 03 explains it all.

  Little green men often make the front pages of supermarket tabloids. Little green laptops? Not so much.

But this Sunday, the XO (which we’ve been talking about for months) will get its mainstream news debut on CBS’s highly regarded program, 60 Minutes. (A far cry from the National Enquirer.)

Faces familiar to our readers have helped make Nicholas Negroponte’s dream a reality. From the earliest concept (remember the hand crank?) to its current working build which has been deployed in several nations for beta testing, this laptop has come a long way. And it would not have been possible without the hard work of folks like Chris Blizzard, Dan Williams, David Woodhouse, Marcelo Tosatti, and John “J5″ Palmieri.

Just as our developers were inspired by Nicolas Negroponte and Walter Bender’s concepts, we hope the millions watching Sunday night’s newscast will see in the project the promise for a worldwide solution to poverty. In a word: education.

And more than that, we hope they’ll get involved, whether it’s donating money, developing code, or simply spreading the good word.

Congratulations to everyone working on the project. We wish you continued good luck and prosperity. And good press.

XOXO

http://dev.laptop.org/~j5/BlockParty_tutorial/block_party_lesson_2.tar.gz

For this lesson you will need a computer with the latest version of the Sugar environment running on it. This can either be from sugar-jhbuild or any build after or including build 303 running in an emulated environment like qemu, from the LiveCD or on the laptop itself.

Entry points

The first thing we need to clean up in the Block Party source is the entry point. When running standalone, we call init() from the main() function. This creates a window, sets up all the signal handlers, and then goes into the mainloop.

When being run by Sugar, however, the main loop and toplevel window are all taken care of by the Activity class. In fact, the Activity class is just a subclass of GtkWindow. Because of this we will define init() as the common entry point and shift the window creation code from init() to main().

def main():
    toplevel_window = gtk.Window(gtk.WINDOW_TOPLEVEL)
    init(toplevel_window)
    gtk.main()
    return 0

In the init() function we now take a GtkWindow as a parameter and use that, instead of creating the window ourselves.

def init(toplevel_window):
    global window
    window = toplevel_window
    
    # remove any children of the window that Sugar may have added
    for widget in window.get_children():
        window.remove(widget)

You will also notice we remove the window of any child widgets. This is because Sugar comes stacked with a HippoCanvas widget, which is usually what the main UI layer activities are built on. At some point it may be nice to port Block Party to use the canvas — but for right now we are dealing with direct drawing layers, so we need to discard the canvas.

A child plays Block Party on his laptop in Porto Alegre, Brazil.

That’s all that needs to be touched in the current code. Now that we have our entry points, we can still run and debug the program without Sugar by simply running the command python BlockParty.py, but now we also have the API call necessary to hook into Sugar.

The activity class

These next parts require Block Party to be run in a Sugar environment. The Activity class is the central API for hooking into Sugar and the entry point when Sugar launches an activity. In order to create a Block Party activity, we simply inherit from the Activity class, hook up to a couple of signals, and run the entry point for Block Party. We will do this all in the BlockPartyActivity.py file.

import BlockParty
    
from sugar.activity import activity
    
class BlockPartyActivity(activity.Activity):
    def __init__(self, handle):
    activity.Activity.__init__(self, handle)
    self.connect('destroy', self._cleanup_cb)
    
    self.gamename = 'blockparty'
    self.set_title("BlockParty")
    
        # connect to the in/out events
        self.connect('focus_in_event', self._focus_in)
        self.connect('focus_out_event', self._focus_out)
        BlockParty.init(self)
    
    def _cleanup_cb(self, data=None):
        return
    
    def _focus_in(self, event, data=None):
        return
    
    def _focus_out(self, event, data=None):
        return

As you see, we import BlockParty which loads the BlockParty.py file and then imports the activity module from sugar.activity. We then have the BlockPartyActivity class inherit from activity.Activity which takes a handle argument for its constructor. The handle is the id given to the instance of the activity when it is launched.

Notice we attach to the focus_in_event and focus_out_event. Right now we don’t do anything in those handlers, but we could use them to conserve power by having the activity stop processing when it is in the background. In the case of Block Party, we could simply pause the game.

At the end of the constructor, we call the Block Party entry point. We pass self to init because, if you remember, the Activity class is itself the toplevel window we wish to draw on.

That’s it. That’s all the code needed to sugarize a PyGtk application.

Now let’s look at some of the support files that go into making this activity into a bundle.

Bundles

An activity bundle is a self contained set of files which make up a Sugar activity. They are usually zipped up into a file ending with the .xo extension. This allows activities to be run simply by placing the bundle in the correct place in the file system. Now that we have created the activity, we need to create the support files.

The first support file is the setup.py file. This file makes it easy to manage building and distributing the activity. In most cases we are dealing with python so the setup.py will look the same, but in the future it will be easy to extend setup.py to support other types of projects.

#!/usr/bin/env python
from sugar.activity import bundlebuilder
bundlebuilder.start()

As you can see, it is very simple script which handles most of what you will need to do without further coding.

The setup.py script still needs a couple of other files in order to function. The MANIFEST file is a simple list of source files that should be added to the bundle for distribution. Sometimes there are files which are needed for the version of the bundle in version control repositories but make little sense inside the actual shipping bundle. These files can be left out of the MANIFEST and will not be bundled up. Let’s take a look at our MANIFEST file.

BlockParty.py
BlockPartyActivity.py

Notice we only list the source files and not the files in the activity directory or the setup.py file. These files are automatically added to the bundle and should not be in the MANIFEST file.

The activity.info file in the Activity directory is another of the support files. This tells Sugar about the activity and how to launch it. Let’s take a look at it.

[Activity]
name = BlockParty
service_name = org.laptop.BlockPartyActivity
class = BlockPartyActivity.BlockPartyActivity
icon = activity-blockparty
activity_version = 1
show_launcher = yes

The activity.info file is a simple .ini formatted configuration file. We start with the [Activity] block header and then give a name, the D-Bus service name, the module and class we are launching, an icon, version and if the icon should show up on the launcher panel.

The D-Bus service name usually looks like a reverse URL with the organizations namespace followed by the activity name. In our case we namespace with org.laptop.

The class also includes the module namespace. Here we find the BlockPartyActivity class in the BlockPartyActivity.py file so we prepend the class name with the BlockPartyActivity module name.

The icon field specifies the svg icon which should reside in the activity folder alongside the info file.

Versioning for bundles is handled by the activity_vesion key and is a straight integer. Right now this is used by the setup.py script to take on the version number at the end of the bundle name (i.e. BlockParty-1.xo). In the future this will be used to determine when to upgrade the bundle if another user has a newer version.

Some activities are special activities which are managed by Sugar or other activities. In those cases it doesn’t make sense to show them to the user so show_launcher can be set to “no”.

The final file we need to deal with is the svg icon file in the activity directory. We use a special formatted svg for our icons.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [
  <!ENTITY fill_color "#FFFFFF">
  <!ENTITY stroke_color "#000000">
]>
<svg xmlns="http://www.w3.org/2000/svg" width="50" height="50">
  <rect x="6" y="19" width="10" height="10" style="fill:&fill_color;;stroke:&stroke_color;;stroke-width:2"/>
  <rect x="21" y="5" width="10" height="10" style="fill:&fill_color;;stroke:&stroke_color;;stroke-width:2"/>
  <rect x="21" y="19" width="10" height="10" style="fill:&fill_color;;stroke:&stroke_color;;stroke-width:2"/>
  <rect x="36" y="19" width="10" height="10" style="fill:&fill_color;;stroke:&stroke_color;;stroke-width:2"/>
 
</svg>

Notice the two entities at the top of the file: fill_color and stroke_color. Sugar icons must be two-toned, and we use the two entities in order to fit in with the look and feel of Sugar. Sugar will take those entities and fill them in with the user’s personal colors.

Producing a shippable bundle

After all the files are created and modification done we are ready to build a bundle to be shipped and run in Sugar. All one has to do is run ‘python setup.py dist’ in a Sugar environment and it will produce a bundle which looks like BlockParty-1.xo.

To install the bundle, simply run ’sugar-install-bundle BlockParty-1.xo’ as the olpc user. You should see the Block Party icon pop up on the launcher. Click on the icon to run.

Conclusion

As we now see, sugarizing a PyGtk application takes little time or effort. This is only the tip of the iceberg, though; deep integration will take a bit more effort for other applications. In the next lesson, we will explore more of the python side of things and look into cleaning up the code to use classes in preparation for moving to the cairo drawing layer.

Have questions you’d like answered about the project? Or an idea for a future episode? Leave us a comment–let us know what you want to see.

Other related videos: Inside One Laptop per Child, episode 01.

What is Sugar?

Sugar is the desktop environment which runs on the laptops being developed at OLPC. It provides a number of interfaces which can be used by applications to integrate into the Sugar environment. These include interfaces for registering with Sugar and using the mesh networking capabilities of the laptop, among other features. When an application is integrated into Sugar it is said to be a Sugar activity.

What is Block Party?

Block Party is a Tetris clone written in PyGTK by Vadim Gerasimov and modified by John (J5) Palmieri for this tutorial. Vadim is one of the original authors of Tetris which he helped create in 1985 when he was 16 years old. It has been ported to many platforms and clones of it with various modifications are too numerous to count. Because of this and its relative simplicity it is the perfect program to start playing around with on the OLPC laptop.

What you will need for this tutorial?

You will need a computer with the latest version of the Sugar environment running on it. This can either be from sugar-jhbuild, which was covered in a previous Red Hat Magazine article, or any build after or including build 303 running in an emulated environment like qemu, from the LiveCD or on the laptop itself. The builds have vim and pico editors installed in them but you may want to use an editor you are more familiar with and copy over the files to test them.

You will also need to download the source files for the lessons. There is a separate package for each lesson.

It is also assumed the reader knows a bit about the concepts of gtk+ programming and in particular gtk+ programming in python.

Lesson 1: An Overview of the Block Party Source Code

The first step to porting an application is understanding the application you are porting. To get the source code please download and untar the first lesson’s source bundle which can be found at http://dev.laptop.org/~j5/BlockParty_tutorial/block_party_lesson_1.tar.gz. You should end up with a directory structure looking like this:


block_party_lesson_1/
    BlockParty.py


To run the program simple change into the lesson directory and run BlockParty.py using python.


$ cd block_party_lesson_1
$ python BlockParty.py


The anatomy of a game

Games for the most part follow a similar structure consisting of a couple of high level elements. There is the main loop and timing element which makes sure events are triggered according to a relatively strict time line. Along with that goes the logic phase which determines positioning and interactions between elements in the game world. There is also input which needs to be processed and can affect game state. Finally there is the output which typically happens on the computer monitor.

Mainloops and Timing

Most games have a tight custom mainloop which they use to squeeze every last bit of performance out of their platform. Games can do this because for the most part they are dedicated applications which interact little with the environment outside their own codebase. Gtk+ games and in particular Sugar games are a bit different and will often access code not specifically written for the game itself (for instance Sugar’s networking facilities which will be discussed in a later lesson). Because of this we need to use a more generic mainloop and do some tricks to get as tight a timing as possible to grantee our game runs smoothly. For this we use the ever popular glib mainloop.

The glib mainloop allows programs to attach sources to it in order to execute application code on specific events, whether it be networking events, keyboard interrupts or timers. Of particular interest to us right now is the timer sources. Timer sources are added using the gobject.timeout_add method.


import gobject
 
main_loop = gobject.MainLoop()
 
# call the timeout_cb function every second
timeout_id = gobject.timeout_add(1000, timeout_cb)
main_loop.run()


This can be seen in the BlockParty.py source at line 480 in the init() method.


gobject.timeout_add(20, timer)


Here we call the method timer() every 1/50th of a second. It is interesting to play with the timeout value to find the optimal timeout period to call. Calling more times per second doesn’t necessarily speed up the game and can in fact slow it down as well as drain power from devices which run on battery. This is because you are running more instructions per second, mostly just checking to see if it is time to trigger an event. Most of the game’s time is spent waiting around for events to happen; letting the gtk+ mainloop determine this for you means more efficient use of resources. However, the gtk+ mainloop is not guaranteed to call the timer() function at exactly every 1/50th of a second; it only tries to make its best effort to do so and may be preempted by higher priority sources. Let’s look at the timer() function to see how we can tighten up our timing to make our game run smoothly.


# time_step = 100
 
def timer():
    global game_mode
    global next_tick, time_step
    while game_mode == PLAY and time.time() >= next_tick:
        next_tick += time_step
        tick()
    if game_mode != PLAY:
        next_tick = time.time()+100
    return True


What’s happening here? We are getting the current time from the system clock and checking if it is 100 milliseconds after the last ‘tick’. If we are in PLAY mode and it’s time for a new tick, we update the next tick to happen 100 milliseconds from now and call the tick() function where we perform all of our game logic. Returning True at the end of the timer function tells the mainloop to call this function again at the prescribed timeout period. One always wants to set timeouts to be more granular than the actual frame rate needed for the game. This is why we call timer() every 1/50th of a second when we only need to update every 1/10th of a second. I leave it up to the reader to figure out how many frames per second that is. Hint: Block Party doesn’t need to run all that fast to be playable.

Input

Again in most game mainloops one of the steps in the loop is to check for input. Luckily with the glib mainloop we just get notified when interesting input happens. This is separate from the timeout source, so we don’t have to wait for the timeout to be called or the tick to be run to process an input event. This allows input to feel responsive even if we only update the game logic every 1/10th of a second.

For Block Party we are mainly interested in the keyboard keys for input, but other games may use the mouse, or even a web cam if the developer possesses some ingenuity. To get key press events we attach to the key_press_event and key_release_event signals on the main application window in the init() function in BlockParty.py at line 457.


window.connect("key_press_event", keypress_cb)
window.connect("key_release_event", keyrelease_cb)


In reality we only care about the key_press_event so the keypress_cb() function is where we do all of our work.


def keypress_cb(widget, event):
    key_action(gtk.gdk.keyval_name(event.keyval))
    return True


Notice that the keypress_cb takes a widget and event object. The widget in this case is the main GtkWindow we connected the signal handler to. The event itself contains the key we pressed. Here we get the key value from the event, translate it to a string and pass it into key_action. It should be noted that translating the key value to its string representation is a step used to make the code more readable when debugging or looking at other parts of the code. It does require more processing power to compare the strings and should perhaps be refactored in the future to use just the integer key values.

The key_action() function does most of the heavy lifting, so let’s take a look there now.


left_key = ['Left', 'KP_Left']
right_key = ['Right', 'KP_Right']
drop_key = ['space', 'KP_Down']
rotate_key = ['Up', 'KP_Up']
exit_key = ['Escape']
sound_toggle_key = ['s', 'S']
enter_key = ['Return']
 
def key_action(key):
    global figure,px,py,tickcnt
    global glass_update
    global game_mode
    global soundon
    global level
    global next_tick, time_step
    if key in exit_key: quit_game()
    if key in sound_toggle_key: soundon = not soundon
    if game_mode == SELECT_LEVEL:
        if key in left_key:
            set_level(level-1)
            glass_update = True
        else:
            if key in right_key:
                set_level(level+1)
                glass_update = True
            else: # if key in enter_key:
                complete_update = True
                next_tick = time.time()+time_step
                game_mode = PLAY
        update_picture()
        return
    if game_mode == IDLE:
        return
    if game_mode == GAME_OVER:
        init_game()
        return
    changed = False
    if key in left_key:
        px-=1
        if not figure_fits(): px+=1
        else: changed=True
    if key in right_key:
        px+=1
        if not figure_fits(): px-=1
        else: changed=True
    if key in drop_key:
        changed = drop_figure()
    if key in rotate_key:
        changed = rotate_figure_ccw(True)
    if changed:
        glass_update = True
        update_picture()


If you look closely at the key definitions, you see that we define a list for each key. This makes use of the python ‘in’ operator which allows us to check against multiple key values with one statement. For instance the statement ‘Left’ in left_key will return True where as ‘Right’ in left_key will return False.

Really, key_action() is a small state machine that responds to user input based on what state it is in. For instance, in the SELECT_LEVEL state the right and left arrow keys will cause the level to go up and down, but in the PLAY state (it is not listed in an if statement because it is the default state) it updates the px variable which is what the drawing code uses to figure out what column to draw the falling block in (py defines which row).

If the input has changed the positioning of a block, the display now needs to be updated outside of the timing loop. If we were to wait until the tick decided to draw input would seem sluggish to the user. Go ahead and comment out the update_picture() call to see what I mean. Later on we will talk about the gdk graphics layer we use to draw to the screen and in a later lesson we will show how to refactor the drawing code to use the more modern cairo drawing layer.

While we are on the subject it should be noted that the way drawing is done in lesson 1’s code is not completely correct since it actually draws to the graphics layer outside the expose event. All drawing should be done in the expose event to avoid bugs and work with features like double buffering. The reasons will become clearer in the Cairo lesson.

Logic

A game is no fun without logic. This is where the rules of the game are enforced and what makes the game fun, challenging and engaging. If you thought the graphics were the cool part, that is just the end result of the game logic. No amount of amazing graphics can make up for lack in game logic. This is why with Block Party’s decidedly dull graphics it is still a fun game to play. Later on we may spice them up a bit but that is just icing on the cake.

While some of the game logic resides in the input handlers the bulk of the logic happens from the timing loop when tick() is called every 1/10th of a second. Every tick the current block is dropped a row and then checked against the game board to see if it created a line or ran into obstacles. If so the score is updated, a new block is dropped from the top and the next block is computed. If not the current block waits for another tick or input to do it all over again. Let’s examine some of the code.


def tick():
    global figure, px, py, tickcnt, bh
    global figure_score
    global complete_update, glass_update
    global level, linecount
    global game_mode
    glass_update = True
    py-=1
    if figure_score > 0: figure_score -= 1
    if not figure_fits():
        py+=1
        put_figure()
        make_sound('heart.wav')
        new_figure()
        if not figure_fits():
            i = random.randint(0, 2)
            if i is 0: make_sound('ouch.wav')
            if i is 1: make_sound('wah.au'),
            if i is 2: make_sound('lost.wav')
            print 'GAME OVER: score ' + str(score)
            game_mode = GAME_OVER
            complete_update = True
            update_picture()
            return
    chk_glass()
    new_level = int(linecount/5)
    if new_level > level: set_level(new_level)
    tickcnt += 1
    update_picture()


In the tick() function one of the first things we do is drop the block by 1 row.


py-=py


We then check to see if the figure is off the screen in the figure_fits() function. If so the game is over and we set the game into the GAME_OVER state.


game_mode = GAME_OVER


If the figure still fits on the game board we then call the chk_glass() function. In Block Party the glass is how we refer to the game board where the blocks are dropped. The chk_glass() function goes over the game grid and compares each piece of the block to already filled in parts of the grid. If there is a collision the glass is checked for full lines and those lines are removed. Since the game logic from this point can get quite complex it is left as an exercise to the reader to follow the code and see how this is all done.

Drawing

At the end of the logic sequence the board is redrawn via the update_picture() function. This is also called at the end of input processing. Block Party uses the Gdk graphics layer to draw into an X window and the Pango API a layer above Gdk for drawing text. If you look in the init() function you cane see code similar to this.


window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect("expose_event", expose_cb)
area = window.window
gc = area.new_gc()


What we are doing is creating a toplevel window, connecting it to the expose event which will tell the window when something has caused it to need a redraw. We then get the GdkWindow and create a GdkGC. The GdkGC is used to tell the Gdk graphics layer how to draw its primitives. Later we will use it to set the colors of the object we wish to draw.


def update_picture():
    global complete_update, glass_update
    
    if complete_update:
    draw_background()
        draw_score()
    if complete_update or glass_update:
        draw_glass()
        draw_next()
        if game_mode is GAME_OVER: draw_game_end_poster()
        if game_mode is SELECT_LEVEL: draw_select_level_poster()
    complete_update = False
    glass_update = False


Looking at the update_picture() function we see a couple of draw function which are used to draw the various parts of the game board. We will be looking at the draw_score() and draw_next() functions to show how both text and graphics are handled in BlockParty.


def draw_score():
    global gc, area
    global linecount, score, level, scorefont
    global scorex, scorey
    global color_score
    displaystr = 'Score: ' + str(score)
    displaystr += '\nLevel: ' + str(level)
    displaystr += '\nLines: ' + str(linecount)
    pl = window.create_pango_layout(displaystr)
    pl.set_font_description(scorefont)
    gc.set_foreground(color_score)
    area.draw_layout(gc, scorex, scorey, pl)


In draw_score we create a string called displaystr of the text we wish to draw. We then create a pango layout and pass the string to it. A font description is then set which was created earlier in the init() function with these commands.


scorefont = pango.FontDescription('Sans')
scorefont.set_size(window_w*16*pango.SCALE/1024)


After setting the font we set the foreground color and use the draw_layout method on the GdkWindow to display the pango layout.

That is all there is to it. Now let’s look at the draw_next() function.


def draw_next():
    global gc, area, window, next_figure
    global bw, bh, bwpx, bhpx, xshift, yshift
    gc.set_foreground(color_score)
    draw_centered_string('NEXT', xnext+bwpx*2.5, ynext)
    gc.set_foreground(colors[0])
    area.draw_rectangle(gc, True, xnext, ynext+50, bwpx*5, bhpx*5)
    gc.set_foreground(color_score)
    for i in range(4):
        for j in range(4):
            if next_figure[i][j] is not 0:
                gc.set_foreground(colors[next_figure[i][j]])
                area.draw_rectangle(gc, True, xnext+j*bwpx+bwpx/2, ynext+50+(3-i)*bhpx+bhpx/2, bwpx, bhpx)


The draw_next() function draws the box which displays the next block which will fall after the current block has been placed. Here we set the foreground color and use our draw_center_string() function to basically do the same thing we did in draw_score(). After we are done drawing the text label ‘NEXT’, we set the foreground color to the first value of the colors array which is black. The colors array is setup earlier in the code and contains a set of predefined colors we use throughout the game. Next we draw a black rectangle with the draw_rectangle() method. This will become the box where we will draw the block in.

Each block in Block Party is defined in a 4 by 4 array. A square block may look something like this:

0000 0110 0110 0000

Or a T block may look something like this:

0100 0110 0100 0000

The 0s represent no colors and the 1s actually represent a color value in the array. When the code loops over this array and sees a color value, a rectangle is drawn at the offset with the color specified by the color value. An interesting challenge for the reader would be to replace the color value with a picture, and change the drawing code to draw the picture instead of just plain colored squares.

The rest of the drawing code does similar tasks of drawing text and rectangles. The draw_glass() function is the most interesting of the drawing code, as it needs to keep track of the game grid and erase previous draws or falling blocks would simply paint the screen by leaving trails of itself every time it moved. We will get rid of some of this complexity when we move to cairo and will end up having to repaint the entire screen on expose events. That might seem like it would inefficient but with effective use of dirty regions it will actually clean up the code quite a bit without loss of performance.

Conclusion

Now that we have a decent understanding of how Block Party works, we can start to delve deeper and evolve the codebase. The next lesson will show how to take the code we have been working with and, with little modification, turn it into a Sugar activity bundle.