I managed to overcome a few more obstacles with hacking today.
First of all, I decided to move forward with the encounter-based hacking system. The player can "use" a powered, unlocked laptop to start doing things with it. The encounter will then show available software. Choosing hacking software then shows all available, locked, powered laptops, and choosing said laptop results in an unlocked laptop. Charges are deducted from the host laptop when software is chosen, and the target laptop when the target is chosen.
In order to make this work, I have two new item subclasses: hardware and software.
Software is a pretty simple subclass of a regular item. It just passes any charge requests to its parent, the hardware that holds it. And since software can't exist outside of hardware, that's about it.
Hardware is a bit more involved, but still basically a regular item. The main difference is that any software items inside it become inaccessible when the hardware is closed, off, locked, etc.
The changes necessary to the encounter system turned out to be pretty simple, too. I just created a new encounter flag called "hacking," to differentiate it from "normal," "combat," and "scavenge." The main difference with "hacking" encounters is that whichever item was used to reach it gets it's mode changed to the specified treasure, rather than the whole item replaced with treasure.
When all was done, I was able to hack one laptop with another, provided the hacking laptop was powered and unlocked, had the correct software (a laptop cracking app), and the target laptop was powered and locked. I was unable to add nor remove any software from laptops unless they were powered and unlocked.
I also made some changes such that draining an item switches it off automatically. This was already semi working before, for things like flashlights and goggles, but I formalized it a bit to work with the mode-switching system I built yesterday. I'll likely be changing flashlights and goggles to use this system, too. That way, they can be switched on and off at will, rather than always/only on when equipped.
So, we're getting there! There's still the niggling issue of being able to see software while the laptop is locked and/or shut off, and it's a bit weird to be able to see a battery's charge with one's eyeballs (as opposed to a voltmeter). However, those are minor issues I could live with if need be.
Next, I think it'll be time to start adding more hardware and software, to make sure the system holds up. And then, tying it into the economy/junk store. Hopefully, hackers will have more stuff to do soon!
That's all for this week. Hope everyone has a good weekend!
Despite yesterday's Greenlight excitement, I actually still got a bit of work done on hacking tools.
As mentioned previously, I've been struggling with a few obstacles for handling the many modes of computers, their software, and the way one can be used to affect the other. After doing some thinking aloud, and reviewing comments and suggestions from players, I decided to use the right-click context menu for switching item modes:
In the picture above, we have a laptop "off" (top) and "on" (bottom) modes. By right clicking the laptop, the player will be shown a list of modes the item can switch to.
In the case of the off mode, the laptop can either be switched on, or closed. Switching on requires that the item have enough charge to be on (typically, at least 0.1 hours of charge left). If the user tries to switch it on without enough charge, a message will appear in the log window stating as much.
Similarly, the laptop can be closed when in off mode, which makes it smaller so it's easier to transport. Once switched on, the laptop can, of course, be switched off at any time.
These three modes exist in both a "locked" and "unlocked" version, so the locked version will produce the login screen we see above, while the unlocked version will show a desktop screen. Only the unlocked version will be usable in any meaningful way. E.g. if the user wants to hack a computer, the laptop they're using to hack with must be on and unlocked.
So far, this is working out pretty well. I can switch modes and see the item change in real time, the battery charge matters, and even space matters (i.e. the laptop can't be opened in a crowded container if the resulting item won't fit, and a message appears saying so).
Furthermore, this seems to work with the idea of "using" the laptop to start a hacking encounter. Since the unlocked+on laptop is a discrete object, I can make it such that only that object type can be used. All others will simply lack the "use" option. And what's more, once in the hacking encounter, I can limit any hacking targets to items that are powered-on and locked, again, because those modes are discrete items I can filter out.
However, there are still some obstacles to overcome.
For one thing, I still have to figure out a way to preserve item contents when it gets switched from locked to unlocked in a hacking encounter. Right now, encounters can add and remove items from the player, but they can't switch an item mode. Add/remove will cause a new item to spawn, with default contents, instead of preserving whatever was inside before (which is what a mode switch would do). I may have to upgrade encounters to allow for mode switching, but I want to see if I can think of any more elegant solutions (e.g. less special-case, and/or using existing systems).
Another thing I haven't tackled yet is how to handle software vs. batteries in a laptop as it gets switched on vs. off. In theory, software should only be accessible if the laptop is both on and unlocked. Meanwhile, the battery can be accessed at any time.
Unfortunately, items can't make this distinction yet, so I need to think of a trick for that. It might mean special-case code for hardware/software that locks and hides software until it can be accessed. Or, like above, there might be a more elegant way.
Finally, I've only touched on the idea of how to handle software. Will the user choose a powered iSlab and cracking software to signal that they want to crack a locked iSlab? Or should I just make the cracking software itself be "usable" to launch an encounter? If I do that, can I discharge the laptop during the process?
And what about the iSlab itself, and its software modes? Are there just multiple iSlab items in the game, one for each mode? That probably makes the most sense, and as long as there aren't a huge number of apps, it's probably manageable. My main concern before was if I needed to have one iSlab for every combo of contained software, and I think that's solved by this mode system.
So there's still work to be done, but it's coming along! It feels good to have at least a few issues resolved. Hopefully, I can nail a few more tomorrow. Good night, all!
Good news, everyone! NEO Scavenger was greenlit today!
I was going about my usual morning routine, when I see an email pop up in my inbox: "you just got greenlit." I stopped whatever I was typing, and immediately checked the link. Seeing that green banner across the top sent chills down my spine.
NEO Scavenger made it!
I've been sitting at rank #30 to 50 for such a long time, I figured I'd have to do a few more rounds of publicity to make a dent. I even did a tentative start last week, and was planning on resuming later this week.
Then, out of nowhere, Valve decides to slam 100 titles down the hatch at once. "Stress testing our system," they say. Well, whatever the cause, I'll take it!
What Does This Mean for NEO Scavenger?
Well, nothing changes just yet. I have to submit a bunch of paperwork to get enrolled, and then figure out a release date. So priority #1 is still getting NEO Scavenger finished.
The main difference is that I no longer have to worry as much about doing publicity pushes to get enough votes on Greenlight. Now that I'm accepted, there's a good chunk of publicity that comes free with launching on Steam. Future sale prices (e.g. holiday sale) will help, too.
I may still do some publicity pushes in the meantime, but they'll mainly be for increasing sales (and therefore, funding).
There's also a chance NEO Scavenger could be accepted into Steam's "Early Access" program. Basically, that means NEO Scavenger could go on sale through Steam as a beta, much like it is now on my site and Desura. Doing so requires that NEO Scavenger has certain Steam hooks integrated, so I'd have to figure that out before I make any progress there.
Will Existing Customers Get Steam Keys?
This question comes up a lot, and my answer is "yes." I'm not sure how it works, or how other developers do it, but I want to give existing Blue Bottle Games and Desura customers access on Steam. So as long as there is a way, it'll be done!
Will Customers from Other Sites Get Steam Keys?
If you're a customer from the Groupees Be Mine 5 bundle, you should've received a Desura key, so you're covered, too.
As for the rest, it'll depend. Not every vendor makes this process easy (or even possible), so I don't want to promise anything. So for now, only Blue Bottle Games and Desura/Groupees customers get automatic Steam access.
Thank you to everyone for your support, votes, and spreading the word. We made it happen!
Making art was fun, but now the hard part: making this stuff actually do what I say.
A lot of the groundwork for these tools should already be in place. Systems in the game include:
Ability to restrict items to certain container types. (e.g. an app may only fit in a phone/tablet, while a program only fits in a laptop. But I could also make data fit in either container.)
Ability to launch an encounter by "using" an item (e.g. the Cryo window can be used to explore Exam Room 17)
Ability to create a new item from one or more tools and consumable ingredients via crafting.
Ability to make items bestow buffs/debuffs based on whether they are charged or not, and which slot they're in. (e.g. night vision goggles bestow night vision when worn on head, but nowhere else)
Ability to determine if an item is charged.
Ability to discharge an item when used, per-hour while equipped, per-hour all the time, or per-hex moved.
Ability to discharge and degrade an item when used as a tool inside an encounter.
Ability for player to add/remove charges to an item manually.
Based on the above, I think I can make different hardware types able to store different software items. I can also make held/equipped items bestow a buff/debuff (e.g. iSlab in lamp mode). I'm pretty sure I can launch a hacking encounter, similar to scavenging, by clicking "use" on an unlocked laptop. Once inside the encounter, players could choose cracker software to unlock phones, etc. Or they could use data-mining software on unlocked phones to get data "treasure."
That all seems straightforward. There are a few hang-ups, though, that I need to sort out.
For example, if a tool could be used in multiple ways, how would the user signal a mode change? E.g. how could the user switch between off, GPS, and lamp modes?
Let's say iSlab + GPS app = GPS iSlab. So far so good.
GPS iSlab + lamp app = lamp iSlab. Also good. However, how do we go back to GPS?
Maybe GPS iSlab + lamp app = lamp iSlab + GPS app. That works, as long as there wasn't another app inside the iSlab before crafting. What if there was a botany app, too?
I guess I could just say the apps are tools, like using trapping as a tool to get skin and meat, instead of just meat. That way, whatever apps the player had to start with are preserved. However, I'd have to make sure the newly-output iSlab gets those apps added to it again, because right now, any items inside a container just get dropped on the ground after crafting (to avoid being lost forever in a non-compatible output item).
Doing mode switching via encounters might run into the same issue, as it also adds/deletes items with each new screen.
Then, there's the question of access to apps while the tool is uncharged. Players can add/remove charges from an item in the inventory screen, so they may remove all charges from the hardware, making it useless. However, the game would still let them access apps to move around, illogically.
Plus, the game doesn't necessarily know which app is in which hardware when it comes to crafting or encounters. So any encounter or crafting operation is just going to show all available apps, regardless of which tool they're in (and whether that tool is charged).
So yeah, a bit trickier than I originally thought. Some time away from the problem might help, so I'll see how it looks tomorrow morning. Maybe a fresh brain will reveal something. And if not, there's plenty more to work on while this stews!
Last week's work on hacking tools and treasures continues.
As mentioned last week, I've been working on ways to flesh-out the hacking skill in NEO Scavenger, to make it a more worthwhile skill. There are places in the game where it can be used, and plans for more in the future, so it'd be nice if the skill wasn't dead weight in between those instances.
Adding to the iSlab and laptop artwork from Friday, I drew some item artwork for smartphones and cellphones. I also added a battery for the laptop.
As you might have noticed, I've made a few changes to the screen art for each. Previously, I had different screen art for each "mode," such as the iSlab lamp app and GPS. However, upon further thinking, this might be an unsustainable precedent. Every time I want to add new apps to the game, I'd have to add new screen art for each piece of hardware, and that's a scalability nightmare.
Instead, I decided to trim each hardware art set down to three images: off, locked, and unlocked. That way, the item can be either unpowered, powered but inaccessible, or powered and usable with any app.
I'm still not decided on how this stuff is going to work, in terms of UI and game code. But I have some ideas. The following is a brainstorm of things I'd like to try, if it's not too crazy in terms of code:
Some hardware will start locked (common), others unlocked (rare).
Software can only exist inside hardware.
Hardware cannot be hacked nor used unless powered.
Hacking skill and tool required to unlock hardware.
Lamp software only works inside iSlab or smartphone, and should work like flashlight.
GPS software only works inside iSlab or smartphone, and could reveal nearby hexes, spawn new scavenge sites nearby, and/or reveal creatures carrying GPS nearby.
Hacking software only works inside laptop, and can be used with powered laptop to "scavenge" iSlabs, smartphones, or cellphones for bank account info (rare). Somehow this bank info can be transferred to player's account, maybe only via DMC activity.
"Scavenging" iSlabs, smartphones, or cellphones with hacking can also produce important personal info (rare) that a fence in the DMC or sprawl will pay for.
Alternately, "scavenged" personal info could be email snippets that reveal setting background info, much like headlines.
The DMC/sprawl fence will buy locked and unlocked hardware at a flat rate, even when not hacked. Unlocked will be worth more, but neither will be worth the rare data/paydirt found via hacking.
Field guides may be substitutes for certain knowledge skills or recipes. This could affect balance, though, so I'll have to tread carefully.
And, of course, there's encounter stuff to be added (e.g. using computer skills in the DMC, in a digitally-secured facility, or work done for Hatter, etc.).
Also, all of the above comes with a big caveat that it's theoretical until working. It sounds good on paper, but there are some tricky UI and game code hurdles to overcome with the above.
However, I think a lot of the above could make hacking more fun to play with. It'd be a huge trade-off against more practical wilderness skills, but it might make the proper blend of urban and wilderness skills lucrative.
Still lots to figure out, but that'll be all for today. Hope everyone has a good night!
Since Ludum Dare is launching today, and the indie press is likely to be busy with the contest's activities, I decided to put off the PR push until after the weekend. I've certainly got plenty to work on yet, and I don't want to get lost in the blast radius.
Do be sure to check out the games folks are making, though. You're guaranteed to have hours (maybe weeks) of playable content after all is said and done!
Toys for Hackers
Instead, I decided to turn my attention to skills in need of some love: hacking, electrician, and mechanic. And to start things off, some hacker toys:
I'm considering making the iSlab reconfigurable into a few different tools, such as a lamp and a GPS. The iSlab will be useless without a charged battery (top right). When powered, however, players can switch the iSlab between different running apps. I'm thinking it may be via the crafting screen, but I'll have to test that out.
Below the iSlab, there's a laptop. It'll work in a similar way, though it'll likely be able to do some things the iSlab can't. In particular, I'd like to try and make it a potential hacking tool. Perhaps some (most?) iSlabs are locked until hacked, so players with hacking skill and tools have quicker access to the iSlab's features.
I'm also considering making the player's money stat a bank account at the DMC, so it makes a bit more sense than ambiguous "apocalypse dollars." If I do that, I can also make it possible to hack bank account information out of electronics items such as iSlabs, laptops, or maybe even by doing something inside the DMC itself.
Then, finding iSlabs is more of a game, as some may have useful data on them (e.g. bank account info or software). Hacking will still be a skill better suited to near-DMC use, but it'll have more opportunities to be useful in the wilderness (in addition to any encounters that might come up).
I still have some testing to do here, to make sure all these ideas work. And, of course, electrician and mechanic are still in need of lovin'.
But making those skills more valuable was a step long overdue. Between the changes above, and future content/encounters, hopefully techy type characters can have just as much fun as brawlers, trappers, and sneakers.
Yesterday's build seems to be doing well so far. The reports have been pretty positive, so that's good news! I was waiting to see if any major issues came up, because if not, I think it's time for me to do a little bit of hawking wares.
Today, I spent most of my day compiling data on all the press outlets I've spoken with so far. I collected names, email addresses, links to relevant articles, and dates for my last contact with them. I also started shopping around for YouTubers who do Let's Plays and similar videos for indie games. I'm hoping to start contacting a few to see if they'd like to do a video on NEO Scavenger.
So if you guys have any favorites out there, let me know! Especially if they're into games like NEO Scavenger. With some luck, and some help from the vidcaster talent out there, maybe NEO Scavenger can reach interested players who haven't seen the game yet. And what's more, I think a few lucky shots of publicity could tip the scales on Greenlight.
I've just finished uploading new beta build 0.976b and demo build 0.976d. This update includes some rebalancing, stability and memory leak fixes, new UI tools, and new missile behaviors.
Updates to both the Beta and Demo
Both the beta and demo versions have quite a few changes and fixes, including:
Added code to recycle GUIFitItemResult in GUIInventory update loop, to reduce memory leaks.
Added delete cursor mode back, mapped to 4 key.
Added random encounter to help players that are unfairly hypothermic from bad luck in the first 24 hours.
Added mousehweel support for selecting attack modes.
Added code to improve spying feedback when AI approaching loot.
Added code to make AI seem more interesting when spying.
Added code to prevent messaging player when distant AI has items degrade.
Added message to let player know when scavenge sneak check fails.
Added code to message player when creature is taking or dropping items on ground.
Added code to make spears impale and cause penalties until removed.
Added .308 rifle recipes to allow adding a scope to a strapped rifle, and vice versa.
Added stack info to items in container preview popup.
Added code to default cursor to take mode while in encounters/battle, and switch back when done.
Added code to prevent same item from being used as multiple consumed ingredients when crafting (e.g. pill bottle counting both as container and small parts in noise trap).
Changed scavenging encounters so they don't spawn creatures, but rather attract nearby creatures, if any.
Changed the way images are loaded and stored, improving memory usage.
Changed the way item sprites are handled, to reduce memory leaks.
Changed creature zones so starting area spawns bandits instead of raiders, and 1 instead of 1-2.
Changed item pop-up to accommodate more longer newspaper articles.
Changed long newspaper article to fit better in limited space.
Changed Lure to be available less often.
Changed sleeping bags to work on ground as well as camp.
Changed wording in .308 rifle recipe for consistency.
Changed wording in "Long shaft" to be "Large shaft" for consistency.
Changed fur-wearing condition to use term "hide" instead, for consistency.
Changed container size properties so metal sauce pan can do 2x and 3x water, and bottles/cans cannot.
Changed loot tables to produce fewer nanorobot kits and more saucepans.
Changed mushrooms to degrade over time.
Changed HVAC recipe to accept non-waterproof sheets as ingredients.
Changed electric charge to not be usable as heat source.
Changed lockpicking scavenge option to only allow lockpicks if skilled, so player doesn't have to use skill explicitly.
Changed recipes requiring monocular and binocular optical zoom to only accept small or medium ingredients (to avoid using scoped rifle and other large items as inputs).
Fixed a bug that caused scavenging to require selecting both lockpicking skill and lockpicks when it shouldn't.
Fixed a bug that incorrectly nullified old object references.
Fixed a bug that caused crafting to break if multi-page yield included a broken object.
Fixed a bug that prevented player from being able to offer surrender.
Fixed a bug that misreported charges remaining in attack mode UI.
Fixed a bug that caused quick recipes to sometimes leave crafting button active after crafting complete.
Fixed a bug that caused quick recipes to sometimes craft wrong or missing output.
Fixed a bug that would leave crafting page buttons active after crafting.
Fixed a bug that sometimes prevented creatures from from spawning.
Fixed a bug that allowed non-raw meat to be cooked or cured.
Fixed a bug that caused item pop-up info to report wrong charge count when charges were stacked.
Fixed a bug in wound slots that made right and left arm appearances mirrored.
Fixed a bug that caused pain indicators to be on wrong side when in 1360 mode.
Fixed a bug that caused lights and nightvision to be unavailable in scavenge encounters.
Fixed a crafting bug that caused a null pointer exception when a consumed ingredient was also a tool.
Fixed a bug that caused stacked items to have wrong components when shown in crafting screen.
Memory Optimization and Stability Fixes
One of the biggest changes in this build is the way memory is managed, particularly for items. Items should now use much less memory than before when not currently visible on the inventory screens. In practice, this should mean that the game is less likely to crash due to memory leaking as one explores more of the map.
In addition, several bugs in the crafting system have been fixed, which should reduce the number of cases where the game starts acting funny (clicking not registering, crafting failing, etc.).
Another major change to the game is the way creatures are spawned. When scavenging, creatures will no longer spawn in the same hex when the player's sneak check fails. Instead, the player is alerted that they might've attracted some attention. Any creatures close enough to hear/see the player's activity will head towards the hex to see what's up.
Additionally, the creatures most often seen in the early game are now bandits instead of the tougher raiders. They'll come in smaller groups, too.
And for early games where bad random loot drops combine with freezing weather, there will be some relief against unfair hypothermia.
New UI Tools
The delete cursor is back! Now, if the player holds the 4 hotkey, they can rapidly delete items much like they would use them. Also, the mousehweel now changes attack modes.
Updates to the Beta
In addition to the changes above, the beta has the following updates:
Added code to scatter missed missiles in adjacent hexes.
Added code to transfer missile into wound slots if weapon does enough cutting damage.
Added code to drop missiles impaled in wounds to the ground for retrieval when creature looted/dead.
Added code to allow impaled weapons to cause damage when removed or over time from being bumped.
Added code to degrade charges when attack mode used.
Changed flashlight to always have either 0 or 4 batteries inside.
Changed slung pebble to have lower damage, so it's differentiated from stone a bit more.
Changed shopping cart parts to degrade with cart, instead of remaining at 100%.
Changed bows not to count as shafts in recipes (e.g. making spears, greenwood bow).
Fixed a bug that allowed junk market exploit if game saved at midnight.
Fixed a bug that caused missing flashlight image when wielding flashlight.
Fixed 1360x768 sling attack mode image.
Fixed box to not be wearable as a backpack.
Fixed a bug that caused shopping and box carts to be too big for crafting screen use.
Removed container property from jar of eyes.
Removed ability to retrieve primitive missiles immediately after firing.
Most of these changes are small tweaks and fixes. However, one bigger change involves primitive missiles. Now, primitive missiles can no longer be retrieved immediately after firing. Instead, those that miss will end up in an adjacent hex. If the missile hits, and it does enough cutting damage, it'll impale into the wound. Impaled missiles can be removed by the target, causing further wounding, or they will appear on the ground when the target dies. Blunt missiles, like stones, will simply disappear if they hit.
Overall, the above changes should make both the beta and demo smoother, more fair experiences. As always, if there are any troubles with the new builds, let me know!
I continued work on yesterday's optimizations, and I just about have them working as intended now. Once I fixed a few issues with the way items have their sprites created and destroyed, I was able to make the game only load the necessary item sprites while the player was mucking around in the items screen. Otherwise, item sprites are unloaded to save memory.
I also found a helper object that was getting created each frame (used to store coordinates and other info when fitting items into a grid). By recycling this item instead of creating a new one, I think I further helped the garbage collector.
As a test, I continued my big save game where 25% of the map was explored, and continued exploring. And in the process, the memory seemed to stay pretty stable. In fact, it even dropped a bit! (likely due to creatures dying) I still have one issue left to deal with when switching resolutions, but this should be a major improvement for folks who saw the game crash due to memory leaking.
I also spent some time working on bugs, both newly discovered in 0.975t and old.
For one thing, there was a bug revealed by the spying code which involved AI having bad goals. I made a few fixes in there, and also added some more elaborate AI messaging when spying under certain conditions.
I made a few adjustments to newspaper articles so the full text and headline could fit on the screen.
Scavenging still had some leftover settings which required lockpickers select both the skill and picks when picking a lock. I forgot to remove that flag in a few places, and the next build should only require the picks.
AI should no longer spam the message window with item pick-ups and drops. And furthermore, AI items degrading should now only be messaged if the player is in the same hex.
I re-added some text to let the player know when their scavenging sneak check fails, as suggested by some players. With creatures' appearances now a bit subtler, this should make it clearer when the player is at risk of being discovered as a result of scavenging.
Finally, I'm looking into whether I can make missed projectiles just appear in a random, adjacent hex. It seems like it should be easy to do, and logical, so I'll look more into that tomorrow.
I decided to take a look at performance and memory again today. A few tech support forum posts suggest that the game is still suffering from memory leaks and crashes, among other things. So I wanted to see if there was anything else I could do to improve stability.
As an experiment, I decided to give a character extreme vision range (all the eye augmentations), and just start teleporting around the map to reveal as much as possible. After getting about 1/4 of the map exposed, I noticed the memory was creeping up near 1GB. For reference, the game is in the 300MB range when it starts.
I created a save file, and proceeded to start poking around using The Miner. The Miner is handy tool I picked up a while back when I was last doing this type of work. It allows me to peek at the way memory is allocated and garbage collected, and see some other useful performance metrics.
Using the The Miner to look into what's happening with the large save file I created, it appears that a large part of the memory is wasted as new items are added to the map. Specifically, I was being sloppy about the way item graphics get initialized. And in longer games, there are a lot of items initialized
After a few hours of tweaking, I was able to make items load without initializing any graphics. Basically, instead of setting up the item image, stack counter, and other bits, it just loads the item's position and dimensions for reference. And the result was a 300MB drop in memory use after loading the aforementioned save game. That's pretty good!
There are still some issues, however. For one thing, I need to make sure the items have images when they need them, and release the images/memory when the player's done. In theory, this should just mean images are added and removed as the player switches into and out of inventory screens. (AI uses items without images, since I can just use height and width to position items for NPCs).
By the time this evening rolled around, I had a fairly successful test running. It has some issues with duplicate images appearing when switching screens, but I think I know why.
Once finished, this should help with crashes in some of the longer games. It might not solve everything, but a 30% reduction in memory is a good start!
I've just finished uploading beta test build 0.975t, which consists of some significant gameplay balances and bug fixes. This test build is a prelude to a full suite of beta and demo updates, assuming no major errors are found.
One of the bigger changes in this test build is the way creature spawns happen. When scavenging, attracted creatures will no longer appear in the same hex as the player. Instead, the game will alert any nearby creatures to the player's presence, and those creatures will approach/flee accordingly.
Also, the starting area should prefer bandits to raiders, which are slightly less well-trained. Furthermore, the number of bandits typically found will be smaller than previously encountered raider groups.
Early Onset Hypothermia
I've also added an encounter which shows up in some early games when the weather is particularly harsh. If the player is unfairly being frozen to death and not finding clothes, this encounter should give players at least a fighting chance.
Primitive missile weapons no longer drop their missiles to the ground after being fired. The missiles are lost unless they stick into the target, in which case they can be recovered when the target falls unconscious or dies.
Missiles stuck in a target represent health hazards from wound exacerbation and removal. Missiles should also degrade when fired, unlike before.
New UI Options
The "Destroy" cursor is back! Players can once again quickly delete large swaths of items by holding the 4 key down when clicking. Also, the mouse scroll wheel now maps to switching attack modes.
And in encounters and battles, the cursor will now default to take/drop, and return to whatever the player had before when done. I think quite a few people didn't realize they could advance encounters with a single click and spacebar, and this might help.
Crafting and Other Bugs
Quite a few bugs have been fixed in the crafting system, especially the Quick Recipe system. Incomplete crafting, null pointers, instability, and poorly-prioritized ingredients should now be much improved.
And several other bugs have been fixed, including many recipes and ingredients.
Overall, this test build should be a little bit more fair, and a lot more stable. Let me know how the changes feel, and if you notice any major issues I've missed. If it seems pretty safe, I'll roll it out to replace all the 0.974 builds!
Well, at least some major ones. I did some lengthy playtesting today, to see how stability fared in longer sessions, and I finally ran into some of the harder-to-find issues you've reported!
It looks like a lot of the problems we were seeing were due to a bug in the way quick recipes interacted with multiple yield output pages. If the player tried to use a quick recipe after manually crafting something on page 2 or higher (from the possible crafting yields), the game would start losing track of items. There were also some bugs that caused the crafting button to remain active even when there were no valid crafting yields.
So I spent some time in there, fixing various bugs, and I think it's running smoothly now.
I also started experimenting with a different way of spawning creatures.
Previously, creatures could be spawned either on the map over time, or as a result of scavenging. However, this often resulted in raiders ganging-up on the player early in the game, and felt unfair. It also felt somewhat unrealistic, as some players described a feeling of conjuring monsters from thin air just by scavenging.
I changed scavenging such that it no longer spawns creatures, and instead, causes creatures nearby on the map to come check things out. There aren't always creatures nearby, though, so I'm still testing to see if the map feels too empty. My tests so far feel pretty good, though. (Less crowded than before, but still populated.)
I also did some switching around so that bandits appear where raiders used to in the early game, and in fewer numbers. Bandits can still be formidable, but less-so than raiders. Between the lower creature count and change from raiders to bandits, I felt the early game was much more manageable.
And speaking of the early game, I added a random encounter to help with games that start with really harsh weather. Death by hypothermia was basically guaranteed in some games, which is unfair, so this new encounter should help reduce the number of false starts. It won't always show up in a game, but hopefully those that need it most will get it.
Apart from that, I fixed a bug that prevented the player from being able to offer surrender. There was a bug misreporting the number of charges in attack mode UI. The flashlight image was missing when wielded as a weapon. And the sling had a tiny graphic when in 1360 mode.
I also adjusted the Lure battle maneuver to be available less often. It's pretty powerful after my last change, so having it several turns in a row was a bit too much.
Finally, I added some code to message the player when AI is taking or dropping items in their tile. This should make it a bit clearer when items go missing, as it should say things like "Bandit picks up metal saucepan" instead of the saucepan just disappearing.
I still see at least one bug in the music code, which is preventing music from playing after a while. So that'll be first thing tomorrow.
I've posted a question on /r/AskReddit which is related to NEO Scavenger. It asks what you would do if certain reality-altering powers were available to you. I have some answers of my own in mind, but I'm betting I haven't thought of everything, and I'm interested to see what people come up with. The creativity and wisdom of a large group could completely blow my assumptions out of the water, in other words :)
It's a bit spoilerish, if you're sensitive to such things. However, it's more about the setting than the story. It would be akin to reading a role playing setting book, and learning the world's quirks, without knowing the dungeon master's adventure plans. (e.g. learning that the Spelljammer universe consists of crystal spheres and phlogiston, but not that the DM plans to bestow a Cloak of the Void to you, or pit you against the leader of the Rock of Bral)
I managed to fix quite a few things today, but it was pretty boring. "Weeding a garden" was the first thing that came to mind when summarizing my day: lots of small, unexciting-but-necessary changes and fixes.
The first thing I tackled was to bring spears in line with the arrow changes I made yesterday. With most of the legwork done already, it was just filling in the slot graphics and stats for impaled spears. I briefly considered adding bullet shrapnel, too. However, it'd be impossible to bandage a wound with the shrapnel in place (game would block the slot, which is unrealistic/unintuitive), and as it turns out, bullets are rarely extracted in real life medicine. It might've been cool to have, but not worth rebuilding the wound system to support layered shrapnel/rags.
After that, I made several wording changes to items, recipes, and ingredients, to help with consistency across all instances.
And then, recipe fixing time!
I changed the cooked and cured meat recipes to only accept raw input meats. I reworked container sizes, so 2x and 3x boiled water (or rags) can only be done in larger containers, like saucepans. (I.e. No more boiling 3x water in a soup can.) And speaking of saucepans, I did some loot table tweaking such that saucepans are a bit easier to find now. Conversely, nanorobotic health kits should be rarer.
Mushrooms will now degrade over time, like their berry counterparts. HVAC repair now accepts any large sheet object, instead of just waterproof ones (e.g. can use flannel sleeping bags now). Electric charges no longer count as a heat source (after all, it's the resistors that generate heat when electrified, not the electricity itself). Scavenging with lockpicks no longer requires the player to select both the picks and the skill. Instead, the game will only show the option if the player is skilled, and only requires the use of picks.
Recipes that previously accepted any monocular/binocular item now only accept medium or small items (e.g. no more making a scope with a strap out of a rifle and string). Also, I finally added new recipes for adding a scope to a strapped .308 rifle, and vice versa. You'll have to select the appropriate quick recipe to do so, but at least it's possible now without disassembling the rifle first.
I also finally added stack counts to items shown in container peek/preview pop-ups. And while I was in there, I fixed a bug that misreported number of charges in item pop-ups. Lastly, flashlights should now always have either a full load (4) or no batteries inside, instead of just half their complement.
Like I said, mostly small, boring, but necessary fixes and changes. Tomorrow, I'm thinking of looking into one of the bigger-ticket balance issues, such as the rate of creatures spawned (particularly in scavenging), or more ways to use mechanic/electrician/hacking. It should be a welcome change of pace.
As mentioned yesterday, I'm looking into ways of adjusting how primitive missiles are retrieved. Right now, when one fires a bow, sling, or other primitive missile weapon, they can simply pick up the fired missile after using it, even while still in combat. In practice, ranged attackers can just keep their distance from targets while firing, and never run out of missiles. It's not only unrealistic, it represents a balance issue.
While I could prevent creatures from accessing the items during battle, I'd prefer not to lock out item access completely. When far enough from enemies, I think it should be possible to access items and reload, pop a pill, take a swig of vodka, or otherwise do non-crafting things.
I'm going to switch things so that primitive missiles no longer drop on the ground when fired. Instead, they will disappear, as if they sailed into the distance beyond reclamation.
However, missiles that have cutting damage and which hit their mark, will now stick:
These stuck missiles can be retrieved from an enemy if one either loots or kills them. They'll just appear on the ground when the enemy is looted or dies.
Furthermore, removing such a missile will cause extra cutting damage, particularly for barbed cases (such as the broadhead arrows). They can be left in, but there's a chance they'll cause additional damage each hour.
Now, this means that sling stones and other blunt, ranged objects are at a disadvantage, since there is no possibility of recovering them. However, their relative abundance in the wild should make up for that.
Hopefully, this should mean primitive ranged weapons are now a bit more balanced when compared to melee and firearm attacks. It should add a bit more realism, and perhaps the new wound management will provide interesting challenges.
In addition to the above changes, I found and fixed a few bugs in the wound screen. There was a mismatch between left and right labels and slots on the arms, and pain images were appearing in the wrong place for some slots in 1360 mode.
Lastly, I nerfed slung pebbles a bit, to differentiate them from slung stones. The pebbles were almost as effective as stones, but could stack 20 high, making them a dominant strategy. Now, they should perform a bit more in-line with their smaller size. (Basically, stones should be used when you need to down an enemy fast, while pebbles are better for enemies you can stand to fight a bit longer.)
That's all for today. Hope everyone has a good night!
It was back to bugs today. After several days of exploring alternative technologies, it seems Flash/AS3 is probably still the safest way to proceed. It's not ideal, and it cuts short some possible features, but existing customers won't lose anything, there's no down time, and no extra risk. My imaginary project manager is breathing a sigh of relief :)
My first bug after the hiatus was the scavenging with nightvision/light sources issue. That turned out to be a typo left over from when I converted scavenging encounters to use the new item properties. It should be possible to use any vision enhancements now, whenever they make sense.
I also decided to try a UI optimization I'd heard suggested: making the encounter/battle screen switch to the take/drop cursor by default, and switch back to whatever the user had before when done. There are quite a few players who complain about the tedious item dragging in combat (and encounters), and I don't think they realize they can advance turns with a single click and spacebar combo. We'll see if this change makes things a bit more tolerable.
Also, big thanks go to Bernd for emailing me a savegame with a hard-to-find bug inside. His provided save game helped me find and fix a null pointer bug that only occurred when an ingredient was serving as both a tool and consumed item. It's very likely that this bug occurred many times in a single playthrough, making the game increasingly unstable over time. Good catch!
There was a related bug in the recipes which made it possible to create a noise trap with just a string and pill bottle, and I think I've got that fixed now, too. The game was counting the pill bottle as both small parts and container, so I changed recipes to only allow items to fulfill one consumed ingredient requirement each.
I also fixed a bug that caused shopping and box carts to degrade without affecting their components. Now, the wheels and such should degrade along with the cart when used.
There was also a bug which caused stacked items to have the wrong components when disassembled in the crafting screen. This at least allowed for an exploit, if not a null pointer bug. So that should be a valuable fix as well.
Bows should no longer count as shafts in recipes, preventing things like spear-making with a compound bow.
Finally, I started looking into primitive missile weapons and the way the missiles can be retrieved. The attack, wound, and charge system is fairly complex, so I'm not yet sure what I can do here. But I have a few tricks I'm going to try.
That's it for today. Hope everyone's enjoying their weekend, and see you Monday!
Just a heads-up, we have house guests this week, and we're taking them out around town today. So there won't be a usual update this evening. I'll definitely be back to normal on Monday, but I may sneak in some work tomorrow to make up for lost time.
Yesterday, I mentioned that I was considering moving forward with AIR packaging for NEO Scavenger. This move was to address a few of the limitations I was encountering in Flash, without having to commit to the significant downtime and risk of changing technologies mid-project (i.e. HaxeFlixel).
However, some comments on yesterday's news pointed out that AIR on Linux might be a step back. My understanding was that AIR could be packaged and deployed without requiring any separate installs, but on Linux, AIR is frozen at v2.6 (predating captive runtime support). In practice, this means that downloading NEO Scavenger as an AIR application on Linux won't work out of the box. Instead, the user would see a prompt saying they were missing AIR, and would need to download a specific AIR runtime and install it first.
That's far from ideal, of course. So the next question is, will Flash projector format be sufficient?
So far, we've been able to get by using the projector format. All three platforms are limited to Flash 11.2, but otherwise, they're single files that execute cleanly after downloading. The downsides that I can see are:
Limited File Access - Flash cannot access the file system except when the user asks it to. This means I could only load a file that the user selects in a dialog, and only save a file the user selects in a dialog. That screws up the permadeath, which I know some folks wouldn't mind. But it also hampers things like quick saves/loads, and loading custom data (e.g. modding).
Steam Interop - I know that Lars was able to get Defender's Quest integrated with Steam using AIR, but I am uncertain if the same can be said for Flash projectors. There are a few other games out there that might've solved this, such as VVVVVV, Machinarium, and Binding of Isaac. Of course, this is hypothetical, as I'm not on Steam yet. But it'd be nice to get there some day :)
There are also some minor issues which might apply, such as flaky full screen support. Though if we're stuck on AIR 2.6 for Linux, that might be even worse than the Flash 11.2 fullscreen support there.
Neither of these are great options. HaxeFlixel might solve those issues, but is also the "devil we don't know." It's a lot of work, it's untested, and may have a raft of problems of it's own once we try it. Deciding against HaxeFlixel the other day was actually one of the biggest reliefs I've had in a while, so I'm not thrilled with the idea of putting that back on the table.
For now, it seems the best option might just be to stick with Flash projector. It'll suck for modding, and save games, but it won't be worse than what we have now. And come to think of it, at least it'll be identical to the browser version (rather than fragmented features and code between browser and desktop).
I'll have to think some more. Maybe modding and fancy saving are something better reserved for a NEO Scavenger 2. I might be able to improve save games a bit still using the Flash shared object system. It'll just remain difficult to find and manage the files in the special folder.
We returned from our camping trip last night, and it was back to business this morning.
Over the long weekend, I spent a lot of time thinking about whether NEO Scavenger should go forward using AS3 (current language), AIR (Adobe's preferred way of porting Flash to desktop), or HaxeFlixel (an AS3-like language that builds native apps for most platforms). This image roughly summarizes my feelings on the options:
As you can see from the bottom line, my decision was not made significantly easier by mapping out all the variables. I rather hoped that the chart would have a clear winner, rather than a 7% spread. Adjusting values for their weighted importance muddied the picture even further. Basically, what this told me is "yes, you are having a hard time deciding because the options are roughly equal."
Fortunately, speaking with actual, live humans turned out to be more enlightening. Lars Doucet saw my subtle cry for help, and the resulting conversation helped put a few things in perspective. Namely, that I might be able to get a good compromise on my goals by using Adobe's AIR with some specific packaging settings.
Using AIR means that I can bypass the clunky Flash projector build process, which uses increasingly out-of-date versions of Flash (limiting features to stuff from early 2013). And importantly, I shouldn't have to change any code, which means I should be able to continue work on NEO Scavenger with little interruption. (As opposed to porting the game to HaxeFlixel, which isn't too bad, but would require some down-time)
What's more, I think there might be a way to still get the benefit of file system access via AIR, so maybe I can improve save game and data-loading (i.e. modding).
I still need to get it working, though. I once managed to get it to work, but I have to dust off those files and make sure it still does.
It's not as fancy as going full HaxeFlixel, but I think I feel more confident about sticking with the old code and just finishing the game. As Lars said, "I stuck with DefQ1's old and grey engine cuz' hey, she worked, and I could hit my deliverables with it."
So that's tomorrow's plan: dust off the AIR project, fix it up, and see if I can get multi-platform executables running. Assuming it works, maybe I dive right back into content, bug fixing, and features!
Well, two more big steps forward today. I was able to get the HaxeFlixel port of NEO Scavenger's main menu compiled and running on both Mac and Linux!
Most of the work, surprisingly, was just getting both Mac and Linux OSes setup with the required libraries, compilers, and other such software. That, and me getting better acquainted with command-line usage in OSX and Lubuntu. It's been a while since I needed to manage files in a Unix-like environment, and definitely a while since I've had to fire up vi.
However, by early afternoon, I was able to get the Mac to compile a native version of NEO Scavenger's main menu, and everything seemed to look ok there. And after a few more hours of downloading and installing, Linux wasn't far behind.
Linux did present a weird issue, though. For whatever reason, the compiled executable wouldn't run if double-clicked via the file browser. Neither "Execute" nor "Execute in Terminal" options seemed to do anything (not even an error message or blip of a window). Just double-click, and nothing. However, executing the application from within the terminal seemed to work. So I'll have to figure that out.
Minor issues aside, this is pretty good news. It seems I can generate native versions of NEO Scavenger for Flash, Windows, Mac, and Linux using the same set of HaxeFlixel source files. It seems like we may be all clear to move forward on porting the rest of NEO Scavenger's gameplay code. It's a bit of an undertaking, likely requiring a week or more of editing. However, it seems like it'd be worth it (even if for no other reason than better native OS stuff like file access and performance).
I'll need to give this a bit more serious thought, though. And as it happens, I have a few days to do just that!
I'll be out of the office for the next few days as I'm off camping with Rochelle and her family. I'll be gone tomorrow morning until late Tuesday, so probably won't be back in the office until Wednesday morning. I'll bring a laptop in case any major issues arise (account access, order problems, etc.), so feel free to email me if things like that come up. I may be slow to respond, but I'll try to check emails periodically.
Enjoy the long weekend, for those of you that have it. And I'll see you guys Wednesday!