Hey Folks! Bit of an unusual day today. No real dev work as I spent most of the day on biz admin emails, site spam defenses, and app icon design. Still, I think some good progress was made!
First of all, the spam attack. It looks like the seasonal spam botnet swarmed by early this morning, leaving a trail of senseless Korean spam links. Annoying to wake up to, of course, but thankfully not hard to clean up. Just a few clicks and the users and all their content was zapped. I recorded IPs, usernames, and some other choice info in my "spammer investigation black book" for future reference. And setup a few new content filters in my site's blacklist. Hopefully, they're gone for a while.
Josh's latest track arrived, and I spent some time listening and taking notes for him. This one's for the space game's docking sequence, and is meant to conjure feelings of warmth and safety after a long journey. We both think it's really close, and just needs some sounds cleaned-up for clarity.
There were the usual admin emails, as well. Replying to partnership inquiries (e.g. publishing, PR), web designer updates, some fan emails. That sort of thing.
And finally, app icons for iOS. I have some placeholders already that Tiago and I use for the game, but I'm thinking of upping my icon game a bit. Instead of the game logo, I'm thinking of using the player's sprite with some colorful clothes and equipment. This way, it's a clear pixel art character dressed in post apocalyptic fashion. It's eye-catching, obviously a game, retro, and concise/easy to understand. Users who are into games like that should be interested in looking further, and people who hate pixel art can move on :)
Unfortunately, there's something like 24 different icon sizes for iOS to account for all devices, screens, and OS versions. Sheesh! There are also tools and templates for auto-exporting icons from a single image, but with pixel art, this may not be ideal. Still wrestling with this.
Hey Folks! Had a bit of a rough start this morning, but I think I'm gaining momentum again.
This morning was a terrible slog through mismatched Haxe libraries, compiler errors, and other issues. As usual, the tinkering I did in my library versions to make one project work (encounter editor) completely broke my other projects.
Incidentally, Tiago setup some batch scripts to help change libraries to and from what the project needs for just this reason. However, in the process of using them, I discovered a bug. Missing files, actually. For some reason, the GitLab repository was missing all .exe files from the Flixel and OpenFL libs. And that caused compile issues on my Windows (i.e. main dev) machine.
Fortunately, once I figured that out, it was an easy fix. I had the .exes in my downloaded lib folders from before, and could just copy them over. But Tiago's going to look into why the GitLab repo just ignored them during his check-in.
With that out of the way, I was back on the path to bug fixing. And I actually knocked off some pretty tricky bugs!
First, I had to (re)fix a bug in our old version of Flixel that caused the console debugger to disable keyboard if the game lost focus. Modern Flixel has this fixed, but we're using an older one for compatibility (and stability) reasons.
I also fixed a bug that caused a null pointer error when trying to use certain items' context menu. Basically, any item with mode changes would crash the game if you opened the context menu for it, closed inventory, and opened it again. Nasty!
And while fixing that, I noticed a related bug. The item popup peek would be empty if the inventory was closed while the popup was open, and then the user tried to view the item peek again. Not too hard to fix, but hard to find.
There's one more peek bug, too. Hardware items and their hidden contents when locked/off. Now that we use sprite atlases, this is broken until we rewrite it for atlases (instead of the old bitmap blitting code). Might be trickier, but at least we know the cause of this bug!
Not a bad day, considering the rough start. Hopefully, tomorrow continues the trend of more progress!
Hey Folks! Hope everyone enjoyed their (long?) weekend. We visited with some friends, Skyped with family, and generally enjoyed decompressing from the normal life stresses for a few days.
Unfortunately, I had to pronounce the NEO Scavenger Encounter Editor dead this morning. At least for now. After a bit more debugging, it seemed to be failing in ways that I could barely see, let alone fix. And what's worse, I discovered that the old (slow-but-functional) Flash binary I was using wasn't actually working, either. It was correctly loading and displaying the network of encounters, but when it saved the data, it corrupted special characters. This, in addition to the extremely slow writing process issue, pretty much killed the editor revamp as a viable task.
However, all was not lost.
As mentioned above, it did still show the data, even if it couldn't save it. And for encounters, that's a big help. Using the standard database editing UI, I could make any changes I needed to and re-export the XMLs for mobile. So in fact, I could still use the editor, just as a viewer.
And that I did! After a few hours of cross-checking and nudging data around, plus a few new marker conditions, I think I've got the first wave of achievements all done. All that remains for those now is to test on iOS and Android.
There is also a second wave of achievements, but they're a bit more tricky to check for. Instead of simple "has condition?" tests, they may require some more involved calculations such as passage of time combined with conditions. And an even harder third wave may require comparing data between games. But, it seems pretty doable, so I'm not worried yet.
Tiago reported in, and he had a pretty low progress week, too. What work he did manage to do was entirely sunk into memory leaks. And worse, he thinks this week may be slim on available time, too. However, we're hoping to both be back on track soon and "firing on all cylinders," as they say.
Hey Folks! Not a lot to show today, unfortunately. Still working on encounter editor issues. But I did get some cool stuff from Josh to review.
One of the tracks Josh has been working on for the space game has been a "take off" track. It fits the bill nicely, with a build-up leading to a vast, empty heartbeat style Great for setting the tone of a potentially deadly flight :)
I'm not sure yet if I will always play this track for take-off, but there are space games I really enjoyed that do take-off and docking tracks. Assuming it doesn't get repeated too frequently, I'll be trying the same. If repetition does become an issue, there are some tricks I'm sure we can try (easiest maybe to have a couple to cycle through). But this gets us rolling for the time being.
For the encounter editor, I decided to take another dive into the code. This time, I made some progress in narrowing down the problem. My encounter nodes are absolutely killing memory. The app thinks it's only using tens of MB, but according to Windows, it's inflating 100s of MB each second, capping at 1.8GB before crashing. So obviously something is amiss.
I've hacked apart my code and tested a bunch of stuff, and I know roughly where to look. But the feedback from the app doesn't help any more. So I've downloaded hxScout to see if I can tell more.
hxScout is a telemetry app for Haxe, and it can report things like framerate, memory use, garbage collection, etc. Useful stuff for memory debugging, and highly pertinent to the mobile memory leak stuff we're now looking at anyway (Tiago's using it as well for his bug). So getting this working was useful in a few regards.
It took some doing to get it running, though. In true Haxe fashion, I had to download and juggle my libs to get the right combo of versions such that every dependency worked. (Now I remember why I switched to Unity for the space game!) However, it's now working. As of this post, I have hxScout showing me useful callstack info, function processing times, and wild numbers of strings and arrays I'm instantiating.
I think I can use this to make a plan of attack for shoring-up the editor.
However, it's the end of the day. And what's more, the end of the week, since tomorrow is Thanksgiving. So I'll be out of the office until Monday. If you're into the turkey thing, enjoy the holiday! And if not, have a good weekend!
Hey Folks! Been a bit of a slow day today. I actually had a lot of time to work, but seemingly made little progress.
The main issue I'm encountering is that my old NEO Scavenger encounter editor seems to be dying. I was about to start updating some achievement data, which requires changes to some encounters' condition rewards, but ran into issues saving my work.
For one thing, the old encounter editor binary wasn't working anymore, and I couldn't compile a new one.
The editor uses php and mysql to edit the game's database. (I use the database to manage the game's data before packaging it for release.) However, the last time I compiled the editor was before the website was updated, and uses some out of date code. I had to update a boatload of stuff just to get it to run.
And even then, it was just enough to get my old Flash binary hobbling along. It currently takes something 20 minutes to write the game's data back to the database, while in the past, this was more like 20 seconds. I have no idea why there's a sudden jump in execution time.
I briefly tried updating the editor's code to bypass Flash entirely, since Haxe is now getting pretty stable. But I couldn't get it to launch without crashing due to memory limits. It was up to 1.7GB of memory before it gave up, which is pretty ridiculous. I mean, it's a lot of data. NS is data heavy, if nothing else. But it should maybe be half that in memory.
Anyway, it feels like a lot of wasted time there. I'm actually able to edit stuff slowly this way, or "by hand" by using phpMyAdmin (which is like editing text files in a web editor). But I'm thinking this may be a more serious problem. If I need to do any real encounter editing, this is going to be painful.
Despite all that, I did manage to fix a couple of achievements, so they should now trigger at the right times. And I've sunk at least an hour today reacquainting myself with the way the encounters flow and branch. Been a while since I reviewed that nest of wires!
Anyway, probably more of this tomorrow. Maybe I'll take another crack at the editor, and see if I can bring it into the modern times. Might be a waste of a week due to this and the holiday, but then again, who ever gets anything done on Thanksgiving week?
Hey Folks! Hope everyone had a good weekend. Getting ready for Thanksgiving season here, and have already had on TG-spinoff: Dessertgiving! (It's pretty much what it sounds like.)
Back at work, it was a bit of a slow day as I had to run some errands midway through. I did, however, update the site, and knock-off a few more bugs.
The site needed yet another patch, so I had to take it offline briefly to upload/install. It's not a difficult process, but tedious. Fortunately, it went smoothly, and we were back online within minutes.
In the realm of bugs, I was able to solve a small UI issue with decimals in the "moves left" area. And I also found and fixed some issues with saving preferences, mute, and autosave. Nothing mission critical, but some users will appreciate the game, you know, doing what they tell it to :)
Tiago's still tracking down a memory leak that will probably hobble/kill the game on iOS. He's seeing ~1MB per turn, and sometimes much larger spikes. Also, spikes when starting a new game.
If any of this sounds hauntingly familiar, you've probably been reading this blog for a few years :) I've asked Tiago to let me know what he's doing to test memory, and I'll see if any of the old Flash memory optimizations are the culprit this time around. (E.g. text rendering bloat, AI bloat, undisposed references between turns/games, etc.)
That's all for today. Have a good night, and see you tomorrow!
Hey Folks! Pretty standard bug-fixing day today. Trudging through the bug list a bit faster than we're finding new ones, so we're still on track.
Some of today's fixes include fixing redundant campsite log spam when autosave is turned on. The unsocketing/socketing of campsites was causing noise trap and other status messages to repeat each turn, which isn't very useful.
I also fixed a bug that caused the player to move if they clicked the slide-out tray I added. Simple to fix, but I didn't think of it until the bug showed up.
The unlicensed power tap stopped working, and it turned out to be a sign error in a loop for negative charge profiles (i.e. profiles that add charges per use, instead of removing). Again, simple fix, hard to find.
Finally, I updated the 1024x768 main menu and options UI to be a bit cleaner, as the mobile port had moved things around a bit.
Meanwhile, Tiago's fighting a bigger bug: memory leaks. There is still a slight leak in the game, especially battles, so he's been testing and tweaking that code. On the up side, he's discovered the joys of some handy debug commands, such as spawning a laser rifle :) (Though, my latest favorite is hitting the "K" key to cripple both arms on the current target in battle. What can I say, I'm a cruel game master.)
Anyway, progress is continuing there. Hope everyone has a good weekend, and see you Monday!
Hey Folks! Now that Josh and I have had a chance to hear the dynamic music, we've agreed to tweak it a bit in the future. Probably with some shorter pieces for more variety. However, before that, he's going to work on a few more standard tracks, to further nail down the style and have more reference material.
So, I've turned my attention back to the mobile project.
First up was testing achievements. Tiago was able to get the basic system running, and all seems well so far! What's more, I think most of the achievements should be pretty easy to do now that the system is in place. We're currently looking at about 20, most of which are hidden until found.
I also got a bit more testing in, and logged some new bugs. Some misplaced UI bugs, possible loot bugs, audio, etc. Nothing terrible, though those loot bugs could cause plot issues. Going to look into those tomorrow.
I also managed to fix an issue or two during the day. Campsites were getting dislodged when AI was in the player's hex with autosave turned on (usually in battle). It's possible this is related to the weird behavior on PC. At the very least, it causes misaligned campsite icons and temporarily invisible items. So maybe a long-standing bug fixed?
I also fixed the way stack remainders get positioned if the user slots a stack into a socket that only holds a single item. Normally, on PC, this isn't a problem as the remainder follows the mouse each frame. But on mobile, there isn't a constant mouse position update until the user taps again. So the remainder disappeared to the top left corner. I added code to leave it where the original stack was, for easier reference.
Finally, I did a bit of financial research and chatting with the accountant. Now that I have a corporation (LLC S-Corp), I have to figure out what to pay myself. And that decision is more complex than "how much do I want?" E.g. how much did the company make? How much did it lose to costs? What is a "reasonable" salary compared to non-salary distributions? Do I want distributions?
I'm probably too poor this year for this to be a problem, but this is good info to be aware of. You know, in case NEO Scavenger Mobile sells like hot cakes and makes me rich :)
Anyway, back on mobile dev for a while. See you tomorrow!
Hey Folks! I spent another day refining the procedural music mixing code mentioned in yesterday's post. It takes individual layers that Josh has composed, and randomly mixes and matches them to a rhythm to create an endless, non-repeating mix.
To help fix some of the timing issues I ran into yesterday, now the audio manager uses Unity's coroutine system. Coroutines are just a way of running code asynchronously (i.e. not interrupting the rest of the game), and one can set delay timers inside to control timing, too. This way, instead of randomly starting stopping all tracks each measure (4 beats or 2 seconds), I can kick off a track for some predetermined number of measures, then stop for a while, then start later.
The end result is that the individual tracks come in for longer durations before stopping again, and it sounds less frenetic.
I also added some code to reinforce start/stop times to be on the beat, as well as make tracks fade out rapidly (0.1s) instead of cutting instantly, avoiding clicks in the audio.
Overall, the result is pretty successful. It has some rough spots here and there, but the bulk of it actually sounds pretty good! And what's more, it's all a consistent style/mood, endless in length, and the randomness mitigates repetition fatigue.
I've send Josh a recording of it at work so he can hear for himself, and I'll see what he thinks about what we can do next!
Hey Folks! Took a bit of a diversion from the mobile project today. Josh just sent me some audio tracks for an experiment on the space prototype, so I wanted to get some feedback to him.
Since the player is going to be spending a while on the ship editing screen, we were talking about ways to prevent the music from getting repetitive. One way is to simply have a batch of songs to play at random, much like how NEO Scavenger does it. Josh, however, had an interesting alternative.
The idea is to try randomly layering some specially-constructed audio tracks to create an ever-changing soundtrack. If all the tracks have the same time signature, key, and tempo, they can fit together pretty seamlessly in various combinations. And depending on the number of samples, that variety can be quite large.
Right now, we have six track types: kick drum, high hats, percussion, bass, arpeggiator, and pads. And they all have a compatible 2-second measure with most events on the quarter or half notes.
And after a day of work, I've actually had a few variations of it up and running. The code itself is actually pretty simple. The hardest part was figuring out how to get Unity to load .ogg files from disk instead of using the Editor/Asset system. (A constant problem with a game like this that has procedural/runtime systems.)
And so far, it sounds pretty good! My first attempt simply had a 50% chance of starting a random track of each type, and if that track was already playing, it would stop it instead. The checks were conducted once every measure (2 seconds).
However, that approach had some flaws. For one thing, the player would usually only hear the first few seconds of each track over and over. Rarely would a track continue past the 2, 4, or 6 second mark. So a lot of the music was being unheard.
I made some adjustments to start at a random measure within each track, except the first time it's played. And that helped increase variety.
Another problem, however, is the timing of the checks. Setting a timer is pretty easy in Unity, but that timer can be messed up by slowdowns, alt-tabbing away from the app, and other system events. I thought I was using the right timers for these, but I think I need to change them.
Still, not bad for a day's work! I hope to have more tomorrow. Until then!
Hey Folks! Hope everyone had a good weekend. I felt really tired for some reason, but I seem to be back to normal today. I'll blame the baby's wonky sleep schedule, I guess :)
Today I tested Tiago's latest work on the in-app purchasing mechanism to upgrade from demo to full version on iOS. And I think we may have it! I was able to upgrade on my iPad from within the app (requires app to restart, though). I also was able to restore full version access if the app was deleted and reinstalled, as well as passing some other edge cases (failing authorization, new account, etc.). That's one big task out of the way, and one of the last few major ones!
I also got another 1-2 hours of testing done, and it's feeling even better now. A lot of the user input refinements Tiago's been working on went in over the weekend, and precision item placement is much easier now. It's getting harder to make mistakes in the item UI.
Also, I think I stumbled across not only one, but two of the most famous bugs on PC version: King Elias appearing and missing/stuck camp items!
After months (almost a year?) of trying and failing to repro this on the PC, I stumbled across both within minutes of each other in iPad. I don't have 100% proof yet, but my theory is that it was caused by the AI entering the player's hex, and possibly by him dropping items in said hex during combat (e.g. crippled arm/dying).
I have yet to test this theory, but if it works, maybe I can finally stomp this bug!
King Elias might or might not be related to the hex thing, though. That seems like a stretch. But in his case, it might be down to saving the game early on, restarting the app, loading, and continuing the game. Something I rarely did when trying to repro a bug, since I usually just poured hours into a single session without shutting down the app.
Also, let's have a round of applause for a bug that transcended porting the entire codebase from one language to another. That is one cockroach of a bug :)
Anyway, we're closing in on target. Exciting couple of weeks ahead!
Hey Folks! Had another pretty successful day of fixes and upgrades to the mobile engine today.
One of the more visible enhancements is the new font treatment:
Since we now use bitmap fonts instead of embedded ttf files, they can pretty much look like anything. In this case, instead of having to render a shadow font to improve legibility on noisy backgrounds (such as the map), we can just add outlines directly to the font's bitmap. And the result is pretty snazzy!
The down side, of course, is that each font color requires its own bitmap, so it limits our options a bit. Though, if this proceeds to replace the PC engine at some point, perhaps we finally have non-latin characters as a possibility? After all, it's just a bitmap and .fnt file, which can easily be created using web-based generators for free. Could be interesting!
Fortunately, this had only minor effects on the existing UI. The quick recipe list was the main casualty. I had to adjust the number of those per page to avoid an overflow, now that the font is a few pixels taller. And since I was in there anyway, I just doubled their height to make them easier to target with touch input.
I also found and fixed an AI bug involving faction relations. It turns out our data parser was assigning the same feral dog faction to all creatures, which made conversation attempts interesting. Once that was fixed, I was finally able to get brushed off by DMC guards again. Whew!
So, not a bad way to end the week! Started strong, took a bit of a dive midway through, but I think we're back to a good pace again.
Hope everyone has a good weekend, and see you Monday!
Hey Folks! A bit more productive today, but still nothing like a few days ago.
Most of today was UI related stuff. The first thing tackled was adding the pixelsupertiny font to the game for use in stack counts. We had been trying a scaled-down version of the tiny and mid sized fonts used in the rest of the UI, but it had legibility issues on some screens. This one seems more stable.
Then, I restored map labels that had disappeared. It seems to be that their camera settings were wrong, so they were probably being drawn in another view someplace. And while I was in there, I restored the shadow to help legibility over the hex art. Both of these may have been casualties of switching from Flash-based fonts to Bitmap fonts.
Finally, I'm looking into missing hex illustrations in some encounters (such as when hearing noises outside of Zom Zom's). I think I've got this one fixed, but while in there, I realized the conversation one may also have the same issue. And when I went to test that, I noticed I couldn't converse with anyone.
So, possible bug there? I'll be looking into that next.
These are getting really, really minor, which is good. Like edge cases and rare events in game.
Plus, Tiago just had me setup a bunch of burner emails for testing iOS in-app unlocks of demo/full version. So the store stuff is coming along, too. All good signs that we're nearing the end!
Hey Folks! Things were a bit slower today. Tiago and I tested the latest build, noted a few persistent user experience issues with precision placement, and reassessed how to tackle that. We also chatted achievements, and a few other things.
In terms of actual change, the only thing I checked-in today was code to fix item position when one stack is added to another and an overflow happens. On mobile, there's no current cursor position since the user's finger hovers over the screen. So I added some code to move the resulting overflow stack to near the last drop point, where it was more visible. Otherwise, it would sometimes appear in the top left corner of the screen, and be missed.
I also tried mucking a bit with stack count fonts, but I think my attempts failed to improve anything. The legibility is pretty bad at some resolutions, and we may need an alternative font or representation there.
One bit of good news, however, is that after testing the latest build on both iPad and Android phone, no new bugs were found. It was mostly new info on old bugs, and that's hopefully a sign the game is approaching the end!
And that, in itself, is scary. The idea of launching on mobile feels so foreign, and I don't want to screw it up. I guess the worst case scenario is that it sells poorly, and I've basically paid money to upgrade the engine from Flash. It now runs on iOS and Android, and NEO Scavenger 2 is basically ready to start at any time. Not a terrible outcome.
But finances are getting thinner if I don't launch something successful in the near/mid future. So if there's anything I can do to tip the odds in my favor and give me a sales boost, I'd like to pull that lever. Particularly since amplifying a launch is a heck of a lot easier than building a new game and trying again :)
Mobile bug hunting continues today, and we're knocking them off left and right.
Today's fixes included:
Changed end of demo text to be less confusing now that NEO Scavenger is no longer in beta.
Fixed newlines in encounter descriptions to match PC spacing.
Fixed player's target unseen creature sprite position on combat UI.
Fixed context menu staying open when hacking laptop.
Fixed rest & heal button placement when slide tray closed.
Fixed pills not going into pill bottle sometimes.
Fixed hide/unhide button sync with actual status.
Added code to prevent player moving when clicking attackmode area.
Changed edge of demo hexes to limit sight.
And Tiago's tackling the more difficult ones (e.g. input and touch, resolution, performance) while I snipe the UI, logic, and other bugs. I logged a few new ones, too, while testing. But I think I actually closed a good chunk of the new ones again, so we're hopefully still trending in the right direction!
Hey Folks! Hope everyone had a good weekend. What free time I had was largely dominated by voting. There were no fewer than 39 things/people to vote for in Seattle! Takes a while to learn the relevant stances and pros/cons. But after several hours of research, I'm done! Just have to drop the ballot in the box tonight. And then break out the popcorn, I guess. Seems like an interesting week (years?) ahead.
Back in the world of NEO Scavenger, I think we're coming to the last mile. I triaged bugs today, and the number of serious ones is pretty small. And many are already partially fixed. The rest are fairly minor, and possibly comparable to/better than what v1.14 on the PC is already living with. Still no ETA on launch, as there is more to it than simply uploading when done. But it feels good to see the list this manageable.
Today's fixes include some UI positioning and interference issues on mobile. One of the big ones was where the player reaches the edge of the demo. It was hard to tell on mobile without a cursor and floating tooltip to warn them, so Tiago's suggestion was to change the hex art for that boundary. Now there's black hex art with "Full Version Only" where that boundary used to be regular terrain with a tooltip. The same "end of demo purchase/return to demo" encounter is there, though.
There were also some full version creatures appearing in the demo, so I trimmed that list down. I also threw in a null-pointer check in the GetRandomCreature() method which may or may not have been causing null pointer errors.
Finally, I made a few adjustments to context button behavior on the map now that their size is much taller.
While testing, I noticed a few new issues, but most are low priority. So More demo fixes are likely on the plate for the rest of the week!
Another bug-fixalicious day today. I was fortunately able to dive right in this morning as I had nearly fixed an issue last night before quitting. I should do this more often. It makes getting restarted so much easier!
The issue in question is sound effects re-fading-out every time certain screens opened or actions in game. This was made clearer when I was testing the DMC, as urban sounds were fading while I was in the wilderness.
In the end, it turned out to be down to Flixel's change to the way sounds were faded. In Haxe, this just lowers the volume, but the sound remains playing. And since the code was using ".playing" to determine when to fade out, it kept re-fading out each time the sound was updated. The fix was to just add a manual onComplete = pause() type command to each fade out.
I also updated all the bruise and cut images with invisible padding pixels that are only detected by the Flixel hit testing code. This way, the player doesn't have to be as pixel-perfect with tiny wounds on tiny screens using their finger. No visible change, and easier to use. The best outcome :)
Finally, I did some reworking of the item tooltip/context menu to make it easier. I doubled the button heights so they weren't as fidgety on touchscreen. And while I was in there, I found a way to make the tooltip appear on-screen more reliably at different resolutions. The one side effect is that the amulet has wonky text in the tooltip buttons. Nowhere else in the UI does this happen.
However, since the tooltip menu was completely obscured in some cases before this change, this is a net improvement. I'll go back and fix that niggling detail if there's time. (I.e. probably not)
Anyway, this was a pretty productive day! And I see Tiago's got his latest fixes wrapped up in a new test build, so it looks like some testing may happen over the weekend. You know, in my "spare" time between diaper changes :)
Hey Folks! Tiago wrapped-up a new test build overnight, so I spent a good hour+ testing it today on my iPad. And I think we've officially crossed into minor bug territory. All of the issues I recall finding are non-game-breaking, as most have workarounds or are just don't impact play much. I could do pretty much everything I intended to, either on my first try or via the new zooming/panning and other UX tools.
I hesitate to say we're pretty much done, as I'm always wrong. But I feel like I could probably launch with this experience and be forgiven.
Of course, that isn't as desirable as launching and being praised. So we'll continue bug-fixing and polish a bit longer :)
I haven't had a chance to try out the slide tray yet, as the iPad makes use of the permanent button layout. So that's still up for debate. But the larger buttons were nice on the iPad, so that much is improved. Tiago's preview offset enhancement also made precision item placement a breeze. There's a niggling oversight in slotting/socketing items with this system, but I had no problems placing pills into a pill bottle jammed between two items in my backpack, or even in a 1x1 space surrounded by items, and that's saying something.
Some of the other things I looked into today are a VFX null pointer in the DMC map, which was an easy fix. (Slight difference in Flash vs. Haxe ways of initializing a VFX path.) And also, a sound effect bug that's been plaguing us.
So far, after a few turns, there's a rush of noise every time the player moves hexes, opens/closes the UI, or some other events. And I had a new clue today: it happens to the DMC ambient noise even after leaving the city! This means a sound that shouldn't even be playing is getting played, and fading-out, each time UI is opened. And that's easy to replicate.
As of now, I've found the code making this happen, but I don't know why it's being called. I can probably resume there tomorrow.
Overall, a not very productive day, but still a good news day. Perhaps a releasable mobile version is in sight?
Hey Folks! Another day of mobile dev work here. Today, I finished updating the action buttons to be easier to touch on mobile.
As previewed a few days ago, the action buttons are now twice as tall, and closer to square in their dimensions (instead of thin rectangles). The intent here is to make the user more comfortable using them on touchscreens.
On 4:3 mode, they now live in the empty space that was below attack modes. Conveniently accessible via the right thumb when held like a book.
On 800x450 mode (which tends to appear on widescreen devices), there isn't this empty space to work with. Doubling these buttons' heights means we don't have room for half of them anymore. To solve this, there is now a slide-out tray where the buttons used to be:
When closed, the scavenge and end turn buttons are still accessible. And there are indicators for hiding and running. Tapping the arrow/tab on the tray opens and closes it, revealing the rest of the buttons. And the camp screen still shows sleep and rest buttons, as before.
It still requires some testing, and might need to support dragging as well as tapping to open/close, but I'm going to see how it feels first. In any case, users should now be able to tap the buttons without worrying about fat-fingering an adjacent one, unless they've got some really big fingers!
Hey Folks! The barrage of bug-fixing continues today, with finalizing combat fixes, and moving into inventory.
The issue with unconsciousness wearing off too soon turned out to be what I thought yesterday. A simple fix to the way the game checks for an items' properties resolved it, and dogmen were happily falling unconscious from shock, and importantly, staying that way :)
I then turned my attention to slot bugs. Namely, we were having trouble applying stacked bandages when the last bandage was in hand.
This turned out to be a deceptive bug, as the problem appeared to be involving stacks, but turned out to be slot hitboxes. The new touch input changes didn't account for some slots needing pixel-perfect hitboxes. Wounds are slots, and they all overlap in the same big box around the body, with only a small portion opaque. This was causing the wrong wound to intercept touch/click events when applying bandages.
After some changes to the way buttons intercept input events to account for alpha channel (only in slots and wounds), this appears to be working again. There might be an issue with the high degree of precision needed here and touch input, but only testing will tell.
Tiago also made a significant improvement to the inventory: the ability to drag an item for precise placement. Previously, the player would tap to pick up an item, then tap to place it. This often resulted in items missing their target, and returning to the source point. Tiago added some code to improve this placement, which tries a few placements before giving up, and the result was much improved placement success.
However, there was still an issue with really deliberate, fine-tuned placement. Like wanting to put pills into a certain bottle that was near another bottle, or between two objects.
With Tiago's update, it now works a bit more like the mouse did. Tap once to pick up an object, and then the user can drag that object around the screen, easily seeing where it'll be dropped when released. This should be pretty intuitive, and I think it'll fix the remaining user experience issue I worried about. We'll see in testing!
Finally, I've started looking into the new slide tray action button UI, while Tiago continues testing demo/full purchase path, and other bugs, such as sound playback on android.