View Single Post
Imper1um
Member
 
Join Date: Jun 2010
Posts: 40

Old March 7th, 2015, 06:17 AM
Just note this is all of the issues I've experienced. Its just really annoying. I'd love to force an update when possible.

One thing people aren't considering, and they are thinking, is that Synchronization requires the *entire* file to be redistributed. However, with how synchronization works, unless its the first execution, you're not distributing the entire file, just what was modified. You'll notice this when you synchronize first, it can take up to a minute (depending on internet connection), but when you do a synchronize after-the-fact, you're only updating for a few seconds.

This would be the same for if an auto-synchronize happened. A few bytes or kilobytes. Even the worst connection would have no problem dealing with it, unless you're on 5800 Baud Modems. A single reveal is a single bit, with a location identifier (so, 2-15 bytes). Adding in 500 characters to a single item would be 500 bytes. Truly, synchronizing automatically would cause less bandwidth usage than if you accessed Facebook. The *only* time that you're going to run into a single-item update will cause a huge update is if the GM drops a huge high-resolution map. With this, its probably vital that background downloading would need to exist, so the player can continue to read while a synchronize happens, then update once the synchronize completes.

The thing is, an auto-synchronize cannot be implemented as-is. Its dumb, because the Synchronize system as it stands now is slow, obtrusive, and annoying. It pops up a dialog box, takes a few seconds to ramp up, downloads for a few seconds, then a few seconds to implement the changes, before it releases control. Synchronization would *need* to happen on a background thread. While a synchronize happens, the user would need to be notified with a circling "synchronizing" icon, but, besides that, they should not be interrupted in any way. Unless the article being synchronized is the one that is being modified by the sync, they wouldn't notice the difference between before Sync and post Sync.

Fortunately, you're all saying "RealmWorks is database-based." That's great! Database structures were built with multi-access in mind. Even NoSQL is built around allowing multiple processes and threads to access the database.

Multi-Threading isn't easy, and, at the moment, it looks like no (or just single job multi-threading) multi-threading is done. Its unfortunate, because this is what I expected of RealmWorks, that the system would operate on a Multi-Thread System, where updates can be done independently of the user's UI updates, allowing for the GMs to make modifications and update players immediately.

Now, why is this important? Well, I'm trying to keep up with technology. When I saw RealmWorks, I saw it as a solution to the distraction of Technology. Nowadays, half of my groups have Laptops, and everyone has a smartphone. If I engage them by allowing them to look up elements on the fly, they would be engaged with the game, and I don't have to be that "Old Grandpa" that tells "those whippersnappers to put away their laptops." They are engaged in the game, and I'm not the enemy. I see this as a tool to make them enjoy my game, while making them focused on the game. They can explore my rich world at their leisure. I don't have to spend vital time when someone asks a question on something that happened before, they can just look at RealmWorks, and their answer is revealed. I continue telling the story, and they find out information when they want/need to.

As it stands, RealmWorks is half of this. Auto-sync is something that I have to stand firm that it must implement, otherwise, it simply only serves as a way of aggregating my thoughts independent of a book or such. There is almost no reason for anyone in my group to purchase a "player license." The tools are there, I just wish it strived to be a little better.

Last edited by Imper1um; March 7th, 2015 at 06:19 AM.
Imper1um is offline   #15 Reply With Quote