Back on the homefront, I managed to squeeze quite a bit of work into NEO Scavenger in the limited workdays since the 30th.
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.|
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'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.|
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.
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.|
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!