Blacky
September 11th, 2014, 05:16
This is a small list of things I thought might slip through the cracks on FGNext (Unity engine rewrite–or any other engine or rewrite–of Fantasy Grounds 3) project. Call it FGUnity, FGNext, FG4, FG5, whatever. It's absolutely not a feature list or a Christmas wish list about better maps or dynamic lighting or pink ponies. It's about the self-evident things that one might forget when he get his head down in an engine and his hands dirty, the things that are small to do from the start but if one forget they're a bitch to redo later on.
It's a bit geeky, technical, again not a feature wish list (which already exist here (https://fg2app.idea.informer.com/)) but a purely technical please don't forget list.
I'll try to keep the comments in check (dreaded 10K post limit), but if necessary I can expand/explain.
Basics
Unicode, UTF-8 (without BOM) everywhere: And for legacy content, converting from ASCII/Latin is extremely easy.
Unicode standard sorting (collation): goes with the last.
Language tags: goes with Unicode to handle multiple languages, and it's quite easy it's already in XML.
Gamma correction: it's daaaaark (or liiight) in here.
Sub-windows outside main FG window: maybe it's a fully fledged feature in Unity, but at least keep it in mind for future code.
Native 64bits: probably included in Unity, but it's probably better to think and code it all in 64bits and let Unity convert to 32bits when appropriate (in a few years, people still in 32bits won't care much about performance).
Native Mac & native Linux (Debian?): Unity realm, but still. Also, some thought on Linux distribution might help. For example Debian is well documented and easy and cover things like Mint or Ubuntu, whereas limiting to Mint or Ubuntu might get trickier down the line.
Threading, threading, and more threading: being multicore friendly, think about net/chromebook and future mobile or handheld hardware.
Display isn't streamed: as in, even if the network if fully clogged, I need to move that window now!
Optimizations: Unity will take some chunk of speed by itself, so please please pretty please don't forget to post-it this on the dev monitor ;) An immediate easy example comes to mind: don't need to lead all tokens into memory when most of them aren't used.
ARM support for the future: probably handled by Unity but maybe there's some do&don't about it.
Commenting: I'm guessing the ruleset code won't need a rewrite, but I would suggest any rewrite involves a lot of comments in the code.
Shortcuts: hey I got 26 buttons on my mouse, why can't I use these for FG? :rv:
LTR: left-to-right languages. Even if FG doesn't move after i18n right away, spending a little time to put some RTF markers and such into existing code (UI, lang packs, etc.) might help incorporating LTR in a few (or a lot) years.
Path to versioning: full versioning (of PC sheet, NPC sheet, stories, notes, well everything in fact) is probably a full fledged feature of the not near future; but thinking about it right now shouldn't be hard and would probably help immensely in the future. Something among the lines of “each time I think I load thing X, just remember that in fact I'm loading thing X[last in the pile/array/whatever]”.
Network library
IPv6
On-the-fly (and smart cached?) compression of networked resources (see HTTP deflate, could be done as zlib); except of course for already compressed resources (images mostly, and very small packets).
Network fast automatic transparent resume upload/download.
Internal network QoS: an Image can probably wait half a second more, an attack roll probably can't.
External network QoS: plug in OS QoS strategy to avoid VOIP (and other) issues because FG is uploading and taking all the bandwidth for itself.
P2P: why waste client upload bandwidth capacity? Host send n different packet to n different clients, then each client send them to other clients based on what they have and upload speed while host is sending next packets and so on). If needed, look at how World of Warcraft (and a lot of others) are using bittorent to push upload on their servers farms and how much it speed things up.
External (as un URI) resources loading: there really shouldn't be any difference loading d:\fg\myimage.png and https://sub.domain.tld/myimage.png (think of all the poor people with quotas or slow DSL, and their poor children! ^^).
TCP port # option.
Unicode domains: because some people have their GM at فنتسيجروندس.امارات
TLS? again throttling, and for general privacy. Yes it's a question, not sure it's worth the speed hit and the certificate hassle.
Graphic library
Full PNG support in Images.
SVG (or at least the Chrome or Firefox subset) support in frames&images.
JPEG color correction (color profile) per image.
Frame size > 2048² pixels: as in much more, quite fast you're going to have a lot of clients with 8192×2096 display and that's just the decal size, a frame need all the other parts too.
Better (much much better) and much faster algorithm for bitmap down/upscaling.
Touch UI: I have zero ideas how Unity handle touch screen, and beside the obvious UI modification what's the impact code-wise. Probably something worth looking into it for 15 minutes, even if FG doesn't go Touch for several years.
Ruleset, coding
Step by step or stepping debug: not sure at all if this would be something helped by Unity, but if such any tool that helps ruleset coders and tinkerers is a good thing.
I'll edit to add more as they came along.
Yup probably some (very little amount) of these could be described as features (like SVG or color correction) instead of things on the level of “my keyboard works with FG, yes even the numpad”. My guess is that Unity handle those, but if that's not the case maybe thinking about it when writing the code to help incorporate those later without rewriting hundreds of line of delicate code would help?
Just my hopeful 2 cents.
It's a bit geeky, technical, again not a feature wish list (which already exist here (https://fg2app.idea.informer.com/)) but a purely technical please don't forget list.
I'll try to keep the comments in check (dreaded 10K post limit), but if necessary I can expand/explain.
Basics
Unicode, UTF-8 (without BOM) everywhere: And for legacy content, converting from ASCII/Latin is extremely easy.
Unicode standard sorting (collation): goes with the last.
Language tags: goes with Unicode to handle multiple languages, and it's quite easy it's already in XML.
Gamma correction: it's daaaaark (or liiight) in here.
Sub-windows outside main FG window: maybe it's a fully fledged feature in Unity, but at least keep it in mind for future code.
Native 64bits: probably included in Unity, but it's probably better to think and code it all in 64bits and let Unity convert to 32bits when appropriate (in a few years, people still in 32bits won't care much about performance).
Native Mac & native Linux (Debian?): Unity realm, but still. Also, some thought on Linux distribution might help. For example Debian is well documented and easy and cover things like Mint or Ubuntu, whereas limiting to Mint or Ubuntu might get trickier down the line.
Threading, threading, and more threading: being multicore friendly, think about net/chromebook and future mobile or handheld hardware.
Display isn't streamed: as in, even if the network if fully clogged, I need to move that window now!
Optimizations: Unity will take some chunk of speed by itself, so please please pretty please don't forget to post-it this on the dev monitor ;) An immediate easy example comes to mind: don't need to lead all tokens into memory when most of them aren't used.
ARM support for the future: probably handled by Unity but maybe there's some do&don't about it.
Commenting: I'm guessing the ruleset code won't need a rewrite, but I would suggest any rewrite involves a lot of comments in the code.
Shortcuts: hey I got 26 buttons on my mouse, why can't I use these for FG? :rv:
LTR: left-to-right languages. Even if FG doesn't move after i18n right away, spending a little time to put some RTF markers and such into existing code (UI, lang packs, etc.) might help incorporating LTR in a few (or a lot) years.
Path to versioning: full versioning (of PC sheet, NPC sheet, stories, notes, well everything in fact) is probably a full fledged feature of the not near future; but thinking about it right now shouldn't be hard and would probably help immensely in the future. Something among the lines of “each time I think I load thing X, just remember that in fact I'm loading thing X[last in the pile/array/whatever]”.
Network library
IPv6
On-the-fly (and smart cached?) compression of networked resources (see HTTP deflate, could be done as zlib); except of course for already compressed resources (images mostly, and very small packets).
Network fast automatic transparent resume upload/download.
Internal network QoS: an Image can probably wait half a second more, an attack roll probably can't.
External network QoS: plug in OS QoS strategy to avoid VOIP (and other) issues because FG is uploading and taking all the bandwidth for itself.
P2P: why waste client upload bandwidth capacity? Host send n different packet to n different clients, then each client send them to other clients based on what they have and upload speed while host is sending next packets and so on). If needed, look at how World of Warcraft (and a lot of others) are using bittorent to push upload on their servers farms and how much it speed things up.
External (as un URI) resources loading: there really shouldn't be any difference loading d:\fg\myimage.png and https://sub.domain.tld/myimage.png (think of all the poor people with quotas or slow DSL, and their poor children! ^^).
TCP port # option.
Unicode domains: because some people have their GM at فنتسيجروندس.امارات
TLS? again throttling, and for general privacy. Yes it's a question, not sure it's worth the speed hit and the certificate hassle.
Graphic library
Full PNG support in Images.
SVG (or at least the Chrome or Firefox subset) support in frames&images.
JPEG color correction (color profile) per image.
Frame size > 2048² pixels: as in much more, quite fast you're going to have a lot of clients with 8192×2096 display and that's just the decal size, a frame need all the other parts too.
Better (much much better) and much faster algorithm for bitmap down/upscaling.
Touch UI: I have zero ideas how Unity handle touch screen, and beside the obvious UI modification what's the impact code-wise. Probably something worth looking into it for 15 minutes, even if FG doesn't go Touch for several years.
Ruleset, coding
Step by step or stepping debug: not sure at all if this would be something helped by Unity, but if such any tool that helps ruleset coders and tinkerers is a good thing.
I'll edit to add more as they came along.
Yup probably some (very little amount) of these could be described as features (like SVG or color correction) instead of things on the level of “my keyboard works with FG, yes even the numpad”. My guess is that Unity handle those, but if that's not the case maybe thinking about it when writing the code to help incorporate those later without rewriting hundreds of line of delicate code would help?
Just my hopeful 2 cents.