http://www.wundermint.com/ The Fresh Express RSS en-us Sun, 5 Feb 2012 09:17:33 GMT http://blogs.law.harvard.edu/tech/rss CakePHP john@wundermint.com john@wundermint.com http://www.wundermint.com/posts/view/109


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. ]]> Fri, 13 May 2011 13:10:16 +0000 GMT http://www.wundermint.com/posts/view/109 http://www.wundermint.com/posts/view/108 Wed, 04 May 2011 16:28:12 +0000 GMT http://www.wundermint.com/posts/view/108 http://www.wundermint.com/posts/view/107 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. ]]> Wed, 27 Apr 2011 14:24:55 +0000 GMT http://www.wundermint.com/posts/view/107 http://www.wundermint.com/posts/view/106
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. ]]> Wed, 26 Jan 2011 17:26:54 +0000 GMT http://www.wundermint.com/posts/view/106 http://www.wundermint.com/posts/view/105 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! ]]> Wed, 19 Jan 2011 16:53:54 +0000 GMT http://www.wundermint.com/posts/view/105 http://www.wundermint.com/posts/view/104 Gruedorf Scoreboard after my tinkering last week (thanks for the heads up Kildorf), so I set out to fix it. It turns out that in updating the library I use to sort the tables I killed off some unofficial changes I had made to it when originally adding the sort feature. Oops.

So, I did the only sensible thing and hacked my changes back in and presto! We were back in business. After a short while this solution stopped sitting so well with me, though. Indeed, it relied on hacking up someone else's library and then using invalid HTML attributes; surely there must be a better way!

Of course there is. The trouble was that this sort library can't handle unconventionally formatted data properly, which is what I wanted to populate the table cells with. Something like, say, the Gruedorf time remaining is beyond its capabilities. So I had added support for a custom value to sort by elements by. The new solution is simply to put the sort value inside of a comment prepended to the contents of the table cell. No more broken libraries. No more bad HTML. Why I didn't think of this before is beyond me, but it is fixed now.

Then I got to thinking about the format that the time is presented in and how awkward it can look. After a bit of fiddling it now shows a much more human friendly "English" format for the times. This came at the cost of some precision for larger values, but it has it where it counts: in the final hours of your countdown to inevitable failure.

This all got me to thinking: "Hey, wouldn't it be neat if the times were updated in real time?"

Yes. Yes it would.

And now they do. It seemed a simple task. And it was. Yet it caused me immense grief over a period of several hours. But here we are and it is done. With all of the huge failures clogging the scoreboard, it's not all that impactful right now. Hopefully, one day, when you're checking in to see just how much time you have left and the seconds are ticking away before your very eyes it will motivate you to get that much more done. Or get it done sooner. Or do something. Anything. Please.

So there you have it. A whole mess of extra meta-gruedorf work for some very minor improvements. Let me know what you think of the changes and if you find anything broken. ]]> Wed, 12 Jan 2011 22:43:42 +0000 GMT http://www.wundermint.com/posts/view/104 http://www.wundermint.com/posts/view/103 Gruedorf Scoreboard. They are almost entirely administrative improvements, but it is now possible to look at the individual award ladders. Check out the Streaker Ladder, for example.

Going to keep it short this week, but I'd also like to briefly direct your attention to Slippity Slabs before we wrap up here. While this was not made just this week, it never got a mention here. A while back I was coerced by one "McGrue" into participating in a "compo." This is the result. And the singular entry into that rat's sham contest. It's a pretty simple game, but I think it makes for a fun little distraction. Give it a try if you haven't already. ]]> Wed, 05 Jan 2011 15:01:20 +0000 GMT http://www.wundermint.com/posts/view/103 http://www.wundermint.com/posts/view/102
Upon considering what would happen if a ship was put into battle against itself, I found that two of them yielded unwinnable encounters. Well, unless you consider "staying alive until the other guy accidentally suicides on the terrain" a form of winning (and not all terrain types have lethal collisions, so that's not always an option anyway).

This left me with the decision between pressing forward as is, or chopping things up a bit to make things fit together better. The obvious option was to just omit battles against ships of the same type and be done with it. While that does prevent the stalemate scenario, it feels more like avoiding the problem than solving it.

In a competitive multiplayer game, a bout between two similarly matched characters (e.g. two Warriors with approximately the same stats / build / what-have-you) is often more interesting and exposes the players' skill through success or failure. I mean, we all know rock beats scissors, but rock vs. rock becomes about who has the bigger rock. No, it is not a tie!

So, I set about fiddling with the ship concepts so that they'd be able to competently fight their twins. In doing so, I also discovered a few glaring oversights in some of the heterogeneous match-ups. After getting all of this patched up, the design feels significantly tighter, even on paper. The downside is that the ship diversity has suffered. The original concepts were just too different; if each had its own game tailored to it, it would be fine, but as they all have to play well with each other and adhere to a core rule set, a compromise was made.

As grouchy as I sound about all of this, I'm quite happy with how it's shaping up. This coming week should see some quick an dirty prototyping. VERGE's gimped input capabilities aren't quite up to snuff, but I'll probably use it anyway out of familiarity with both it and Lua. It won't be ideal, but it should be enough to let me know if I'm on the right track without burning up a lot of time. ]]> Tue, 27 Apr 2010 17:38:54 +0000 GMT http://www.wundermint.com/posts/view/102 http://www.wundermint.com/posts/view/101
There are currently 4 different terrain types. I've been fighting to come up with a few more, but doing so and keeping them mechanically unique has been difficult. The "Metropolis" terrain from the original is being retained, but adding something like "Forest" would be essentially the same thing but with different shapes. Maybe I'm underestimating the value of visual variety, but for now it's just easier to think in mechanical terms.

After much fiddling, I've gotten six competent ship designs that all offer a different playstyle without breaking the others' (in theory). There are some dramatic disadvantages to trying to get six different things to play nice together instead of just two. With the original Vector Knights, one side took damage, dealt "hits", and regenerated health; the other side took damage as "hits", dealt points of damage, and could not regenerate. With a two-sided system, the player doesn't question this; because the match-up is always the same it behaves consistently in every situation.

By adding more things to the mix, with different health "types", each ship would need to output multiple damage "types" to match and the player is left getting inconsistent feedback about the effectiveness of his character. This is fine in many game times, but in a simple (hopefully even elegant) action game, this convoluted scheme makes the rules feel arbitrary or subject to change at any time. So, health and damage have been made universally "hit-based" to keep things as simple as possible (no more fractional damage). Also gone is regeneration, which should help to curb the unkillable enemy effect. There are two ships that could be accused of exhibiting regeneration-like behavior, but I think they stand as integral mechanics unique to the ships' design, so it's not quite the same as hidden number voodoo.

Something else worth noting is that four of the six ships actually do "shoot bullets" by default. This is a very hard thing to avoid in a shmup. Although the actual way in which they do it and the effects they have are pretty non-standard, to help keep things interesting, three of these get an upgrade that modify their behavior in a substantial way (the other one gets to remain as a classic shmup ship). Hopefully, by retaining the some of the more familiar concepts early on, the player will learn the quirky mechanics in a more comfortable environment before getting to the more outlandish stuff.

Coming up next: it's time to clean up some odd bits in the design (mostly in the ship upgrades) to get everything feeling right. Then, time permitting, it'll be time to get a crude prototype together and see if this "different but complementary playstyles" thing is working as well as I think it is (hint: it won't). ]]> Tue, 20 Apr 2010 10:16:53 +0000 GMT http://www.wundermint.com/posts/view/101 http://www.wundermint.com/posts/view/100 Gruedorf, I don't feel right posting about flavor of the week progress, but I am posting now because..

Eldritch has dethroned me!

..and also because I am currently working on the design for a new shmup-ish game that may or may not be Vector Knights 2. It's being built as a sequel now, but if you consider that the original VK was started as Block Dodger 3, you can see why I'm not committed to the branding.

This announcement is admittedly more for me than anyone else as it'll (theoretically) force me to be accountable and stick to a single game. Right now it's shaping up to be a nice mixture of manageable and ambitious, and plays nicely into my not-so-secret vector fetish, so I'm hopeful. More details to come as the preliminary design comes together. ]]> Tue, 13 Apr 2010 13:22:57 +0000 GMT http://www.wundermint.com/posts/view/100