Over the last 2 months I’ve been continually surprised by the ideas that the students have come up with. As I wrote in a previous post, the 5 groups that I mentored all came up with very different game ideas for their projects. I was really pleased that all of them were interested and committed to the class and that I didn’t see any of them get bored or lose interest. What was even more impressive was the degree to which they actually finished the game ideas they presented to us. My main worry was that they would bite off more than they could chew and end up with some half-finished product that didn’t run, or just stopped part way through the game because that was how far they’d gotten. We tried from the outset to impress upon them how important having something that worked was and how they could implement their gameplay in increments. Judging by the state of the projects that I saw on Tuesday, this advice seems to have paid off.

The teacher whose class we were attached to had some great feedback on the project as a whole, but first some background: The project is not just about people like myself going into classrooms and helping out with the students. There are also several off-site days organised for them where they get bussed out to the IBM offices in Kanata and get to do things like take laptops apart, have an introduction to a development environment and more.

However, the thing our teacher said was that none of the off-site trips were really important to him and his class. For starters, they took time away from other classes and therefore made the whole scheme less attractive.

The XO laptops weren’t the main draw either: Sure they’re excellent machines and there are educational aspects involved in learning about the target market. OLPC is a great project. But in the classroom, from a programming perspective, it was sometimes a hindrance. The testing cycle was always longer as code had to be copied across to the laptop every time a change was made. We didn’t have as many XOs as project groups, so we had to share and give limited time to each group. Furthermore, there were issues with performance. As anyone who has ever done any embedded development will tell you, optimizing code to run on a target device is a huge consideration. For grade 12 students who are just learning programming, worrying about how many times you can redraw the game background before the performance suffers (for instance) is not high on their list of priorities. Nor should it.

The most important aspect of the whole OCRI program for our teacher was us. The mentors. His opinion was that even if there had been no off-site visits or XO laptops then he would still have wanted us to come in and talk to the students and help them out. That was what made the difference, and it meant that the students didn’t get bored, or lose interest.

OCRI is currently looking at what form the program should take next  year, and I’d like to be involved in it whatever form it takes. That said, I will also talk to them about the pluses and minuses of the current scheme and see if we can’t improve it for the next batch of students.

I was pleasantly surprised that all of the groups had started out in different ways. The first pair that we spoke to had jumped right into their astronomy-based game and wanted to know how to make a sprite move in a circle. This required a brief maths lesson from the teacher as he explained the equations for finding the x and y co-ordinates of an orbiting object based on the distance from the center of rotation  (the Sun in this case) and the angle the object was at.

One of the other teams had started straight out with designing their interface in photoshop. It was therefore the prettiest (albeit least functional for the time being) of the games at this early stage. Fortunately,because REAL Basic is a visual editor, there’s no harm in throwing design elements at the canvas first and then hooking up the logic later.

Another group hadn’t done any coding at all. They had decided to theme their game around the environment, concentrating on endangered species. Rather than tack this element onto the end of their game production they had instead decided to do the research required up front and when I saw them they were busy looking species of exotic birds on Wikipedia.

There are other groups in our class, but these three were the ones that I spent the most time with today. The range of different approaches to the project is interesting as since university I’ve not been part of a project from the get-go besides my own personal one-man efforts. I think all of the student teams have made a good start and I’m looking forward to heading back next week and seeing how they’re progressing.

3 XO Laptops

Chief amongst these is the mesh networking capabilities of the XO. Whilst it can connect to a regular wireless network just like any other computer, the XO can also form its own peer-to-peer network with others in the vicinity. This is really important as many of the applications that ship with the XO are social or collaborative in nature and the mesh allows them to be used in situations where a centralized network is unavailable.

With this in mind, I started thinking about how to harness the powerful capabilities of the mesh for my own applications. As far as I could tell, the whole thing just worked by magic. This was great, but didn’t give me any idea on how to send and receive messages from other machines on the network.

The teacher of the particular grade 12 class I’m mentoring (along with my good friend Dan Menard) is teaching his students REAL Basic. I’d not seen this environment before, and I can’t remember the last time I did any Basic programming. Fortunately, RB comes with extensive documentation.

RB comes with a set of pre-defined ‘modules’, roughly equivalent to the way that Java provides default packages/objects for common tasks. There were a couple of interesting modules that I wanted to take a closer look at: EasyTCPSocket and EastUDPSocket.

Both of these allow simple interaction over the network. You bind them to a port, then send information to a specified IP on that port. That’s all well and good, but what I really wanted was a way of discovering other machines on the network automatically. I knew that each XO on the mesh was somehow assigned an IP address, but neither socket provided a means searching for addresses automatically. I dug a little deeper, and struck gold.

RB has a nice little module called AutoDiscovery. Subclassed from the EasyUDPSocket, it allows you to bind to a port and then join a named group within the subnet. Furthermore, it can pull back a list of IPs in that same group. Perfect! After a little bit of trial and error, I managed to get two desktop computers on my home network to join the same group and exchange IP addresses. For proof-of-concept, that was enough. It was time to move to the XOs.

Fortunately, RB can cross-compile applications for Windows, Mac and Linux. The XO runs a modified version of Fedora, so I built a linux version of my simple app and transferred it to my pair of laptops via a USB key. I was slightly worried that they wouldn’t have the required GTK libraries installed, but both applications started up fine. A couple of seconds later, and success! Each XO was proudly displaying the other’s IP in it’s group list.

A pair of XOs running my proof-of-concept app

From this starting point, it is easy to see that more complex network-enabled apps can be built: Either by using the discovery mechanism as a way to exchange IP addresses before forming dedicated one-to-one connections with other machines (using the EasyTCPSocket, for example) or communicating with the group directly using a broadcast function. Both options have their pros and cons, but the main hurdle of harnessing the underlying mesh has been solved.

I’m really excited to see what the students do with the starting point I’ve given them. They’re still at the design stage right now, but by the end of term I expect that they’ll have produced some really phenomenal stuff.

An XO Laptop on my desk at work

Over the last couple of weeks I have had the pleasure of a pair of XO Laptops at my disposal. The XO is the result of the One Laptop Per Child project, founded by Nicholas Negroponte. The device itself is a real marvel of design and engineering, and I’ve had great fun hacking around with it.

The reason I am able to do this is because I am a volunteer mentor for OCRI, the Ottawa Center for Research and Innovation. In a nutshell, their remit is to promote Ottawa as a prime candidate for software and other technology companies to set up shop in. To quote from their website:

Our Vision for 2010 [is] to make Ottawa recognized as one of the most innovative cities worldwide.

One of the things OCRI does  is run a high-school program to encourage students to consider a career in the technology sector. That’s where the XO laptops and I come in.

Over the course of 12 or so weeks, myself and other industry professionals (I feel like such a fraud calling myself a ‘professional’) go into classrooms around Ottawa and mentor the students as they design, create and test an educational game for the XO laptop platform. The idea is that these projects will become available over the internet to teachers in Africa whose schools are part of the OLPC project and that they in turn can pass the games on to their students.

The students at the school I’m mentoring in are currently preparing presentations on their game designs, and I’m really excited to see what they come up with. I hope to post follow-up articles over the coming weeks describing some of the challenges of programming for the XO, as well as neat things the students manage to pull of. I already have a post in the works on mesh networking which I will be putting up later this week.