In Regards to Unity

I'm reinstalling Unity for what I believe to be the 10th time this month. 

The keener eyed dev-log readers may have noticed the "Post-Mortem" Post Type selected for this post. It's not entirely true. This isn't post mortem. Rather, post-mortem for the engine I've chosen for this project (or..... is it?).

For the past month, I've had numerous issues with Unity 2020 across my laptop (a 2018 MacBook Pro 15") and my desktop (custom built Linux desktop running Pop OS 21?).  While I accept that Linux support for Unity may still be a bit broken, macOS has been a stable and reliable development environment for me since I started the project. In fact, that's where the originally demo originated from in that 6-day Covid crunch. 

When I started this project, Unity seemed like the obvious choice. I was getting quite familiar with the interface and style of  constructing huge Object-Oriented containers for everything. Not only that, it was only going to be a demo (or so I thought). So I hacked and hacked away just trying to get a semi-authentic experience. The original goal being: it would be something good to put on my portfolio. The response from this little hack-a-thon was positive enough that I wanted to continue working on it. 

Notice that Net-Play was never even a thought. In fact, this wasn't really supposed to get as big as it did. I'm happy it did, and I'm happy to have connected with a bunch of fellow Duelists of the Roses fans. The truth is, Net-Play was a bit tacked on and it was my first attempt. For one, I'm not happy with the Mirror API at all. Mirror works well and is an amazing legacy codebase migration tool. However, Unity's multiplayer API implementation is quite abstract and to be blunt, quite poor. Mirror does what it does incredibly well. However, I do not recommend that modern Unity games use Mirror. Find something else, I'm not sure what yet though.  I've been spending a lot time lately seeing how lower-level projects in C/++ do it. A tightly controlled event loop or event-based API is much better than this strange NetworkBehaviour object concept in my humble opinion.  

Which leads me to another short sighted decision: C# for this project.

The original game would've been written in C or C++ with (almost certainly, at least somewhere. even in a lib or something) PS2 specific assembly. I chose not to reverse engineer the game at all, and instead re-build each component from the ground-up as a Unity MonoBehaviour (in C#). For a game like Duelists of the Roses, it turned out to be a fairly good way to do things. The things that it does aren't exactly rocket science, and the community has done an excellent job documenting the cards + combinations. 

Unity enables me to write bad code. C++ encourages me to think about the code I write much more closely. 

The problem is that the code is not exactly portable. For example, this game would be next to impossible to port to the 3DS without a complete re-write. If the game were written in C/++ from the start, porting could've been possible from day one. Now, Unity supports a wide range of targets. But most require licenses, and Vita and 3DS and of course no longer supported or available to download. Not to mention the game targets Unity 2020 (2017/2018 are the latest supported on the Vita, if the kits were legally available).

Before this project, I had some limited experience writing SDL2 apps that were cross platform to the PSP. It was a very primitive 2D engine. Recently, I've ported TheXTech and 3D Space Cadet Pinball to the PS Vita. Both arguably more complex than my prior projects. 

Then there's the Unity issue.

This game will never make over $100,000. So Unity is probably a fine choice. But besides the lack of portability to strange and obscure platforms, it's also bound to Unity's EULA. 

Not to mention, Unity seems to have gotten buggier and buggier and heavier and heavier since I started this project. It's a huge engine, and I just don't need all the fluff. Most of the time now, it actually gets in the way.  I'm once again spoiled by the time I've spent in the C/++ code bases recently. Though recompilation can take a long time (even then, full recompilation happens rarely) you are much more intimate with your code. Most libraries are open source. If not, most of the usage of the library can be gathered from traversing its headers. Getting something to happen is much more direct. It requires less thought and overhead from an experienced developer too. 

Maybe I'm just overthinking when I develop, but I frequently spend time thinking about the consequences that my code has. In a Unity/C# environment, there's a lot to keep track of. What does Unity do behind the scenes when you call `new GameObject();`? What does the Mono runtime do on top of that? When will garbage collection come and ruin my day? Etc. etc. 

I must reiterate, Unity is an amazing tool. But I'm ready to move on from it and not be tied to it. 

What's the move then?

To be honest, I'm not entirely sure. It's a fairly large code base at this point, but I could work to slim down the current code-base and open source. I'm interested in finding maybe one other C/++ developer to work with this time. I don't want to do a straight conversion of C# code. Instead, I want to write a tightly driven Network-based Event Loop and create a "console version" so to speak of DOR. In other words, I want to write the logic and hard data aspects first and ensure the network code makes sense, is easy to read, and is extendable. Then, extend to include the graphics and create a refined multiplayer mode. 

It would be absolutely trivial to export all the data I've already collected for the game and bring it into another engine. The models I've created were made in Blender, so they'll export easy. All the data was originally imported as a CSV, and I've already populated all of the cards in the game into a database. It would be trivial to export to CSV or JSON and then work to import it as an optimized binary format from there. 

But even then, I haven't completely sold myself on the nuclear option yet. It sounds better and better every day though. I could start over with a proper planned out code base, fresh experiences from the current iteration. The code base would be portable to any platform that has a C/++ compiler and reasonable graphics acceleration (Raspberry Pi anyone? Vita anyone? 3DS anyone?). Not to mention, I'll be able to ensure an efficient and tightly driven network event loop for the game before I have fun implementing graphics and gameplay. 

Either way, there's another factor that hasn't  been discussed: and it's life. I have a YouTube channel called Florida Van Man. In addition making videos and helping people and managing the website for that, I'm managing yet ANOTHER website on top of that. I really need to lighten the load and focus on refining my game design portfolio, instead of these other distractions. 

Concerns About a Rewrite

One concern regarding the re-write would be handling the data storage. It would need to be either in some sort of archive or some sort of database. Ideally, it would only be the text/byte flag data to keep it small. It should also be easily edit-able or, at the very least, the game needs to support adding new cards dynamically from community created cards. 

Campaign storage would need to be similar to allow community campaign creation. 

Tools would probably be easiest implemented in the game engine. I am a huge fan of native tools. However, adding native tools on top of everything would be an immense load. I would prefer to keep it simple and implement the editing tools with Dear ImGui in the engine. 

Card Effects might be handled via Lua. However, I plan to keep the concept of "generic effects" aka select this type of effect from a list and then fill in the parameters and how it should be executed. For more complicated cases, cards should have the ability to be coded with Lua. Additionally, external card effects need to be sanitized. 

I am open to any and all community input regarding this. 

Here's to hoping I can get Unity working properly again. Otherwise, a re-write may be in order....