Monday, October 24, 2011

Detroit Megacity is born!

After a few days of painstaking pixel-wrangling, Detroit Megacity is finally finished. Behold!

Detroit Megacity, and the shantytown sprawl around it.
I've been struggling with the art for that tile set a while now. I even had to stop and put it aside at one point, to come back later and try again. Getting isometric wall tiles in a hex grid to line up was a bit of a pain, and the amount of detail needed to populate the city was higher than one would expect for such a small collection of tiles. But Detroit Megacity (the DMC) plays a pretty central role in NEO Scavenger, so I wanted it to be something special.

The DMC is meant to be the hub for NEO Scavenger. When not out in the wastelands scavenging for treasure, the player can trade hard-earned loot for a hot meal, safe rest, and replenished equipment for the next expedition. There may also be some clues hinting at the player's origins hidden within the city's sprawling reaches.

The DMC also fulfills a larger, peripheral role in the game. It stands as a stark counterpoint to the ruined, ravaged wastelands, and an example of what's possible. The world of NEO Scavenger includes sharply contrasted civilization and badlands, high technology and supernatural horrors, and mankind struggling to reclaim his once stable footing in a world which has spurned him.

Finally, the DMC is at least one part guilty pleasure. Having grown up with truly inspiring dystopian megacities such as Blade Runner's Los Angeles, Akira's Neo-Tokyo, Shadowrun's Seattle, and Rifts's Chi-Town, I wanted one of my very own to play with.

Usability Upgrades

Outside of having fun with art, I've also been doing my homework, so to speak. The UI still needs lots of attention to prevent new users from giving up in frustration, so I've been hard at work refining that. Having some folks test the game has revealed many shortcomings in the UI, both those that I didn't realize were there, and those I was in denial about.

Above, you can see the status bars have now further evolved to change size as well as color. Now, as they grow more menacing in color, they shrink in size, to further indicate that a stat is running low. What's more, it's now easier to tell relative values, so "how green is my thirst" is less of a question.

I also added clickable buttons for player condition and map screens. There was no excuse not to have them, I just hadn't gotten around to it until now.

Edge-scrolling the map with the mouse was a bit of a failure. Even users who asked for it quickly changed their mind. It seemed to scroll by accident a lot, and it's a lot of work to scroll when one actually wants to. Still, some sort of mouse-driven scrolling is probably a good thing. I've always liked Sim City's style of scrolling (click a spot, and drag to one side or the other to start scrolling the map, kinda like a "soft" joystick). So perhaps I'll have to try something more along those lines later.

And then, there was the big one: the inventory screen.

Inventory UI Polish

I finally did it. I combined the ground and personal inventory screens. I think just about every tester asked for it at one point or another, as dragging from one screen to another was tedious. I had some (likely poor) reasons for wanting them separate, but I finally gave in and combined them.

New combined ground and personal inventory screen.

I gave up the overzealous 8 amulet and 10 ring slots, and shifted a few things around, and now it all fits on one screen.

I also got rid of separate slots for socks, forearms, eyes, ears, and face, and merged them into feet, torso, and head slots, respectively. Originally, I wanted the player to have items for these slots (especially headgear such as sunglasses, helmets, and bandannas), but it was starting to look like that old scheme would be too tedious for the user. Also, the crafting of layered clothes was a bear for what little fun it offered.

So now, players can just drag and drop items onto the paper doll, and it'll "just work." T-shirts will drop over the hospital gown, or vice versa, and still look correct. Dropping a hoodie onto the torso covers them both. (Slots like the torso allow a finite number of items at each layer depth, and they draw-sort according to that depth.) Dropping an item onto a filled slot swaps those items. Dropping an item onto a container inside another container fills the container. Dropping onto a rollover button (right side of screen) tries to fit the item as best it can.

Also, the old shift+click behavior is now default click behavior. If you click an item, it "just goes" to the first appropriate and available slot, or else a container. If it can't fit, it starts dragging. If the user wants to fine tune where it goes, they now shift+click and drag.

Oh, and WASD and arrow keys now rotate dragged inventory items now, for better inventory Tetris.

Bandit Loot, Wounds, and Degradation

I also added a few new features. Bandits now drop loot, so that engaging them is more rewarding for the risk. Wounds are now full-on player conditions, which means they can affect player performance, and get worse over time if untreated. And items can now degrade.

Item degradation was something I had planned from the start, but felt was optional until recently. It didn't seem right in a post apocalyptic setting to find a pair of bluejeans in the trash, and never have to worry about pants again. They'd surely go threadbare over time. New shoes and fresh socks too should be treasures. Lighters should go empty after enough usage, and campfires should go out over time.

Eventually, the reasons to add item degradation piled up, and I got it over with. Items can now degrade based on usage, time, or equipped time, as well as lose charges per use. A lighter is an example of an item that loses charges when used, but can also degrade until it breaks. It might discharge and recharge many times before it degrades, but it has a limited lifespan based on number of times it's used.

Shoes are an example of an item that degrades per unit time while equipped. Meat cleavers are an example of an item that degrades per use. And campfires are an example of an item that degrades over time. When items break, some will turn into new items (t-shirt becomes rags, campfire becomes ashes). Others simply disappear (e.g. plastic bags).

If I do end up adding item repairing in this iteration, it will likely be via combining skills and items in the crafting window (e.g. sewing plus dental floss plus one or more pairs of pants to repair).

Encounter Responses

There's still one more change in the works, and that's how encounter responses are dealt with. I don't think many testers realized they could use skills and inventory items to respond to encounters, since they're on other screens. I had intended for the player to be able to use anything at his disposal to solve an encounter. I thought it'd be fun if the player could think outside the box, and try something that wasn't presented as an obvious option.

However, I think that's going to be hard to teach new players. It also means I need to create many, many permutations of responses, and players have to trial and error to get the response they want.

As an alternative, I'm going to try and pre-fill the response area with items the player could potentially use. If they have the right items or skills for an optional response, it'll be right there for them to use. It means there are less surprises, unfortunately, but also less work for the player. Also, if there are fewer possible responses to each encounter, I can probably make them more meaningful. There should still be some replayability if the player chooses a character with different skills and items the next playthrough.

Tuesday, October 11, 2011

Roguelike vs. Civ-like

I had the opportunity to playtest the game on some new folks this past weekend, and it revealed some very useful info on the design.

Overall, I'd say the test went pretty well. The players' feedback suggested there's a decent gameplay loop in there. It's gonna need some polish (a lot, actually), but I'd rather have that problem than the other way around.

Moves Per Turn
One of the bigger points of confusion involved the "movements per turn" and "end turn" mechanics. I think most everyone figured out that they have a limited number of moves per turn. But where things fell apart was how to replenish those movement points. It appears nearly everyone assumed the "Sleep" button was meant to rest and restore those points, rather than the "End Turn" button further down. And as a result, people were dying left and right in their sleep from dogmen and bandit attacks.

The few that did use the "End Turn" button mentioned that it could get tedious pressing it all the time. Fortunately, they had a suggestion: what if the game automatically ended the turn for you? Or better yet, what if each move was a turn?

That sounded familiar. Practically every roguelike out there operates on the same principle, not to mention many of the familiar board games. It meant deviating somewhat from other staples in the strategy and rpg genres, though. Namely, I was trying to emulate the early exploration mechanics in Civilization. Fallout and Silent Storm are both sources of inspiration too. And all of those games utilize "moves per turn" or some similar mechanic.

What should I do? I haven't decided yet, but I have mocked up the roguelike movement for the time-being. I've had a lot of time to test the Civ-like schema. Now it is time to give roguelike a fair shake.

Post Apocalyptic Monsters, Tracking, and Weapons
One of the other major changes I've made is to the wandering monsters. The game now has a raft of wandering creatures added randomly to the map at game start. All creatures, including the player, leave behind tracks where they walk. These tracks are "hot" where the creature stands, and gradually cool after the creature has left. Creatures will follow tracks when they can, and otherwise seek out loot.

Tracking a creature.
When a creature is adjacent to another creature, they take turns attacking until one wins. This includes the player, who can now attack an adjoining creature by clicking on him. Once that was in place, it wasn't long before the first in-game weapons followed.

Currently, the most powerful loadout in NEO Scavenger: dual-wielding the rusty meat cleaver and the monkey wrench.
UI Work-Over
The game UI has undergone some refinement again. Both in preparation for playtesting, and as a result of it. You may have noticed that new status bars no longer have banded colors and needles representing state. Henry pointed out that it was tedious to keep looking over there for changes, and that it could just show a solid color to get the same point across. It was a great suggestion, and simplified the UI considerably.

New loot icons, and player sprite!
The map screen also has some changes. Now, only certain hexes have loot, and that is indicated by a loot icon. The icon is gold when it is "new" loot, and gray when the player has visited that loot before. I've also finally added an appropriate player icon! He's the dude with the green outline, coincidentally dressed the same as the previous inventory picture. I don't think I'm going to make the player sprite change with equipment, due to time constraints. But the iso player sprite was long overdue, and it even makes the player easier to find!

Playtesting also indicated that I needed more obvious controls. Buttons for inventory, clicking current hex to open loot screen, arrow-key and mouse-based map scrolling, even some conflicts with accelerator keys on Macs. It's all extremely useful feedback, and I'm glad for it.

The List Goes On
And there's more. Too much to list here without getting exhaustively dry. The summary is that the game still needs some work, but is starting to show its colors. Playtesting, even with a small number of people, has been a tremendous help. And I think I can make this into a complete game soon. Maybe within the next month.

Though, I'm starting to wonder if I've made something heavier than a Flash portal game. I feel like I'm in a weird territory between a heavy Flash portal game and a light premium/downloadable game. I still think a free option is necessary for increasing awareness, but now I'm starting to wonder if I've created a demo for a premium game (a la Armageddon Empires, or Weird Worlds: Return to Infinite Space). That'd be fine, except the premium version is unfinished.

I guess it's good that my business model can adapt even this late, but the uncertainty is a little unsettling.