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.
