Devlog 1: The foundation

Nice to see everything working as intended, despite everything being quite barebones. But it really is a good thing as the foundation should be thoroughly ensured that it is of upmost quality before proceeding with the more decorative implementations, especially when dealing  with mutliplayer systems and authentication.

The project makes use of PUN2 for the multiplayer portion while firebase manages a realtime database for the player data like inventory data. Firebase also provides the authentication service where the user can create an account via email and have their player data saved to that account.

Not going to lie, when I actually push myself to adhere to good practices, I feel much more confident in the project. This is compared to what I usually did last time for other projects, where I had a "if it works, move on" practice. That usually resulted in a highly coupled, messy and straight up rubbish architecture. Managers would reference each other, a single function call would trigger a chain reaction that spans 5 different scripts, and so on. 

I feel like maybe it was because my main focus was the rate of development; developing new features, adding more content, fixing UI, where I had a very agile mindset where if it came to my head, I would not stop and think about how to implement it wisely, I would just do whatever was the most straightforward. Sure, back then it was fun seeing all my implementations work in the end. It gave me confidence. But by now, I have to grow up and mature my process. The earlier you mature the better, as I would see adhering to good practices as the "real coding", where you actually have to put your foot down, draw things out, rack your brains to optimize a system even though it does exactly what you want already.

Specifically for this project, I really need to make sure the foundation is clean. I have PUN2 and Firebase, and if I don't integrate them well, I can tell that this project will become an absolute shithole. I remember early on in the project, where the PUN2 and firebase scripts were working completely independently. It gave me so much stuff to worry about; like what if the user signs out midway in a room? That is the firebase side being signed out but what about the PUN2 side? The player will still be able to move around and interact with the world. Will there be a situation where the user signs in on their firebase account but is able to control another player? And so I had to wrap them together in such a way that synchronizes them and restricts all the shenanigans from happening.

Working on the realtime database was quite interesting. Learned quite a few stuff like for ScriptableObjects, when serialized to Json would just appear as "Instance: 22142" for example. It almost works, but on different runs the instance id actually changes sometimes so is completely unreliable. I used scriptable objects for my items, so when I wanted to store them in the database, it would be stored as "Instance 22142",  but when I retrieve it, my item instance id can change to "Instance 0" for example, and so even though I have a reference to an item, that item would not be the same item/would not exist in the first place. Hence, I had to make it so that the inventory system used a reliable way to represent the item. So, I just represented the item scriptable object using a string. For example, dirt. The string dirt would be saved to the database and when its retrieved and the player wants to use it, I can load the item dynamically using that string, by loading it from "resources/dirt", which is the scriptable object itself that contains all the necessary data for dirt. This architecture also makes a lot of sense, as lets say I make the whole dirt scriptable object serializable. The database would contain all the data from the scriptable object; data that will not change. Quite redundant. Extrapolate that for every single item, every single player,  majority of the database would be that redundant info that can just be stored locally.

Another thing is, I originally intended this project to be based on android, but building on android using unity is an absolute shithole. You have to install android ndk, android sdk, java sdk, deal with gradle and version hell. Running it on my phone through the editor was fine, so I really do not understand why it is so troublesome when it comes to building. There were so many errors related to java where it says it has trouble invoking some command for java sdk but when I run it on cmd it works perfectly. I searched everywhere, typed y to all the sdk --licenses, changed my environment variables, reset the external dependencies but still had error after error. What is worse is on all the forums, it seemed that for other developers, even if the build succeeded, the game would not run / multiplayer features would not work and all that.

So much bullshit happening on top of your own game. So I decided to just base the project on windows. Bright side is I learned quite a lot through trying to build it on android. Best is I did not know that tapping build number in your phone settings 7 times enabled developer tools. Cool.

All in all, the foundation is quite promising, and a lot of experience has been gained already. Hope things go well and I keep committed to this project. For now, I'll just continue optimizing the multiplayer and authentication features and make sure they work seamlessly. When I'm confident it is foolproof I'll start on the actual gameplay features. Some ideas to start are health management, weapons, consumables. Basically expand on my item system and make it flexible.