New Hex Tiles and Items

Wrestling with inventory took quite a while, but I think it's better for the effort. This post, I figured I'd detour from code talk to show off some of the other stuff that's been percolating.

New Hex Art
First off, we have new hex art! The last round of hex art was a little too grainy and indecipherable for my taste. So I dusted off the Wacom and tried to spruce them up a bit.

New plains, hills, forest, and suburb hexes.

So far, I'm pretty happy with the direction they're going. The style is reminiscent of 16-bit era pixel art, but with an expanded palette. I pushed colors slightly into cartoonish territory, but I think that helps the user to identify features better at this small resolution. (e.g. look at the forced highlights on the treetops)

Approaching urban ruins along a river.

In this shot, we can see the new urban ruins tile. It sports a skeletal skyscraper, complete with draped blue tarp and cables strung across the air to the neighboring brick high rise. And a few brownstones are sprinkled in for good measure.

While I like the tile a lot, it doesn't repeat well. It may be too busy for the primary city tile. The water is passable, but I may rework it later.

A couple mountains along a river.

I also have a smattering of mountains in certain highland regions of Michigan. I liked them when I was drawing them, but in-situ, they just don't seem to fit the scenery well. I may have to save that art for something else, and replace them with greener mountains.

All this new art presents a new issue, however: draw-order. Both the player and the hex highlight are being drawn on top of the hexes. It ruins the illusion a bit. I'm thinking an easy solution might be to create a foreground graphic for each tile, and just draw it on tiles that need it (e.g. when player or highlight is in a hex). But I'll save that polish for later.

New Inventory Screen and Items
I also have a few shots of new items and the new inventory screen to show. First off, you'll notice I went with the third layout mentioned in my previous post.

New inventory UI with new items.

Thanks to everyone for the input and support. I was a little overwhelmed, and your comments helped guide me to a solid solution. Most importantly, you reminded me that good, agile development means taking baby steps. I was trying to design the perfect system on paper, and forgetting that it'd be further defined by trying it out in-situ.

So what we have here is a paper doll UI with storage spaces. Simply drag and drop any item to an applicable slot, and it gets installed in that slot. Dragging a container to a slot creates a storage box alongside that slot for holding items. Drag any item into a box to store it. Only one item per slot now, but there are a hefty number of slots to play with. (e.g. one per foot, one per forearm, face, head, eyes, etc.)

In the above picture, the player has two plastic bags in his hands. Note: There are four hands in the paper doll. The attached ones are for gloves, the unattached ones (behind the bags) are for holding items. In the left bag, there's a wadded-up, brown t-shirt. He's wearing a hospital gown, a hospital wrist strap, and a talisman (more on the reasons for this starting loadout in a future post).

Dragging a shoe to a foot slot.

When dragging an item around, it gets highlighted blue when over a valid slot, and red otherwise. Valid slots that are empty are highlighted white. I've made equipped items semi-transparent during dragging in case slots are obsured (such as the legs under the gown). Here, I'm dragging a boot to the empty foot slot (boot image gets mirrored when installed, if necessary).

Wearing a t-shirt.

One final feature is the concept of equipped vs. stored items. Earlier, we saw this brown t-shirt crumpled into a plastic bag. Since inventory management was such a big deal in this game, I wanted to make sure items took an appropriate amount of space when stored. And since I had a paper doll, that meant one image for equipped, and one for stored. Containers will collapse when stored too, unless they have items in them.

I've started working on the encounter system now. I'm actually trying to make the initial 5-minutes playable, so that means I need some way of communicating a quick backstory, as well as negotiating an encounter. Not out of the UI woods yet!

The Bag Lady Experience

So I think I may be going around the bend on inventory and crafting. I have this tingling feeling, and I can't tell if it's spidey sense warning me against over-ambition for my game, or if it's just some healthy fear of the unknown.

A few posts ago, I unveiled my first draft of inventory management. And as usability for inventory management often goes, it hobbled around shakily in the wild for a few moments before being torn asunder by a razor-sharp predator. I had Rochelle test it, while I watched over her shoulder (holding my tongue). Let's just say it didn't fare well. Even my own testing showed some extreme tediousness moving things around. And Mitchell's comment only further extinguished any doubt that this was the wrong approach. It was pretty clear version #1 wasn't going to cut it.

Version #1

Which is a shame, since it was really elegant on the coding side: simple and extensible. But, as should've guessed from previous experience, simple and elegant code doesn't necessarily translate into ease-of-use.

So my next draft was going to include a somewhat more graphic UI. Instead of clicking on arrows alongside names of body parts to see the contents of that body part, the user could click on body parts in a silhouette to see items stored there. It looked something like this:

Version #2

I think this was an improvement. In this version, rolling over any body part highlighted it, and clicking on it showed installed items for that body part in the center of the screen. In this mocked-up example, three items can be equipped into the current slot. I guess I figured I'd want to be able to wear three shirts at the same time, to simulate "the bag-lady experience." Alongside each slot is a storage area, that would only appear if an item was installed with storage space.

There were still some flaws, though. As Mitchell pointed out, it's nice to see everything you've got at once, and not have to click on menus to see additional items. In this case, one could (at best) see items on the paper doll, and in the current slot, before clicking. And that's assuming I could find a clever way to show all the items on the paper doll. Just looking at it, there's no way the hands and "HOLD" slots could fit some of the objects I envisioned going there (like a quarterstaff, or a rifle). And showing layered clothing was only going to complicate it further.

The three icons on the left were supposed to be other inventory-related screens one could get to. Dragging any item from the paper doll or center area onto one of those icons moves it to the first available slot in that icon's category. I figured the user could pile stuff into the crafting area, then switch to that screen to craft stuff.

But Mitchell's comment kept nagging at me. Why couldn't I try to show all items equipped and held at once? Why not bend over backwards to make the UI as easy as possible on the user? So I went back to the drawing board, and made version #3.

Version #3

Ok, so now we can see everything the user is carrying at once. Equipped items show up over the silhouette, in place. Any equipped items with storage space enable the storage boxes surrounding the player. I backed-off "the bag-lady experience" and allow only one item per slot now. (Except for necklaces and rings, which have blow-out slots on the top and top-left, respecitvely)

In theory, this makes personal inventory management a breeze. Just drag-and-drop items around to equip or store them. No clicking sub-menus to see each set of items. And now that slots are restricted to one item each, I can actually display items on the paper doll.

But there are still two issues. First of all, this is going to be a bitch to make. There's going to be some special-case code in here, for sure. And the paper doll means extra artwork to make equipped items look good when combined. It's more work, but I think it's worthwhile work. Usability trumps elegant code, in this case.

The second issue is what to do about the other item-related UIs. All down the left-hand side of the screen are icons for other UIs that involve items. From top-to-bottom, they are:

1. Items - The current screen: personal inventory and paper doll.
2. Vehicle - Any vehicle the user has found and equipped (anything from a shopping cart to a pick-up)
3. Crafting - This is to be the screen where the user combines items and skills to craft other items.
4. Respond - This is to be the screen where the user combines items and skills to respond to an encounter.

#1 is solved in the above image. #2 can probably work a lot like #1. it just wouldn't fit on the same screen because I wanted the vehicle to potentially have a ton of storage space. It's unfortunate the two can't co-exist simultaneously on-screen, but I think I can manage the next best thing by having the screens flip when the user rolls over each screen icon with the mouse. In this design, the user could potentially grab an item from the backpack on the above screen, and drag it over to the "Vehicle" icon. The screen would auto-flip to the vehicle storage area, where the user could drag into the storage space. Alternatively, the user could just drop the item onto the "Vehicle" icon and the game would try to auto-add it to the vehicle.

It's #s 3 and 4 that scare me. Honestly, I spent half a day working on mockups of #3, and I'm still not satisfied. I looked at other crafting UIs out there too. I just haven't come up with anything that seems both intuitive and easy-to-use. Here's a rough mockup so far:

Crafting UI Mockup

As you can see, it's extremely busy and clunky looking. I envisioned the user dropping items in the storage area on the left side (much like how the vehicle would work, above), toggling one or more pertinent skills in the middle list, and then clicking craft to create an item in the right storage area.

The trouble is that I think this'll be really tedious to use. I want this UI to support two types of behavior. First of all, I want the user to feel encouraged to experiment with item and skill combos to make stuff. That means lots of trial and error. Getting items into this screen is probably already too clunky to begin with, without having to do it dozens of times with different combos to see what results.

Secondly, I want the user to be able to quickly use already-discovered recipes. Somehow, the user should be able to browse recipes they already know, see whether they have the requisite materials, and craft one or more copies.

I'm not sure what to do. My brain became pretty burned-out after mocking up both the "Items" screen and this much of the "Crafting" screen. I needed a break from the UI design, so I decided to try and implement the "Items" screen as-designed, and come back to crafting later. I think "Items" is about as easy on the user as it can get, so it's probably safe to work on. The only thing better would be to integrate the other screens into the "Items" screen so the user didn't have to page-flip. But there's just not enough real-estate to do that.

Has anyone seen a crafting screen layout that might work here? Maybe I've made incorrect assumptions on the required inputs? I assumed skills would be a fun thing to include in recipes, since they act almost like verbs on the nouns of the item ingredients. But is that over-engineering? Do the skills add value? Maybe skills should be passive, so the user creates things with items only, and their skills determine the success rate or quality of the output? Maybe the user doesn't drag items from other screens into this one, but instead just sees all items they own here, and picks them from this screen?

Like I said. My brain was on "E" after hours on this problem, so I'll need to recharge before revisiting it. If anyone has insight, though, I'm all ears!

Trojan vs Indie

For the record, if one is ever contemplating how much time to set aside for technical issues in a 1-man operation, a full OS reinstall is a 1.5 man-day project.

Windows Defender found and removed a trojan a few days ago. It raised some concern for me, as I'm a pretty careful web user. But, WD claimed to remove it successfully, and my ESET online scan showed no infections. I figured I got lucky, and moved on.

Friday morning, WD found it again. The same trojan (Hiloti D, for reference). Now I was concerned. I went into paranoid mode, and started researching. WD claimed to succeed, and ESET seemed to agree. But I was suspicious. I realized I didn't have MS Security Essentials yet, so installed it. But quick scan came up empty.

However, I was starting to catch the subtle symptoms in action. That was it. I needed to do something, and I was considering the worst case: the trojan had compromised my OS, and potentially transmitted password info I typed into my browser. And it had a few days head-start. I ultimately decided on an OS reinstall, and changing all my passwords.

Friday and Saturday were coincidentally my weekend, as Rochelle and I decided on that arrangement not a day before. It gave us one weekday where I was off to run errands in town, if necessary, and one weekend day. One half-day of errands later, it was time to start the reinstall.

The reinstall went smoothly. Both times. Why install the second time? Because Windows Update was not-so-smooth. #20 of 90 got stuck for over an hour, and force-rebooting must've killed the restore points. Fortunately, that was #20 and not #90. So all told, backups, Windows 7 and 90 updates took most of Friday. And SP1, password changes, and reinstalling software took a good chunk of Saturday. Today, I still have a few essential tools to install before I can resume work, but the big stuff is out of the way.

So there you have it. A solo operation offlined for 1.5 days. It'll end up costing me a little production time today, and a lot of lost relaxation time over my weekend. The up-side?

• I have a fresh Windows 7 install, which I was probably due for.
• I have a better awareness of security issues on my setup, and have patched some of those holes.
• I finally broke down and bought a NAS and some 2TB HDDs upon which we can store data we don't want lost in a PC crash. (Which also gives me enough space to write restore system images, if necessary)
• I read some interesting articles, and got acquainted with newgrounds.com while waiting for Windows Update to finish!

Inventory and Maps

Well, our trip to Eureka was a success. We had a good number of nights by the fire, a few days out on the boat at the lake, and tons of fireworks! I was a dork for not bringing my audio recorder, as the wilderness noises out there would've been handy to have. The crickets sound different, there were crackling campfires, and even distant elk grunts. And the semicircle of campers were a bit of inspiration for post-apocalyptic makeshift communities (though way more luxurious).

Back on the homefront, I managed to squeeze quite a bit of work into NEO Scavenger in the limited workdays since the 30th.

Inventory Screen
When we last left the inventory screen, one could see equipped items in the various slots by pressing "I" on the keyboard. Clicking on the arrows at the center of the screen allowed the player to toggle which equipment slot was displayed on each half of the screen.

Fast forward a few workdays, and here's what we have:

Inventory screen showing local hex items and a plastic bag in the player's right hand.

One of the new features in the inventory screen is a category for showing the items on the ground in this hex. This is probably going to expand to include items the player scavenges for, but for now, it shows randomly generated loot. Each hex has a probability for finding certain items, and in this case, we found a few cans of soup. I noticed I was constantly opening the ground contents as I moved around the map, so I made that category open by default when the screen opens.

The right side of the screen is showing the player's right hand slot, which currently has a plastic shopping bag equipped. Equipping an item is just a matter of dragging the item over an empty slot graphic for a category, like so:

Equipping a plastic bag in the right hand.

If an equipped item can act as a container, they will have a dark box below them, representing their storage space. The ground always has available storage space, and the bag has room for about 6 cans of soup.

The idea is that items will have differing sizes, and differing storage box sizes, to limit to how many items one can fit in a container. Items cannot overlap in a container, so the player must arrange the items via drag and drop to fit if they want to maximize carrying capacity.

Containers that are moved around maintain their contents, and can contain other containers. To avoid infinite nested containers, I want to make containers use at least as much storage space as they provide.


To make life a bit easier for the user, I added a few helpers to the inventory screen. First of all, the drag and drop highlights the object to let the user know if it will fit here or not. Red means it won't fit in it's current position, blue means it will. I also added a snapping/padding algorithm to be a bit more forgiving on the player, so placement doesn't have to be pixel perfect. The game will just snap an item to the nearest space where it will fit, within a certain threshold.

Dragging the can to a location it won't fit (left) vs. a place it will (right).

I also added doubleclick support to the items, so the user can just doubleclick an item to move it. The behavior right now tries to move the item from it's current side of the screen to the opposite side's slot or container, if available. If it can fit, it finds the first available space and puts it there (preferring the equipment slot if empty, otherwise the storage space). If it cannot fit, it does nothing. I thought this would be important because constant mousing across the screen can be tiring, and I always appreciated it when games like Fallout allowed for doubleclick transfers of items. I will likely add a "transfer all" mechanism in there too.
I'm still not sold on the UI for the categories, but I haven't figured out an improvement yet. I did toy with the idea of a human body as a category selector, but haven't hooked it up yet.

Human silhouette as selector for equipment slots.

I'm not sure this makes it much easier to use, though it might slightly improve user recognition of slots. It'll require more testing and experimenting.

Eating and Time Passage
I also made a slight change to the game after trying out the scavenging of soup cans. Originally, a turn lasted 4 hours, and the player could move 4 spaces per turn (barring hills or forests). With this timescale, I was getting hot/cold/hungry very quickly, and hardly had time to deal with it. Also, the player character ate whatever he had on hand automatically when he became hungry. Overall, this left me feeling a bit overwhelmed by the amount of "surviving" I had to do each turn, not to mention the rapid day/night/weather changes.

So I decided to change the turn length to 1 hour, and make eating a manual task. Now, weather changes less drastically per-turn, and the player can choose when to eat vs. ration. And health conditions take longer to set in, allowing for more exploration time between crises.

So far, I like the new pacing. After tinkering around with it a bit, it felt more like a game than before. One thing which did seem to work as-designed was the overheating mechanic. My character was starting to suffer from heat exhaustion, and it started raining. Immediately, the player returned to normal. And on another occasion, I was able to postpone heat exhaustion by taking off his t-shirt. A few times, I died of heat exhaustion as well, in sustained 105F+ temperatures.



Maps!
Up until now, the game has used perlin noise to generate smallish (36x72) hex maps. Anything larger tended to bog down the game and ultimately crash due to timeout. Since I wanted to stage my game in a post-apocalyptic Michigan, I needed a way to edit maps. So I decided to repurpose my random-image code to support loading a hand-painted map of Michigan.

Michigan, in 422x489 pixel, 6-color glory.

The map is 422x489 pixels, with one pixel corresponding to a hex. Each color is a different terrain type. It lacks a lot of the features I would like to add, but has enough to equal the random maps I've been using.

But first, some optimization was in order. As said before, I was having trouble much above the realm of 70x30 pixels. There was no way 400x500 would fly as-is. So I broke up my map-parsing into manageable chunks, and called a chunk each game cycle until it was done. Then, I dispatched an event to signal the game-start code. This, along with a few bug fixes it revealed, allowed me to load much larger maps.

Second, my map needed some special treatment. Careful readers will note that hex maps have every other row offset by half a column width, so using a square-grid bitmap to define a hex map may cause weirdness. Well, it did. My rivers looked like stitches in-game, with land bridges every other column. Turns out, I had to paint my rivers using a 1x2 pixel brush, rather than 1x1, to avoid broken rivers in-game.

The outcome was actually kinda fun to play with. For the first time, I could pick out where I was in the world by features, and sort of knew my way around. And the vast distances allowed me to tinker with the eating and overheating mechanics a bit more.

Still to come, per-hex shelter from the heat, additional types of items to pick-up, new hex features like ruins. This next week may be a nice artistic breather from the code work I've been up to lately. Till next time!

Going Rogue Going Dark for a Week

Off to Eureka, MT for a short vacation. Perhaps some genius will strike me while there?

See you next week!

Player Inventory, Hypothermia, and More!

Player Inventory
I finally started tackling one of the systems I was dreading: Player Inventory. It's a system I'm anxious to play with in-game, but it requires so many subsystems to be in place that it was a bit daunting to start developing. But in the spirit of Agile Project Management, I decided to tackle the big risk right now. It's one of the more crucial gameplay mechanics, so it makes sense to deal with it sooner than later.

So far, the player is able to enter the inventory screen by pressing "I." While it shares some traditional RPG behavior, I do deviate a little from the norm. In it, the player is presented with a list of categories such as "left hand," "right hand," "back," and "torso." Each of these represents a place to carry or equip stuff. Here's a peek:

Player Inventory showing the contents of their left hand and torso slots.

In this screenshot, the left side shows the item in the player's left hand. The right side shows the item on the player's torso. In this case, we see the player is holding a can of soup, and wearing a t-shirt. The center shows a list of other areas that can have items equipped. The player can change the left or right display areas to show any of the categories by clicking the appropriate arrow alongside each category. Yellow arrows show the currently selected category for each side.

I haven't yet added it, but the bottom of each side of the screen is meant to show available storage space in the object depicted at the top. For example, the shirt may have pockets, which would show up as an empty set of boxes below the t-shirt image. If the pockets had anything in them, they would appear in the boxes below the t-shirt.

Once this system is complete, the player would be able to drag items from one side to the other. In this case, perhaps the player wanted to free up his left hand, so they could drag the soup can from the hand into the (not yet depicted) pocket space below the shirt. A more traditional example might be to equip a backpack in the "Back" category, and store lots of stuff in the ample space it has. And to equip an object, the player would drag an item from one side into the "socket" of an empty category.

Here, the right foot has nothing equipped yet.

Right now, we only see parts of the body in the list of categories. But I would also like to include an "On the Ground" option, which allows the player to drop and pick up items in the current hex. I will probably also dynamically add a "Trader" category when the player is bartering with an NPC. Crafting may also factor into this UI, but I'd like to get it inserted into the gameplay loop and tested before I build much more into it.

Will this be intuitive, or will people hit it like a brick wall? That's the question I'd like to answer through testing before settling on this approach.

Class Naming Tidiness and FlashDevelop Refactor
As the project grows more complex, class names are starting to become an issue. I'm already starting to think some class names are going to need rewriting, or perhaps even grouping and subfolders. Things like my GUI-related classes seem like a logical set to group either in a folder or with a "GUI" prefix.

I haven't sweated it yet, as the classes are still few enough to keep track of, and I thought it'd be a cinch to just refactor the class names in FlashDevelop. That stopped being true Friday, when I tried to refactor a classname due to a class's change in purpose. Turns out, FlashDevelop doesn't yet (v3.3.4) support class refactoring. It's slated for the next release, but that was a bit of a shock. It's probably not a huge deal, as search and replace should probably cover it. Still, I was surprised to discover that feature missing.

Hypothermia and Hyperthermia
NEO Scavenger now supports hypothermia and hyperthermia (heat exhaustion). The player has a normal range of temperatures wherein they maintain a healthy core temperature without clothes. If the player is in a temperature cooler than that range, their core temperature starts to drop, until symptoms of hypothermia start to appear, and eventual death by freezing. Similarly, above that temperature range, heat exhaustion, stroke, and eventually organ failure, occur.

It's not terribly sophisticated yet, as the symptoms are primarily descriptive. However, the really severe cases do cause a reduction in movement rate. And player conditions are built to support penalties to any player attribute down the road.

Clothing
I also added rudimentary clothing to the game. The player can endure wider (or shifted) temperature ranges depending on which clothing is equipped, and each clothing item also changes the rate of core temperature loss/gain when outside that range. So far, my limited testing of a t-shirt-wearing player in winter and summer seem to work. As this ties into the inventory system above, full testing will have to wait until they're both working in concert.

FlxGroup Revive Override
One minor task I tackled was overriding the revive() method on FlxGroup in flixel. As of the May 20, 2011 revision, FlxGroup's revive() defaulted to FlxBasic, and would therefore skip all member sprites that were added to it. Since some of my GUIs use the FlxGroup and need to switch on and off, I added an overridden revive() which behaves a lot like the override for kill().

I only mention this in case any other flixel devs are out there and plan to use kill/revive on groups.

Webserver SVN
Finally, I've used SVN to check-out php and image files into my localhost's webserver. Until now, I had been using the old copy+paste after each edit to update my webserver. But with SVN, that was made easier via check-out.

Back in the Saddle Again

Porting to flixel: Complete
It's been almost a week since adopting flixel, but it's paying off. It took only a day or two to convert most code to flixel-friendly FlxSprites and FlxGroups, and it was a huge win already. Adopting flixel meant I had a game state structure already built, as well as many helpful functions for input handling, graphics, and audio. The one shortcoming was the hexmap. flixel supports square-grid tilemaps out of the box. But hex grids are another story.

After trying to make a hexmap out of multi-layered FlxSprites/FlxGroups, and seeing the resulting framerate drop, I decided to try my hand at extending flixel's tilemap classes to support a hex grid. That was a few days in itself, but the results are astounding. Performance is back up to 30 solid fps, regardless of scrolling or any other activity. I had to make a few architectural changes to the hexes, including pre-baking the graphics for each state, rather than layering dimmed and blacked-out states overtop. That approach is probably more sensible, though. It makes sense to do the (already minimal) graphics lifting up front, and save the processor time for things the artist can't do.

With that in place, I'm back to adding features from the backlog. Only much faster now!

Player Status
As described in earlier posts, part of the game involves surviving in the post-apocalyptic wilderness with nothing but raw character abilities, scavenged items, and the player's wits. With map navigation, visibility, and weather in place, it seems like a good time to add one of the game's obstacles/antagonists: metabolism.

The player now has hunger and sleep status fields. Each time a turn ends, time advances a few hours, and the player's character gets hungrier and more tired. Hunger gives way to weakness, and if unchecked long enough, the player can now die.

Game Over - Player died of: Starvation

Sleep is also going to be important, but for now, is a text-based descriptor-only. These two conditions are the first in a series of conditions, including exposure and disease, which the player must monitor and address to stay alive.

Item Database Prototyped
As part of the above player status work, I also prototyped an item database so I could test food items. Right now, the database is little more than an item table with an entry in it flagged as food category. If the player has an item in their inventory that corresponds to the food category, they eat it at the end of their turn if they are hungry or worse. The food item's mass is used to calculate how much hunger is satisfied, the item is removed, and the player's hunger status is updated for the next turn.

As part of this item database prototype, I've also created several fields to address the crafting component of the game, to be built later. Items have properties such as group info, for use in algorithms like the food check above, as well as for use in crafting substitutions. Items also have weight and volume information, for the inventory management activity mentioned in the design doc. Finally, items have properties which help describe the durability of each item. Some of these are related to crafting, as durability may suffer if the crafter uses poor substitutions. Others are part of a nice-to-have feature list, which includes items perishing in heat, freezing in the cold, or being affected by water (heavier to carry, reduces body heat, etc.).

New Hex Art
One nice thing about being a jack-of-all-trades solo dev is that one can switch to a completely different discipline for a break, and still be productive. After days spent monkeying around in flixel's guts, I needed a breather from code. So I picked up my Wacom stylus, and tried my hand at pixel art.

Up until now, my hexes have been top-down, in a simple two-tone line-art style. Much like the old wargaming and TSR Greyhawk maps. However, I've seen some really nice pixel art hexes out there, particularly the isometric ones, and I wondered if I should go that route. Here's what I came up with:

Upon first glance, it's not quite the effect I was hoping for. Ignoring the out-of-date highlight and person graphics, the hexes look too muddled, and possibly too big. Both the Uniwar and Greyhawk hexes linked above seem more deliberate, beefy, and satisfying. So next revision may be scaled down a bit. And possibly more cartoonish.

The isometric effect is nice, though. I kinda like the way the hex art overlaps. It might end up being more headache than it's worth, in the end, but it warrants some more tinkering.

SVN
I finally started using version control today. In the past, the project was simple enough to just periodically copy into a backup folder. But it's quickly growing branches with vastly different code (flixel vs. no, iso hex art vs. top-down), and I'm not far from losing track of which version is where. Not to mention, I'm getting more fearful of major code revisions each time, in case I need to revert.

So enough of that. SVN it is. FlashDevelop integrates with it easily, and it's free, so no excuses!

Whew! That's a whole morning spent documenting/blogging, and setting up SVN branches. There's still a few hours left, so let's see if we can get some more work done. Cold weather exposure is probably next, maybe heat exhaustion, and adding movement penalties for said conditions. I may also have to tackle basic inventory soon.