Pretty much sums it up, yeah. It's a Cube is my second project. With this one I've been trying to apply what I learned when developing my first game (Deathly Descent) both when developing It's a Cube, and when marketing/sharing it. Overall, I'd say this project has gone a lot smoother than Deathly Descent did so far. I want to take a few minutes to share some of the things I think I've done with It's a Cube that have helped the development process run smoother and overall just some methods I've been using that I wish I had used when developing Deathly Descent.

One of the mistakes I made with Deathly Descent was that I didn't make a page for it until I had nearly finished building the game. This time I made getting the pages up one of my first priorities, that way I could start getting some exposure for my game as early as possible. My second priority was creating a minimum viable product, aka the tech demo, which you can download on either Itch or Game Jolt. The tech demo isn't a lot, and it's not supposed to be, I just wanted to put something out as early as possible to get feedback from people as early on as I can and also as a representation of how far It's a Cube has evolved since I started the project.

I've been posting about It's a Cube as often as I can, both here and on Game Jolt. A lot of what I think people like to see from indie developers is the story behind what they've created, and how their projects evolved over time as they learned new skills. It's like what I was saying in the last paragraph about the tech demo being a representation of progress. I will keep making posts on social media, Itch and Game Jolt, and whatever other communities I can find about the effort I've put into what I'm building and the skills I've learned from developing my games.

Something else I've been trying to do is keep the code in It's a Cube as clean and organized as I can. What happened with Deathly Descent in the latter half of the project that really slowed down the projects development was many of the scripts were codependent, and any missing objects would cause a cascade of null reference exceptions from several others. I've been deliberately limiting codependency this time, the only script in It's a Cube that relies on multiple others is GameLoop, which is responsible for the gameplay flow and events that happen when the player does certain things. It takes data from many other classes, and calls public methods in many other classes, but these classes are for the most part independent and do not need GameLoop to be in the scene to exist. I saw the benefit of this way of programming when I added the main menu! I found that I could use the same cube prefab that's in the main scene (including the CubeRotation script, which is, well, take a wild guess what that does) without it breaking anything because the CubeRotation script doesn't check for player input to rotate the cube, rather the Player script checks for player input and calls public methods in CubeRotation that trigger the cube to rotate along either axis. If it's in a scene with no Player instance, then that script just does nothing. Player needs CubeRotation to exist without throwing a null reference exception, but CubeRotation does not need Player. Now that I think about it, I could probably write a line in CubeRotation that checks if there is a Player instance and disables itself if there isn't to save calling a FixedUpdate loop that doesn't need to be running. Yeah, there are definitely many areas of It's a Cube's code that I'd still like to polish up whenever I have some free time!

Another thing I'm trying to improve at is knowing when to ask for help. I don't like to ask for help, this is a weakness of mine and something I'll need to work on if I'm ever to succeed as a developer. There is a bug in the tech demo that anyone who's played it probably noticed where whenever the cube rotates to 0 degrees on either axis, it starts doing this weird jittering. I tried for a while to fix it on my own, but I was unable to find a solution. I decided that I wasn't going to be able to fix it, so I posted about my issue on r/gamedev summarizing the bug I've been having and asking how I could go about fixing it. I also pasted in the related code (which is part of the CubeRotation script I mentioned in the last paragraph) and a video of the bug. Someone commented on it and told me about Unity's interpolation functions (mathf.lerp for example) and after I read a bit about interpolation in the documentation, I was able to fix the bug by replacing my function to rotate the cube with mathf.MoveTowards which fixed the jittering! If you're reading this, thanks for the advice. I actually didn't know about Unity's interpolation functions. I really don't know as much about Unity as I like to believe I do honestly, maybe that's another thing I need to work on.

Overall, It's a Cube's development is going smoothly, certainly more smoothly than Deathly Descent did anyway. I should have an alpha version ready soon, all I need to do is find some music to play in-game because the game is a bit too quiet right now. Thanks for reading!