Progress Report: 2019


While Discord is always the best place to see the latest updates, I’ll be trying to keep this thread updated with new developments as time goes on as well. :slight_smile:

Scratch that, We’ll make a new thread for each week. It’s not ideal but it allows for feedback.

Progress Report: 2019, Week 2
Progress Report: 2019, Week 3
Progress Report: 2019, Week 6
Progress Report: 2019, Week 8
Progress Report: 2019, Week 4
Progress Report: 2019, Week 5
Progress Report: 2019, Week 9

Main screen has had some improvements. Still need to add a room selection option.

Tabletop now supports loading/saving the current state and is fully networked.

New token creator menu. Needs some refinement but is a huge step up from before!


Caching is now enabled for tokens. More cleanup is needed for forward/backslashes, a WebGL workaround and texture processing needs moved to it’s own function.

Additionally, function names should be cleaned up and standardized.


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,, 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.


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.


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.


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!


Unity has backed down from their challenge of Improbable, fixed their EULA to clarify third-party developers are acceptable and no longer apply it retroactively. The original situation will probably never be fully explained, but with the technical information provided from Improbable, it appears Unity was entirely wrong in their claims. While they may not appreciate how Improbable competes with their new hosting service, I’ve yet to see a shred of compelling evidence that SpatialOS was ever in violation of any Terms of Service before Unity changed them December 5th and put basically everyone in violation.

Thankfully, it seems rational minds still hold the helm over at Unity and these changes should serve to prevent future overreach from Unity. Hopefully they use this extra time to improve their core products and help their customers rather than worry about their competition.

Additionally, in light of these updates and the EULA updates, BiosHub will continue to use Unity and updates will resume. I’m still of the opinion Unity acted in bad faith with this entire mess, but it shouldn’t occur again and despite any flaws, Unity is still an excellent platform to use.

I look forward to my next post returning to actual technical updates on BiosHub. :slight_smile:


After a very long week of decision making, I’ve settled again on PUN 2 for our networking solution. While I was thrilled to find Mirror, a Unet replacement which would have meant nearly free server costs for our early releases, it is simply not ready for production use. While the code itself is functional, it results in compile collisions which prevent the debug information being generated for use by the editor. This makes debugging more difficult without constant restarts and this is, naturally, a huge drag on attention and is simply not worth the benefit.

At the same time, a complete revamp and restructure is in progress since if I’m reworking the networking, I may as well take the time to clean up the code that goes with it as well! This process is actually going far faster than I expected and while the end result will be a graphical downgrade, the goal is to permit the same build to also work on Android and WebGL. Once this is complete I believe we will be ready to begin private alpha testing with select groups. This is less for exclusivity and more because of limited network resources currently and I hope to get us into public alpha as soon as possible.


Little bit sparse on updates this week. Ohio is currently at the tail of some really quite bitter cold weather, as in arctic cold, which has left me running for blankets and a hot drink. Thankfully it seems things are returning to our regularly scheduled winter horror and I’ll be able to focus once again. Having said that, I’ve not been entirely negligent and have some decent updates to report.

To begin, Photon’s PUN 2 has been implemented yet again and while organization leaves something to be desired, it does work.

Additionally the game map has been added, but not without difficulty. See, currently I’m using canvas image components residing in world space for everything. This makes sense as I’m not using colliders or anything that requires physical interactions and Image components are the most efficient way to display the large number of images a tabletop game needs. Like most things however, nothing is as simple as it appears and scaling assets to be of matching sizes despite resolution differences is a difficult task which I’m still struggling with. In the end it might require a custom map system, no longer officially allowing imported maps, but I’d like to have a system that was at least ad-hoc capable for groups that don’t want to port their entire map to BiosHub.

Noting the current map you might notice I took great care to align the tokens to the map grid. This was painstaking but…Nah, I’m just kidding, We have Snap to Grid support now! And dang does it feel smooth. For anyone also needing a snap to grid system, BenZed provided some excellent code on Reddit which is what I’m currently using.

Vector3 SnapPosition(Vector3 input, float factor = 1f)
    if (factor <= 0f)
        throw new UnityException("factor argument must be above 0");

    float x = Mathf.Round(input.x / factor) * factor;
    float y = Mathf.Round(input.y / factor) * factor;
    float z = Mathf.Round(input.z / factor) * factor;

    return new Vector3(x,y,z);

For our future WebGL users, I added a bypass to fix browsers being unable to work with our caching system. Browser security forbids using local storage, but for a browser it’s obvious you have internet and so it shouldn’t be a huge issue.

Max Camera Zoom was added to prevent the world flipping when the camera went into negative zoom.

I need to investigate a regression where the Esc toggle for our Control Panel is not working, probably just broke the game object reference.

Upcoming tasks are reviewing the token/map scale so I can guarantee it works with any map size and also support varying token sizes. Additionally adding a room selection to the main menu is a priority. From there, save/load and ideally a token browser will be all that is needed for alpha support! I look forward to getting feedback and finding what direction the community wants this to go.


Additionally, I forgot to mention this but there’s a great talk on Unity UI and Optimization from Unity 2016 I’d totally recommend.


As the world ‘outside’ finally thaws, the time has come for a pre-preview release! Ok well maybe release is a strong word, but you can access a prototype of BiosHub at right now! Now to be clear, this is super not polished, but it ‘is’ functional. As we move from a preview into an alpha release I’ll begin packaging downloadable releases but for now iteration is occurring so fast that it isn’t worth it.

Current features include Tokens, Map background and a d20 roller for testing purposes. My gaming group is planning to begin testing it during live games and see what further features it needs. Nothing here is close to our long-term goal, but function comes first.


This is a super late post, but don’t take this to thinking there hasn’t been work occurring in the background. I’ve been having tons of discussions on how to monetize the project ensuring it isn’t exploitative but also ensures a steady income for development. BiosHub is a long-term project and I want to ensure it lasts longer than just a year or two.

I’d love to hear what others think about both the prototype and if you have any questions or suggestions, please let me know!


Hotfix: d20 wouldn’t roll 20! Naturally this has been resolved. :slight_smile:


There isn’t much to report this week I fear. Most of this week has been spent evaluating possible features for inclusion during our upcoming playtest, what might be necessary and researching different UI architecture for Unity. Oddly, this seems to be a topic not often discussed which is going to make BiosHub tricky to design since it relies so much on the UI. Additionally, due to a death in the family I’ve had to spend some time on that so this is a pretty spartan week for updates.

Next week I intend to update the dice roller, implement an update log and hopefully a chat system of sorts. This will be intended to allow inline chat rolls e.g. /roll 2d6+5. From there, a better token and map interface are on the to-do list before character sheet implementation is begun.


Did I say not much to report? Well that day wasn’t over yet! A chat window has been added complete with partial network support. While newly joined players won’t get previous chat messages, connected players hear everything as it happens!


Dice rolls are now sent to the chat window so you always know what was rolled and in what order! Additionally, dice rolling sounds play for each roll and a temporary sound is played for new chat messages.


Having missed last week’s report, I’m pleased to say it wasn’t an entirely wasted week although it was very slow going. I’ve added d4, d6, d8, d10, d100 and d12 dice to the roller and spent much of the week trying to fix the WebGL networking before finding it appears to be an issue with Photon’s servers, not our code. Convincingly, they seem to have no idea anything even happened despite the fact that other, established developers reported issues with their service leading me to wonder if it’s worth the cost. I’m looking to see if Mirror has resolved the previous issues and to see if switching back might be worthwhile to ensure our service can actually stay online.


I have some awesome changes for folks this week! The biggest being a dynamic panel system which is going to serve as our temporary GUI until a permanent system is decided upon. This means windows can be placed in tabs, attached to screen corners and resized depending on player preference! No more are you limited to my petty whims. :wink: Additionally, deleting tokens is now possible with editing and copying tokens in the horizon.

I’ve also made a quick overview video of the project for this week, so check it out and let me know your thoughts below!

closed #19

The past couple weeks I’ve honestly just been busy with classes and struggling with some personal issues leaving me with little time to work on BiosHub. Have no fear however, for it’s not forgotten nor ignored. My biggest task this week is evaluating how much more needs done before another alpha release.

Currently I think token rotation and saving/loading scenes are top priority followed by a simple health/mana tracker for tokens. Once I have a final list however I’ll be publishing it for feedback.

Sorry there isn’t much to report, it pains me to make so little progress but sadly that’s life and I’d rather show signs of life than hide and pretend everything is fine. Thanks for bearing with me.