Post Apocalyptic Loot and Cholera

It's been another busy couple weeks (sorry for not posting last week!). A lot of the recent work has been adding post apocalyptic loot and design iteration. And frankly, it's been a blast.

Loot in the Apocalypse
I'm especially enjoying the loot. I caught myself playing my game instead of testing it on several occasions, and I think much of it has to do with loot being more fun now.

Phat lootz!

As seen above, now you can find any of the following enticing loot:

• Plastic shopping bags
• Empty plastic water bottles
• Full(!) plastic water bottles
• Packets of stale saltine crackers
• Soup cans (some with condensed soup inside!)
• A handful of twigs (used in making fires)
• A yellow disposable lighter
• Binoculars
• A fashionable S.T.A.L.K.E.R.-like hoodie
• Hikers
• Water purification pill bottle

Combining the lighter, twigs, and a stick in the crafting screen will create a campfire now (which provides warmth in the current tile). Dragging any of the food or water items to the "Use" button in the lower right makes the player consume that item. In the case of food and water, they affect the hunger and thirst bars on the left. And combining the water purification pills with "contaminated" water produces "purified" water.

"Contaminated water?" you ask? That's right! Water comes in two flavors: purified and contaminated. The former can be consumed with no ill effects. The latter gives you...cholera!

Oregon Trail's lasting impact on our generation.

Cholera
One thing I wanted to include was the Oregon Trail style afflictions. After all, when wandering the wastelands of post apocalyptic North America, it's not all fun and games. Cholera is the first of several diseases I plan to add.

Diseases like cholera cause two things to happen. First, they have in-game symptoms. Cholera causes things like diarrhea in humans, which translates into increased dehydration per turn. It also means wandering monsters are more likely to track you down (though why they would choose to seek you out based on that scent is an exercise left to the reader's imagination).

Secondly, cholera progresses over time to worse stages. There's a chance each disease will progress after some time has passed to a new stage. Each stage has progressively worse symptoms, some fatal.

The counter to diseases in the game will likely be in the form of medical supplies. Antibiotics might prevent the disease from progressing, as will certain more unique loot. However, it is still up to the player to mitigate other symptoms, such as dehydration.

Art and UI Iteration
You might also notice that the art style evolved slightly. Now the 3-tone pixel art has been replaced with 16-ish color pixel art. I found that I was making nicer loot pics with Photoshop's pencil tool at 1x1 pixel size with opaqueness linked to stylus pressure. It meant breaking with old-school sprite technique a bit, but I think the result looks nicer while still maintaining a bit of the retro flavor.

The UI has also undergone a facelift. The inventory screens no longer obscure the player status bars on the left, nor the message box at the bottom. It was annoying to equip items and have to leave the inventory screen to see if they changed anything in the player status. So now, the player can just see in real-time.

The inventory buttons (first image, on the right) also moved around a bit, so that they reside in places that make sense for how and when they are used.

I also upgraded the hex highlighter to turn orange when you have an inaccessible hex selected. Previously, there was no feedback when moving the cursor over an invalid hex.

"Can't get there from here."

Game Structure
The overall game structure got some love as well. For one, I finished the critical path encounters. It is now possible to navigate the entire game's storyline. It's rough and skeletal, just the basics to step through the clues and such. But it helped solidify the game in my mind. It also led to an unusual discovery.

After playing around with the gigantic, to-scale hex map of Michigan, I started second-guessing my design. The way the player was finding loot, there was really no game to it at all. They just walk from hex to hex, and click the scavenge button. The frequency of suburban and urban ruin tiles meant they never had to go far to find food and supplies.

The more I thought it over, the more I realized that maybe my simulation wasn't going to be fun. Maybe I needed to sacrifice some realism to make room for fun?

As an experiment, I replaced the scale map of Michigan with a much smaller one. I took out all water tiles and rivers. And I made the entire map wilderness. Then, I added a ruins tile at about 5-10% frequency. Finally, I added 20 randomly wandering monsters to the map.

It was a huge improvement. I enjoyed the more sparse city placement, being more selective with my scavenging time, and dodging the monsters. Does this mean I scrap the storyline? Maybe. Does this mean scrapping the scale map of Michigan? Very likely.

For now, I'd like to make the wandering monsters more interactive, and add a few more item and obstacles. And I really need to find something more compelling as a scavenging mechanic than clicking the "Scavenge" button. It's serviceable, but I bet it could be more fun.

NEO Scavenger: Minimum Viable Product?

It's been almost a month since I've mentioned anything about NEO Scavenger, what with the indie survey and all. But rest assured, the development on the game has been moving steadily along. I think I'm at minimum viable feature set now. I'm starting to put new features into a "version 2" category, as this is already growing quite complex (and slightly beyond my original schedule). From now on, I'm focusing more on content, and getting this wrapped-up for closed playtesting.

Here's the recap of the last batch of features.

New Start-up Sequence
First of all, the game now has a title screen and menu. It's a placeholder for now, but I decided it was time I started thinking about how this game is going to be presented to the player, and the game states that implies. Fortunately, Flixel has a nice state system already built-in (one of the reasons I chose to switch to Flixel). So setting this up took almost no time at all.

The title screen I'm using for now.

It's nothing spectacular yet. I didn't want to spend too much time on art/layout until I was sure what I wanted, so for now, I took a cue from Canabalt and kept it to a quick-draw pixelated silhouette and text. It may become something more complex at a later date, but for now, an homage works.

Skills, Quotes, and Fade to Black
When the player clicks "Play," they're immediately taken to a skills/abilities selection page. Here, they can choose what skills their character will have to use in surviving the wastelands.

Skill selection page, v2

While this screen existed before, it's undergone a slight revision. Namely, there are now disadvantage slots available. Each of the eye-patch icons in the lower left represent a slot for a disadvantage. Players can choose any disadvantage they want, up to four. Why would a player choose a disadvantage? Well, similar to GURPS and Fallout's S.P.E.C.I.A.L., I wanted disadvantages to allow for advantages beyond what a normal character can take. Willing to be myopic? Great! That gives you room for a few extra skills or abilities!

Extra skill/ability space granted for taking a disadvantage.

I enjoyed choosing handicaps to grant more room for benefits, and allow for greater customization of one's character. Currently, there is no reason to take a disadvantage, as the skill space is just enough to take all available skills at game start. However, I want to create additional skills, abilities, and disadvantages, so this will become a more meaninfgul choice in the future.

The above all happens while the game is loading the map. Map-loading can take a few seconds on my dev machine, and longer on older machines. In case the character creation step is completed before the game has finished loading, the user will see quotes that are relevant to the game universe. I want to use every available space to paint more depth in my game universe, and this is one such case.

Main Game UI
The main game UI has had a lot of work done as well. It's now possible to visually track one's character status via some colored status bars in the top left. As time passes in the game, the needles in these bars slide to show how the character is holding up (e.g. getting colder/hotter, more hungry, more tired). Each color represents a stage of hunger, fatigue, hypothermia, etc. As the needle crosses into gradually more red stages, penalties accumulate.

New in-game UI, including status bars and message window.

I think this pushed the game more towards "game-like" and further from "frustrating simulation." Previously, it was hard to gauge the current status of the player, and what was causing it to change. Now, the player can better see how their actions affect character status, including moving, equipping items, eating, etc.

To further enhance player feedback, a running message log was added to the lower left. It calls out status changes in hunger, temperature, etc., as well as when items are found in the current hex.

Scavenging and Sleeping
I also added some more buttons to the top right. "Sleep" causes the player to sleep in the current hex. The map disappears, and only the UI remains. All buttons disappear except a "Wake" button. If the player is in a yellow or orange fatigue state, "Wake" is not automatically successful, because the player is too tired. (A message in the log tells the player this is the case.) If the fatigue is in the green state, the player will automatically wake up.

The scavenge button was added to allow the player to search for items in the current hex. It takes movement points to execute, but may reveal useful items. Currently, that's the only way to find items in the game. A recent playtest with Rochelle revealed that this is probably not ideal, as she expected to find some items automatically as she wandered. I agree with her, and will probably change it so that scavenge finds more "out of the way" loot in a hex, in exchange for the movement points spent searching.

Encounter Improvements
I've spent quite a bit of time upgrading the encounter system to cover the types of encounters I want. One such change is the ability for encounters to spawn creatures on the map.

A dogman is stalking the player.

Each time the player ends their turn, the creatures move. If the creature is visible, the player sees it move one hex per second. Otherwise, it's instantaneous. For now, creatures are fairly simple AIs. If they detect the player in an adjacent hex, they go there. If not, they look for the player's "scent" in any adjacent hexes, and follows the strongest scent they can find. (The player leaves his scent wherever he goes, which fades over time.) Finally, if none of the above are possible, the creature wanders randomly. When a creature and player intersect on a hex, an encounter for that creature happens.

Encounters can also teleport the player to a new hex (handy for quick travel). Encounters can be triggered by date range, location, or hex type, with a certain percent frequency. They can also be unique, so they only fire once, and can trigger only on certain player conditions (or the absence thereof), which is handy for setting game variables like "player angered crime boss."

Encounters can also reveal distant hexes on the map. And to help give the player landmarks to go by, it made sense to give them an overview of the map. So I added a minimap!

Minimap, with labels.

The minimap is fairly crude, but it's a 1-to-1 relationship with the hex map the player sees. It makes navigating a bit easier on the player, as well as development easier for me. The map can be scrolled around in WASD fashion, with the ability to zoom out. Here, we can see the starting cryo facility labeled. Any revealed hexes can have labels as well.

Encounter Editor
Encounters were quickly becoming confusing to author, especially since one encounter can branch into zero or more other encounters based on character responses. So, I decided to take some time to make a visual tool for editing these encounter relationships. It makes encounter authoring much easier on me, and much faster. And since encounters are the meat of the game, I'm already reaping the benefits of an editor.

Try editing THAT in a spreadsheet!

As you can see, encounters are pretty complex flowcharts. That tangled mess at the top was my first game encounter. Seeing that has helped me restructure later game encounters to be easier to follow and maintain.

One thing to note about the editor: it uses fl.controls instead of Flixel. It still lives within a Flixel game state, but I needed quick access to text boxes, scrollbars, and select boxes. So I managed to load a swc with all those controls from Flash CS4, and that helped me get this editor up and running within a week.

Crafting and Item Conditions
I finally bit the bullet and hacked together crafting for the game. I think it was easier than the last time I approached this problem because more of the game is fixed in place now. With less wiggle room, decisions became clearer.

Crafting a campfire.

It's really cut and dry for now. The player adds items to the center "Ingredients" panel like they would any other container. If the ingredients can make something, it appears ghosted on the right along with a "Craft Item" button. Clicking that button removes all ingredients, and un-ghosts the crafted item for player use. Also, the discovered recipe appears in the left scrollbox for use later. Clicking any known recipe on the left tries to fill "Ingredients" with the necessary items from the player inventory or ground.

Regarding the campfire, I wanted the player to be able to place items in a hex to help them weather the night, take shelter, etc. So I made items bestow conditions (buffs) based on where they are stored or equipped. In this case, simply being in the same hex as a campfire warms the player, restoring his body temperature each turn he ends or sleeps there. This goes for clothing as well, which only works when equipped in the correct slots. Finally, I use this in a later encounter to trigger a quest option based on what the character is carrying.

Also, Other Stuff
A raft of other less-visible things have gone in as well. I've finished an overall story arc in Illustrator, and that's helping me keep everything in context for the game. The game architecture was changed from a sloppy if/else block to a more robust game state (within Flixel's "play state"). Now, I can more cleanly keep track of when the AI vs player are doing stuff, when game should be paused due to inventory or map screens, and what order the game should load data.

And of course, there's the game content. New encounters, new items, new hex types...this is going to continue for a bit. I'll also be continually tweaking game rules as I go. I've already started counting hex movement costs against player fatigue as an experiment. Now there's an additional reason to consider which hex to choose when traversing an area.

There's still much to be done, but I think the end is in sight. I have to stay disciplined now, try to keep scope in check, and keep my eye on the release as a real thing. And figure out how to get some wider playtesting done soon!

Indie Developer Survey Results

After putting together the indie survey last week, I feel obligated to both my readers and other respondents to provide a follow-up with the results of that survey. So in today's post, I'm going to do just that.

The Results
For the most part, everyone with a web browser can see the same data that I can. So I'm not going to re-post the survey results directly.

Instead, I'm going to call out some of the more interesting things I noted. Some of it is based on some data crunching and slicing. And all of it is based on my personal bias, so please apply the appropriate context when reading.

Who Responded?
All told, it had a pretty good response rate. In one week of activity, it collected responses from 121 people (myself included). The lion's share (56%) went to those currently employed and considering becoming an indie. And of those, 62% were employed by a game studio. Surprisingly, indies only made up 27% of the respondents. In retrospect, it isn't impossible to imagine such an outcome. Perhaps the readership is skewed accordingly? Maybe word of the survey spreads faster among employee pools? Maybe employees are more willing to take time for surveys than indies? We can't say for sure, but those are some likely candidates.

I should also point out that my survey's first shortcoming turned up in the "employment situation" question. I left out two key groups in the survey, based on the phrasing:

1. indies who are currently employed but working on games part-time.
2. indies who became indies directly from school or other unemployed status.

Even with those accounted for, the variety of specific working conditions made that question contentious for some. It's safe to say that there is no small number of optional responses to that question that would satisfy all respondents.

What Are the Biggest Reasons People Go Indie?
Not surprisingly, the most popular reason for going indie was "creative freedom." 73% of all respondents cited that as a reason. "Sharing one's ideas with the world" is in second, with 58%, and "improved working hours" was 49%.

Interestingly, 47% of respondents cited "the chance to earn more than a salary and/or benefits." That's one I didn't expect, given my perceptions of the indie scene. Everything I've read to-date has suggested that if one is seeking money, indie is the last thing one should try.

Also, game studio employees had roughly the same top 4 reasons and percentages as non-game studio employees. I had expected a slightly different set of reasons between those two groups.

I did one other data slice to compare game industry employees to non-game industry employees. I checked which reasons game studio employees cite more often than non-game studio employees. Expressed as a ratio of game studio employees to non-game studio employees, here are the biggest discrepancies:

1. Tired of the IP: 4.7:1
2. Tired of the genre: 4.4:1
3. Concerns with current project quality: 3:1
4. Concerns with current project marketing/publishing support: 2.8:1
5. Friends laid off: 2.1:1

The first two are probably to be expected. IP and genre probably don't figure into non-game employees' decisions if they work in an industry without a game IP or genre. #s 3 and 4 are interesting, though. Is project quality and marketing/publishing effort really that bad in the games industry, compared to other industries? Also, do game studio employees see more frequent layoffs than other industries? The above numbers may suggest just that.

What Are the Biggest Reasons NOT to Go Indie?
Asking the inverse question turned out to be similarly symmetric both in and out of the games industry, and equally unsurprising. The biggest reason? Inability to go without pay long enough to ship a game (54%). Lack of business acumen also figured in equally inside the industry vs. out, at 37%.

Two deviations did occur, however. First, "family depends on income" showed up more frequently outside the industry than in (43% outside vs. 30% inside). Also, game studio employees cited "liking coworkers" 34% of the time, compared to 20% outside the industry. It appears studios are hiring good people, and that matters to employees.

Also, one reason which was strong for studio employees vs. other employees was "liking current project." Despite the apparent dissatisfaction with IP, genre, and project management cited above, it appears 3 times more game studio employees like their projects than those outside the games industry. Wait a minute, based on the data in the previous section, that sounds like a contradiction. Why the discrepancy?

As it turns out, it's a very small fraction in both employee groups. 15% inside the industry vs. 5% out. So while more studio employees like their project than non-studio employees, they are both very low numbers overall.


What Did I Learn?
Did it answer any of my questions? Yes and no. Many of the responses are about what I expected, so I'm not sure how much I learned via the data directly.

However, I did learn some things from the failures of my survey:

1. The employment situation of indies isn't as clear-cut as my first question implies.
2. My provided reasons for becoming an indie are nearly complete (very few "Other" responses were wholly different than a provided option)
3. Roughly 4% of indies had no fears or reasons not to become an indie. (as indicated by "Other" responses)

For a game studio, I think there are some useful lessons to be learned. If I were to list them, they would be (based on above data):

1. Find a way to better engage employees' creative instincts, and let them express and share it with others. This can be creative input on the project, or on side projects. And my guess is there are as many non-content creators (e.g. programmers, QA) in group as there are traditional creative-types (e.g. artists, designers).
2. Crunch is not yet a solved problem in our industry. Get off the crunch crutch already!
3. Consider ramping-up profit-sharing alternatives. The fixed-ceiling compensation is stifling employees.
4. Provide a greater latitude in genres and IPs for employees to work on, to prevent burn-out.
5. Keep up the good work on hiring inspiring coworkers.

Improved project quality showed up frequently in responses as well, but I didn't list it above because it's a bit hard to interpret. Every studio's leadership wants improved quality, I'm sure. Unfortunately, you can't just pull the "improved project quality" lever. However, some things which might help include:

• increasing employee input in project decisions (and therefore increasing employee buy-in)
• avoiding projects with extreme constraints on time (e.g. movie tie-ins or financial quarter Hail Marys) or scope (e.g. sequels with little room for creativity/innovation)
• allowing creative side projects on company time (e.g. Google Fridays, studio-wide Ludum Dare, etc.)
• allowing creative side projects outside the company

Also, Marketing
I also learned a few things about marketing. For example, my personal internet reach is pretty small. Posting to the blog, twitter, Google+, and Facebook resulted in a limited number of results. It was pretty clear early on that I was going to need some more publicity to get useful results. So I started leveraging other communities where I saw indie discussions occurring.

Initially, that included a post on polycount.com, and a comment on a gamasutra.com blog. The former had shown up on my blog stats radar due to an "indie start-up" thread that linked to me, so I figured I'd give it a go. The latter was a comment on an article related to what made me put the survey together in the first place.

Later, I decided to use gamasutra's blog feature to make my first post. As it turns out, that was a good move. My post got featured on the first page as an "Expert Blog," resulting in a large increase in traffic. Both polycount and gamastura represented large influxes of readers for that week. Forum posts on indiegamer.com and tigsource.com made a difference too, but not quite to the degree of the former two.

It's taught me a bit about juggling target audience vs. audience size. Both indiegamer and tigsource are probably well-defined groups of readers who would appreciate the blog, but gamasutra and polycount generated a larger volume of interest. One piece of the puzzle which is missing, though, is who filled out the survey from which source? In other words, did 100% of 10 visitors from site A fill out the survey, and 1% of 100 from site B? And that's a big lesson learned: employ better metrics next time. For now, I'm satisfied knowing a bit about the reach I have, but I should've at least asked "how did you hear about this survey" in there somewhere.

So there you have it: The GDGR's first indie survey! Will I do another? Perhaps, but not until some time has passed. And not without some much needed edits. Until next time!