Progress Report: 2019, Week 2


#1

This has been a very eventful week, but not all the news is good. But let’s start with the good! I’ve recently gotten a part-time job at my college which will help cover my living expenses while also putting me into contact with very influential people on my campus. This, in turn, widens the pool of contacts and references I have which should help future development. Additionally, I don’t believe it will substantially impact my ‘off-time’ which is very important to me as my previous job left me unable to think of anything else and if I wasn’t working, I was dreading going back.

Returning to development, the new UI has been fully ported to to the main scene and a caching system was designed to ensure repeated downloads of the same image are a thing of the past. Additionally I was in the process of porting this into a standalone utility library when some big news hit.

To make a long story short, Unity revoked a third-party developers license to use Unity. Incidentally, the same day Unity launched the page advertising a service that SpatialOS would have been in competition with. Now to be entirely fair to Unity, they have responded denying Improbable’s claims while stating they did violate the Terms of Service in some undisclosed way.

This post appears to directly contradict what Unity’s Terms of Service actually say and simply adds further confusion to the fire. For reference, this is the current EULA.

There are two chief concerns. Firstly, the EULA can be updated and applies retroactively meaning, at any time, you can lose your license even if you developed your product to comply with the existing version. Additionally, the language is horribly vague. For example, apparently distributing your game via Steam, hosting a server on Linode or streaming a game via Twitch are all forbidden per Section 2.4.

You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services.

Unity’s blog directly states hosting a server on a ‘generic’ hosting platform is acceptable, but the wording of the EULA, a legal document, states otherwise. Thankfully they have stated they are working to clarifying the language “right now” and if this occurs, the risk does greatly diminish, but the risk of EULA changes remain.

I’d like to think Unity Technolgiies will stand by their word and work with the community, but so far their response, while certainly not ‘evil’, is so tone-deaf as to be scary. This entire situation is toxic and while Improbable may have been in the wrong, this results in Unity attacking a third-party business for vague ToS violations that were not even apparently in effect at the time.

Hopefully the backlash from this results in Unity bringing clarity to the Terms of Service, properly announce changes to it and not apply those changes retroactively or have some form of grandfather system for existing customers. These are not unreasonable requests and I think it’s vital for a company such as Unity to have a legally binding contract their users can rely on.

During all this unnecessary drama, I’ve been researching alternative systems for Unity including Unreal Engine 4, Godot, Love2D, Heaps.io, MonoGame/FNA and even just using Golang. None of these solutions is a drop-in replacement for Unity, but perhaps one might be even better than Unity. While early development time will be slower, the end result might be a lighter, faster game that is better for the community. Perhaps even HTML5 technologies would be appropriate, however my experience with Roll20 leads me to believe it would not be well suited to large resolution files.

My intention is to create a bare-bones framework and attempt to impliment it within each engine. For example loading external tokens, moving them around, replicating them on the network and having a simple character sheet. From there I should be able to gauge how each system works, some of their pros and cons and which might be a winner.

I certainly realize this may be an overreaction, since Unity doesn’t care about me whatsoever. But that might change one day and I want to ensure BiosHub survives long into the future. And in the end, even if Unity ends up being the final platform, further research and planning will result in an even stronger platform for everyone.

If anyone in the community has any suggestions, criticism or would like to help, please be sure to let me know! At the end of the day, BiosHub isn’t just for me, but is for every aspiring adventurer.


#2

Godot is officially off the table, largely due to two major outstanding issues.



BiosHub uses a great deal of text and so this is a complete show stopper for using the engine. I’m sure, given time, these will be resolved but for now it just isn’t ready.


#3

On the subject of text, I’ve spent nearly three hours attempting to test UE4’s font rendering for our purposes and, well, this is the result of three UE4 answers posts and a bunch of setting tweaks.

And just to be clear, that’s m3x6, a pixel font. Clearly either I’m doing something horribly wrong during the import process (certainly a strong possibility!) or UE4 isn’t designed for such fine detail fonts, also quite possible. Either way, this result is pretty much the final nail in UE4 for this project. It’s totally amazing for high-fidelity games, but the lack of Paper2D updates for the last three years combined with the heavy editor and the probable optimization conerns for weaker hardware leaves me moving on to other options. Note that this is not to say I dislike UE4, It’s an amazing engine, but as BiosHub is as much an application as it is a game and because I don’t have a C++ coder on staff to bend it to my will, it’s simply a bad fit.


#4

After some basic testing with Heaps, which uses Haxe as it’s language, and careful review of MonoGame, I’ve concluded both of these would be very strong options. Haxe perhaps has an edge in portability, but MonoGame is very well supported and uses C# which makes it compatible with any generic libraries written for Unity. This gives the advantage of letting me use any generic libraries I develop with either system with few to no changes required. Using a library such as Nez with MonoGame would be quick a good start for a 2D game, however with a changing project direction, I’d like to keep 3D on the table now.

Other worthy possibilities include Xenko, PixiJS, Armory and Cocos2d however for this project I feel they’re either not suited or not ready for production yet.

Additionally, there has been some promising progress from Unity’s side with an update from one of their employees handling the ToS debacle stating that the entire 2.4 section isn’t meant to apply to game developers whatsoever. If this is the thought process they’re using when resolving the ToS, given the continued upset and poor PR that has resulted from the change, I can’t imagine Unity will push the issue much further and will be forced to use some common sense for a change.

Currently the plan is this. Since my goal if getting BiosHub out in an alpha state before I started classes again is already out of the picture, it makes sense to refactor now rather than later. Additionally, I’ve realized keeping the ability to use 3D models open is very important. Voxel terrain and characters would be a simple, really cool style and even 2D sprites in a 3D world might make for a really fun way to explore the game world. Think of a digital dollhouse where the roof comes up and you can explore the tavern, dive into the dungeon, etc. Here’s how sprites might look. Full disclaimer, this isn’t my work but it has the general idea.

Now to be clear, these are not Alpha level features. The 2D goal remains for now, but keeping the ability to shift to 3D will be important during the refactor as currently everything is designed around a flat plain.

With that said, I’ve rambled enough and should get back to work. Please let me know what you think!