Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Janx" data-source="post: 5881911" data-attributes="member: 8835">Here's some general feedback on the VTT idea (bear in mind, I am a web app developer, so I know the challenges you face):try to support IE-Latest if you can.  I know IE ain't quite HTML5 compliant, but there's enough market share out there.  Write your GUI code in modular libraries that are are aware of the browser version and will swap in the correct HTML/JS/CSS to do the job, rather than hard-coding a bunch of stuff (which would be the same mistake IE-only sites make when they use IE-only features).Try to make your chat commands easy to use, as most users won't take the time to learn them if they are complex, thus missing most of the value of the commands.Try to make DM prep-time minimal.  One of the barriers to my group adopting a VTT is all the work the DM would have to do to put his notes into the system.  In real life, he writes his stuff in a notebook.  If we start a combat, he draws up the scene on the battle mat with a marker (and not using pre-loaded tokens and art).  It should be THAT FAST to get the scene setup with no prior work for him.  He'll subtract HP on his own in his notebook.In the past, we ran a game using IRC and the mIRC client with macros.  I had whipped up macros to remember my HP, do dice rolls and remember my attack modifiers for weapons.  This let the GM address my PC:"/Janx dam 5" and I would lose 5 HP"/Janx heal 10" and I would gain 10 HP"attack longsword" would look up the attack bonus and damage code for my "longsword" and tell the GM what I rolled and what damage would be if I hit"/roll 1d8+1" would  put 1d8+1=## on the screen, where ## was the resultVery simple stuff, we did not need our entire character sheet loaded into the PC.  The HP and other consumables were handy to have (gold, etc).  The attack numbers for our weapons was also a time saver, which could easily be solved by your macro language, rather than direct support in the system.In fact, that's probably how you can avoid getting into the game specifics.  Provide a solid macro language, and let people share/publish macros.  Make sure the system includes "runtime" variable storage that stays with the user, that way the user can load up the macros once, use Macro_A to load up some variables, that Macro_B and Macro_C rely on (like definitions of weapons, gold, XP).  That way, whenever the player logs in, their variables and macros are set and ready to resume play.I had coded my macro library, so it's variable bank was keyed by screen name.  I could then change my screen name to another PC, and have different variables set for each.  A Dictionary or KeyValuePair structure would enable this.We found, as we were purely text chat based, that we naturally gravitated to more roleplaying than combat.  Having the right VTT to enable roleplaying (or not impede it) and still do combat when it comes up would probably fit within your mission.Another free idea, is individual volume adjustment.  Each person has differing microphone and audio quality issues.  Some people are very quiet.  I want to be able to turn the quiet people up (with some background noise filtering). without getting blasted out by Loud Mindy, who is naturally louder than everybody else.Also include a "hand raising" signal.  It's very easy to get drowned out by Loud Mindy.  If the GM can see that you want to say something, he can interrupt/mute Loud Mindy and give you the floor.If you're including initiative tracking, you might tie that into an auto-mute feature (GM choice to use it) where only the current player (and always the GM) can speak.Your project sounds interesting.  Good luck.</blockquote>

Verification