Crysthell Devlog - The First of Many!

I started working on Crysthell for the #BulletHellJam2021 which ran from Thursday, April 15th - April 22nd. Although we had 6 days, I didn't fully commit until the day after launch. So, already a day behind, I sat at my desk and hashed out ideas.

I toyed with working on something more complex with fully animated characters, and even though I'm confident I could have had "something", I know how time consuming that can be. So, I decided force myself to keep it simple -- not an easy task for me.

With this being my first game jam I wanted to yolo it -- ya'know, go big or go home -- but I didn't really know what to make.I  looked at some examples of what was expected given the allotted time frame. Now that all being said, this isn't my first game. Just my fist jam. I teach game design and am doing what I can to go indie. I'm a huge fan of other indies like Team Cheri, and some lesser-known ones like DevDuck and Jonas (shout outs to Dauphin and Will You Snail) .

The idea of Crysthell came to me in the first few minutes of inspiration-gathering. I like action puzzle games like Portal which features "deadly lasers", and the visual esthetic of Will You Snail really pops. Now that I had that, I needed a name which came to me when asking myself what to call a crystal bullet-hell. It seemed obvious.

All that took about 5 minutes...maybe, an hour? I started modeling the ship, items, and environment pieces, and setting up the base project in Unreal. I'm a stubborn stickler for not using pre-made assets. I yell at my students for doing so and I wasn't going to stoop beneath my own standards.

For the music, I commissioned my composer Elisha, who was already working on my mobile game Blockout. He was naturally excited about the job and brought immense enthusiasm and a unique sound to the project. If you like what you hear, let him know. His itch profile page is here: https://elishamullinsmusic.itch.io/ 

When  it comes to programming, I typically prefer C/C++ but for this project I stuck with Unreal's Blueprints. Though they get rather messy.

I tried to prioritize features based on what was necessary for the main game loop, movement, and feel. I did add some extra features like an options menu to allow user control over how the game handles, a save system for storing progress. There were several features I wanted but couldn't implement for the jam like a line of sight opacity system to fade out obsticals that obstruct the player's view to the ship, a mini-map, and a third level that introduces another element of difficulty ( a spinning laser turret that causes the crystals to spin fast with lasers in 8 directions. I also wanted some extra pickup items. A lot of that was left on the cutting-room floor for one reason or another but mostly because of priority and time. Like i said earlier, I started almost a day late into the jam but also lost almost another entire day because my home internet went down and I was so worried I wouldn't be able to upload that I crammed as much as I could in while borrowing internet from elsewhere.

Known Bugs... in play tests players didn't like the physics-based tank controls even though it makes the most sense for the way the player and camera move. The advantage of tank controls is that the forward button is always forward regardless of camera angle. This helps keep the player on track as they move and look around the world. The downside is they can be disorienting for players expecting discrete axis inputs. To mitigate this, I added in two features to make the tank controls more bearable. The first was rewriting the physics to handle in the way I intended them to which is what the default setting is. The second is to disable momentum when using the custom physics movement. I did, however, run into a snag with dialing in the precise move speed for the player since movement varied drastically between the editor testing and standalone play testing. To help with that, I began adding in an option to allow players to manually adjust forward and angular input speeds in the options. But I had to disable the forward adjuster. The option is there but it won't do anything. The angular one works fine. I had to stop because of the deadline to package and submit the game.

There is controller input for basic movement but the camera currently doesn't work and neither do the menus. I honestly hate Unreal's widget system. I think it's the worst thing ever invented. It doesn't natively support controller input beyond a few buttons and what's there is so broken that I often just write my own logic for it. And let's not get into widget communication. It's not so much as difficult as it is unintuitive -- but that's just me ranting.

Ultimately, I worked to polish the game as much as possible. Still, some things are a little clunky. Sometimes the cut scenes don't transition out, causing the player to get trapped in the cinematic camera and forcing a restart to the main menu. I should have added a retry button in the in-game options menu.

Some optimization is also needed. The lasers run off of line traces which throttle the performance on lower-end systems. This wasn't noticeable as much in editor plays but standalone and packaged game plays showed this. I would also like to make the walls shorter. The player will never move that high so it they don't need to be that tall. Plus I think it will add to the esthetic.