SpaceWar! clone.

A Virtual MIDI keyboard using PyPortMIDI, Python, and pygame for pathetic hacks like me who can't be bothered to learn a real instrument. "Tune" your instrument to a particular major or minor key (like G minor) and play away; it is impossible to hit a note that is out of key.

No instrument? No skills? No problem.

I made this game as the final project for both my OpenGL programming (with Dave Dobson! Sorry about the name-dropping. Just so you know, he usually likes to play FPSes, not puzzle games!) and AI classes. It tries to create a somewhat interesting environment that's not player-centric. I half-assed a lot of things and it was a good learning experience in the fact that I should A) be more careful about the way I design systems, with an idea of its eventual uses and B) try to use data-driven classes a bit more in the future, since using just static c++ classes can cause some headaches when you want a flexible, extensible system.

Please remind me to clean the source just the tiniest bit (because I'm far too lazy to really 'clean' it all up, meaning removing all the silly hacks) and release it under the GPL.

"Emerge" is the name for what I eventually want to be a general-purpose space sim engine that makes heavy use of procedrual geometry and uses a 'retro' aesthetic with modern flair (a la Darwinia). The early stages aren't going to really have procedural geometry at all... for a 0.1.0 release all I really want is "Quake in Space": a multiplayer environment where you can blow up your friends in space.

I might eventually decide to rename it to something more space-ey and instead have it implement a procedural geometry language which I would call "Emerge". From looking at the way .werkzeug1 (those demoscene boys should really hear about Open Source, though I guess they're too competitive for that) works, I think it would be based on a series of data types (primitives: cube, cylinder, sphere, etc.) with a series of possible operators (at the vertex, edge, face, and object levels) with which you mess with the mesh. Basically, it would be a file-driven 3d modeller of sorts. I would want it to be . I might even just make it as a Python library so I don't have to worry about parsing, but then I'll have the "problem" of using scripts as opposed to making a mini-'compiler'. I figure all this compiler would really do is turn all of the human-friendly elements of a script into binary (example: if there are 256 operators or less, I can compress the word "extrude" into a single byte), and perhaps compress it with zlib. This would be more difficult, but more 'true' to the goal of tiny mesh file sizes.

A perl script that I vomitted out in about 30 minutes (most of that was figuring out the right regexp) that will print out the text of one of my favorite webcomics of all time to the terminal. Currently it does this by wgetting the entire html page and parsing out the good bits. This is humongously inefficient but I don't know if the RRS feed or anything else contains just the bits I want (and thus not require the bandwidth to grab the whole page). Usage : jerkcat.pl
No, I don't really know why I made this.

Anole is a Python library inspired by this thingie on the Ubuntu wiki. It's basically just a heavyweight wrapper around pygame which aims to provide the sort of beginner's functionality for making games and other fun stuff which modern *Basics provide (I'm talking about DarkBasic, BlitzBasic, hgulahgaBasic, not VB.NET) and which, in the early days of home computing and the not-as-early days of QBASIC gave young kids an outlet for prorgamming. In the modern world, there just doesn't seem to be an open-source equivalent to this sort of beginner programmer's environment which doesn't require them to pick out and successfully install a series of libraries which will do it for them.

The first objective is to get a drawing system and certain other basic wrappers going. Wrapper functions are going to make assumptions and use global variables (well, namespace-aware ones) to make the API as simple and opaque as possible. I might eventually even do smart exception handling so that the user won't get funny errors when a dependecy library is at fault! Eventually, all of this would need a snappy IDE which includes a canvas and some other things, at which point I start hoping that other people will be willing to help.

SanGuo (meaning "Three Kingdoms" in Mandarin and referring to this time period) will be an attempt at doing two things. A) Appreciating the Kohan: Immortal Sovereigns series of RTSes which I've recently discovered (It ranks up there with Total Annihilation in my opinion). and B) estimate what a curses-drawn game(Rogulike, ASCII console, whatever you want to call it) would be like if it were drawn with Chinese characters. I'm using Python and Pygame right now, but I am planning to switch to either using PyOpenGL for the display or messing around with Pyrex because vanilla Pygame rendering is just too damn slow, even if I pre-render the text onto a bunch of images and use those as tiles.

I'm using Simplified Chinese because I also sort of want it to be a quasi-educational game... just in case you ever need to know the words "spear" or "broadsword" or "general" or "crossbow" on your next trip to Beijing. The game will probably be set in the "Three Kingdoms" time period (duh) unless I feel some other period would be neater. I might just change it so it is sort of like "high fantasy in medieval China", featuring dragons and the such, but I think I want to keep the game quasi-realistic.

Initially, I won't bother with sticking to the Three Kingdoms story at all until all of the gameplay is complete. I think then I would just present it to some Chinese history nerds and get them to flesh out the content-creation portion. I'm really just a programmer at heart.