Accepted into the Google Summer of Code!

Anyways, after the final countdown yesterday, I am very happy to announce that I got into the Google Summer of Code for working on the PySoy Scene Designer! It should be an interesting summer, and I plan to use this opportunity to learn as much as I can about open source, python and game engine programming in general. I plan to post to this blog over the summer about my project as well, with my primary goal being to learn how to explain programming related topics better in the written form, and to become a better writer in general. Even if I'm the only person who reads this blog and I just end up just explaining things to only to myself.

PySoy GSoC Proposal: PySoy Scene Designer

Anyways, this blog was originally created because of the Google Summer of Code, so I might as well make a post about it. :P

I only made one proposal, and that was for PySoy, a project under the umbrella of the Python Software Foundation. Why only one? Well, before recently had no real experience with open source development whatsoever, and it was only project that I came upon which seemed more about learning than just getting code out. I'm not saying there is anything wrong with this approach, but for those of us who are intimidated by open source to begin with, it can be a bit daunting.

My proposal for PySoy is to create the PySoy Scene Designer. Essentially, in the simplest terms, it's a project which comes together in two parts: An editor which will allow one to edit and connect scenes, and a GUI which will automate the process of adding bodies to these scenes. (As well as a simple game demonstrating how it can be used, but I can hardly count that as a part of the project.)

Obviously the most difficult part of the project will be the editor itself, as the rest of the GUI is mostly just a wrapper for the existing API. e.g. a body added to a scene would essentially be added through the same methods as it would be if a programmer were to write it the normal way. The editor will display interconnected scenes as nodes, furthering the idea that PySoy is a cloud game engine. As, theoretically all these scenes could be on separate servers it makes sense to have be visually represented as separate entities in the editor as well.

Connections between scenes could be any number of things, but one such connection that's been thrown around the PySoy irc would be the portal. Portals should connect rooms, a type of scene with six planes facing inwards creating a room to keep bodies contained within, to each other in such a way that you should be able to see into the next room as if it was really the next room. Even if the next room on the other side of the portal is the room you are already in.

Anyways, that's just a little explanation of what I hope to be working on this summer for the PySoy project. If you are interested in knowing more I suggest checking out the wiki page.

Temporary VirtualBox Fix for New Macs

So lately I've been trying to run linux in Virtualbox on the new mac I bought recently, only to find that I had this problem. As talked about later in the comments you can fix this problem by simply booting into the 32bit kernel. Obviously this is only a temporary solution, but it works and if you want to be able to say, pass your Advanced Unix course without using another computer it's certainly better than pressing the host key over and over again.

To boot into the 32bit kernel simply hold down the 2 and 3 keys at boot.

Cumulus, or How I Learned to Stop Worrying and Love the Cloud

Silly post title aside, lately I've been working on a side project I've simply been calling Cumulus, a cloud based package manager that uses the BitTorrent protocol. There are a few obvious advantages to this: less servers needed to distribute packages and faster download speeds on some networks. (Assuming bandwidth throttling isn't taking place.) But I think the greatest advantage is the power of an endless amount of repositories... if you have a cool package you want to distribute you can just seed it, and if others like it they can seed, and so forth and so forth.

A Master Seed would serve as essentially a main repository with a tracker that tracks these trusted packages only, and with a predefined but not required stack to the job it would be relatively easy to set up a similar system for an external repository.

Almost as a sort of satire towards the cloud, I've also been following a cloud based naming scheme for it's commands. To install a package, you precipitate. To remove a package, you evaporate. To update you accumulate. I'll explain the inner workings of how dependency handling and the like will work when I get a chance, but for now I'll leave you with this. :P

I haven't uploaded the source to the github repo I created for it yet, but eventually I hope to turn it into an open source project written in python and using the libtorrent python bindings.