Art is Art and Water is Water

March 31, 2011

March Game: Pipecraft

Filed under: Month Games — foone @ 11:35 pm

Pipe Mania?
For my March game I made a sort of Pipe Mania inspired game, using CraftyJS, a very neat library I sorely underutilized in this game. It uses a component-based design which I had some problems with early on, so I basically just wrote around it (because I was low on time) rather than figuring out how I should really use it. I’m hoping to correct that for my next CraftyJS game. I also made use of CoffeeScript, which is an excellent language that’s really just a sanity wrapper on JS. It fixes some JS misfeatures and changes the syntax to something that’s more like Python/Ruby. It compiles JS pretty directly, though for-loops end up looking pretty weird.

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.


March 7, 2011

Minecraft: Beds in multiplayer

Filed under: Minecraft — foone @ 11:31 am

So the 1.3 Beta release of Minecraft was released towards the end of February 2010, and it adds a nifty new feature: Beds. Beds are easily made (if you don’t mind smacking up a few sheep) and let you skip the night phase of the game. This totally changes how safety works in Minecraft since you don’t have to worry about getting killed by monsters except at the very beginning of the morning, before they despawn. (Or when they spawn next to your bed because you didn’t build your house correctly according to the slightly-odd mob spawning mechanics).

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.

Blog at