Art is Art and Water is Water

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.

Advertisements

February 28, 2011

February Game ZapRogue

Filed under: Month Games — foone @ 10:54 pm

ZapRogue

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)

December 24, 2010

December Game: Dec3

Filed under: Month Games — foone @ 2:52 am

Klotski

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!

December 7, 2010

Bug: Windows appearing behind the top window on Ubuntu

Filed under: Google bait — foone @ 10:22 am

Disable your always-on-top windows. If you don’t have any, disable your onscreen keyboard (OnBoard was doing it for me)

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

December 1, 2010

November Game: Nomo

Filed under: Month Games — foone @ 12:15 am

Nomo

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.

November 1, 2010

Game Inventory

Filed under: Month Games — foone @ 8:47 am
Month 2009 2010 2011
Jan microgue Slam!
Feb PyCross ZapRogue
Mar jsTanks Pipecraft
Apr scramble/pank
May Journey To The Surface
Jun X/Y
Jul Match3 Oshi
Aug MultiTank Space Resistance
Sep FAILED Coin Op
Oct Dark Stars Mahjong Solitaire
Nov FAILED Nomo
Dec Sokoban Dec3

October 30, 2010

October Game: Mahjong Solitaire

Filed under: Month Games — foone @ 11:31 am

Mahjong layout
Pretty simple game this time. I got a new laptop which has a touchscreen, and discovered how well Mahjong Solitaire works on a touchscreen.
I’m still using my framework from the last two games, but I had to modify it a good deal to handle only redrawing the screen on updates, instead of constantly.

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

October 1, 2010

September Game: Coin Op

Filed under: Month Games — foone @ 9:48 am

Coin Op screenshot: Space ships and bullets
I was working on this right up to midnight on September 30th, but here it is: A coin-op shmup using tyrian sprites!

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)

August 29, 2010

August Game: Space Resistance

Filed under: Month Games — foone @ 10:49 pm

Space ships and resistor color codes
I made an edutainment game for resistor color codes. For each level, you have an enemy ship firing at you (the speed of the torpedo increases as the levels go on), and you have to match the color code to the number. If you pick the wrong number, there’s a delay before you can fire again. Pick the right number, and you get some points and warp off to fight another enemy. (I’m taking an electronics class and I need to learn this, so this will hopefully help me drill color codes)

I also worked on an RPG, and by “worked” I mean I did some sprite edits and made a basic level editor.

August 15, 2010

August game – planning

Filed under: Month Games — foone @ 12:10 pm

I’ve not started on my game yet, I’ve a bunch of ideas and haven’t picked one yet.

  1. I created a bunch of particle textures in the GIMP using this tutorial, so I might make a particle system in OpenGL and a space combat game to use it with.
  2. I want to make a trading game. Different locations sell and buy different goods at different prices, so you travel between them trading. I might do this as an IRC game if I can figure out how to make time work. (Annoyingly, this won’t work with my current IRC Game framework)
  3. I’ve still got my half-finished Drakon code, which’d be nice to finish.
  4. And I’ve got the Gem Miner roguelike code and map renderer.
  5. The third Reddit Game Jam is ongoing, but I’m skipping this one as the theme is laaame.
  6. I might make an RPG with these graphics. I bugged a friend to draw me one more tile, so I’ll be doing that either this month or next.
  7. I ordered a coin-acceptor off ebay, so I might make a coin-op game. Almost certainly a shmup.
« Newer PostsOlder Posts »

Blog at WordPress.com.