If you go too far from a star it's easy get lost without being sure which way to go back. I later realised that there is a marker on the map, but it's very subtle.

The tutorial doesn't mention landing on planets? Possibly because there's nothing you can do there yet?

You should be able to press "space" everywhere you need to use "enter".

The stars should probably be inter-connected? It's a bit weird that you can't travel between stars which are close on the map but aren't directly connected.

This is really rather lovely. Awesome work!

Nitpicking:

In the cave of respite, I got the gem and walked over to the purple-haired guy next to it. The mysterious off-screen voice and the guy in the cave both started talking together and you couldn't really read them both.

If I can teleport to places from the central area it would be nice to be able to teleport back.

The girl who wants her pearl back shouldn't immediately drop the detector before talking to you.

The detector doesn't seem to do anything.

Pause menu should appear if you press escape.

Most annoying of all: I quit by pressing q and it's partially lost my progress. My collected gems are still in the central area but I've lost all my endurance. The pause screen showed my stuff but said I had collected no gems and no nuts. Then I reloaded the swf and now the pause screen is completely blank again.

At least go v1.4.3, it's much harder in 2.0 for Box2D.

I'm just curious why this is?

More graphics improvements (they appear as you play).

Also tweaked the gameplay a bit: the ball is now faster and the paddle is now smaller.

Thanks to everyone who has commented, it is really helpful.

I have asked a friend to work on some sound effects, but I don't know when/if he'll have anything.

[Composition]

These are all fairly solid. Some hopefully useful feedback:

Composition

I was trying to go for a sense of flow in this level. What I mean by that is that by the time you master the level, you'll be able to run through it without ever stopping. You can just hold right, and make it to the goal without ever having to slow down for obstacles.

The problem with holding right constantly is that after respawning at the checkpoint you almost immediately run into a spike. I think moving them apart would improve that feeling you were going for.

Atmosphere

My theme was "Outer Space/Asteroid Belt".

I liked the placement of the goal relative to the easiest path through the level. Personally I would probably have put the checkpoint just before the end of that bottom path though.

Teaching

Your goal is to get to the flashing light in the upper-right corner.

Right off the bat, before the player even gets a chance to do anything, they'll be knocked upwards by an enemy bullet, the enemies will kill each other, and a single stray bullet will bounce around off the mirrors below. Essentially, the player learns almost everything they need to know about the game instantaneously as they start. However, the second half of the level then makes the player execute those actions themselves, making sure that they understood everything that was shown to them at the start.

I don't think this does a great job at teaching the mechanics.

General rule of thumb: anything that happens immediately when a level begins will not be picked up on and will only serve to confuse. By the time the player has worked out who they are controlling, everything has already happened and they're wondering what that moving blue thing down the bottom is.

Then the next two puzzles require the player to have a detailed understanding of how the game mechanics interact with each other and to use that knowledge to execute a multi-step plan.

I already knew the rules of the game and it took me several attempts to make both jumps.

That's just stupid, as I don't even have to use any parameters for the main() function if I don't want to...

You do if you're using SDL. Also there are situations in which you might be passing in unused parameters to functions other than main().

Even the article is broken...

Updated the graphics tonight: got rid of the Box2D debug shapes and now the bricks can be happy happy.

Making happy bricks for my game Happy Happy Brick Catch.

Average sale price is about $1800. Median is $800, mean is $500.

Can you clarify this? What is that initial $1800 figure if it's not the mean average?

Never used any of these, but I've also found GameSWF (found via this thread: varied opinions of it there).

I think it's a cool event and I'd be disappointed if it stopped so soon.

So in the interest of making the world I wish to live in, I'll volunteer to be a participant. Or do I have to challenge someone?

Code:

  public static BufferedImage createNewOptimizedImage(BufferedImage image) {
      BufferedImage temp = createCompatibleDestImage(image, image.getWidth(), image.getHeight());
      temp = toCompatibleImage(image);
      return temp;
  }

The first line here seems to be superfluous?

It's been a while since I did Java game dev, but my code for loading fast images is here: http://svn.warwickgamedesign.co.uk/repos/wgd-jgf/framework/Images.java

You might find it useful as a comparison.

Right now I'm playing with using Inkscape to make SVGs and embedding JSON in the description tags for game-specific metadata

I've had success with this method, except I used the Inkscape XML inspector to embed extra XML attributes for game metadata. Possibly a simpler solution than yours?

If I'm making a tile-based game I will generally make a very simple in-game editor.

Just submitted a game! Didn't really manage to polish it up much though.

I've not used it personally, but this is exactly what PixelToaster was made for.

My second choice would probably be SDL: you can set that up to give you access to the screen as an array of pixel values.

I would personally not use OpenGL: that seems to me to be the wrong tool for this job.

Are there any details anywhere about how to make Winnitron-compatible games?

I.e. key bindings/screen size/download requirements

I'm intending to improve one of my old two-player games for the online jam.

[Updated build and new name:]

I didn't quite understand the 'bonus' score. I thought it related to the number of bricks in the paddle but sometimes I would shake them all out and the bonus remained high? how is bonus computed?

The bonus is the number of wakened bricks still in the play area, so it is mostly bricks caught in the paddle but also includes bricks which are lodged in place at the top.

Updated build and new name: http://www.draknek.org/games/happy-brick-catch/

I hope to have improved on most of the issues people have mentioned, let me know what you think.

Thanks for the feedback everyone!

At one point, I thought that the blocks would continue to collect on my paddle until I would be playing with a hodgepodge fortress as a paddle.

This was the initial idea but I didn't have any success in tuning the physics to make this feasible. I might try some more at some point but it's hard when the paddle moves as quickly as it does.

I think you could improve the game with the breakout "classic" rule: the angle of the bounce of the ball is determined by the angle of the hit and the position of the hit on the racket. In your case the computation isn't as expected (imho).

I didn't add this because a) I didn't want to hack it into the physics and b) often the ball hits a brick on the paddle rather than the paddle itself and I wasn't sure how to handle that case. You have some control over the horizontal velocity by hitting the ball with the sides of the paddle but it's not very fine-tuned.

i like the game but play sessions are too long

I would probably agree but am not sure how to improve this.

[Original post:]

Happy Happy Brick Catch

Original post:

Made this in a few hours over this week. It is a fairly standard Breakout-with-a-twist game.

http://www.draknek.org/games/knock-em-down/

Not a lot of polish gone into it but I'm happy enough with the gameplay mechanic I wanted to try.

The current name is very temporary until I think of something better.