Devlog 2: Never ending polish

Previously I talked about how important the foundation was. At that time, I was quite proud of how it was built. Things were working well and the architecture was fairly decoupled, but after looking through the system and finding ways to improve it, it lead me on a journey where I uncovered area of improvement after area of improvement. Stuff like using observer patterns to decouple scripts, properly synchronizing my network ecosystem, which I only realized were horribly unsynchronized by making a debugging tool that shows me the connection status for each system throughout all the scenes.  Actually even though it flows much better now, im still confident there are huge areas of improvement for that part.

But having the debugging tool shows the power of investing in debugging features for our projects. Looking back, I would definitely have prioritized it at the start, so I would have had discovered these small bugs earlier on, and wont have to trace back and refactor everything from ground up.

I remember there was a period where I was so baffled by a script from another scene having runtime errors in a scene that it was not in. The entire scene did not have a single reference to the script, even during runtime. That is the equivalent of writing on a piece of paper and your writing appearing on another piece of paper. How the hell did the writing transfer over? No idea. Made absolutely no sense at the start, until I realized it kinda made sense based on what I was doing. It was my observers from the previous scene being triggered by network events. Now I finally learn the hard way, why its such an important practice to unregister your delegates on the OnDestroy or OnDisable events.  But seeing the errors happening in realtime was genuinely so baffling. Glad I put two and two and found out why it happened.  

I also remember a period where if the player left a room and joined back, their pun network instance would duplicate and so the player could spawn in multiple copies of their player object that they can control. Until now im not sure why it happened, but I fixed it by using a normal script to spawn the player objects as opposed to a static instance previously. Not really sure why it resulted in duplicates, but hopefully one day I will find out.

Another weird thing: I noticed my database data as being wiped out randomly sometimes. Apparently, it was because there was an error where my script could not retrieve the userId, so my parameter passed into the database was null. It being null meant it wouldnt save the data in the inner layer, but instead save it in the outer layer. So essentially someones player data would replace all other player data, wiping out and overriding everything. Lesson learnt is always handle nulls when saving to the database. One wrong save and you can kiss all your data goodbye.

I found all these bugs even though I was confident the foundation was quite strong, but looking back from now it was really not that great. Glad I actually was able to find those areas of improvement and make the system more robust. But this really shows perfection is always a few steps away. Take those few steps and it will still be a few steps away. With my limited experience with unity, if I have already found so many areas to improve on, I can only imagine what an experienced developer finds. But I guess for now the most important thing is after implementing, to question your design before happily moving on to implement other, more fun features.

Oh also, for the development so far, I found having a piece of paper and pen on the side to jot stuff down proves really useful. Sometimes stuff pops into our head like questions on why something happens, or sometimes you have an idea on how to implement something, even more times, you have uncertainty about a particular system and so drawing it out helps you clarify your thoughts. This is something new that I am trying, and so far it has been extremely valuable.

Another really useful thing I find so far is doing these devlogs. Coding is one thing but voicing out your process and learning points really reinforces your confidence and knowledge about what you do. Sure it takes some time to remember stuff and voice it out but I feel like it makes the experience much more fruitful, and it almost feels like this gives the project a "soul", even before the in-game world is created. Better yet, other people can read these and gain all the insight into what I went through. Insight no random youtube tutorial can give.

The main updates for this devlog is mainly the polishing of the networking system. A huge chunk of code was refactored, the online statuses now work; go online when logged in to pun with authentication from firebase and then go logged out after signing out or on application close. The online status also helps kick out another instance from logging in with the same account. Although these seem very trivial, on the backend it gets really convoluted and confusing and so I took quite some time figuring it out. Another update is a options system, where the player can adjust the display and volume. Quite straightforward, but very necessary. Next is continuing to polish the network system and then I can hopefully start on expanding on the item/inventory system.