The only area of technology not revitalized by the discovery of this new energy source was space exploration. Because CND generators work by using the curvature of space near massive objects to redirect and capture neutrinos, CND generators only worked up to low Earth orbit, beyond which they could only supply a trickle of power, decreasing to a barely measurable amount once a spacecraft left orbit.

Despite the setbacks CND generators (and the abandonment of the partially completed Space Solar Power Array which was being built at L1), in 2126 a massive project was undertaken to build a moon base. The initial phase involved launching hundreds of small mining robots to the moon using a mass accelerator built up the Serra do Imeri mountain range in Brazil. The robots were powered by CND devices which were useless in transit but reactivated once they reached the moon (although at 1/6th the power level they would have had on Earth). The first goal of the project was building a massive network of large CND devices under the Moon’s surface, to provide power for the automatic factories and pressurized domes which would be built later.

It was shortly before the completion of the Lunar CND Array that the Periodic Neutrino Anomaly was detected. Every 24.3 days, there were two bursts of neutrinos 68.3 minutes apart. Both their polarity and the sequence in which they hit the Lunar CND Array showed that they couldn’t possibly be solar in origin, and after statistical analysis of stationary CND devices on Earth they were discovered there too. After parallax analysis, it was determined that they were coming from a point near L4, and the partially completed Wide Lunar Array telescope was used to example the area for the next anomaly.

It was the discovery that defined Human history even more than the invention of CND: A small spacecraft of alien origin was repeatedly appearing, deploying solar sails, and then disappearing 68.3 minutes later, having returned to approximately its starting point. Radio and PNC (Polarized Neutrino Communications) signals received no response or reaction from the spacecraft, believed to be an observation probe of some sort. The ESS Armstrong (built for the lunar colonization project) was quickly re-purposed for a mission to observe the probe up close. 68 scientists from 12 nations arrived in the general area of the probe (there was some uncertainty as to where it would appear, as observations of the last 13 cycles showed the probe always appeared within a disc 2km in diameter.

On close inspection, the alien object was confirmed to be some sort of observation probe, but all the telescopes and sensors that could be identified were pointing back towards the disc, none towards Earth or any of the other planets. While maneuvering to better observe the disappearance and eventual reappearance of the probe, all contact with Earth and the lunar outpost suddenly ceased. After a few paniced minutes, contact was re-established over radio. Somehow all neutrinos were being blocked in a cylinder-shaped area beyond the disc. Even solar neutrinos weren’t detectable within this area. The scientists on the ship and on Earth were no closer to finding an answer to how this was possible or why it was happening when the ship reappeared. The ESS Armstrong continued observing it from within the cylindrical area (labeled the L4 Neutrino Anomaly), but something entirely unexpected happened when the probe disappeared again, right on schedule: The Armstrong vanished too.

To be continued at some point.

I also used some of my Tasari sprites, which is a series of unfinished RTS games I worked on from around 1998-2002. (These sprites are so old they were originally drawn for a Visual Basic 5 game!). Tasari 1 was a VB RTS, Tasari 2 lasted about 20 minutes and was a C++ translation of Tasari 1, and Tasari 3 was a fully 3D mess that got nowhere because I didn’t understand model formats, so I just hardcoded all the models into the source. It was deeply ugly.

As for the gameplay itself, it’s pretty simple Pipe Mania with some tweaks in strange directions: You place randomly selected straight/90-degree turn/crossover pieces, and if you replace an existing piece there is a time penalty. You have a time limit, and one of the ways I tweaked it was adding a “sink” tile. Instead of having to create a series of pipes that will survive for Xty seconds/Xty tiles, you have to connect from start to finish within the time limit + travel time of the water/electricity/flooz. It also has levels (A whole 3 of them, including a tutorial level!) instead of just being a blank grid with increasingly difficult time limits.

I’m not sure if it’s the different library, the fact I know JS better now, the lack of multiplayer, or the calming influence of CoffeeScript, but unlike my last JS game I don’t feel like pulling my hair out. (My last JS game was last March, which shows you how much I hated it: It took me a whole year to get back into JS)

PS: I called it “Pipecraft” because I’d developed it in my CraftyJS demo folder, which I’d just named “craft”. Since I’ve played too much Minecraft and based it on Pipe Mania, Pipecraft it is.

But a more interesting aspect of them is the spawnpoint-changing aspect which has been promised in a future update assumed by players. Notch has previously said he’s not sure about changing the spawnpoint because it’d change the gameplay. There’s not so much danger in wandering far from your spawn point or dying if it doesn’t make you respawn far away. But assuming this is going to be implemented, there’s also some griefing issues with it in MP.

Say a player makes a house and a safe bed inside it on a server. They then later log out, and a griefer signs on. The griefer could find their bed, destroy it, and replace it with lava/a TNT cube/a fall-to-bedrock drop. When the player logs in again, if they then die before they return to their house and discover the sabotage, they’ll spawn, quickly die, and then repeat the process forever.

There’s a few ways to fix this problem, none of them without their own issues. (And it is a problem that should be fixed. The existing spawn-point invulnerability proves that: In Minecraft, you should be able to kill other players and destroy their things, but not permanently and unfixably.)

1. Beds are invulnerable/the area around them is.
This is a bad idea, because you could log into a public server, quickly build a bed/surrounding dirt dome in a key spot, sleep in it, and then log out forever. It’s now undestroyable (except by admins). This sort of thing can already be done with obsidian, but obsidian is very hard to get, limiting the amount of damage a griefer could do with it (plus it’s not completely indestructible, just annoying to deal with).
(I list this first because it’s the most obviously unworkable answer)

2. Players can pick where to spawn, their bed or the default spawnpoint.
This is really just a workaround for spawnpoint griefing: If someone does something nasty to your spawn point, you can give up and revert to the (ungriefable (in theory)) default spawnpoint. Adding the UI for this shouldn’t be hard, it’d just change the interface from [Respawn] [Exit to menu] to [Respawn] [Respawn at center] [Exit to menu]. Alternatively this option could only be given (or just forced on the player) after they had died several times at their non-default spawn point (which opens up the possibility of griefing the player in a way that won’t kill them, like putting an obsidian-tomb around their bed.

3. Beds only work as a spawn point so long as the bed is intact.
It would be simple for minecraft to check that the bed is still there before spawning a player, but it wouldn’t fully solve the problem of spawnpoint griefing. Firstly, the griefer could just surround the spawnpoint with lava (without destroying the bed). So the player would spawn near lava, with no way to pass through it without dying . Secondly, the griefer could surround the bed with obsidian, so the player can spawn but not escape their bed. Despite these issues, this is probably the best solution as it incorporates #2. If a player spawns in their bed and can’t leave it(/without dying), they can simply destroy their bed and get back to the default spawn. There is the issue of player knowledge, however: It may not be obvious that that is an option.

This does assume that a bed can’t be placed in a situation where spawning in it would kill the player, but the bed is intact. For example, putting blocks directly over a bed might cause the player to spawn in them and “drown”. This specific issue could be avoided by having the game also check for enough room to spawn in (which it already does for default spawns), and having lava destroy beds (which I believe it does) so you can’t have a lava river running over the bed.

An unrelated minor issue of having beds change the player’s spawn point in multiplayer is that it would reduce the social aspect of multiplayer servers, since right now everyone has to build houses clustered around the spawn point, making them near each other. if players are free to wander 20,000 generic distance units away from the spawnpoint in search of a perfect spot and then live there, they won’t be forced into close quarters with each other. This has obvious negative effects on player interaction and server memory requirements. It also makes griefing possible if option #3 is implemented, as a griefer could find a player’s house and destroy their bed, making it hard for the player to get back to their home (or even impossible, if the player can’t remember existing where off in the endless wilderness their home is.

Given all that and the lack of any clear statement from Notch and the Mojangs that backs up the widely assumed “fact” that beds are going to change spawn points but it hasn’t been implemented yet for reasons of programming/testing time, I think beds changing spawn points was left out for reasons of game balance (and may not be coming, ever!) rather than time issues. There’s enough issues with them changing the gameplay as it is (You don’t have to spend nearly as much time making a beautiful creeper-proof castle if you can just skip over their active cycle with a small mound of dirt and a bed), making them change the spawnpoints too would introduce too many changes at once. Maybe in a later update once beds have been better balanced and their contributions to gameplay better understood and accepted.

My february game is ZapRogue, which isn’t really a roguelike at all.
I was playing with some sample code from the Roguelike Wiki
and built it into a monster-hunting game, since my original ideas failed to work thanks to issues with curses and 256 color support. Oh well.

You move with the numpad (make sure numlock is off!) and you press Z to shoot LASERBEAMS! which fly in the direction you last moved.
Enemies are randomly placed and have random ranges of activation (so sniping them from afar won’t always work). The level should be randomized, but I ran out of time, so it’s static.

(I did do and release a January game I just haven’t taken the time to write it up yet)

I got a very late start on this one because I was planning to do the reddit games jam, then I had a bunch of homework to finish. Then I was going to do Ludum Dare, and I wasn’t feeling well. So I built a simple prototype-ish version of Klotski. I’m thinking of making one for Android when I have more time, so this was a nice prototype to flesh out some of the algorithms in Python before I have to deal with the TERROR of Java games dev.

And hurray! This means I’ve done a full year of monthly games with no failures (although technically that was true last month too): All of 2010!
My new goal is going to be to make AND RELEASE a game each month. (Either the new game or one of the backlog)

Here’s to 2011 being an awesome year of gamemaking!

It seems this is a metacity bug but Compiz hides the problem, so it’s getting no developer love.

For my November game, I implemented a Nonogram puzzle (also known as Gridders, Paint-Doku, or Crosspix). I called it “Nomo” as “Nomograms” is a funnier name than “Nonograms”.
I developed it for my new touchscreen laptop, so it has a non-keyboard interface. I even coded part of it on the laptop while riding in a long car journey, which was fun as I had no docs.
Codewise, I’m still using the new framework I made for Mahjong Solitaire, with some minor fixes to handle resizing. I added a neat handler-stack system which nicely handles the switch between the list of puzzles and the puzzle itself. I added it in the last ten minutes of November, so I’m surprised I got it finished in time (“Hmmm, ten minutes to go… I know, I’ll recode half the event handling/drawing!”).

For puzzle sources I had intended to make a simple editor, but instead I just ran some regexes against a GameFAQS guide so I could import the puzzles from Nintendo’s Picross DS. I stuck the puzzles in a SQLite database, which I’ve not done yet for a game. It’s a good idea, it gives me pretty powerful data management for very little work. This would help support things like recording which puzzles are won/unlocked, but I didn’t get around to implementing that.

(I kinda rushed the end of this one in order to have time to play the new Minecraft update)

Code-wise, this one is very similar to Space Resistance, my august game. (Though I didn’t get as crazy with dumping invisible “thinker” objects into the draw queue this time). Nothing horribly special here, though I did have a neat idea for a color-shifting scrolling background (The current one is always that color, though it does scroll) that I never got a chance to implement. I did make use of the new PyGame microframework that I developed last month, and it worked beautifully. A few tweaks at the beginning and it stayed out of my way and provided some handy bits like easy screen scaling (The above screenshot is from running at 2X scale, and during development I was playing at 3X scale) and all the standard PyGame setup crap that never changes (at least for 2D games. OpenGL is trickier).

Gameplay-wise, it’s a pretty straightforward shmup. Enemies have Dark Stars-style random movement and shooting, your weapon repeats as long as you hold it down, and enemies randomly drop powerup crystals on death. Powerups upgrade your weapon so it shoots more bullets at once, and once you hit level 5 enemies start dropping coins which can be collected for a bunch of points. You’ve got one hit point, but if you have a powerup you’ll lose it instead of dying.

The enemy count starts at 10 and goes up for every stage beaten (all enemies onscreen defeated) or every minute that passes. Each stage is a random assortment of 4 enemy types (I planned to have it start with the easy ones and increase the proportions of stronger ones as stages go on, but ran out of time). There’s no boss or end, it’s just a survival game (it gets hard, fast!), aiming for highest score.

The real gimmick of the game is that it actually is a coin-operated arcade game. I bought a coin acceptor off ebay, stuck in a plastic box, and hooked up a microcontroller to the coin-accepted switch. This is the result. It communicates with the game over USB-serial, and the game won’t let you play until you pay 25-cents. If you want to get far, you need to shovel in quarters since it’s (sort of) a 1-hit-kill game and you have as many lives as you’ve paid in quarters.

Finally, the weirdest thing about the boringly named Coin Op: It has sound! (OK, maybe that’s only weird for foone-games) I created a bunch of 8-bit sound effects with the awesome sfxr project and dropped them in. (I see that playing sound with PyGame is surprisingly easy, now that I’ve finally tried it)