Rhythm Quest Devlog 42 — Demo Release

I missed the last 3 updates due to a whirlwind of a month:

  • Released the Rhythm Quest Demo
  • Won the Zelda: A Link to the Past Randomizer tournament I was competing in!
  • Started a new part-time job
  • Had to grieve for a personal loss which left me bereaved

Let me see if I can recap some of the stuff that’s been going on…

Demo Release

I published the free playable demo for Rhythm Quest, and it’s received some really nice reception! I’m really glad that people enjoyed playing through the demo levels, and it’s also been good to take a short break after accomplishing my demo release.

Something that was nice to see was having the demo release single-handedly kick my Steam wishlist count from 1,000 to 2,000:

Something I was a little surprised to see was how many people were trying to play the game using the (unfinished) screenreader support that I’ve been integrating with the aid of the UI Accessibility Plugin package. This was actually a bit concerning since so much of the game still needed more work before being ready for prime-time with screenreader support (especially for users who are blind), but the people who did manage to fumble their way past the various issues really appreciated it. I decided to spend a week or two cleaning this up since there was clearly more demand for it than I had expected.

Screenreader Improvements

First off, I’ve added a new scene that pops up before anything else if screenreader software is detected. The screenreader voiceover functionality will always be enabled for this scene:

The accessibility menu has some new options, including a menu that will let you manually toggle screenreader mode, as well as enable a new mode that retains normal keyboard navigation but still reads aloud the selected item.

In the previous devlog I showed off the new audio cue configuration screen:

Unfortunately (and somewhat ironically), it turns out that the screenreader-based navigation for this particular screen was comically bad, with options being selected out of order, and several elements not being read correctly. Having to raise the volume balance (defaulting at 0%) for any of the other options to have an effect was also unintuitive, so I’ve gone back to having a global toggle for the audio cue system in addition to the volume balance. Hopefully it should be a little more useable now…

I’ve also fixed up a lot of other areas where the screenreader functionality was lacking, such as the world and level select screens, as well as the “how to play” tutorial (which previously didn’t have any voiceover integration at all). There’s still much more work to be done here overall, but I’m going to table this for now and turn my attention to other things instead.

Build Automation Cleanup

I’ve finally gotten a new macbook to replace my aging one from 2012, which I’ve been using up to this point for all of my OSX and iOS builds. Besides being a little slow, the old machine only had a 256GB hard drive split across two partitions (OSX vs Windows), so there was barely any space for any builds.

Since I was setting up a new machine (as well as all of the associated stuff like Jenkins, Unity, git, fastlane, etc.), this was a good opportunity for me to also clean up my automated build system so that it’s a little more maintainable.

I’ve been using fastlane to drive a bunch of the build steps (particularly for iOS/Android builds), and Jenkins to manage build jobs and workspaces. However, I now have something like two dozen different Jenkins jobs to manage all of the different Rhythm Quest builds (demo builds, steam builds, mobile builds, etc.) and each one of them had a different Jenkins config involving various shell commands to tell Unity (often a hard-coded Unity path) to generate the build and then get it copied/moved to the appropriate folders.

Updating a bunch of disparate Jenkins jobs was quickly becoming unwieldy, so I’ve switched to having most of my logic in my centralized `fastlane` config file (which is version-controlled). I’ve also cleaned that up and started breaking down the logic into different subfunctions so that everything is more manageable, so I might have common functions/lanes like:

# Invoke Unity with a given build_target and build_script function
private_lane :unity_win do |options|
system "#{unity_path_win} -projectPath .. -batchmode -nographics -quit -buildTarget #{options[:build_target]} -executeMethod BuildScripts.#{options[:build_script]} -logfile -"
end
# Move a build from ../Builds/platform_name to network-share/Builds/platform_name/build_number
private_lane :movebuild_win do |options|
src = "\"../Builds/#{lane_context[SharedValues::LANE_NAME]}\""
dst = "\"#{builds_path_win}/#{lane_context[SharedValues::LANE_NAME]}/#{options[:build_number]}\""
latest = "\"#{builds_path_win}/#{lane_context[SharedValues::LANE_NAME]}/latest\""
system "mkdir", latest
system "mkdir", dst
system "robocopy #{src} #{latest} /MIR /XD \"*BackUpThisFolder_ButDontShipItWithYourGame\""
system "robocopy #{src} #{dst} /MIR /MOV /XD \"*BackUpThisFolder_ButDontShipItWithYourGame\""
end

The individual lanes for each build are then extremely simply to write:

lane :win64 do |options|
unity_win(build_target:"Win64", build_script:"Win64")
movebuild_win(build_number:options[:build_number])
end
lane :win64demo do |options|
unity_win(build_target:"Win64", build_script:"Win64Demo")
movebuild_win(build_number:options[:build_number])
end
lane :win64steam do |options|
unity_win(build_target:"Win64", build_script:"Win64Steam")
movebuild_win(build_number:options[:build_number])
end
lane :win64steamdemo do |options|
unity_win(build_target:"Win64", build_script:"Win64SteamDemo")
movebuild_win(build_number:options[:build_number])
end

Moving Forward

I honestly had a hard time remembering exactly what I was working on before the demo release came up. There are a lot of little things here and there (lots of feedback came in from people playing the demo as well), but I think my first priority here is going to be to get back to working on more levels. I think the next one is supposed to be level 4–4, where I’m supposed to experiment more with flight paths / jump sequences that go in and out of water zones.

I’m going to continue taking it a bit easy for now though — I’ve got some more travel coming up, and will be moving residences after that (Ludum Dare is also coming up in a little over a month), so I’ll have plenty of real-life stuff to take care of.

I’m actually fairly concerned about my ability to maintain a good pace of progress on Rhythm Quest due to my new job (currently 3 days a week) which on paper cuts my time by over 50% (!). This isn’t something that I take lightly, and is going to have to be something I evaluate moving forward to see if it’s really working for me or whether some changes need to be made. We’ll see if for example I’m still able to get one level per week done. I’ll also probably have to rethink my devlog writing time, as before I always used Fridays as devlog-writing days — that doesn’t make as much sense when I’ve only got 2 full days per week for Rhythm Quest…

On a more personal note, though, my recent experience with grief and bereavement have also put some thing into larger perspective for me and have reminded me that in the end my goal in making this game is primarily for my own enjoyment and satisfaction (and everything else is secondary to that). Of course, it’s still very important to me that I’m able to consistently make concrete forward progress here, but past that maybe I don’t really need to worry so much. Well, wish me the best of luck going forward, I guess?

Wishlist Rhythm Quest on Steam today at https://store.steampowered.com/app/1635640/Rhythm_Quest/

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store