http://www.wundermint.com/ The Fresh Express RSS en-us Thu, 23 May 2013 00:48:55 GMT http://blogs.law.harvard.edu/tech/rss CakePHP john@wundermint.com john@wundermint.com http://www.wundermint.com/posts/view/113
Defense

Previously, items that gave protection from damage had two relevant values: damage reduction (the amount by which it would reduce incoming damage) and defense (the item's "health"). As an item took damage, both its defense and damage reduction would lower in proportion to each other. After sustaining sufficient damage, it would provide no protection at all.

Enter the "Boolean Defense" system. Now, an item retains its full damage reduction until its defense is reduced to zero, at which point it is "broken" and no longer provides any protection. While I liked the complexity of the old, slow-deterioration system (which had been in place since the very first prototype!), I don't think it actually suited the game. The new system is much simpler and leads to quicker, smarter decisions. This is good.

Traits

These allow the player to tailor the game to their taste. Some are simply stat boosts, but others offer new mechanics or adjusted rules. At the outset, the player selects a few Traits that (hopefully) work well together and then begins the game.

Several traits were revised this week. Most of them were related to equipment and how it was used. There are quite a few of these and rather than go through them all, I'll just talk about one as an example. Ambidextrous used to allow you to equip two weapons instead of a weapon and a shield. It also granted you two attacks while wielding two weapons, effectively doubling your damage. Its utility has been expanded, allowing you to dual-wield shields as well as weapons. It still retains its two attack behavior, but the damage for each attack has been halved to prevent insane damage inflation; any "on attack" effects, however, still benefit from there being two attacks.

I also added 9 brand new traits this week, bringing the total up to 63. I don't expect all of them to make the final cut (and certainly many will need to be changed too), but I think it's good to work from a large pool and cull it as needed later. The new traits are a pretty random mix, but they do include 2 traits that build off of the recently implemented throwing weapons, which I really wanted to have.

Names

Randomly generated names are used for enemies, items, locations, and some other things. These aren't critical, but they do add a bit of flavor and there's something fun about not seeing the same names every time you play.

The old name generator was perfectly adequate, but lacked variety, consistency, and, well, just created too much gobbledygook. So, it has been expanded from 3 "flavors" to 9, and uses a system that is more flexible, expandable, and produces more consistent results. The names are still gibberish, but it's largely pronounceable gibberish. Hopefully, this superficial change yields a more consistent and believable game world. ]]> Fri, 11 Jan 2013 19:13:02 +0000 GMT http://www.wundermint.com/posts/view/113 http://www.wundermint.com/posts/view/112
Throwing Weapons

While it has been possible to throw items via the Heave trait for a quite a while, I decided it would be worth adding a dedicated class of throwable weapons. Enter boomerangs. And shurikens. And, yes, even bombs. These fill the previous void of consumable, offensive items; consumable recovery (food) and utility (potions) items are already well established.

Because thrown weapons are generated (using materials and quality levels) like equipment, the way an item's throwing starts are calculated needed to be changed. This was a great opportunity to try a new approach to stat calculation that I've been wanting to use. So, the throwing stats were set up using the new system. It worked exactly as intended (yay!) and I went ahead and added it for equippable items as well.

Old Stat Approach -- Some lazy thing I did at a gamejam

Previously, items derived their stats by multiplying the different factors of their components (quality, material, etc) together to get a composite value. This works well enough for easily adding a lot of variety to items, but it also produced a lot of "underpowered" items. This is undesirable. Junk items should be bad because they don't fit a player's needs / build / playstyle, not because they are numerically inferior. So, rather than just adjusting the component values to create a glut of bland, "balanced" items, the entire system was rebuilt.

New Stat Approach -- Items as Unit Vectors (Sort of)

Individual components are now looked at as a whole and weighted according to what they provide. Then the component weights are combined to create a set of percentages that make up the item as a whole. These percentages are then multiplied by a stat-specific scale, yielding the final value.

The end result is that items of a given quality will always be on par with other items of the same quality (even if the specific distribution of values isn't useful to the player). In a game that revolves around maximizing the quality of items you receive, this consistency is crucial. Without it, the player's success is simply too random. ]]> Sat, 08 Dec 2012 05:14:55 +0000 GMT http://www.wundermint.com/posts/view/112 http://www.wundermint.com/posts/view/111


Since then, I have been slowly improving on it and putting some meat on its bones. I even have proof! Here is a screen from the latest version:



While it looks largely the same, there's a quite a bit more going on there. Not exhaustively and in no particular order:

• Quests
• Traits
• Time
• Status Effects
• Scenic Locations
• More of.. everything!

There's still a lot of work yet to be done, but it's getting there. So let's touch briefly on the game itself and why I think it's interesting.

The Standard Stuff: You are a hero. You kill monsters. You collect items. The difficulty increases over the course of the game. The quality of items increases to compensate for the increasing difficulty.

Important Details: You have limited recovery options while out adventuring, but returning to town will completely restore your character and items to top condition. Inevitably, you must return to town to avoid death.

The Big Wrinkle: Returning to town also permanently lowers the quality of items that you find (by a small amount). Take too many trips to town and you will find the monsters are outpacing your equipment and you will die. This press-your-luck arrangement exploits your greed and forces you to play outside of your comfort zone. "Can you survive another battle? What if it's a werewolf? Or a dragon?" Also, there is permadeath.

So that's it in a nutshell. Future posts will address new additions, improvements, existing features that were un(der)explored in this post, and just be more detail-centric in general. ]]> Fri, 30 Nov 2012 23:10:34 +0000 GMT http://www.wundermint.com/posts/view/111 http://www.wundermint.com/posts/view/110 Ben McGraw recently posted about reviving an old blog Pact. I have elected, against my better judgment, to participate in said Pact.

Posting will commence with a brief summary of my current project, Roguelite, and continue with weekly updates on its progress until release. ]]> Tue, 27 Nov 2012 20:48:29 +0000 GMT http://www.wundermint.com/posts/view/110 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