This week Juhani Junkala came back with some new sounds for menus and the Adventurer. When adding them in game, I was reminded about how delayed the sound is in the web version of Flashcard Clash.
Sound is generated by the game engine and pushed out to the operating system to play, but in the web version I'm using an external library that helps simplify converting code to the web. The problem with this library is that when it takes in the sound from the game, it gets put into another buffer before then being pushed out to the web browser to play later. These extra steps were delaying the sound output a small amount, maybe 1/5th of a second, but enough to sound wrong.
So to reduce the lag time, I cut out the helper library, and wrote replacement code to directly output sound to the browser. It's mostly working well, although there are some issues with sample rate that currently make sound effects sound a little sped up.
The next issue I’ll need to fix in the future is that when the game does too much processing all at once, it might not generate the sound in time to push out, and when that happens there's a noticeable gap. But I’ll need to improve a few things before that can be fixed.
There were also some minor fixes to the fire goo animation that was not looping correctly and some card fixes.
Over the week we've been completing the effects (FX) that accompany the attack animations of the Pyromancer, one of our hero characters. These three attacks are called Flash, Fireball and Firewall.
Our process of developing the FX for these attacks goes as follows:
Let's have a closer look at these steps with the creation of the effects for Flash, Fireball and Firewall.
Here we begin with the concept sheet. I created this page to visualise how I would like the FX to appear in association with the character movement.
From there, our animator Ariane Lapointe works up a test animation. This ensures we're on the same page before proceeding with the final animation.
Once approved, the frames are exported as PNGs, and are ready for vectoring in Illustrator. The frames are easily converted into vectors using the Image Trace function and then the Brush Tool for small edits. The frames are then exported as SVGs. We do this is to reduce overall game size, allowing the game to run faster.
Below is a folder view of all the Flash FX frames, ready for vectoring.
Once vectored and exported as SVGs, the files are sent back to the animator, where they'll be composed in Spine.
Here's the final Flash FX, in two parts:
1 - The start of the animation, where the ball of light lifts from the Pyromancer's hand.
And, 2 – The flash effect that appears over the enemy monster.
After reviewing the final animation, we decided to opt for three flashes over the enemy. Here's the final outcome.
That's all for this week. Until next time!
This week has mostly been spent playing around with code on Android so there isn't a lot of pretty stuff to show.
Most of the time as been playing with integrating AdMob so I can integrate some ads and start stacking that mad app money. Which is a bit of a pain in general, as the AdMob API isn't as friendly to programmers as it should be, and also because the game is written in C and the Android stuff is written in Java, a lot of time is spent trying to communicate between the two.
Before getting into that, I should first explain how our games are written and how that relates ot Android. Flashcard Clash is written in C but could just as easily have been written in C++, these languages are pretty low level and are compiled down to instructions the CPU runs directly this makes them fast. These languages are also widely supported so they can be compiled to run on everything.
Android runs Java, it's an interpreted language, meaning that it does not run directly on the CPU, there is a program in between that takes the Java code and outputs commands to the CPU instead. This means that Java is slower than C, but it's also safer as the in between program can catch problems like memory leaks.
Now those two languages are in conflict since they are running in completely different ways, but luckily the people who made Java foresaw this and created the Java Native Interface, or JNI. The JNI, with a bit of manual effort, allows C code to call Java functions and Java code to call C functions. This allows us to create a bridge between the game code and Android specific things, like input and AdMob.
Calling between languages can be a bit painful with a bit of repetitive code and issues with calling things on the correct thread. So once I was able to get AdMob working somewhat in Java, I spent a bit of time creating a wrapper to make it more straightforward to call between the languages.
So after all that effort I have something no player is excited to see, Ads. But don't worry, I won't be a jerk about it, and I'm also looking forward to adding stuff like getting game rewards for watching ads.
GAME ART TWEAKS & ADDITIONS
This week involved making a few simple tweaks and additions to niggly design elements. Here are the changes made:
1/ Edited the title screen background
During the development of a game, it's not uncommon to create quick placeholder art to fill in the gaps until a better piece is made. The sky background featured on the title screen was one of them, and oh, have I been eager to fix this one up!
In this case, it was the sun rays. They were a quick effect made in Illustrator to indicate a radiant sun, but they really lacked the 'oomph' we needed.
Here's the Before:
See: sad, weak, little sun rays.
So I beefed them up, thickening the rays and increasing the vibrancy of the sky.
Here's the After:
2/ Made an “About” (credits) button for the main menu.
Turns out we didn't have an About button on the main menu to access details about the Numbat Logic team behind the game. So I set off to correct this.
It was decided that we'd use the Numbat Logic logo. Here are a few different options I tested:
And here's the final design we went with, sitting with its other button buddies on the menu screen.
3/ Created tool tips for the flashcards
An issue we'd run into during user testing was gamers not knowing when they were required to type in an answer to the flashcard as opposed to selecting a multiple choice button. This was fine on phones as the keyboard would pop up, but on desktop versions that visual aid did not appear, leading gamers to believe the game had crashed.
To resolve this problem, we decided to implement tool tips; prompts that would pop up after a few moments of inactivity. These tool tips would be handy for another potentially confusing problem – gamers entering a valid answer to a flashcard, but not the answer we're looking for (some Japanese characters can have different meanings depending on the context).
For this, two tool tips have been made. A general tool tip (grey) version and a 'Try Again' (green) version.
You can see the tool tips on the screen mockups below:
4/ Created a “Card Explanation” set of buttons
Since Flashcard Clash is a game for memorising the characters of the Japanese language, it made sense to implement a way for gamers to find out more about a new flashcard when it pops up, plus give them the ability to check back over that card after they've answered (and before the next card comes into play).
For this function, I created a set of two buttons. One to appear on the flashcard itself and a second for the top right of the screen (once the flashcard is closed). Below is a mockup of these button options.
We've opted for the teal coloured circle with a question mark button on the flashcard (seen in the left screen mockup) and the mini flashcard with the question mark button (seen in the right screen mockup). The mini flashcard will likely feature the character of the card that was just viewed, and the circle backdrop coloured teal.
And that's all for this week. Until next time!
Look at how excited he is to be in the game! Unfortunately we havent created sound effects for him yet, so he's a silent protagonist at the moment.
Now after all the time spent setting up data in the back end, I now actually have something helpful in the front end for players. Cards can now be setup to refer to specific readings or meanings of cards, rather than the whole range of available options for that vocabulary. This means that cards can be more helpful with manga vocab as you'll learn the specific meaning or slang reading that will be coming up, instead of learning the formal reading and then having no idea what the slang is when you read it in the manga.
In addition to this, the card will still know all possible readings and meanings, so if you answer with one of those, it will let you know it's not the right answer and let you try again without failing the card. Currently it's just a boring dialog box, but hopefully next week we can art it up nicely.
The first time you see a new card, the answer will be given to you in the form of a faded hint at the bottom of the card. There was an issue tho, with cards having so many possible meanings that they overflowed the card, as you can see here:
Or as you may not be able to see as the hint answers are also shrunk down so much that you can barely seem them.
Now we've split those hints up and the card will rotate through them:
I've updated the skill buttons to have user friendly text instead of having the internal skill code.
One day we will have cool skill icons. But text is good enough for now to ship the game :P.
Here's a process gif showing the development of our app icon. There's a rundown of the steps involved below.
Sketch – A very rough sketch of the concept is drawn. (You can see the other concept sketches on our previous post here
Refined Sketch – The paper sketch is transferred and cleaned up on the computer using Adobe Photoshop. The concept is clarified and improvements in pose and composition considered. In this case, the flashcards were moved from the top right of the frame to the bottom left, improving the focus of the design.
Rough Colour – Colour is applied in variations to find a harmonious colour palette. While we looked at purple and red backdrops, we settled on blue as it produced contrast with the Adventurer character and tied nicely with the RPG battle theme. (These colour variations can be viewed in our Previous Update. The sketch was further refined at this stage too.
Final Artwork – At this final stage, the artwork is moved to Adobe Illustrator to create the graphics in vector. Once the vectors are constructed and colours applied, tweaks are made to tighten the design and ensure it's consistent with in-game art. And voila ~ the app icon is complete!
Here's the final app icon at various scales (as it will appear on different devices).
And with that, we're one step closer to releasing Flashcard Clash.
Next week Kristy will make a start on applying some tweaks and finishing touches to the game art assets. Stay tuned!
Here's what we got done this week on Flashcard Clash, a game that combines RPG battles with Japanese flashcards.
I've continued working on the data editing tools I've talked about in previous updates. It's finally coming together and I've been able to start editing cards with it. There's still a bit more to go, particularly in game, with supporting the extra data I've added to vocabulary and cards.
Kristy's art updates are a lot more interesting:
This week I continued developing the Flashcard Clash app icon.
App Icon – Logo Badge
First I started exploring how to present the Numbat Logic logo on the Flashcard Clash app icon. We'd established that the logo badge would appear on the bottom right corner of the app icon (this position best suited the icon designs) so now it was a matter of creating the badge shape.
To simplify the design and avoid legibility issues at smaller app icon sizes, I opted for using the logo alone, without the “Numbat Logic” logotype. From there I started building shapes that would house the logo while not fighting for attention with the app icon design.
Since the bottom right corner of the app icon is automatically rounded to approx 180 radius when posted on the Apple iTunes store, it really came down to how the top left of the logo badge would interact with the remaining app icon area.
I looked at various curves from full circles, to squares with rounded edges. How the logo stamp flowed back into the app icon edge was also considered, using perpendicular lines or rounded, concave curves.
The various design options can be viewed in the image below. They're presented in both white on orange and orange on white – the Numbat Logic colour palette.
At the end of this design pass, I selected the soft sloping badge shape with the slight concave curve (3rd column, bottom) to use in the app icon design process. Overall, this shape felt harmonious with the app icon, whereas the sharp edged shapes felt obtrusive and dominant.
App Icon – Sketches, Rough Colours & Size Testing
Continuing from last week, the rough paper and pencil sketches were transferred to the computer where they were redrawn and refined in Photoshop.
Here are the four cleaned up sketches.
After reviewing the designs with Adam, we decided to proceed with design #2 and #4 (top right and bottom right). The next step was to explore these two design in colour.
Since we're keeping in style with the in-game graphics, the colours of the Adventurer were already established. For the background I wanted to find colours that contrasted with the Adventurer (and flash cards) and evoked a sense of excitement and the RPG world.
In both designs, blue and purple stood out the most. The blue being reminiscent of the sky and journeying through RPG worlds. Purple relating to magical elements and a colour that frequently appears in game.
The next step was to test our favourite colour schemes to see how they would appear at various icon sizes (48px, 72px, 96px, 144px, *192px, *1024px).
*192px & 1024px are not pictured below.
We couldn't pick a clear winner, so I'll be proceeding with the vector stage and see if one stands out then.
Characters – Setting Up the Pyromancer
An extra side project for the week was helping set up the Pyromancer character for animation and creating a couple of additional assets.
When creating the vector assets of a character, it can be difficult at times to tell how well the parts will convert into animation. This requires some trial and error, and collaboration between artist and animator.
In this instance, the Pyromancer's fireball attack didn't quite translate well, leading to a broken model in the second key pose. Thanks to our animator, Ariane, for supplying screenshots of the Pyromancer setup in Spine, I was able to provide draw-overs to adjust and (hopefully) fix the broken pose.
The draw-over helped me to discover the need for an additional hand to indicate 'letting go' of the fireball in the throwing pose. So I quickly vectored that up for Ariane to use.
Here's how the new hand will look in action, following on from the original hand that 'holds' the fireball.
And that's all for this week!
Here's the next development update for Flashcard Clash, a fun game to help study Japanese. This week I’ve been super busy with other stuff, but luckily Kristy and Arianne have been working away.
Currently the editor, which you can see in last week’s post, as a simple side menu and a main editor that lets you edit one thing at a time. This works well enough, but there’s a bit of jumping around when creating new things.
For example, to create a new monster, you need to first head to the skills section to create their skills, and then go to the monster editor to assign those to the monster. This was going to get even more complex with vocabulary cards, as we’d need to create the vocabulary, attach it to a card and then attach that card to a deck.
My solution to this is to change the editor into a ‘stack’ of windows, so that instead of having to travel to different sections of the editor to create different things, we can just push the window for doing that onto the top of the stack. And when you are finished, pop that window off and go back to what you were doing.
So for example with creating a new monster, instead of having to pre create the skill in a separate section, we can just push the window for that on top of the monster editor, then when we are done, just close that window and go straight back to editing the monster.
It's still a work in progress but hopefully I can finish that all up next week and ship out some new decks.
Today we'll also be introducing the art segment to our weekly Flashcard Clash Development Updates. The art segment will take a look into what we've achieved over the past week in the visual development and production of Flashcard Clash.
Kristy Kate, lead artist and art director of Flashcard Clash will take the reins from here:
Hi there! This past week (or two) have been focused on preparing the app icon for Flashcard Clash and assisting our animator Ariane wrap up the final animation for our first hero character, the Adventurer.
The Flashcard Clash app icon is the first artwork visitors will see when browsing for apps on the Apple iTunes and Google Play stores.
It's important for app icons to be clear and easy to identify, so when approaching this design, I knew there would be 3 points to convey:
Clearly, flash cards, Japan and the excitement of RPG battles had to take precedence when choosing what elements to portray in the app icon.
It was also decided that it'd be worth including a stamp of Numbat Logic's logo in the bottom right corner to establish consistency between future apps.
So, I set off brainstorming and sketching ideas for the app icon. As seen in the images below, I went for quite a direct visual approach, incorporating flash cards, a sword (RPG element) and the Japanese flag into the design concepts.
Some of these would be quite clear in establishing that Flashcard Clash is about learning Japanese with flash cards, however the feeling of excitement and adventure from RPG battles wasn't as strong as we would have liked.
The turning point came when I decided to explore the interaction between the sword and flash cards, changing the flash card to the Hiragana character あ (transliteration 'a'). Eventually this lead to pulling the main hero character, the Adventurer, into the mix. This gave the app icon a greater feeling of action and excitement and sent a clearer message of the connection between Japanese flash cards and RPG battle.
From here we marked out our favourites (indicated with blue dots) and I have now transferred the sketches to the computer to start the process of refining and clarifying the designs.
To be continued!
Adventurer Spirit FX
My other task for the week involved finalising a segment of fx animation to play alongside the “Defeat” animation when a character (in this case, the Adventurer) is knocked out.
This proved to be a great lesson in improving my art direction skills as I had an image in my mind of what would happen, but didn't quite explain it to Ariane, our animator, in the best manner.
When the character was knocked out, I thought it would be fun to use a popular visual trope found in anime and manga, where the spirit (or soul) of the character leaves their body and lingers around. TV Tropes calls this “Giving Up The Ghost” if you'd like to know more.
With that in mind, this is the art direction I provided:
And the description: Little spirit “smoke” effect rises up from head.
Not the clearest of descriptions (sorry Ariane!). Ariane got to work and sent me this nifty little rough animation of the spirit rising from the knocked out Adventurer.
Despite the awesome work, unfortunately it wasn't what I was looking for, which is where I learned that I had to get specific when I had a very specific image in mind (it's not like we're mind readers!)
So I created these sketches and sent them back along with a much clearer description and a few animated gifs from anime I found online.
I received the revised rough animation from Ariane and voila, perfect! The frames have now been vectored and they'll soon be compiled into the final animation.
That's it! That's what happened this week!
Here's the next development update for Flashcard Clash, a fun game to help study Japanese. Not a lot to publicly show this week, as there's been a bit of backend database tinkering, but i'll get ot that in a bit.
The big change this week was actually pretty simple, changing the 'reviews remaining' counter to show the actual number of answers the player needs to give before they are done.
Some backstory is needed for this. Cards in Flashcard Clash can have multiple 'sides' or questions to them, for example a vocabulary card could have 4:
I think this gives a deeper understanding as it requires the player to pull out the knowledge in different ways,
So the player will need to answer those four sides correctly before that card is considered completed. Now coming back to the reviews remaining counter, since it was based off cards remaining, it would only tick down sporadically, about once every four questions.
This leads to a bit of ambiguity in how much work actually remains for the day, which can be slightly disheartening. Now that the counter has been changed to show the number of individual answers remaining, it ticks down with each answer, giving in indication of progress every time, which feels better.
Following up on the new way I’m storing and handling vocab cards from last week, I do not like how the final result is in game.
Currently a vocabulary card in a deck will accept any possible answer, eg: the game might accept お父さん or とーちゃん or ちち for the word "father". Which is all well and good in that you won't get a card wrong if you gave the wrong word that meant the same thing. The bad part is that it was intended for you to learn a specific word, for example in Yotsubato learning とーちゃん for father, and you can skip around that giving a different answer. Which means you'll pass the card and think you've learnt it, but then not be able to read it in the manga since you studied the wrong answer.
I think the correct way to go from here is have a card only cover a specific reading and meaning of a vocabulary. And if you answer with a different reading or meaning, the game can say "that's not the answer we're looking for" and let you correct it and carry on.
But before I do that, I need to update the editor so I can more easily create vocabulary and eventually be able to select what meanings/readings I want for a card.
That's it! That's what happened this week!
So I'm going to attempt to try and to weekly updates on the status of Flashcard Clash. Even tho I figure most of the changes are all backend technical things that usually don't have any pretty pictures to go along with them. I hope you like words!
I've added prestiging to the game, basicly once you've battled through enough dungeons and it's too hard to contine, you can reset all your characters and the dungeons back to level 1. In doing so, you get rewards for how far you progressed and these rewards make it easier to go deeper the next time round.
Currently the rewards are pretty slim, just a useless gem, and there's not even any fanfare animations or sparkles. But I wanted to add it in anyway as my own personal account was running into a dead end and I needed to reset my progress :P.
We've been working hard behind the scenes with Ariane for a little while now to get our main characters animated before we can start showing them off publicly. One of these characters, the Adventurer, has a scarf that turned out to be a bit of a challenge to animate. A scarf animation is pretty simple technically, the first bone swings backwards and forwards about 15 degrees in a smooth motion, and each child bone swings the same way, but is slightly delayed. Hopefully you can make that out in the animation below:
It's pretty simple to animate the first bone, you just set key frames for the left and right positions and Spine will animate through them in a smooth motion. Which you can see as the red checks in this very exelent diagram I have created.
The trouble comes when animating the second (green) bone, beacuse it's delayed, you can see that it does not have a check on the orange line, which is where the animation starts. Te way Spine works, is all bones will be in their default position at the start of an animation, and the first time they are keyframed, they will jump to the correct position, so you need a keyframe on the orange line.
We could add a new keyframe at the start of the animation, but we'd have to manually work out the start position and somehow adjust the interpolation so it matched the existing stuff. Which all seemed like a bit of a pain.
Note the keyframe on the far left, before the animation starts. Being able to set a keyframe there would be my dream solution to this problem, but alas Spine does not support that.
My solution as a programmer was to overengineer things, and precompute a sin wave and use that to set the angles for the animation. For this I used the most powerful program in the world, Excel.
In the far right columns you can see what angle the bone needs to be at what frame, which was easy enough to setup, but a lot more effort than just having left and right keyframes with smoorth interpolation. The bonus was that for the child bones, we could just copy and paste these keyframes and delay them easily.
Another option mentioned on the Spine forums was to force the animation to loop between a set of frames, ie: use frames 50 to 150 instead of 0 to 100. This would have worked as well but it kind of breaks everything else that expects animations to start at frame 0 and end at the last keyframe, like exporting gifs. The game code would also have to be updated to support this.
Previously all cards in Flashcard Clash are free standing, with a bit of text for the question and answer. It's a little bit more complex than that, with things like dynamic cards, but it's still all based on a fixed set of text on the cards.
Currently reusing cards between decks is possible, but error prone. So adding a new type of card which is slimplified toto "this card uses this vocabulary" will make it easier to stop cards being accidentally duplicated. Which also means that if you learned a word in one deck, you can skip it in any other deck since the game will know that you already have it.
Longer term i'm looking to have things like automagic substitution for nouns, eg: currently I have a card that switches between "there is a cat" and "there is a dog", but those permutations are fixed. What I'd like to have one day is that if you learn "fish" then that card will dynamicly pull that in and become "there is a fish". That's a long way off, but the first step is building a solid vocabulary in the database to be able to reference.
Currently the only Vocabulary cards are the new ones I'm adding to the Yotsuba decks. I'll need to go back and convert previous cards, and cleanup a lot of those old decks in general, but I'm just focusing on the things I am studying at the moment :P.
That's it! That's what happened this week!
Since Flashcard Clash can be run in the browser, I've tried to keep it as tiny as possible so it can be downloaded quickly. Also keeping the size down allows me to bundle all the assets in with the game on mobile platforms like Android, so there's no ridiculous second download process once launching the game. Specifically with audio assets, there's two parts, music and sound effects.
The music is created by Juhani Junkala in a 'tracked' music format from the 90s called Extended Module or XM. Tracked music allows you to create instruments as sound samples (eg: a single drum hit) then reuse them throughout the song, as opposed to more regular music formats that just stores the final sound data directly (eg: multiple drum beats with a voice singing over it). This means that tracked music can be smaller than the regular formats, which is great for us.
Originally I was using libxm to playback the music, it was easy to add to the game and use, but it sounded too different from the output of MilkyTracker, the tool Juhani was using to create the music. This brings me to what seems to be a common issue with XM music, every piece of software I’ve tried seems to play it differently. I think this is due to there not really being a definitive description of the format since it is based off what people have inferred from digging through the output of FastTracker2, the original tool to create them.
Luckily for me, Miky Tracker is not closed source, and the licensing for their playback library is permissive enough to use in my game. So by using that, I can ensure that the songs will sound exactly as the musician intended. There was just a day of hacking on the library to rip out all the things I didn't need, create a simpler interface for the game to use, and to create a wrapper for the code as it is written in C++ and the game is written in C.
On the sound effects front, instead of using a normal format that stores sound waves like a WAV file, I've forced Juhani to use BFXR instead. BFXR lets you create parameters for sounds, so that they can be generated later by the game. Since we are only storing the parameters and not the actual sound, the asset size is much smaller (currently 28kb vs 2.5mb). While these sounds can be a bit simple, BFXR also allows us to layer them together which improves them somewhat, and since the game is going for an old school JRPG kind of feel that does not hurt either.
BFXR hasn't always been awesome tho, we've had a lot of trouble with it breaking files, and also being very specific about what it can load. I didn't even know that SVN changed the line endings of text files until BFXR files stopped loading after I committed them.
BFXR is also open source, but it was written in AS3, which is a different language from the game. It wook a while to copy the code to C and get it running, but hopefully that’s sorted now and I don't need to spend any more late nights trying to work out why a sound is borked.
We were originally generating the sound effects in real time as the game ran, but it turns out that was VERY slow, especially on the web version. I have since switched to generating the sounds when the game starts up and storing them for play back as needed. This works ok with 30 sounds, but in the future I’ll need to do something smarter to generate sounds as needed (eg: only generate sounds for a monster when you are loading into a battle with that monster).
Once all that's done we have simple waveform data we can pass off to whatever platform we are running on to play the sounds. Currently we are defaulting to 16bit signed ints, but I think I might try to change to float as that's the native format for web browsers and that will mean less data conversion so it will run faster.
Over the last few days i've been working on a little tool to be able to edit battle formations.
A lot of data for the game, like monster stats and battle formations are stored in the database. Obviously it's not wise to directly update these things in the live database, so I need to be able to set it up in such a way that I can make the changes locally and be able to repeat the changes later on the live server.
I do have an existing setup that does something like this, using numbered SQL files. The server keeps track of the last sql file it ran, and will not run it again. So since the server last ran the number 10 file, i can put all my changes into file 11 and test them locally. Once I push it live, i can run a script that will then process file 11 and those changes will go live.
This works pretty well with low level changes, like adding or changing tables, or other simple things. But adding a battle can be a bit painful, as it involves having to add multiple rows and looking up the monster ids. So I created a tool to edit the battles that you can see below.
It's ugly but it works!
It would be too much work to have the tool creating sql files for every change, so I make it just output a simple save file. This save file is loaded by the update script and it makes the changes to the database to match the save. That way I can edit the file as much as I want, test it locally then update on the live server.
It's a little bit simple right now, but in future i'll move more of the static data into this file, like monster stats, stage backgrounds and music. So it's one stop shopping for anybody on the team to be able to make changes to the game.
The art for the endless mode I mentioned in the previous blog post has come in, and you can see it in the image below:
I've been having some issues with the UI systems in Flashcard Clash, and I was expecting to go in and fix them after the alpha release, but supporting different screen sizes has brought this all to a head. The main issue is that a snapping the ui to pixels will make animations less fluid, so things like windows sliding in and out not look as nice.
My plan with supporting different screen sizes is to make a virtual screen of about 640x480 pixels and approximate the actual screen to it. This should make UIs a bit easier to universally layout rather than having to work with the native pixels that could be anyhting between 640 to 4000.
After spending a day or so converting to floating point for the UI, and another day or so trying to make it not look too blurry when compared to pixel perfect coordinates, I started on supporting resoultion changes whilst the game is still running. The UI system was quite easy to update, I just trigger another reflow and the elements correct themselves, but I also had to rerender the SVGs so they are the correct scale for the new screen size. I still need more work to have the Spine model support changing the underlying texture, but that is in third party code that I don't want to deal with so ill postpone that as long as possible.
I don't think there's anything left in the game to do before the first public alpha test, just cleaning up the site and making sure things make sense for new users.