Abilities and Effects Work Continues

It has been a pretty quiet week in the grand scheme of things, but I needed a bit of a break - and I've gotten that in rather well. It's not been a complete write off in development terms though! I've been chipping away at the various bits of code to make abilities do all the things I want - and I'm proud to say, I've actually FINALLY gotten to making creatures use abilities.

I've added a lot of functionality to how abilities work, added in the various target/directional and shape code (I still need to add in cone shaped effects) which amusingly got me to look up some math formulas I've not needed to look at since school days!

I'm currently working on the code that lets a creature decide what abilities to use in what circumstance, and how they play into the general things it does in combat. I've had to change things up a good bit to achieve all that, and it's not entirely finished yet, but I think I'm on the right path in that regard. As always, that means I'll need to circle back to quite a few editor screens to add in the new fields that I've come to need, but that's easy work in the end, even if it is rather droll.

Burning the Midnight Flaming Oil

Late in the evening last night, I wasn't quite ready for bed, so whipped out the code to get working on more things with Abilities. Months ago, when I was chatting with my mates, Nath in particular detail, about how abilities could work - and on the topic of if abilities that target an area, I was torn between "they hit EVERYTHING in that space, friend or foe" and "when you do damage, you don't hit your guys, when you heal, you don't heal monsters!". Nath made the glaringly obvious comment that I'd missed. Why not a little of column A and a little of Column B - meaning have some abilities that are indiscriminate, and others that are smarter - so last night I finally got around to implementing that.

So, some abilities will be quite basic, hitting anything within the target area, some will stop splash damage to allies, and not heal monsters and some will fall in between, with a chance of adverse effects per target in the area. This will mean that often, as your characters ability levels improve, they'll be able to use abilities with much more efficiency, and that those abilities will be able to be used in completely new ways!

Ranged Attacks & Abilities and Character Stats

Last night, I got some really good coding time in, sorting out some code for abilities (yay!) finally. Abilities that are delivered by a Ranged Attack, so things that will tack onto an arrow shot from a bow or something like that, now have the range of that weapon applied correctly. So the longer the range on your weapon, the more distance you can cover using that ability, so good weapons will be really valuable to the right characters.

Additionally, I got to fixing up the character screens, which meant also working out all the stats that will be needed. I've got a bunch of these already there sitting in the background, but having them properly displayed, so I can check them quickly and easily is great. I'll still have to do a landscape layout, but I'll work with this for a bit, work out what I've missed and then fix it up before making the landscape version.

Memory Management Mayhem

As I was testing the app, I noticed that as I'm making many changes to streamline how it uses memory and tweaking processes, the app was still starting running nicely, then slowly degraded over time. So, on Friday, I got into "fix-it" mode, started running various tests and profiling the app to see what was going on.

First up, I found out that by placing nice backgrounds on the login and landing pages, I was using up 70 megabytes (no, really, seventy megabytes) of Androids small allotment of memory to show these as the Activity was sort of sitting there off-screen somewhere. So, that got resolved to only show the images when the Activity was visible. Bam. Seventy memory back thanks!

Next up, turns out that following some basic docs on how to show/create Activities (or, in game terms, how to open up a character screen, inventory and skill trees) actually causes memory leaks, which is a terrible way of saying that the meagre memory you start with is getting wasted on more trash that's not needed. That one was quite a bit harder to fix, as it needed a reasonable re-write of the was I call certain activities, but also changing notification methods completely (or again, in game terms - when you picked up an item from monster loot, it needed to move the icon from the "loot" pile, into the "Inventory" pile. Wham, no memory leaks.

Finally, testing again.

The Android emulator I have still seems to be doing a lot of pause-y stuff, but I gave it a run on my actual phone... and it ran smooth as smooth can be. Glorious success. I'll do more testing, but I am really really happy and confident that this is squarely back in the fast lane now.

Conversations and Early Layouts Polished

I got a bit side tracked with some code this evening, but am, really happy with the outcome. I have been meaning to circle back to some of the earliest layouts I've done and tweak and polish them up a bit, so today I ended up doing that instead of what I was planning to do. There were a good few various bug fixes along the way, but the main output is that conversations now happen looking a lot neater than they were before. There's no more horrid title bars in the screen (that's gone from a number of layouts now) but additionally there's a different layout for portrait and landscape modes which looks a lot better than it did before. Additionally, I've tweaked the way NPC images are processed, so the images will be proper art, rather than pure pixel-characters. It's both more and less work in different ways, but it certainly looks better than some of the early NPC images I'd been able to create/purchase.

Like, all the bug fixes and stuff!

The day before yesterday, yesterday, and today have been a flurry of great coding, implementing some basic spritesheet features that arguably I should have always started with, but instead went down the path of server requests and many, upon many bug fixes.

On the spritesheets, I've written the code to output a number of seriously large spritesheets, and the game processes internal data, basically telling it where any image is on the spritesheet, then, and this is the good bit, keeps in memory only the parts that are in the surrounding area to the player. As you move about, it maintains that nice fence of "things I need to have in RAM" and deletes everything else until it is needed again. On that note, I've given myself a to-do to implement that same functionality with special graphics, such as NPCs and the like, but it's still to be done.

Secondly, there have been another few long-running bugs that again, have never quite been big enough to make the priority list - but I finally cracked it with. As the player moves about, the recent fix makes walking a nice smooth experience - which sadly highlighted a bug I had where the terrain would "flicker" into the wrong spot, then snap back into the right one. It took quite a bit of tracking down, but turns out that although I was changing some values in consecutive lines of code, there was a lot that was being executed between them - so I narrowed that gap down by moving some code into another method and who'd have thought... GREAT SUCCESS. The rendering stopped it's annoying, janky flickering, and renders really nicely again.

I've also done some rather neat supporting work in the editor interfaces to support these things, but the main work has been in the app - which is always great fun.

With some luck, tomorrow, more progress on abilities again, as that needs to get rounded out!

Panels, Information and Interface

The holiday break has been rather kind to my coding time, and I've used that time well to really dig into code on two fronts. Firstly, continuing on with the development of the interface, so I've managed to get great forward gains on the various information panels and when they should show up/hide/change. I ran into a bit of goofball issues when the device went into landscape mode, as the layout I'd designed just wasn't able to do what I wanted.

So, a good bit of android layout redesign and much, much frustration in testing, and finally I managed to get what I wanted. Fun Fact: If an android view is off the screen, using "wrap content" as the height makes it infinitely tall - so a few single lines of text that were off the screen had me scratching my head four literally hours trying to work out why things weren't working. Also, I called it a "Fun Fact" but there's another F-word that comes to mind.

But... the big one... I've resolved interface speed-walking and rubber-banding issues with movement. The game now runs delightfully and the movement pace is independent of framerate. I'd tried to get tricky with it, and match up two threads, and it sort-of-kind-of should-have worked.... but didn't. And it wasn't till I had some friends over and was showing it to one of them, and it was running like a complete mongrel that I put that onto my plate to fix. Turns out syncing two application threads together, and having them line up, and then control movement is a "bad idea". Anyhow. Smooth sailing (walking) now.

Oh, and to make this a four-in-one update, I've also managed to wrap up the game text-output nicely so that the game can output messages as needed, either in combat, or out of it, and they stay for an appropriate amount of time, the fade off and disappear off the screen. You'll be able to scroll through what's there before it fades off the screen, but the code nicely handles removing them to keep things clean, and that journal also nicely fills in the space between the two sections of screen that are fixed in size.