Quick overview of all changes/updates implemented this month:

• MUSIC: wrote almost all remaining music for Episode 1, and recorded some live parts for certain tracks
• MYSTERY: created a "glossary" menu in the backlog notebook for reference (including things like the terms of the Witch's deal, etc)
• SAVE/LOAD: system can now handle loading from multiple "progression points" within each scene
• AUDIO IMPLEMENTATION: code for seamless audio looping (with reverb tail) exists now and works
• TEXT SYSTEM: scrolling text can now support rich text codes, including font style changes mid-text
• POINT-AND-CLICK SYSTEM: there is now a visual change to the background image when hovering over an interactible object
• UI DESIGN: started reformatting main menu - still in progress

The rest of this development log is a lot more personal than usual, and is quite long. This month has been a lot, and I want to talk about how that impacted my ability to work on this game. The fact I have still done so much is a testament to how much this game means to me, and how much it helps to acknowledge when I just can't do what I planned to do and need to re-prioritize.

I was severely set back this month because of health issues. This resulted in a compounded setback because the health issues made me more easily frustrated by life in general, so any development issues ballooned into perceived catastrophes.

I eventually identified that I was really stuck on a few particular aspects of the finalfinal-final-forrealfinal vision for the game:

• Design - I hadn't sat down with my overall art direction since finishing the demo. It was still feeling rather demo-y from a design perspective and I became self-conscious about this. On the other hand, I was really stressed about whether changing anything about the design philosophy this late would create exponentially more work for me as an artist, and feeling like I might have to choose between quality and finishing.
• Narrative - although I'd written Episode 1 in full, I wanted to do more foreshadowing of much-later reveals. As I started considering how to do this, I began to worry about being so heavy-handed with it that I would give everything away and completely undermine the whole project before it gets going. I was too afraid of striking the right balance to make any actual progress.
• Build/Implementation - a lot of mechanics were still buggy, and in addition to fixing them, I still needed to do a lot of tedious and very manual work to build the remaining scenes of the game. This work felt so mind-numbing that I had no desire to do it, and yet it still needed to be done. A perfectly demotivating combination.
• Over-fragmentation - at this point in the game's development, the fact that all of my tasks for it were separated by category in Asana ("art"/"audio"/"mechanics," etc) made it difficult to see the dependencies in how these all come together, which in turn made it difficult to manage the remaining tasks to ship the game. It seemed like my to-do lists were all invisibly interconnected and felt impossible to track progress.

Once I realized I was stuck, and was stressed out by my to-do list but not actually working on it, I ignored my actual planned tasks for that week and gave myself a new assignment of figuring out how to get un-stuck and feel less overwhelmed. This mostly came in the form of asking friends for advice. It also involved following my own advice I love to give other people, which is "acknowledge when a system isn't working for you and change it." I went from feeling frustrated, lost, demotivated, and stressed to really excited after some self-reflection and 2 conversations.

Over-fragmentation

...Technically 3 conversations, as the fragmentation issue was solved thanks to an earlier conversation I had last month with a different friend about my narrative workflow. After talking with her, I started using Notion to manage the writing side of things. I built out different projects for each particular scene so I could have not just the text embedded, but also additional notes on metanarrative information, links to BGM inspirations, checklists, and more. This was something I did just to make it easier to finish writing the full script of the game, and it was definitely a game changer (hah).

I initially built it out as a writing tool, but now that the game is in the final stages of development, I find it is useful to think about all of my remaining tasks like this. It helps to consider them holistically in terms of the multimedia scene(s) they relate to, not as discrete and disconnected art/audio/mechanics needs. Once I realized this, I spent a weekend migrating all of my Asana checklists into the scene-based projects I'd already made in Notion. This was a lot of work, but it is now much easier to see a direct path from the current state of Amadeus to a finished game. And it gives me achievable goals on the way there: discrete checklists for finishing individual scenes, which are playtest-able while I work on the rest!

(I still use Asana to manage big picture stuff as well as recurring reminders and what I plan to do each week, but the specific tasks pertaining to the build of Amadeus Episode 1 all live in Notion now.)

Narrative

To address my narrative bottleneck I first had to get over the thought that spoiling my narrative to a particular friend would ruin it for them. Once I actually asked them if they'd like to be Amadeus Spoiler Friend #2 (because I was desperate and knew I needed more help workshopping the narrative), they were so enthusiastic I regretted not asking them several months earlier. We set up a voice call, I told them everything, and we bounced ideas on certain Very Important Topics.

I know that the more I have figured out from the very outset, the stronger the whole series will be; so I am very excited about this.

This friend also asked some questions that I hadn't thought to ask myself before (even though, in retrospect, they seem obvious) - and answering those questions gave me solid direction for finishing this installment in a way that's fun and also should pay off really well later. Then after our conversation they also offered to proofread certain sneaky things I am doing from the lens of their Forbidden Knowledge.

Talking to them has made me feel much better about my reveal/foreshadowing pacing, and I have someone I can ask directly about my "is this too on-the-nose" concerns, which helps a ton. Also, it just felt good to hear someone say "oohhhh, that's really cool!" about something I can't talk about until way later, because I THINK SO TOO I'M GLAD YOU ALSO THINK SO.

Build/Implementation

As for build issues, I talked to a friend (listen, the power of friendship got me through this month, I'm not going to lie) who is a career game developer, and who previously worked in Unity although he doesn't anymore. I used to worked with him on game jam games... the first of which was in 2016... when I was fresh out of undergrad composing exclusively in MuseScore. In a roundabout way, it's partially thanks to him that I eventually built a portfolio to go to grad school, which in turn got me to make Amadeus and also become a (much worse) Unity developer myself. Funny how things work out.

Anyway, I really enjoyed talking to him. He is non-judgmental - he knows I've taken exactly one Unity/C# course and have learned the rest by trial, error, and StackExchange.

He gave the best possible advice for where I am currently at in development: since I've built almost everything, even if I've done it with the world's jankiest spaghetti, the most important thing right now is to Just Finish It. But once it's done, we're going to have another call where we can discuss how to refactor everything to make my life a million times easier making Episode 2.

But it wasn't all about planning for Episode 2. He also helped me identify how I can slightly tweak some of my existing structure to automate more things that I've been doing incredibly manually. We effectively made a list of "here are the things to do NOW to make things simpler, and here are the things that are not worth fixing at this stage but we can talk about for Episode 2." (Example of a quick NOW fix: instead of dragging a reference to my Menu Settings script to every single slider and button in my menu, just have a script in the parent for all of those menu sliders/buttons that automatically grabs the sliders and buttons in its children and assigns it that reference. Then I only have to assign the reference ONCE to the parent. Seems so obvious now! I need to be doing a lot more stuff in scripts to just make my own life easier.)

In the grand scheme, though, that advice wasn't the most helpful thing he told me by a long shot.

In our conversation, since he is a developer who chose that career because he enjoys it, he started talking about focusing on what I LIKE about building the game. When I open Unity, what do I find fun, and want to do more of? Obviously I should also take note of the major pain points so we can reduce the amount of time I have to deal with them in future episodes; but he also told me to pay attention to what I really like to do.

I'm going to be completely honest. I'd completely forgotten that building the game itself was something that was, at one point, fun. When I was first building the game, it involved a ton of interesting problem-solving. It was asking myself "I wonder if I can figure out how to do this..." and being excited when the answer was "yes." It was showing off by doing way beyond what the Unity class homework assignment asked. It STOPPED being fun after I'd built all of the baseline mechanics I wanted to use, and then my to-do list slowly - so slowly I didn't realize it was happening - shifted from "stuff I want to build," into "stuff I think other people will want me to implement."

And while many of these mechanics are indeed important and good, it is not particularly motivating to build mechanics just because I think someone else will want me to build them. For the past several months I have been programming for other people and not for myself.

I really, really appreciate this next bit of advice this developer friend gave me. He prefaced it by saying "now I don't usually advise people to increase scope, but..." and that's how you know it's good advice! It is clearly tailored to ME and what I find motivating. His point was: this is MY game. I'm building it entirely myself. So if there's anything that I'm curious about, anything that's made me think, "hmmm, I wonder if I can figure out how to do this?" - then I should just do that. It's my game, I'm not building it for anyone else. I can build stupid mechanics for no reason. I can, and should, try building stuff just because it would be cool.

And that was so incredibly motivating. I actually HAD been thinking of a particular "what-if" mechanic, a mechanic I'd actually literally said "man, it would be cool if..." to my writer friend in our conversation from a few days earlier! But I'd given up on it because it seemed not as important as other things I "should" be working on. This new advice gave me permission to prioritize self-indulgence, not just in writing/art/direction/music, but in the programming of the game itself. There's a reason I am making a game, and not another form of media! I find the process of building the (janky) mechanics myself fun, interesting, and rewarding! It lets me play with the part of my brain that watches math YouTube videos for fun, in addition to the part of my brain that likes making music that goes dugga dugga and drawing pretty pictures.

Opening up the engine and writing code is supposed to be something that makes me feel like a cackling evil wizard, not a bored and frustrated person going through the motions because they have to. There is no obligation. I am making this because I want to make a game.

Soooo after this conversation I immediately built three things that I'm really happy with.

• Text now supports rich text codes, which means I can be REALLY tacky with fonts and colors and all sorts of stuff.

(Obligatory this-is-a-WIP disclaimer but the finished game will probably be comparable in terms of how much psychic damage it deals to graphic designers.)

Now, Unity's TextMeshPro supports rich text by default, so you may be wondering why I haven't been doing this all along. Two reasons: one, I didn't realize that until recently. Two, the way my text-auto-scroll mechanic worked was NOT compatible with this. I had to completely re-work the entire logic of that mechanic so that it wouldn't also visibly type out the characters " <style= " in the textbox. But after making the necessary changes, which was a headache but it's fine I figured it out finally, I HAVE BEEN HAVING SO MUCH MORE FUN IMPLEMENTING TEXT!

• BGM with a reverb tail can now loop seamlessly, which I really wanted for a very important later scene I've been working on.

This was one of those things I'd been putting off as a "nice-to-have" and figured I shouldn't spend time on until I finished working on "essential" stuff, but after this conversation I decided to just sit down and make it. It was really easy! It only took me like an hour, including time to research! I'm actually really excited about this because I hate basically every audio middleware program in existence (Wwise, I'm looking at you) and it's so much easier and more convenient to just do this in Unity.

In fact, this is pretty much the only script I have that is super generic and not tied up in lots of other Amadeus-specific spaghetti, so if you have a use for it I put it on GitHub here: https://github.com/ArcanaXIX/UnityScripts/

• Hovering on interactible objects now visibly changes the appearance of the object, in addition to the existing cursor changes.

Actual implementation needs to be tweaked a lot, but this was my first time using sprite masks in Unity and it was very fun getting it to work. "Background objects visually change on hover" was another mechanic I had been considering for a while, but I was thinking about doing it very manually by rendering a unique sprite for every single interactible and then activating that sprite when it's active. This would require so much extra art and very hands-on implementation, so I had given up on it.

Once I turned it into a question of implementation, it became less manual (I no longer need to redraw every single interactible object) and also a fun challenge to learn more about Unity functionality. The only additional art assets needed are something with roughly the right shape to use as a mask, and then an alternate version of the full background art which can be really easily made by just applying a filter.

Here is the version of that background art that I'm using as a proof-of-concept, which was made in about 2 seconds by just converting the existing image to a 1-bit layer:

I will be experimenting with what exactly I want the highlighted areas to look like, but once I've found a process I like, it will be really easy to just apply that to all of the background images.

After importing the asset, I just added some very simple code to reveal part of this alternate art using sprite masks when you hover over interactible objects. The only detail work using this process is in the sprite masks for each interactible, which don't have to be perfect for it to look good, just approximate. Pretty straightforward and feels good. 

I'm really satisfied by how well it works even as just a functional placeholder - this is with using the "N" key sprite as a mask for testing purposes. I intend to do more than just add a black outline, but again, functional placeholder:

(I'm too lazy to make a GIF, but imagine the window there is brown pencil like everything else until you hover over it and then the black lines appear. I'll definitely be making a new gameplay trailer once this is in better shape, so look forward to that if you want to see it in action.)

Which brings me to...

Design

...except not really! I just needed to realize from my playing around in Unity that "Design" is not a separate and distinct thing that can be tackled independently from implementation. Implementation is a driving force of design. By approaching implementation with joy and excitement, I have also found an avenue to address the game's design needs. I'm going ham with fonts and figuring out what visual direction I want to take the interactible mask layer.

Instead of treating the "design guy" and "implementation guy" in my brain as two coworkers who vaguely dislike interacting with each other, if I imagine them as two coworkers who are both stoked and insane about this project and each other's work, the collaboration becomes really fun. The implementation guy shows the design guy this mechanic they built and the design guy goes "oh, I can have SO much fun with this. I'll be right back with some placeholder assets so we can see what looks good!"

Motivation

I think the actual message of this devlog, at its heart, is exactly the same as last month's. I've just been repeatedly coming to the realization that I keep trying to make a "good" game, by some generic "objective" definition of "good," and it's made me miserable. What I really should be doing is making an incredibly self-indulgent game. That means a game I find fun to build, too!

Amadeus is not going to be a broadly marketable smash success. It has a chance, when it's completely finished, of gaining a cult following by word-of-mouth via people going "you have to just trust me and play all 5 episodes of this. We can't talk about it until you're finished though." But, as its sole author and artist and musician and developer, Amadeus is something that I need to make in a very certain way to prove a point. It's coming entirely from within, and I am absolutely determined to finish it, so I must be self-indulgent.

Let's not get it twisted, though: I don't believe that self-indulgent and good are at odds. Spending a couple days making mechanics for fun actually made the game better! But in a project like this, where my primary goal is personal artistic expression, and my secondary goal is proving I can finish a major project... motivation is the most valuable currency in the universe, and therefore self-indulgence matters more than anything else.

I am speaking so passionately about how motivating it was to talk to people who understand my priorities and are excited about meeting me where I'm at, because without motivation this game would never be finished, and I want to be very honest about the fact that finding ways to stay motivated has been crucial.

I would also like to contrast these motivating conversations with how demotivating it is to receive feedback from folks who, shall we say, are missing the mark on what this game is and seeks to be.

While I sincerely believe that Amadeus: A Riddle for Thee is going to be good, there are a few things to keep in mind about it. These are things that I think are pretty obvious, but just in case they aren't:

• It is made by one person.
• With a budget of $0 and all of my spare time.
• With a very strong professional background in audio, 
• And the scrappiest DIY skillset in everything else.

That's not to say it can't still aim to have smoother player experience, to have stronger visual cues, to be better written, to be a better work of art. Those are in fact all things that I have been constantly working toward and seeking feedback to improve, because I do want other people to engage with it and have a positive experience. I am making this to share with other people. But I will occasionally receive feedback that seems to want to steer Amadeus in the direction of your average Kickstarter-funded publisher-backed title with 15 people working on it, and not a solo passion project.

The remainder of this devlog is written as objectively as I can while very demonstrably being upset about it. I debated removing this section entirely, but I think it's important to discuss, because this kind of thing can really impact development when you're a team of one person.

I also know that normally this kind of feedback wouldn't bother me so much, but since I received it after going on 2 weeks of dealing with the onset of a new chronic pain issue (which has been a massive stressor), it utterly tanked my mood.

Dismissive, Demotivating Feedback

I received the following feedback as "things to work on" from an anonymous juror evaluating my game for an indie game event.

When first meeting the witch the dialog is just incredibly long and boring and I ended up skipping through most of it. Given how linear this story seems to be, I think it would be better suited as a webcomic or a motion comic, not a visual novel. The interactivity hinders, rather than helps, in this case.

All due respect: who are you writing this critique for? For me, to make my game better? Or for you, to validate your own preferences? I think the answer to that is clear.

This is an obvious--and egregious--example of particularly demotivating feedback, but since it is real feedback I have really received, I want to talk about it. Specifically, I want to talk about how much it sucks to hear this.

This isn't actionable, unless you count "throw everything away and do something else" as an action worth taking. This makes no attempt to meet me where I'm at or consider my reasons or motivations for making the game as I have. It does not even consider that there may be aspects of the interactivity that are crucial to how the story will unfold; I'll acknowledge that the currently-live demo does not do much to showcase this, but this feedback has already decided that there is no such intention and I've wasted my time making a game.

My actionable feedback is to go make a webcomic instead. It also insists that my writing is boring, but doesn't tell me how to make the Witch dialogue more engaging (which, I have received other feedback from others addressing the same topic, who did give me specific and actionable feedback that has since been implemented). It just tells me that it's boring and they didn't like it.

And what's worse, this was feedback submitted by a juror evaluating my game for an indie games event. This kind of feedback sucks no matter what, even if it's just somebody leaving a public comment. But this is an individual who, in a certain context, was given some manner of influence, authority, and merit; and given this authority and merit, their feedback amounted to, "why did you even make a game?"

The rest of this juror's feedback was similarly dismissive and made it clear they did not like the game. That is understandable. However, it made no attempt to acknowledge that this game does have an audience, even if it's decidedly not this juror. Every single other juror's feedback at least understood that Amadeus has certain priorities and gave feedback that was more or less aligned with those priorities, but this one did not seem to think I've ever so much as had anyone else playtest it. In fact, they effectively said as much:

I get the feeling that this is an experience that makes a perfect amount of sense to the developer but that there hasn't been any attempt made to make it playable for someone who doesn't already know the garden path.

And this is feedback from before I decided to become more self-indulgent! This was the reaction to the game in a state I was actually trying to make even slightly marketable! I suppose in a way it validates my current priorities, because even when I try to prioritize quality over self-indulgence, people like this will still assume I've prioritized self-indulgence and write dismissive feedback about it anyway.

This feedback sucks so much I've dedicated a full segment of my monthly write-up to discussing it. Because as I've already mentioned, when you are one person making an entire and incredibly ambitious game entirely by yourself, motivation is the most valuable currency in the world. In that currency, things like this are expensive.

Further, when you are one person, you are ill equipped to handle things like "100% of your development team suddenly has a new health issue" and can't delegate the role of Accepting Bad Feedback With Grace to someone else in a better mood. I probably wouldn't even be mentioning this if it weren't for the pain that came on this month, but the pain happened and it has tangibly impacted my ability to work on this game, and put me in a place where this kind of feedback was the single last thing I needed to hear.

I know very well what the professional wisdom on this kind of topic is. The professional wisdom is: if feedback hurts, that's because part of it may be true; don't use "it's a solo project" as an excuse for shortcomings of your indie game. If you can't do something, form a team with someone who can cover your weaknesses. The player doesn't care how many people made it, they only care if it's good. Don't whine when people point out that your scrappy indie project feels scrappy.

That's valuable wisdom for someone trying to make a profitable career in games. That's also precisely what I intend to do after I finish Amadeus: take on a more collaborative project with a group of people I trust - we have a tentative team, but I've told them all they have to wait until I've proven I can ship this whole 5-part game. I'm not ready to lead a collaboration until I first finish Amadeus and prove that I know how to manage a project of this scope from beginning to end. Beyond that, of course, it is personally important for me to share Amadeus's story before I worry about other projects.

"Put together a team to cover your weaknesses instead of making excuses" is not valuable wisdom when the entire point of a particular project is that it derives meaning from being one person's vision. That is what Amadeus is. It's far more about expression than quality, even if in my opinion, good expression is quality.

I sought feedback from this indie event because I hoped that indie spaces would understand that "indie" can mean anything from "personal multimedia art piece" to "modest budget and team of folks who quit their AAA careers to follow their passions." I've also really enjoyed attending this particular event myself, and have made meaningful connections with developers who have showcased at it previously. That's a big reason I took this feedback so personally - I had higher expectations that my work would be respected for what it is from this feedback.

Oh well.

At any rate, the lesson I learned from this was not that I should go make a webcomic, or that the music in Amadeus is too dissonant.

(I got that feedback as well, but it's easier to shrug off critiques related to audio because I am extremely confident in my abilities as a musician. I have an ego too big to deflate on that front.)

The lesson I learned from this was that my intentions are always going to be dismissed and misinterpreted by some people. There's nothing I can do about that, so I might as well make what I want to make with full authenticity, and hope the people who are interested in listening will hear what I have to say.