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. |
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.
