You are here

June 2013

Never Surrender, and OOO

It turns out that yesterday's battle-while-unconscious bug was pretty easy to fix. Today, I was able to find a new place to initiate the auto-turn-advance code, and it behaves normally now (i.e. just as if the player was pressing the "confirm" button). That fix paved the way for more AI looting tests, and hopefully also makes ending battles more stable.

Once that was working, I spent a few hours fixing up the looting code I've been working on. AI was looting when appropriate, but what they were taking didn't make much sense. I decided to fudge things a bit so they loot more valuable slots, as well as the ground, before moving on to less valuable ones. I ran quite a few tests, and it felt like there was a good variety of outcomes when the player fell unconscious, including outright death, waking up later after AI looting a few things, waking up later after AI looting many things/multiple lootings, and other creatures happening by and killing the player.

After that, I started work on surrendering:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-27.png) Corey Hart would not approve.

Clockwise from the top left are:

  • Offer surrender - drop everything you have, and offer to surrender.
  • Agree to surrender - agree to surrender, dropping everything and walking away (exiting battle).
  • Accept surrender - accept the opponent's offer of surrender, whereby they drop everything and exit battle.
  • Demand surrender - demand that opponent surrender, giving them the option to agree to surrender.

It's pretty basic stuff, but it's one more way to end battles that avoids murder. Like with looting, the victim is at the mercy of the other guy, who will likely take anything of value. However, it might be worth it to stay alive.

For convenience, the red options are the dangerous ones, as they cause YOU to lose items and flee. The blue ones are the ones that cause the target to lose items and flee.

Overall, these seem to be working ok. There's just one bug that causes AI to surrender too often. It seems to be caused by surrender being the only option when "recovering" or otherwise stunned. Ideally, I wanted one to be able to surrender when in "recovering" state, but I might have to change it to make this work.

Out of the Office

Just a heads-up: I have a couple more travel days ahead.

I'll be out of the office tomorrow, as I'm on the road again. I probably won't have much of a chance to check in until Sunday night or Monday. I'm planning to work Monday to make up for lost time, as that's a stat holiday in Canada (Canada Day). And then, I'll be flying home on Tuesday, so I'll miss that day as well.

After that, I should hopefully be back to normal, and on my home computer again (yay!).

Have a good weekend, all!

AI Looting and Battle Bug

Today, my first task was to get the AI using yesterday's new "Check Body for Loot" move. As of yesterday, players could choose to just loot an unconscious enemy and leave, rather than having to kill them for their stuff. And in theory, so could the AI. But I hadn't tested it yet.

After a few tests, it appeared AI could actually do so as well, but there were problems. First of all, the AI rarely chose to do so. Secondly, the AI often chose to do so multiple times in the same battle. These two issues turned out to be pretty easy to solve, however. A few prioritization value tweaks, and a condition marking a body as already looted, and AI was acting a little more realistically. In practice, looting the player roughly half the time, and walking away after taking a few items.

But a third problem reared its head, and it was a big one. Every time AI left a battle with the player unconscious, the battle UI would remain even after the last AI left. In some cases, this would overlap an encounter which followed, making it impossible to read.

I spent most of the day trying to figure out why this was happening, and it was only in the last few minutes that I figured it out. As it turns out, there was a bug in the way the game advanced combat turns automatically after the player's been unconscious a while.

A while back, I added code to make the game auto-advance combat turns once the player was unconscious for 3 turns in a row. This was mainly to speed up things for the player, since they had no choice anyway. It also added a neat element of realism, as the UI became a flurry of confusing activity while the player was out.

However, it looks like this was causing a weird nested combat loop bug. The game would auto-end the combat turn, and it would check a few things, and start a new combat turn without finishing off the old one. And this would happen until we were 4-5 combat turns deep.

This definitely broke the flow of combat in cases like the one I was testing, but I'm suspicious about whether it might also be causing some of the issues other players are reporting. Things like endless turn advancing bugs, or other stuck combat screens.

The good news is that removing the auto-advance seems to fix it. A quick test showed it working as it should. The bad news is that I'm not sure how to re-enable the auto-advance without causing the bug. However, I only just figured out the cause a few minutes ago, so I should have some more time to look into it tomorrow.

Other than the above bug, I made a few smaller changes as a result of my day of battle testing. One change was to reduce the frequency of tripping when moving around the battlefield. After a day of combat testing, it was pretty clear combatants trip way too much. I've dialed it down by half, per Sid Meier's game design addage.

The other change I made was to the way items break each turn. I think there was a bug that caused all items to degrade as if time did the damage, even if it was usage or other causes. Many times, this is fine. But in some cases, the item turns into nothing when broken over time, but turns into degraded treasure when simply broken from use. We'll see if these changes improve things in practice.

That's all for today. Hope everyone has a good night!

Looting in Combat, and More Bug Fixes

Today turned out pretty productive as well. I started the day off with a few more bug fixes that have been stagnating on the back burner. One such bug was the issue with dropping items in bottles/etc. that sit on the right or bottom edge of a backpack. I made some changes which should make this possible again, whether using take/drop or drag/drop.

I also fixed a bug that caused blurry text in the game over page when multiple causes of death were listed. There might still be blurry words if the cause of death is really long and wraps lines, but at least multiple causes should look better.

After that, I decided to look into non-lethal combat stuff. So far, the only way to get items in battle is to murder one's opponent. Many have pointed out that, while grim and befitting the world, it's not always appropriate. Similarly, the only way out of a battle was to run away or die.

So I started planning a few non-lethal options for battles. One such change is to make unconscious enemies lootable. I made a few changes to the combat system so that the game treats unconscious enemies as non-threats. Combat will continue as normal, but the unconscious enemy doesn't count as an aggressor anymore, freeing up the other combatant to access inventory (even when at melee range). I also made unconscious combatants immediately drop anything in their hands.

In practice, this means that one can now knock out an opponent, and take any items they dropped without having to kick them to death. I also created a new battle move called "Check Body for Loot," which empties out all the target's items onto the ground. This way, players can get stuff and just walk away, rather than having to kill anyone for stuff after they're down.

It'll still be possible to continue attacking the downed enemy, and the result will be pretty much like before: killing an enemy leaves all their loot on the ground. I'll probably look into corpses for dead opponents, since that'll make it possible to do things like dogman fur clothes, or hunting larger-than-squirrel game: both popular requests.

This also lays the groundwork for surrender, since battle moves can now trigger "Drop all items." I plan to add a few new moves for "offer surrender," "demand surrender," and "accept surrender." "Offer surrender" will cause the creature/player to drop all their items, and make the "accept surrender" available to the opponent. If the opponent accepts, the surrenderer exits the battle into an adjacent hex, minus their stuff. If the opponent chooses not to accept, then the surrenderer is in trouble. Better grab their stuff and run, or maybe just run!

"Demand surrender" will be similar, with the opponent losing all items and exiting the battle if they agree to surrender.

Losing all items is harsh, true, but it's easier to code than complex bargaining, and better than dying. So let's go with that for now :)

I'm also interested in exploring the idea of "Declare Peaceful Intentions" as a combat move when entering combat at a range. I always thought it'd be cool to play out the tense moments when one meets a stranger on the road. Are they hostile? Friendly? Pretending to be friendly? Now that range is a bigger factor, this seems like a good struggle for the game's atmosphere. It also pairs pretty well with "Threaten." I haven't planned much yet, just jotted a note down. It'll largely depend on there being non-hostile creatures, so that might have to wait.

There may be some others in the works, too, but we'll see how tomorrow goes. Overall, though, it'll be nice to have a few battles end with fewer fatalities!

That's all for this evening. Have a good night, all!

Bug Fixing and UI Improvements

The last few days have been pretty travel-heavy, so today was the first day "in the office." I put that in quotes because I'm working on my older laptop, and that can be a bit rough. 512MB RAM isn't really enough to run Windows XP, FlashDevelop, and a browser concurrently (especially if that browser's running multiple tabs with spreadsheets.) And when the debug version of NEO Scavenger fires up, well, let's say pagefile access gets pretty intense :)

With that in mind, most of my work today was changing data, and less-intense bug-fixing. It was still surprisingly productive, though.

One of the bigger changes was to the encounter screen. When an encounter gives a single item to the player, it sticks to the cursor until the player puts it down. There has been no shortage of confused new players as a result of that quirk. Many times, players assume the game has stalled and they can't continue. This is especially true of items that are small, like the flash drive, recipe hints, and other 1x1 grid items.

Even when multiple items are granted, the only warning the player gets is in the encounter text and some floaty items moving quickly across the screen.

Sticking the item to the cursor was meant to help the player notice that they got an item, so they didn't leave the hex without it. But since it was more confusing than helpful, I decided to change it.

My first thought was that I should just add a treasure grid to the encounter screen, so players could see, up front, what they got. And before they continued, they would have to find a home for those items. However, that seemed to present new problems of its own (inconvenience and UI space among the bigger ones).

Instead, I decided to add a new button just below the "confirm" button when treasure has been awarded. All treasure, even single items, now just goes straight to the ground space, and this button will appear with a light on it. It looks just like the "Items" screen button, and it just goes to the Items screen. Hopefully, this should provide a very obvious visual cue that items are available for pickup, without interrupting the flow of the encounter. No more items stuck to the cursor!

I also made a change to the text for AI behavior when it's tracking the player, so it talks about following player "tracks" instead of "scent." As some players pointed out, "scent" sounds more animalistic, so "tracks" should cover both human and non- cases.

I also made quite a few fixes to crafting recipes, such as food, ash, and HVAC/lighting items being usable in the rough splint. There were also a few items with missing or extra properties causing problems, including variants of the rifle and the t-shirt. Thanks to everyone who found those weird cases!

Speaking of variants, the last change I made today involved the treasure system. I made a slight change to the way it lists items, so now it's possible to have a treasure referencing another treasure.

Previously, each treasure was just a list of items, the quantity expected, and the chance of getting said item. It was also possible to get one out of a group of items by specifying something like 30% chance of 1x item A OR 70% chance of 1x item B. That worked for a while, but now that I'm adding more variations of similar items (more types of rifles, pistols, clothes, etc.), it'd be a pain to have to update each treasure when a new item was created.

Instead, now I can create one treasure for something like "any random shirt," and have other treasures point to it. So the bandit's starting equipment, the mobile home scavenging loot, and the junk store can each point to "any random shirt." And when I add new shirts to the game, I just edit that "any random shirt" treasure group, instead of all three locations.

Small change in code, but big benefits now that variations are being added.

So that's it for today! As I said, it actually was pretty productive, despite the slow computer. Hopefully, tomorrow proves to be the same. Have a good night, all!

Electronics System Wrap-up, Bug Fixes, and OOO

I think I've got the electronics stuff working now. I made a few more changes this morning which make sure items discharge correctly over time as turns pass, and my night vision bonus correctly disappeared once the batteries were dry.

Once that was working, I moved on to the weapons, to verify that those continued to work. Most were ok, though I realized that I forgot to setup thrown objects and retrievable missiles. After some changes, and making sure the thrown object didn't change attack modes on the player, I had a few rounds of throwing pebbles at angry dogmen, and wrapped that up as well. It's not perfect, as it's possible to retrieve the same missile just thrown/fired if one is out of melee range. However, one must sacrifice their attack and special move options to do so, so I think that's a reasonable compromise for now.

In an ideal world, arrows would stick in opponents and such. However, that'd require some significant system changes, so I decided to focus on higher priorities for now.

After that, I decided to tackle some bugs and details that have been on the wayside these past few days. Several recipes needed minor tweaks, to ensure things like sleeping bags won't work as kindling in a quality torch, and preventing rivers and lakes from being destroyed by boiling them.

The 2x and 3x boiling water and boiling rag recipes are back, too. I took them out originally, since the new crafting times meant one could boil more water per turn than before. However, many of you pointed out that it was still a pain to do in the real life, UI sense, so I re-added those options. However, those recipes require medium or larger containers to boil in. A tin can isn't going to cut it :)

I also tried to find some ways of improving the crafting process, based on some player suggestions. One big change is that quick recipes will no longer empty out the ingredients box when clicked. I also changed the recipe validation to prefer those already chosen ingredients in the recipe.

The net result is that one could load up the ingredients box their preferred ingredients, and the quick recipe will try to use those first. And leftovers can be quickly used again in the next iteration.

Finally, I changed the battle code to use the new hex starting ranges, which correspond to new weapon ranges. Now, starting battle in a field means the opponents are far apart, while battles in crowded terrain start closer together. Retreat mechanics might need tweaking in this new system, as it tends to be easier to avoid/escape fights now. Though, maybe that's a good change.

Overall, it seems like today was a pretty productive day. The work was scattered, but all of it necessary.

Just as a heads-up, I'll be traveling tomorrow and Friday, so internet access will be spotty. I expect to get some work done, but I probably won't update the news section until Monday. I'm thinking the laptop is going to be a pain during the flight, so I might stick to notepad-based work, like plot writing/planning.

I hope everyone has a good rest of week and weekend. And I'll see you Monday! (I'll still try to check email in the meantime, in case any crises arise).

Item Charges and Imparted Conditions

Yesterday's plot planning was pretty successful. I spent a lot of the day thinking about conspiracies I could try to integrate, and whether there are ways to make different skills relevant to those plot items. I think I have a couple ideas that I like, and I was even able to think of a few ways of using existing factions with those plot ideas (e.g. Blue Frogs, Martha's Army, etc.) I still need to make sure the ideas are sensible when strung together, but I'm liking the ideas so far.

Today, I started working on the problems of item conditions being added to or removed from creatures based on whether that item needs charges or not. For example, putting night vision goggles onto one's head should only give bonuses if the goggles have charged batteries.

That part was pretty easy. I just piggybacked on the existing code for equipping/unequipping items, and made it check for charges.

The tricky part is going to be handling items that are equipped while charges get added to or removed from them. For example, if someone is wearing the goggles, and they run out of charges, that person should lose the bonus. So I needed to write new code to handle adding/removing bonuses every time the contents of an item are changed.

To make things trickier, some items hold charges directly (guns, nanorobotic medkits), while others hold batteries that hold charges. This means that the new code I wrote had to check two levels deep, to make sure the goggles got switched on when the battery inside got new charges. It was a bit tedious doing all the checks for each nested level, but it seemed like the best way to go, given the circumstances.

I considered just making all objects take charges directly. However, that could screw up things like vehicles and fuel, which I'd like to add in the future. A car, for example, might have a lot of storage space. And if gas/electricity gets added directly to the car, then all that storage space could be used for gas/electricity. Cars have a lot of room for boxes and such, but one shouldn't be able to fill the back seat with gasoline or electricity.

With the two-level-deep system, I can specify that gas only fits in gas cans, and electricity only fits in batteries. So if a player wants to load up a car with batteries and/or gas cans, then fine.

Another alternative might've been to make items support multiple storage spaces, and have each space support different items. This has some advantages, but there are some major hurdles scaring me off from trying that. One big hurdle is lack of UI space. There just isn't enough room for the existing container spaces, let alone more per slot. And a lot of the code would have to be rewritten to assume multiple container spaces per item, instead of the current assumption of one per container.

So it was a tricky afternoon. I think it's working, though. I was able to don some charged goggles, and use "right-click->empty out" to drop their battery while they were worn, and the bonuses went away.

Provided that system passes some other tests, the next thing is to make sure charges are deducted each turn/move/use, as necessary.

Hope everyone has a good night, and see you tomorrow!

Devlog Preview Today

Just a heads-up: I have to head into town today to handle a few errands, and then we're attending a going-away dinner party in the evening. So my usual evening news post will be absent.

The plan, however, is to do plot planning while in town. It's something I can do without a full dev rig, and doing so on my last trip into town was pretty successful.

Hope everyone had a good weekend, and see you tomorrow!

Prototype Battery

I continued yesterday's work refactoring item charges, so that items could drain power over time or per use, as needed. By the end of the day, I was able to get the nightvision goggles installed with their own, charged battery:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-14.png) New night vision goggles, with battery power.

The plan is for there to be several battery types, and each has a different capacity for energy. Energy items can be moved around like water, except it cannot exist anywhere but inside batteries. So it's possible to transfer energy around freely (which is admittedly unrealistic), but not to hoard it on the ground, or put it in a pocket. It must go into another vessel.

Energy items are 1x1 items, and stack 20 high per space. For now, my rough approximation is that a single unit of energy in the game corresponds to about 1kJ of real-life energy. For reference, a AA battery is about 15kJ (1.5V * 2.7Amp_Hours * 3600 seconds/hour) of total stored energy, and a car battery would be ~2000kJ (12V * 50Amp_Hours * 3600 seconds/hour = 2000kJ). That means a AA battery would have room for about 1 stack of 20 energy units, while a car battery would have room for about 100 (a 10x10 grid).

I'm also assuming that a laser rifle emits about 30kJ per shot at high power setting, so roughly 30 energy units in-game. From what I've read, this is the minimum threshold the military considers to be a "high energy laser." It's about 30% of the power currently used in experimental warship lasers used to down incoming missiles and drones.

These are just data points I'm using for reference, to help model consistent values across items.

There are still some kinks to work out, however. For one thing, the goggles are still operational without charge in them right now. I need to look into that next. They should check if they're charged before imparting their bonus.

I also need to make sure the weapons have survived the refactor. They now use similar charge-tracking code to the goggles (except with bullets instead of energy). In theory, if one works, the other should. But you know theories...

Finally, I'll have to make sure things are discharging correctly when used, or as time/distance passes.

So far, I'm thinking the system will serve my purposes well. It seems like it should cover electronic tools both used and equipped, weapons, and vehicles. And once tested and fully working, I can start adding more electronics to the game like flashlights, iSlab apps, and maybe even a gas-powered test vehicle. Should be pretty interesting!

Hope everyone has a good weekend!

Spears, and Charged Items

Early in the day, I decided to work on a few spears, before moving on to new items. I added the large branch item a few days ago, but never got around to making sharpened versions of it for the range = 3 band of melee weapons. So I mocked up a few variations on a long spear. They include a simple sharpened pole, a fire-hardened spear, and a broad spear (non-wood tip, such as glass). For each, I setup melee and thrown attack modes.

Once those were drawn and hooked up, I started doing some thinking about items that require charges. Even with the recent mechanic-based vehicle recipes, the electrician, hacking, and mechanic skills are still somewhat underutilized. So I wanted to see if there are some more gadget-y items I could add.

One issue I've run into with such items, however, is their power source. Almost anything an electrician, hacker, or mechanic would fix or build needs something to power it, whether it be a battery, gasoline, or more exotic fuel.

There's a system already there to handle charge usage, but it's a bit dusty from disuse. And it could use a bit of strengthening if I'm going to add any amount of new charged items to the game. So I wrestled with design ideas for charges over a few hours. At one point, I became stumped, and decided to write the problem and potential solutions in a text file. And as usual, that seemed to spur things along.

After a bit of paper-prototyping and conjuring example items, here's what I came up with:

Items which require power sources or charges can specify one or more IDs for their "charge profile." A charge profile is just a collection of stats that specifies:

  • The ID of the item that is used as a charge.
  • The number of said charges exhausted per item use. (e.g. a nanorobotic medkit)
  • The number of said charges exhausted per hour. (e.g. a lantern)
  • The number of said charges exhausted per hour while item is equipped. (e.g. night vision goggles when worn)
  • The number of said charges exhausted per hex moved. (e.g. a car)

It might require tweaking as more items are added, but this should cover most of the things I'm expecting to add to the game. For example, I can change the nanorobotic medkit to have 2 charge profiles, so it requires both a battery charge and refill charge to operate. Or, I can make the night vision goggles discharge each turn while worn. And the hex discharging means I can add non-primitive vehicles, like gas or electric-powered vehicles.

There are a couple shortcomings so far, though. First of all, this will probably mean that electricity is a tangible item, like water in a bottle. I can prevent it from being stored in a backpack, but I can't prevent it from being moved around without special equipment. It'd be cool if one needed the electrician skill and wires to transfer charge from one item to another, but that's probably beyond the scope for now.

Another problem is that items with more than one charge requirement will need to share storage space for each charge type. So a nanorobotic medkit might have both a battery and refills inside it to work, and players can stack extra batteries at the expense of space for refills. It's unrealistic, but again, probably not worth building really detailed systems to avoid.

And some items might have several operational "modes." I'm thinking this is going to be a big deal for the iSlab (or any other programmable object). The number of functions available to an iSlab is pretty formidable, and it'd be nice if the iSlab could be used for more than one of those functions. E.g. a flashlight, camera, file reader, etc.

I might have to add little software items to the game that can be stored inside an iSlab, and crafting the iSlab with one of those apps switches it's mode. It's not a bad approximation of reality, but the down side is that I'd need to create a separate item for each mode, and that could get prohibitive. At least I wouldn't need to write a new system, though, as it just uses the existing crafting system.

Anyway, I'm pretty optimistic about this approach. It sounds like it could open up some cool opportunities which I've been avoiding since I didn't know how (e.g. fueled vehicles, electronic tools). I've started laying the data foundation this evening, and tomorrow, I can try hooking a few things up.

Of course, I could have a paralyzing realization overnight that prevents moving forward, too. But hopefully, this is a relatively small amount of tweaking that opens up some much overdue item options.

Have a good night, all!

Hooking Up Ranged Weapons

Today was largely about hooking up the items mentioned in yesterday's art update. Each sprite I drew had to be cropped, saved as image files, and in some cases, modified to fit areas like worn/held on the body, or as an attack mode UI item. Then, the data had to be entered for each item, including ammo types. Plus, ingredients, recipes, and treasure data for items that could be assembled or broken. And, of course, the attack modes that each grants.

So lot's of data entry today :)

I did finally decide to add a craftable bow to the game, after learning about "greenwood" bows (or "quickie" bows). The idea behind a greenwood bow is that one could fashion a suitable length of branch or sapling into a bow without the days of shaping, molding, and treating wood. Most of the work is in shaving material from the bow's "belly" until it bends evenly, and then stringing it up.

The up-side is that an experienced bowyer can fashion one of these bows using naught but a knife and forest materials in a matter of an hour or two. The down side? Greenwood dries out in a matter of days, and then cracks, becoming useless as a bow. So, it'll serve in a pinch, but it isn't something that'll last.

Here's the greenwood bow art, alongside the other primitive missile weapons:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-12.png) New primitive missile weapons.

While hooking up the arrows and stones, it occurred to me that several of these items are also serviceable melee weapons. The stone can certainly be used to smash someone's face, as well as be thrown or hurled with a sling. The arrows can poke a person pretty good, too. So I set about making corresponding attack modes for each of those items.

And, of course, the pistols can be used to pistol-whip an opponent, like the rifles allow for rifle-butting.

Overall, it turned out to be quite a batch! We've now got several modern and primitive ranged weapons, a few new melee options, and in some cases, even new tools. The arrows in particular can be used as a sharp edge or sharp point in recipes that need them, and the sling doubles as a medium strap.

There's definitely more that could be added in the weapons department, but I'd like to wrap this batch up so I can flesh out some other areas that need it. It might be nice to add some more tools, clothes, food items, and other things (both manufactured and crafted), so the game isn't too combat-heavy.

Still plenty to do!

Hope everyone has a good night, and see you tomorrow!

Ranged Weapon Art

Continuing with the latest thrust for more content, I decided to work on a few new ranged weapons today.

One common complaint in NEO Scavenger is the relative uselessness of the Ranged skill. With only the hunting rifle in the game so far, there's little incentive to sacrifice a whole skill slot for a weapon that has such rare ammunition. I've always planned on having at least a couple more ranged weapon options, so since I'm doing new items, now seemed as good a time as any.

Here's today's progress:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-11.png) An assortment of ranged weapon art.

Most players will already be familiar with the .308 hunting rifle, at the top. I left it in the image as a reference point for other weapon sizes.

We'll start with the firearms, as I'm sure most players will care most about those :) As I've mentioned a few times before, part of my strategy in selecting which weapons to include is based on availability in near-future North America. I want there to be at least a semblance of realism in what players find, so it makes sense to choose the firearms that are most circulated in the past 100 years. (Fancier or more sci-fi stuff will likely still come later, but in lesser quantities or harder to find.)

With that in mind, the three new firearms that I've chosen are a 12-gauge shotgun, a .38 revolver, and a .45 semi-automatic pistol. Based on the data I've seen, these four weapons (including the .308 rifle) are, by far, the most widely purchased over the past century, and are the most likely to be found in circulation around Michigan.

The 12-gauge shotgun is loosely based on current-day civilian and law enforcement models, and is popular for hunting, home defense, and police use. There are two types of ammunition available for this shotgun in NEO Scavenger: 00 buckshot (clear shell), and a solid slug (red shell).

The .38 revolver is perhaps even more commonplace in America, arguably the single most circulated firearm in the country (in it's various forms). It has a long history among law enforcement personnel, and is still a popular civilian gun. It's cartridges include jacketed hollow point, and full metal jacket rounds.

Finally, the .45 semi-auto is a former military sidearm that became extremely popular among civilians for both home defense and target shooting. It's available cartridges also include JHP and FMJ flavors.

In all cases above, the chosen cartridges were based on some rough research into best-selling ammunition for each firearm.

(Before anyone asks, .22 long rifle was also a contender, but I opted not to for two reasons. 1 - There isn't a single .22 firearm that represents the lion's share in the market, so I didn't feel confident just picking one at random. 2 - I had already spent a lot of time on guns, and felt other ranged weapons needed some love :)

Apart from the firearms, many players have also requested some more primitive missile weapons. And I think this makes complete sense in a world of makeshift and salvaged tech.

Perhaps the most primitive thing on the page are the humble stone and rock. Stones are pebble-sized, and can be hurled by hand or with a sling (pictured to the stone's left). The larger rock is too heavy to be effective in the sling, but makes a passable deterrent in some situations. (And as the history of capital punishment shows, in large enough quantities, even thrown rocks can be fatal.)

I've also drawn some sprites for a bow and a few arrows. The bow is a typical store-bought, compound hunting bow. And the arrows are a mix of store-bought, carbon shaft broadhead, a makeshift glass-tip, and a makeshift metal/nail tip.

It's not a comprehensive review of ranged weapons, but it's a decent sampling. I have yet to hook these up, so that will probably be tomorrow's work. I'll probably add recipes for at least the sling and makeshift arrows, and I plan to do a little research into makeshift bows.

So far, bowyering seems a bit beyond crafting in the woods with simple tools, but there are a few more techniques I mean to look up. There isn't really time to steam and work wood over days with dogmen prowling about, but maybe there's a quick-n-dirty bow that one could knock together. Crappy by comparison, but good enough to stick a bad guy in a pinch!

Finally, a note about the artwork. I realize a number of players have graciously donated their own suggested artwork for new items and weapons. And in many cases, I think it beats the quality of my own. I just want to be clear that in no way am I refusing to use that artwork based on it's quality. It's more of a selfishness thing: I enjoy making the artwork, so I wanted to take a crack at it myself :) If nothing else, seeing your artwork inspires and educates me, so don't feel discouraged from doing more!

I hope everyone has a good night, and I'll see you tomorrow!

More Item Work and Bug Fixes

I decided to do a batch of bug fixes this morning, to catch up with the latest bugs reported in the forums. Those fixes included:

  • Fixed degraded item outputs for noise trap, tunic, fires, and splint. (E.g. noise trap was degrading into rifles)
  • Added code to prefer cheaper/unsocketed items when using quick recipes. This should prevent more valuable ingredients from being used in recipes while less valuable ingredients exist.
  • Added code to identify items in stack when stack head identified. (Was just identifying top item.)
  • Added "water" property to water items, so only water can be boiled to make pure water. (E.g. not ketchup or corn-a-cola)
  • Added botany skill as required ingredient for tannin tea.

I also tried reproducing a crash bug involving hiding and combat, as well as a fullscreen exit bug, but wasn't having much luck making them happen. If I can figure out how to cause them, though, I'll get to work on fixes for each.

For the rest of the day, I continued adding new items and recipes. Here's what they look like:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-10.png) A travois, broken glass, and the new whiskey drop.

The big, wooden object is called a "travois," and is basically a primitive wagon or sled. It's a long, rigid, wooden frame atop which one can put cargo (usually tied down), and the player drags one end while the other ends of the poles drag along the ground. It's not the most convenient transport, but it's possible to make with few tools, and it's better than lugging the cargo by hand.

I also created a series of items related to broken glass, seen below the travois. Ignoring the droplet, clockwise from top left they are the broken bottle, glass shiv, and shard.

The whiskey bottle is now an equippable weapon, roughly on par with a branch/stick. It'll break pretty easily in a fight, though, and might even cut the wielder. Once broken, the bottle becomes a broken bottle and some shards. Each of those can be wielded as well, and pose similar chances of breaking and self-harm in a fight. The broken bottle will further break into shards, while the shards dissolve into nothing. And that entire degrading chain can be forced via the crafting screen, if one just wants to go straight to the broken bottle or shards.

The shard can be combined with a flexible small or medium sheet to make a glass shiv, which has similar characteristics to the shard, with a much lower risk of self-harm.

Unfortunately, the self-harm can't be forced to the hands, so the cuts can appear anywhere. The shard and broken bottle items have "sharp point" and "sharp edge" properties, so they can be used like a knife in certain recipes. Also, most of the glass recipes use "brittle, rigid" properties, so if any other brittle/rigid stuff gets added, one or both of these glass pieces may be obtainable from that, as well.

Lastly, I decided to take some players' advice and standardize the whiskey drop to match the other liquids in the game. Now, it has the same size as water, but can stack 6x (as opposed to water, which only stacks 1x). This was more of a big deal when lighter fluid was around, as small droplets could be mixed in a container with no penalties. However, it'll be good to treat all liquids in a similar way, for consistency.

That's all for today. I have a few more items I'd like to do tomorrow, so stay tuned!

Item Work, Combat Ranges, and Bug Fixes

Today was an interesting day, mainly because it involved a wide range of work. Some pretty significant changes, too.

However, the first order of business was to tackle a few bugs players recently found. Namely, there were some problems in the recipes for the cryo light and HVAC systems. As it turned out, these problems were bigger than just those two situations, so a few fixes were in order. Quick recipes, in particular, had some issues that I didn't notice before.

I also made some changes to items such that identifiable items each have two prices now. Before, anything unidentified would always be $0.25 at the store. Now, each item has it's own value, which should be more appropriate. Also, the junk store should always be stocked with identified items.

Next, I started working on adding a new item to the game: the large branch. Up until now, we've had twigs and medium branches. However, I wanted to add a travois to the game (man-sized for now, not dog/horse-sized), and that meant having something a bit larger. It also meant a few recipe changes to allow for the new large branch, including the tarp shelter, and roasted meat on a stick.

The large branch also gives me the opportunity to explore something else I've been meaning to do: rework weapon/battle ranges. Up until now, most melee items had a range of 0, and the rifle had a range of 4-5. Tackle had a range of 1, and most battles started with combatants about 2-4 spaces apart.

However, I wanted to try adding a few different melee ranges, to differentiate things like a pocket knife from a crowbar. If you've ever been threatened by an animal while out walking, you'll appreciate the difference an extra 2-3 feet of weapon reach makes. Holding a pocket knife is a helluva lot less comforting than a sturdy branch or crowbar.

So I started prototyping a new set of ranges that looks something like this:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-07.png) New attack ranges, a visual primer.

In this new system, range 0 represents grappling or co-location. There aren't really any moves that take advantage there yet (except the enfield horror's trample), but that's where sitting on one's opponent would be.

Range 1 is a short melee range, like swinging a fist or a pocket knife. Cleavers and wrenches would be here, too. They're longer than a fist, but not appreciably. And kicks fit in here as well.

Range 2 is for longer tools, like the crowbar or a branch. Swords, baseball bats, and other melee weapons would also fall here. They're the kinds of weapons you'd feel better about keeping a wild boar at bay with.

Range 3 is for polearms and the like. The large branch fits here, as would things like spears, or a shovel. Tackle will also work from this range.

Range 4 is just out of all melee weapon range, and is the maximum range for things like luring, and throwing debris/obstacles.

From there, we have a pretty big jump up to pistol and thrown object range (rocks, grenades, throwing knives). And then a huge jump up to rifles and such. The idea here is that combatants might quickly get out of pistol or thrown range in a few rounds of flat-out running, but for practical purposes, there's no getting out of rifle range. For rifles, if they can see you, they can shoot you, and nothing short of leaving the hex, hiding, or cover will help.

Escape will still work like before, with chances getting better as range increases (among other things, like visibility, movement rates, and other conditions). However, I'm expecting that "retreat" and "desperate retreat" will start to become more distinct now. The former is only available when out of enemy weapon range. It's deliberate, and controlled, and should work more often. The "desperate" retreat should usually be available, even in weapon range, but the chances are lower. It's more wild, and luck-based, but it also carries a small chance of increasing range simultaneously with the escape attempt.

The other piece of the puzzle is the new hex ranges. Each hex will now have a different minimum and maximum engagement range. When encountering an enemy, the battle will start somewhere between these ranges, instead of always 2-4 hexes apart. For ruins and forests, this might be in the 3-6 range. Suburbs and cities might be more like 3-15. And open plains are 20-30.

I'm hoping that this makes each hex type more distinct as a battleground. For example, open plains are now extremely dangerous when creatures have rifles. Targets are pretty much at their mercy without clever cover use, hiding, or lucky escapes. Open plains make for easy travel, but getting caught by a bandit with a gun is going to hurt more.

Conversely, forests and other "close" hex types are harder for travel, but it's easier to lose one's pursuer if need be.

This is all in theory, of course. I just finished rewriting the data and systems to match the above. I have yet to test it. I'm hoping that I can keep a lot of what's fun about the current system, while adding a bit more distinction in range bands. Plus, this might also open up the opportunity for hiding to become more useful. I might add the ability to re-enter hiding/sneak mode from time-to-time, making another alternative to flat-out escape.

These changes should also pave the way for more weapon types, which are a perennial favorite among player requests. And if I'm really ambitious, maybe this will be a good time to look into things like "aimed shot," "surrender," and looting unconscious enemies.

So yeah, as I said, an interesting day. A lot of intertwined systems came to the fore when I started looking into the large branch. Stuff I've been putting off until it was time to work on new items. And now that time has come!

Have a good weekend, all. And see you Monday!

Recipe and Plot Work

Today began with some follow-up on yesterday's items and recipes. I had to create the sled item stats, recipes, and some new conditions for when the sled is equipped. I decided to try making two sled items. The first is a plastic sled, the second is a sled with a strap.

The main difference is that the strapped version is beneficial when equipped, while the un-strapped version is a hinderance. I figured squatting down and tugging a sled by the front lip is actually more work than just walking upright. Conversely, a sled with a string makes carrying additional load possible before becoming encumbered.

Both have negative effects on player visibility and tracks left behind, however. As with the shipping cart, people and creatures can hear it from a mile away.

I also decided to try making the sled with strap craftable from any large, rigid, flat container, instead of strictly the plastic sled ingredient. I can't recall any containers that fit the bill right now, but if any more get added in the future, they should be possible ingredients for the strapped sled.

The rest of the day was spent brainstorming plot. I have a pretty good idea of what's going on in the world, but I wasn't entirely sure what the player's role in it would be. There were mysteries to solve, of course ("Who am I? Why was I in stasis? What happened to my memory? Why is someone trying to lure me to my doom?"), but I wasn't sure if there were any bigger questions.

I actually spent some time in the library reading a book on plot archetypes and storytelling. It actually got me thinking critically about some elements of the story, how the protagonist and antagonist can be related, motivations, and critical scenes. I noticed a few opportunities for foreshadowing and tension, and maybe even some places I could work in a betrayal or alliance.

I think I determined some things about our protagonist that I wasn't able to answer before, and also some things about both he and the antagonist that can make them more well-rounded.

Finally, I did some reading on the plot templates the author called "quest" and "adventure." Both seemed far more apt descriptions of the goings-on in NEO Scavenger than some of the others I perused (such as "the rescue," "the escape," "the chase," etc.)

In it's current form, NEO Scavenger is almost a dead-ringer for the so-called "adventure." Most of the plot centers around action, exotic locales, and the protagonist using tools and wit to overcome obstacles. There's little character growth in such a plot, as it's more about causal scenarios. Indiana Jones might be a good example of this.

That's well-enough, but the "quest" plot-type actually enticed me a bit more. It contains many of the elements of "adventure," but involves one key difference: character growth. In a "quest," the antagonist is seeking something, whether it be a person, object, or place, and they meet resistance along the way, and the journey transforms the way they see themselves or the world. They finish their story having changed in some way. Examples of this type of plot might include Gilgamesh, or Don Quixote.

In retrospect, one could argue that many "adventures" are also "quests," so this may be more subjective in nature. But the point of interest is whether to allow the player to "grow" their character somehow. When faced with certain obstacles, are there opportunities for the player to overcome their weaknesses? Or to change their outlook?

It'd be a tricky thing to accomplish. Player choice makes narrative hard to predict or control, and player customization makes it even harder to prepare for. With so many possible outcomes, I'd be hard-pressed to write satisfying growth opportunities for each combo.

However, maybe there are some ways I can let the player develop their own character over the course of the game. Not just adding new skills and items, but actually changing they way they behave. Does the character learn to be brave after starting a coward? Or do they become jaded after starting naive? Maybe they are faced with a choice between exposing a lie and maintaining secrecy, each with penalties?

Lots of food for thought. However, today helped me get a handle on many of these things, and helped me identify questions I'd like to answer. And as usual, it reminded me how hard writing can actually be :)

Have a good night, all, and see you tomorrow!

It's Time

Well, with the new crafting system and property-based encounters up and running, it's finally safe to start adding new content. And that means items, recipes, and encounters.

I decided to have a little fun today, and started on a few overdue items and recipes:

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-05.png) "101 Things with Strings!"

Many folks have asked for ways to sling a crowbar over the shoulder, or wear binoculars around their necks, so those were some of the first to be added. In fact, even scopes will soon be wearable around the neck. And keen observers will notice that the binoculars can now be disassembled into halves (plus parts). These binocular halves can substitute for scopes, both in the strapped scope and scoped rifle recipes. I may adjust them in the future so that they require some mechanical work to be usable as a rifle scope, but for now, it's good enough.

The large-ish bundle of string is used in many of these recipes, and is basically several small strings combined.

And on the left, you can see several of the new vehicle-related items. The shopping cart can now be disassembled (or fall apart), and the parts can be used with appropriate tools and mechanic skill to rebuild a new cart. Mechanically-inclined scavengers can now also jury-rig a box cart from a frame, wheels, boxes, and various parts. And lastly, a new vehicle will soon be in the game: the plastic sled!

I also added a way to create fire without a lighter. Many folks mentioned that a skilled person should be able to create fire using the friction method, so now, using the trapping skill and two branch-like objects, one can ignite kindling.

All of this has yet to be tested, of course. I just cobbled all the art and data together today. Inevitably, there will be typos and gotchas in the recipes and items, so it might take a bit of fixing. However, it was a pretty good day!

I'll probably do another batch like this in the next few days as well. There are certainly plenty of items yet to be added!

Hope everyone has a good night!

New Beta and Demo Builds: Crafting Overhaul, Random Skills, and Item Identification

I've just finished uploading new beta build 0.971b and demo build 0.971d. These builds include the new property-based crafting system, random skill selection, item identification, and several other fixes.

Updates to both the Beta and Demo

Both the beta and demo builds include the following changes:

  • Added multiple pages to crafting output, so player can choose intended outcome.
  • Added random skill/trait button on skill select page.
  • Added ability to scroll map using right-click (rubber-band-style).
  • Added ability to auto-identify items with appropriate skills/conditions (instead of crafting).
  • Added highlight to items on crafting page that are currently equipped/contain items.
  • Added ability to destroy ingredients on certain recipes.
  • Added ability to transfer ingredients' components to crafted output, rather than ingredients.
  • Added code to change label of crafting yield to reflect the item(s) being crafted if "Confirm" is pressed.
  • Added ability for encounters to support item and/or ingredients as input.
  • Added code to reduce durability of crafted output based on consumed input items.
  • Added code to degrade components within objects, so they degrade concurrently with parent.
  • Fixed a bug that caused meat to be a valid ingredient for rough splints.
  • Fixed a bug that caused newspaper to be unusable in recipes (Item.clone ignored properties).
  • Fixed a bug that prevented roasting meat on a stick.
  • Fixed recipe to stoke small fire into medium fire.
  • Fixed torch recipes to degrade into just handle.
  • Fixed item degrading so that it adds new conditions before removing old ones, to avoid campfire degrading blindness.
  • Fixed bug that prevented space from working as hotkey in crafting.
  • Fixed a bug that caused encounters to remove too few items when in stacks.
  • Fixed several stacking bugs caused by StackItem. Dropping parts onto stack in can in jeans pocket, arranging part stacks on ground, etc.
  • Fixed bug in quick recipes that caused some ingredients to be missing.
  • Fixed bug in recipes that allowed non-solid objects to be used as small/medium flexible ingredients.
  • Fixed a bug in the treasure generation code which produced extra loot.
  • Changed crafting system to use item properties as ingredients, instead of specific item names.
  • Changed crafting to deduct turns based on recipe, instead of always 1.0 turns.
  • Changed prescription pills to require medic skill for ID, and use real generic drug names.
  • Changed items to have lower monetary value when unidentified.
  • Changed unlit torch recipes to require unlit kindling, not just kindling.
  • Changed sleeping pill contents to be unidentified.
  • Changed squirrel pelt to small animal pelt, squirrel meat to small chunk of meat, squirrel pelt glove/tunic to patchwork fur glove/tunic.

The biggest change will be familiar to those beta users who had early access to the 0.970t test build: the new crafting system.

IMAGE(http://www.bluebottlegames.com/img/screenshots/screenshot-2013-06-04.png) New Crafting System - based on item properties, and with caution highlighting.

In this new system, the recipes will accept any item that fulfills requirements, not just the ones I've specified by name. So if you're trying to make a torch, you can use more than just a stick and a dirty rag. Crowbars and wrenches will suffice for the handle, and any flexible, flammable sheet will work as a torch head. Similarly, fire can be kindled with plastic bags, paper, and even clothes, so you don't have to rely solely on twigs anymore.

Furthermore, the crafting UI will show you each possible outcome for your ingredients at the same time, and they can be seen using the arrow buttons above the yield box (similar to switching pages in the ingredients or quick recipe area). This way, ingredients with multiple outputs can be controlled by the player.

Another big difference is that items like berries, mushrooms, and pills are automatically identified by players with appropriate skills. Otherwise, they use generic names. No more crafting required to identify most objects.

Finally, the crafting system now has different crafting times for each recipe, so most crafting attempts should take less than one full move now.

Also, the skills page now has a "Random" button, which lets the game choose your starting skills and traits randomly.

Changes to the Beta

In addition to the above updates, the beta has the following changes:

  • Changed isotope mine shaft encounter to be abandoned and resumed at each stage of exploration.
  • Changed isotope mine shaft encounter to be closed after ladder breaks.
  • Fixed a bug causing camp conditions to be stuck on player after save/load.
  • Fixed several encounters that caused player to lose shoes and other items repeatedly instead of just once.
  • Fixed isotope mine optical zoom option to use any item with zoom.
  • Fixed bug that prevented lighter from being a valid response in isotope mine shaft.
  • Removed gelli bear reward from old lady encounter.

Most of these are fixes to encounters that should improve their flow and logic. There's also one bug fix which might solve issues with acid rain/heat stroke bugs after loading a saved game.

As always, if there are any issues that arise with the new builds, let me know on the forums. I'll do my best to fix bugs as they are discovered.

Hope you enjoy the new builds!

Free NEO Scavenger Giveaway!

Heads-up, folks!

Want a free copy of NEO Scavenger? ne_zavarj is giving away Desura keys to 10 lucky posters in this thread:

http://www.gog.com/forum/general/10_neo_scavenger_desura_keys_are_waiting_for_their_new_owners

Note the rules carefully! (Desura username must be included in post for ne_zavarj to award it to you!) Winners will be chosen, June 10th, 2013.

Each Desura key unlocks access to NEO Scavenger at Desura, which can also be used to redeem a copy at bluebottlegames.com, using the Desura Connect feature.

Good luck to all entrants!