A few hours later and we’ve already finished (or at least made good progress on) two of the goals that I was hoping for:
Here we are, 24 hours into the competition.
A lot of the last few hours has been spent doing a fair amount of restructing. Before, I had a single ’thread’1 for each of the tiles, along with another thread listening for user input. Unfortunately though, that lead to all sorts of race conditions. Specifically, whenever two tiles overlapped, it was often the case that one was doing the falling step (which copies from one internal buffer to another) while the other was in the swap step (which copies from tile to another). Then after the first finished, it would copy the second buffer over… overwriting anything that had been swapped.
Oops.
We’re getting there. 18 hours in and I have the first hints of what might actually be a game…
And here we are again. Ludum Dare. Taken directly from their about page…
Ludum Dare is a regular accelerated game development Event. Participants develop games from scratch in a weekend, based on a theme suggested by community.
More specifically, the goal is to make a game from scratch in 48 hours. You’re allowed to use publicly available frameworks and code libraries, but no art or other assets. Previously, I missed the original start time. So although I made my game in 48 hours, it didn’t qualify. This time around, I’m starting on time.
If you were paying attention when I posted part 2 to GitHub (pegs.rkt), you might have noticed a function I hadn’t talked about: play
Hey, remember that post a few days ago about the Cracker Barrel peg game? Right at the end, I mentioned that there would be a part two, all about how to bend the puzzle at least a bit to your advantage. Basically, rather than finding the first solution to the peg game, we’re going to find all of them. From there, we can determine which moves are easier to win from, which are harder, and which are downright impossible. Let’s do it!
Ever been to Cracker Barrel? Remember that peg game? It seems that rather a few people are interested in how to solve it: Google. Let’s do that.
Almost four months ago, I started writing a series on how to write a roguelike in Racket. I believed then as I believe now that Racket is an excellent all around language and that I would like to see more done with it–particularly in games.
Last week we made mazes on a regular grid using the noise generators. That was pretty neat, but it got me thinking. What other ways do we have to procedurally generate interesting level patterns?
I think by now it’s well past time that we got to adding a bit more content. So far, here’s what we have (bolded entries we actually used in day 8):
We can do better than that though!