Hey there! 

I'm happy to announce that I've just uploaded a new build for Heart is Muscle! 

This build features: 

• New Resolution Options in the Options Menu
• No more saving during battle and during active conversations
• A loading screen that you probably won't even see! 
• You can now hear Mirche's corny jokes during the fight with Ratimir. 

Now with these bugs fixed, the only ones left are related to dialogue sprites showing/disappearing not how they're supposed to. Unfortunately to fix it would require me to remake all 100+ animations in the game which would take a long time! I heavily revamped the way I imported/used character animations starting with Ziva (and further streamlined with Mar), so no issues with them in those games. Sometimes you learn by doing and sometimes it doesn't work out, but you learn from that as well. 

BUT WAIT! THERE'S MORE!

Heart is Muscle is!!!! COMING TO STEAM!!!!!! 

WISHLIST IT HERE~!

So now that the 3rd(?) update for Heart is Muscle is out... you might be thinking, wow what the hey! How come this game required so much work? 

HAHAHA, well. I've been really enjoying reading other people's devlogs so I figured-- hey, why don't I talk about all the (honestly fun) challenges this game threw at me. 

-----------------------------------------------------------------------------------------------------------------

Ignoring the smattering of Unity tutorial games I had made, Heart is Muscle was only the second unity game I had made and the very first one in which I programmed everything from the ground up (minus the dialogue system). 

In the end I ended up making: 

1. Turn-based RPG battle
2. Limited Space Inventory
3. Scene Transitions
4. A "World Clock"
5. Overworld map

Which in the end, each of those were not too difficult to make, especially the ones where I was following a tutorial.

What I quickly learned was that it's easy to build systems in isolation. It's a whole other beast to get those systems to work with each other. 

But after a long period of trial and error, I had finally managed to make it work.

"Great, now all that's left to do is put in the art, one last beta test and then build the distributions, right?"

HAHAHAHAHAHAAHAHAHAHA. 

So. If I could go back in time and warn myself about one thing about Unity games is this---

Unity tutorials don't prepare you for the headache that happens when you finally make the builds of your game. EVERYTHING WILL BREAK. You can test as much as you want in the play window, but actually building the game (and having it play on other people's computers) is probably the hardest part of the whole experience. 

About 90% of the bugs only started appearing in  Heart is Muscle when I had pushed out the very first builds and realized.... oh. Unity tutorials sure do leave out a lot when it comes to the tail end of development. 

See, I had build the entire game in canvases, which is like if your player has a piece of paper taped to their face and I'm pulling up images to show on that piece of paper. They're not moving around in space, they're stationary. But canvases can break if the players resolutions is different than anticipated, so I had to quickly add canvas scalers to all the 20+ canvases in the game (good luck if you missed one). 

When I had built my very first build for Heart is Muscle I just burst into tears because the whole screen was just.... blue. I spent 8 months working on a title that when you start it up, it was just a blue screen. 

But it's okay. I finally figured out what had happened (for every unity game I've made post Heart is Muscle I make a folder in the inspector called "UNITY GUI DO NOT TOUCH" ) and thought, okay. That's gotta be it, right? The last horrible completely game braking thing to work with? 

Let me introduce you to the worst bug in this game: 

I had introduced the save/load feature as one of the last steps. BAD MOVE. REALLY BAD MOVE. 

You know what's not fun? Trying to control the order of operations that happens during loading. 

See I had my battle system, my inventory system, and the save/load feature was coming from Dialogue System (side note: this plugin is amazing and has saved my butt so many times, all of the bugs here are not from it but instead from me honestly being a dumbass). And each of these systems goes at their own speed and does their own thing and how do you control that while also not knowing how fast your player's computer is and what will trigger before what. (This is why Ziva has that weird experimental build) 

When you load into a save, I was having an issue where data from the previous load will carry over into the new load because the scene was loaded before the save data 😱 so you get Boro thinking that Mirche isn't with him when the guy is standing right behind him. I tinkered around with it (and major major thanks to Tony from Pixel Crushers for his help) and tried implementing a forced loading scene to try to "clean reset" the scene data. It mostly worked except a single conversation trigger that played when Boro first leaves Swoleville because I threw it into the start function which is apparently triggered before the new save data is called aaaahhhhhh. 😱😱😱 

So then I was thinking, okay I'll implement a string variable that is storing the scene we are loading from (and thus checking to see if you're leaving from Swoleville) but the issue is I couldn't use an override because I'm using SceneManager.LoadLevel at like a billion different points so I'd have to go into the base Unity code and change it there and that feels like a recipe for disaster. (Imagine: me going into the base unity code to change how it calls it's loading stuff. I'm sure NOTHING could go wrong with that, right?)

In the end, it all came down to using a special Dialogue System trigger to control the start function calls instead of it's own code to adjust for the save/load speed. Which, hey! It's great DS has that option to use and it's really great that I now know it exists to use in future games. But it all came down to me not knowing about a function call in a plug-in. (And also maybe I should have reviewed the plug-in's documentation a bit more XD;;)

(Me when I finally fixed the save/load glitch)

Side note: I would not recommend using too many plug-ins concurrently. Plug-ins are awesome but a lot of them are "black-boxed" where you have no idea what is going on under the hood and sometimes you literally can't fix a bug without getting in contact with the original plug-in developer. Again, in isolation they're great. In tandem is where things get scary. 

So! The canvas issues are fixed, the save/load monster has been vanquished, and even more bugs that I haven't mentioned here (inventory bugs, persistent DoNotDestroyOnLoads, and Borislav multiplying himself but only sometimes??)-- surely that's it, right? That's it? 

 For now. I'm sure even more bugs will appear and I might have a few more updates in the future (I haven't even gotten to some typos I've found), but for now I think it's done. For me, it's done. 

I've had many people tell me I should make longer games, but I mean-- I just can't see myself making longer games right now. It was hard enough getting the canvas issues fixed in a game with three towns and an overworld. If this game had been 10x as long?! I can't even imagine what that would have been like to fix...

So for now, I'm still making smaller games. :) Smaller games to streamline my processes before I start making longer stuff. 

Good things come to those who wait~!

And with that, I wish you a very happy weekend and if you haven't had a chance, maybe give this new edition of Heart is Muscle a try. (And let me know if you hit anymore bugs........)

- Heiden