Fri, May 13th 2011, 13:10

Blueberry Intervention  

---

I spent about 3 hours on this:



I would've spent even more had it not be for Overkill. He helped me figure out what needed fixing (the lighting) and how to do it. There just wasn't a lot of room to put in a specular highlight and a crown on each while having them in different orientations so they didn't look like a bunch of clones. I am mostly pleased with the results.

Overkill was also helpful in another way: He told me to knock it off and stop wasting time on something so trivial. He is cool like that. Anyhow, there are more little fruits, but those will be showcased along with (and in) proper screenshots once I have these implemented in the game. With any luck I won't miss the next Gruedorf deadline.

0 comments

Wed, May 4th 2011, 16:28

Name Shame  

---

Very light update this week. The biggest change to mechanics is the addition of an incremental difficulty level. Prior to this, it was possible (and easy) to play indefinitely. Several hours were also spent toiling over the behavior and details of the "naming" system. This is probably time poorly spent, but it's already done and I like adding little touches.

0 comments

Wed, Apr 27th 2011, 14:24

On Pain of Death  

---

Grue has very politely pointed out that I haven't been updating as much as I should. In light of this, I have been coerced encouraged to add a new post. So here it is!

I recently set out to start tinkering with Flash and make a game. This was all pretty new to me, but was easy to get into. I went with FlashPunk as the buzz suggested it was a better general game library than Flixel. The way it handles clipping regions and primitive drawing is a bit annoying, but otherwise it has treated me pretty well so far. I wanted to do something simple as a first project, naturally. While I have a nifty plan for a platformer, I decided it was a little too ambitious for a learn-as-you-go project. Instead I opted to make a puzzle game. In hindsight, the platformer probably would have been quicker and easier. Le sigh.

True to my history, when making a "sequel" to a game, it has turned into something else entirely, albeit with some common bits and pieces between them. What started as Prismatic Arrows 2 has evolved into Juice Game. It's catchy, I know. But clever names come after clever games. So, without further ado, I present a slightly outdated screenshot from when it didn't work quite right:



Yes, it looks a great deal like Pipe Dream. Yes, they do have a bit in common. No, I assure you they are different games. Pipes are a natural evolution of the old arrow model. Arrows only point to the next piece instead of visually connecting to it, making it harder for the player to parse. They also behave somewhat differently in that they have 3 optional inputs and 1 output. Pipes, by comparison, have 1 input and 1 output and they are reversible. Other fundamental behaviors that needed to be banished:

* The ability to inject colors at any point in a sequence.
* The presence of a full spectrum of colors.
* Blending and matching of those colors.

The whole thing was a little too clumsy, but it was built around the notion of "Can I make a game using VERGE's MixColor()?" and in that I feel like I succeeded. Juice Game takes the core of Prismatic Arrows (create long chains of interconnecting pieces filled with different colors) and streamlines the experience, making a much more playable game. This is, of course, still a work in progress, but here are some screenshots of it as it stands right this very moment:





Everything is functional. There are a few mechanics I'm still trying to decide which way to go (for now, playtesting will no doubt reveal me for the fool I am). I also need to slap on a fresh coat of sexy as it's pretty rough looking at the moment. Look forward to more details and more screens in a future update.

0 comments

Wed, Jan 26th 2011, 17:26

Slippery Stones  

---

Chrome users will appreciate that the awards section no longer spills out of its container. This was an unfortunate casualty of getting everything up to W3C snuff, but it is no more!

In more substantial news, I've been looking at ways to improve Slippity Slabs. One of the things I would like to do (and was actually meant to be the original mode of play) is to assign unique physics to each block type.

While each concept comes with it's own headaches, none has been more frustrating than the "slippery" block. The idea is that it will slide until it hits something or falls. Alternatively, another block moving across the top of it will slide onto the next block (continuing to do so if there is a row of slippery blocks) or fall. Since the Gruedorf community is largely unresponsive to text-only posts, the problem is summed up with the following:



And that's where I am. I've got a sense of which way to go here, and I might have to try them all out to be sure, but it definitely seems like none of these is particularly good. I don't want to cut it, because I'm fond of the idea, but if it doesn't feel "right" then it'll have to go. I am completely open to suggestions and opinions on this one; it's impossible to be inside another player's head.

6 comments

Wed, Jan 19th 2011, 16:53

Validation  

---

So, this week I wanted to wrap up the Gruedorf improvements by getting it to pass W3C Validation. This was a simple task, but it did take a little time and I'm glad to have done it. Check it out for yourself: valid HTML and CSS! Hooray!

Now that I'm back on the horse with a few timely, successive updates, it's getting to be time to tackle more impressive feats. What exactly that means and where it leads, I do not yet know. Tune in next week to discover the answer to this and more!

0 comments