Posted on 04/17/2015 - 16:13
Still plugging away at a HaxeFlixel prototype. Today's work centered around tilemaps and cameras.
One thing I'm interested in is whether it's possible to show a tilemap on-screen that not just scrolls, but also rotates. Yesterday's testing seemed to indicate that this was not possible through direct means. The HaxeFlixel engine simply ignores rotational settings on a tilemap.
My next attempt was to see if there was a way to grab the bitmapdata from a rendered tilemap, and then I could just copy that to the screen after rotating it. However, even that seemed to be hidden from public access on the tilemap class. (Within the class, I could probably just grab the screen buffer, but that's a private data field.)
I'd prefer not to mod the tilemap too much, since there's a lot of useful stuff built into it. From rendering optimizations to pathfinding, and even physics, it would be a shame to decouple my work from the moving target of open source improvements.
So today, I decided to see if I could creatively get my desired outcome with fancy camera work. And by all accounts, it seems to be working!
Namely, it appears that a FlxCamera can be rotated on the screen, as well as translated and scaled. This means that I can use a camera to show a tilemap, and simply rotate the whole camera view, instead of the tilemap.
Even better, cameras can be layered with transparent backgrounds, so I could theoretically have one camera for a foreground tilemap rotating independently of a background tilemap. And a surprising outcome is that both the Flash and Windows native outputs of such a crazy contraption seem to perform well! (We're talking a whole 1280x720 screen of bitmaps rotating, here.)
So that's promising! It looks like I can do some pretty cool tricks with the latest HaxeFlixel. And what's more, I'm getting close to a gameplay prototype that I've been meaning to test. It could be working soon, and I can see if it's anywhere near as interesting as I was picturing in my head. We shall see!
For now, I hope everyone has a good weekend!
Posted on 04/16/2015 - 16:12
I spent most of today continuing yesterday's HaxeFlixel prototype work.
Before I could do much more, I had to sort out a debugging issue in my code editor (a.k.a. IDE). For some reason, I could pause the game at any point in my source code, and step through it line by line, but this failed as soon as I tried this in libraries. (Libraries are external code such as the HaxeFlixel engine, OpenFL, physics engines, etc.) The IDE just acted like the library code was inaccessible.
After quite a bit of creating and deleting new projects, changing project settings, and even uninstalling and reinstalling the IDE, I eventually stumbled on the problem: the IDE saw the libraries in c:\, while the libraries had a setting saying they were in C:\. Normally, Windows stuff doesn't care about case sensitivity. But in this case, there were some case-sensitive features that failed (Java? Flex? Haxe?), resulting in a confusing, half-working IDE.
Once I figured that out, I was back in business. Or so I thought.
My next hurdle was figuring out HaxeFlixel's tilemap class. I used the flixel tilemap (or at least a modified hex version of it) back in NEO Scavenger, so I was fairly familiar. However, I kept getting "invalid bitmap data" whenever the game started. As far as I could tell, the tilemap was being created normally, but as soon as the first frame updated, the tilemap fell apart.
I eventually traced this to the HaxeFlixel bitmap cache. This is a relatively new feature to me, since my old Flixel engine simply loaded and then kept any bitmaps until they were manually destroyed (i.e. no cache). What was happening was that my tilemap used a bitmap that was getting flushed while the game switched from the menu state to the game state.
The solution is to either create the game state's bitmaps after the state has fully switched, or to mark the loaded bitmap as "persist=true," so it survives the state change cache flush.
Once that was done, I was really back in business. I managed to get my test tilemap loading, and moved it around the screen. I wanted to see if I could also rotate it, but that appears to be impossible through normal means. I'm going to see if I can maybe grab a copy of it and use that as a sprite instead of a tilemap. I know I can rotate sprites for sure, I just don't know how to convert a tilemap to a static image yet.
Finally, it looks as if test v1.05 is doing pretty well, so I may promote that to default status tomorrow or early next week.
That's about all for today (apart from some legal stuff and emails). Hope everyone has a good night!
Posted on 04/15/2015 - 16:14
Kaaven pointed out to me this afternoon that the "test" downloads were still v1.04. Oops! Turns out I uploaded the files yesterday, but forgot to update the links. They should be working fine now. If you downloaded the new test from this site yesterday, you'll need to download again.
Sorry about that!
Steam is fine, though. The update process there is different, so it was immune to my forgetfulness :)
Apart from the above, there was some NDA/contractor stuff I had to handle. And some emails that needed attending to. And with what time I had left, I decided to spend it on a side project I've been eyeing-up for a while. (Months. Years?)
At the moment, the side project is just a way to draw tiles on the screen from a palette of possible tiles. I had a working version where I could draw with the mouse, and use the scrollwheel to select new tiles. And today, I decided the scrollwheel was too clunky, so I switched it to something where the user clicks directly on the palette to choose the desired tile to paint with. It's is a core component of a game idea I'd like to explore someday, and it's also in HaxeFlixel, so it's partially a learning exercise.
What will the game be? Could be many things. And part of the reason for this prototype is to find out if there's a viable game idea here at all. Too soon to tell yet, as this is just a building block. And depending on how NEO Scavenger "2" turns out, there's always a possibility I could use a tile-based editor...
Anyway, sort of a quiet day today. Interesting! But quiet. Hope everyone has a good night!
Posted on 04/14/2015 - 15:40
I've just finished uploading new test build 1.05, which includes several modding and other bug fixes.
The build is available to anyone who owns the game at bluebottlegames.com, or on Desura and Steam. Desura (and therefore, Groupees) users can use Desura Connect to gain access here, or even get their Steam keys and try it on Steam.
To access the test build on the official site, simply visit the game page, and click any of the download links below the usual Windows, Mac, and Linux buttons.
Steam users can access the test build by opting into the beta for it.
Updates Included in the Test Build
Test build 1.05 includes the following changes:
- Changed DMC guard loadout to only have one firearm, to prevent bug where pristine pistols are littered everywhere.
- Changed loading screen to only launch browser if logo clicked, not whole screen.
- Fixed a bug that allowed the player to freeze to death if imprisoned at Saginaw.
- Fixed a bug that caused player to be automatically re-exiled after exile period expires.
- Fixed a bug that caused modded items with "ignore subgroup stacking" property to stack with any modded item.
- Fixed a bug that caused modded campsites to all be the same.
- Fixed a bug that prevented master volume settings from being saved.
- Fixed a bug that caused modded ingredients used in modded encounters to get mixed-up.
- Fixed a bug that caused NPCs to give food reward with blinkies inside soup cans, and soup without containers.
- Fixed a bug that caused skill/flaw totals not to be visible in Small UI mode after player dies once.
- Fixed a bug in Main Menu small button highlight update code.
- Fixed a bug that still mentioned "bag lady" in Red Gnome Diner.
The most interesting fixes here are probably for modders, as features like modded camps, recipes, and stacked items were bugged. The rest are fairly minor or rare bugs in the game or UI.
The likelihood that this version of NEO Scavenger will work with previous saves is: likely.
As usual, the older the save game version, the less likely it is to work.
As always, let me know what you think of the changes, and if you notice any issues with the new build!
Posted on 04/13/2015 - 16:14
Hey Folks! Hope everyone had a good weekend. Not much to report from ours. A few errands, chores, but mostly relaxing. (Which is good!)
Back at work, there was a long list of business things to take care of today. With taxes done, I had to make a bunch of payments to the accountants and the CRA. Plus a few of the remaining PAX costs had to be paid off. And there's at least one more CRA payment due soon, basically to cover my estimated taxes for Q1 2015. A lot of money flying away this week!
Once that was done, I had some legal things to turn my attention to. I may be working with a dev soon to get the mobile port done faster, and that means contracts. And if I decide to work with a marketing/publishing partner, also contracts. And while I'm a firm believer that one should know as much about how stuff works as possible, I think I want to make sure this contract stuff is professional.
So I'm also working with a lawyer on getting these contracts reviewed/drafted, and that means more dollar signs. (Though thankfully, the firm I'm dealing with has a handy subscription/retainer service that can reduce such costs.)
Apart from the paperwork, I managed to get a couple more bugs fixed. The first was a bug that caused NPCs to give a reward of soup and blinkies, except the blinkies were in the cans, and the soup glop was loose. The second bug was a missing skill total text field in Small UI mode after the first time a player dies.
Still more bugs to fix, as always. And this legal/contract worker stuff will likely require part-time attention over the next week(s). Hopefully, though, it'll help get me into high gear once sorted out.
I'm also thinking it might be a good time to upload v1.05, since I'm sitting on a fair number of bug fixes. Some of them are particularly useful to modders, and it's been a while since the last update. So I'm hoping to do that later this week. Stay tuned!
Posted on 04/10/2015 - 16:15
After a couple weeks of tinkering with mobile builds, I've been feeling a bit guilty neglecting the PC build. So I decided to switch back to that today and look into some bugs.
First on the list was a small bug on the main menu, having to do with the "Small UI" button on the options screen. There was a bad equation there for making sure the button was highlighted at the right times. Probably didn't affect much, but might've caused some cases where the button wasn't set on/off correctly.
I also tweaked the Saginaw encounter a bit to make sure the player wouldn't freeze to death while detained. It sort of didn't make sense given the environment, so I added a safety net there.
There was a lingering reference to the "bag lady" at the Red Gnome, which I removed. It used to start with a homeless woman crime scene, but I later removed it because it wasn't necessary. Now, folks shouldn't be as confused by accidentally reading about something that never happened :)
As many of you have noticed, there can often be a lot of pristine .45 pistols lying on the ground. This was a bug in the loadouts for DMC guards, causing them to drop their pistols in favor of shotguns when there wasn't enough room. To fix this, I've changed their loadouts to have pistols or shotguns, instead of both.
Finally, there was a bug which caused the player to be re-exiled after their 1-year exile period expired. Ignoring the fact that someone actually managed to survive this long in NEO Scavenger (!), that was indeed a bug. It turns out the "wanted" status wasn't getting cleared after the player was processed by the police, so they just got picked up again after the "exile" status disappeared. This should be fixed in the next build.
There are still quite a few bugs out there. And I have a strong hunch a "null-pointer" is among them, given some reports of strange and intermittent behavior. So I'll probably continue sniping bugs here and there as time allows.
Have a good weekend, all!
Posted on 04/09/2015 - 16:30
Another mixed-bag day, today. One of the more time-consuming tasks was to submit NEO Scavenger for IndieCade 2015.
NEO Scavenger was actually submitted to IndieCade back in 2013, but didn't make the cut. The feedback I got was largely positive, but criticized the UI clunkiness. Because of that, I wasn't going to re-submit this year.
However, someone pointed out to me that there is one major benefit to submitting: you are guaranteed to have some professional judges look at your game. And depending on who this is, it could mean exposing new audiences to the game. Plus, I'm guaranteed at least one judge's professional feedback.
And since some things have changed in the game since 2013 (including some UI tweaking), maybe it's worth the $80? Anyway, that took a bit of time, as I had to compose several blurbs and assemble materials for the application.
After that, I decided to look into why the NEO Scavenger Haxe version has a misaligned main menu and disabled buttons. And to possibly help speed things up, I decided to try compiling and testing on an Android emulator. Android Virtual Device is a tool provided by the SDK, and lets me define various virtual Android devices for testing. I setup something akin to a Nexus 7, and gave it a shot.
Not much debug info, either. I had to revert to console "test" commands to see trace output, but it looks like it may be stalling in the same place the physical Android device did before I upgraded Flixel to dev 4.0.0. I only tried a few more things here before abandoning that path, particularly since the build wasn't much faster than skipping the emulator and going straight to the physical tablet.
Instead, I decided to see if a Flash target showed the same align/button bugs. And it did! And since it was a Flash build, I could step through the code in the debugger to see what was happening!
Or so I thought.
It seems that as soon as the code calls something in a linked library, my debugging tools start disappearing. So if I try to step into Flixel or OpenFL code to see why the button isn't updating, I don't see anything. (Well, I do, but it's really hard to tell.)
I poked around a bit on forums to see if this has come up, and it appears it may be an issue with FlashDevelop. One person reported exactly this behavior, and that reinstalling FlashDevelop fixed it. Their hunch was that a .haxelib file may need cleaning up.
I'll probably look into that tomorrow. This is definitely slow-going, though. In theory, once these kinks are worked out, it should be faster. But talk about teething issues!
Anyway, hope everyone has a good night!
Posted on 04/08/2015 - 16:10
Today was a whirlwind of activity, though most of it didn't involve code. I woke up this morning to some emails from my accountant re: tax filing. The good news was that they discovered savings if we filed a joint US return. The bad news is that we needed to compile some more info asap.
At around the same time, I had some decision-making to do re: porting NEO Scavenger. Namely, is this something I want to tackle alone? I'm still thinking it may be best to work with another HaxeFlixel/mobile expert instead of going it alone, but I'm still figuring out what my options are there.
And speaking of HaxeFlixel, a new idea occurred to me today to get around this weird crash bug. (And for those who dev, this is probably a familiar pattern: exhaust all options, sleep, suddenly think of new options, exhaust, sleep, discover, etc.)
I remembered reading a bug report on HaxeFlixel involving fonts, and now that I've wrestled with this enough, it seems more relevant. I found the bug thread again on github, and after reading it, realized it was for a really old version of HaxeFlixel (and OpenFL and Lime). Which reminded me that I had to downgrade some Lime and OpenFL libraries to make my code work.
So when I looked up how far behind I was, I noticed that HaxeFlixel had updated since my last download. And what's more, there was a major revision in the dev branch that completely overhauled a bunch of stuff (including some things I was hacking together anyway). So I updated my libraries, downloaded the latest dev branch, and set about fixing the new errors in my code (mostly referencing outdated classes and methods).
A short while later, it was compiling and...working? How about that! No hacky tracing to make stuff work, it just worked!
There's still a possibility of a landmine awaiting my step, but for now, I may be back on track. And I guess this wasn't entirely wasted effort: now I at least know how to debug stuff on Android.
Perhaps I can get back to making progress on code tomorrow? Or perhaps it's back to old code for bug fixes. We'll see. Have a good night, all!
Posted on 04/07/2015 - 16:20
We made progress today!
After several days of futile Android builds and instant crashes, I was able to get something working! Sometimes.
First of all, by accident, I discovered that the Android build works if in "release" mode, but not in "debug" mode. I don't know why, but it'll run fine if I compile release.
And it's fast! One of the big questions I had was whether a HaxeFlixel port would outperform AIR on Android. And let me tell you, signs point to yes so far. So that's one question down!
However, this debug failure is still an obstacle. After asking around a bit on twitter, I learned that Android debugging may mean less convenient tools. E.g. I may need to do trace/print debugging and checking log files for output, since FlashDevelop cannot add breakpoints in the Android app, nor get call stack info.
However, I can at least see some trace output now, which is helping me track down this crash in debug mode. It's weird that release works and debug doesn't. It's weirder that the debug can actually work if I have more or less trace output, and in certain places of the code vs. others. It seems that if I trace (i.e. print some debug text from the app) enough times before a certain point in the code, it works. If I don't, it crashes.
This shouldn't be the case, under normal circumstances. (It shouldn't matter.)
So far, I've narrowed this down to a place where HaxeFlixel is loading fonts, so that's something. It may be something to do with a race condition? (I.e. code A has to finish before code B can work, but somehow code B is finishing first. And maybe the extra trace text is slowing B down just enough for A to finish?)
Nevertheless, I'm glad to see that:
A - NEO Scavenger main menu can run on Android using HaxeFlixel, and
B - It runs faster than the AIR equivalent
That means a HaxeFlixel port is worth doing, if I can sort out the debug kinks.
In other news, I had several business-y things come to a head today. Taxes, legal stuff, and some fruitful discussions with possible marketing partners. Interesting day, overall!
Tomorrow, I think I may try nailing down that Android bug a bit more, since it could open doors if I do. But if it's looking too stubborn, I may take a break and do NEO Scavenger bug-fixes for a bit instead. We shall see.
Have a good night, all!
Posted on 04/06/2015 - 16:12
Hey Folks! Hope everyone had a good weekend. Pretty mellow here. I had a brief temptation to code some non-NEO Scavenger stuff Saturday, but decided I'd be defeating the mini-vacation if I did. So movies, games, and reading instead :)
I jumped back on the HaxeFlixel port of NEO Scavenger's menu today, specifically trying to get it running on my Android tablet. There were a few API calls that I had to adjust because they didn't exist on Android. E.g. calling Flash's URLRequest instead of the universal OpenFL version, which converts it to a platform-appropriate call.
Once those minor issues were fixed, it was compiling for Android!
And that's about it. I got as far as moving the compiled apk over to the tablet, launching, got a black screen, and then it crashed. Worse still, no debug output to tell me why.
I spent a while looking into reasons it might've crashed. Font issues? Screen size? But as I explored it more, another thing was bothing me: why wasn't I getting any debug info? Is the debugger not connecting to the tablet? Does the debugger even have that ability on Android?
I spent several hours trying different things, researching on forums, running the app via FlashDevelop or the command-line...but no dice. I recall that Haxe does not easily debug C++ code because of the way it compiles into C++ and then compiles that into an EXE (or other platform binary). And judging by the build files for Android, this is probably the case here, too. Maybe FlashDevelop cannot handle a non-Flash app this way. Even so, I'd expect at least the command-line tools to work.
I need some more info there. I could totally be doing it wrong.
In parallel, I've been putting some feelers out for other developers who might port NEO Scavenger to mobile. I'm not certain I'd go this way, but I'm seriously considering it. It would make sense for me to spend time focusing on what I do best (i.e. NEO Scavenger design, content, features), and let other experts handle platform-specific stuff. Though, if they were porting NS to HaxeFlixel, I'd sort of need to wait for them to finish before doing any sequel stuff (since it would use the HaxeFlixel engine).
Anyway, lots of stuff flying around the office today. IDE-wrangling, tablets, business, emails...it'll be nice to get back to regular old game development!