They should pay attention to how Virtual Tabletop software does things. A lot of the setup issues would be similar between the two. For example many Virtual Tabletop had to deal with the issue of animating virtual dice. What they showed in the video is a bit too sluggish.
Another concept of virtual tabletop is rulesets and modules. A ruleset configures a virtual tabletop for a specific game or RPG. While a module is a prepackaged bundle of maps, images, tokens, notes, monsters, etc. It should be easy to do both.
In the end surface computer and virtual tabletop are going to be two parallel lines of development that will impact the futures of RPGs. With e-books being used alongside both as well as normal tabletop play.
The problem isn't BASIC, PHP or any other entry level langauge. They are langauges allowing people with no training in computer language to create *GASP* applications.
The problem is that a lot of people have no formal training. They often don't know about even the most basics of computer science. Things like structured programming. For database the features of referential integrity, transactions, and subselects are needed to implement important database concepts if you want software that maintains and extends easiler.
If a langauge or database that actually hinders you from implementing best practices then criticize away. But to criticize a langauge or database because of it allow novices to start creating application is elitist and smells of snobbery.
Rather than take a holier than thou stance of "I don't use PHP" write a tutorial on the best practices to use to make bug-free software in a timely manner. Show how they can use their knowledge of PHP/MySQL to start using better tools or *GASP* even how to use PHP/MySQL with best practices.
I write a variety of software for machine controllers, CAD/CAM, to office management. Sometimes I don't get to work with the best langauge because of platform limitation. Sometime I have to work with assembly itself. But yet in all the platforms I use, I find my knowledge of using structured programming and other best practices applicable and helps me write good software.
When we hire other programmer I teach just because we have nothing but jump and conditional jumps in assembly doesn't mean that you stop using structured programming.
I would say that closed source would be liable as the customer is unable to inspect the code themselves and relying on the company or developer's reputation to say there isn't any bugs or security holes.
With open source software, the customer has the means to inspect for themselves whether the software can perform as advertised. So if the source code for the software is avaliable then the burden should shift to the customer as it is today.
One of keys to managing large projects is being able to break the project down into its component parts. VB.NET (or even VB6) allows you to do this easily by supporting multiple assemblies linked together. However to be fair this is a feature of the.NET environment so most.NET langauges (C# C++.NET) can make assemblies.
Other langauges can certainly create and use libraries but being able to do this is one of the explicit design goals of the.NET environment. In addition you will find the managed memory making you far more productive then environment like C++ where you have to manage memory yourself. Again to be fair Java certainly has memory management so this is not unique to the.NET environment.
Visual BASIC is verbose where C# is terse, I find this easier to read over the long term but to a experienced programmer it is a minor difference. There is virtually little difference between.NET assemblies and apps written in VB.NET and C#.
However if your app is meant to run in a constricted or resource limited environment like embedded applications then using VB.NET (or even VB6) will not be your best choise. You need to use C, C++, or even assembly. A langauge that will allow you control over every aspect over what resources your program uses.
Problems you will run into with.NET will be with the framework install and maintaining it in face of future Microsoft updates. I strongly recommend that you minimize reliance on 3rd party add-ons if this application is to be maintained over the long-haul. (Short-term or one-off projects are a different story).
Avoid storing assemblies in the global cache unless you have too as that force you into strict versioning rules. This was the bane of large projects in VB6 with the rules for COM DLL versioning. Plus using the global cache force you to register the assembly where otherwise it is a drag and drop situation with local assemblies.
Be aware of how much memory you are using. I have noticed with.NET application they tend to glup memory down like it is nothing. I learned this with VB6 (and later VB.NET) that despite the fact you have managed memory you don't create huge memory structures just because you can. Make sure you need that amount before designing it in.
As for my own personal experience I written a maintained a large CAD/CAM application that creates and runs parts for a metal cutting machine. I maintained this program through its original HP Workstation origin through DOS through VB6 and finally to VB.NET. It is has several hundred thousand lines of code organized using the model view presenter structure (http://www.martinfowler.com/eaaDev/ModelViewPrese nter.html) Also I maintain an open source simulation of the Program Mercury and Gemini capsule and rocket written in C++. So I had experience in both worlds. VB.NET (and VB6) was certainly up to the job of creating and maintain a large application.
Finally get Design Patterns and Refactoring Software these two books (and the othere they refer too) will help make the most out of.NET ability. (Plus the benifit of these applying to other langauge like Java)
http://www.amazon.com/gp/product/0201633612/sr=8-1 /qid=1149165698/ref=pd_bbs_1/002-2543787-3204834?_ encoding=UTF8http://www.amazon.com/gp/product/0201485672/qid=11 49165751/sr=2-1/ref=pd_bbs_b_2_1/002-2543787-32048 34?s=books&v=glance&n=283155
Slashdot Mirror
They should pay attention to how Virtual Tabletop software does things. A lot of the setup issues would be similar between the two. For example many Virtual Tabletop had to deal with the issue of animating virtual dice. What they showed in the video is a bit too sluggish. Another concept of virtual tabletop is rulesets and modules. A ruleset configures a virtual tabletop for a specific game or RPG. While a module is a prepackaged bundle of maps, images, tokens, notes, monsters, etc. It should be easy to do both. In the end surface computer and virtual tabletop are going to be two parallel lines of development that will impact the futures of RPGs. With e-books being used alongside both as well as normal tabletop play.
The problem isn't BASIC, PHP or any other entry level langauge. They are langauges allowing people with no training in computer language to create *GASP* applications.
/MySQL with best practices.
The problem is that a lot of people have no formal training. They often don't know about even the most basics of computer science. Things like structured programming. For database the features of referential integrity, transactions, and subselects are needed to implement important database concepts if you want software that maintains and extends easiler.
If a langauge or database that actually hinders you from implementing best practices then criticize away. But to criticize a langauge or database because of it allow novices to start creating application is elitist and smells of snobbery.
Rather than take a holier than thou stance of "I don't use PHP" write a tutorial on the best practices to use to make bug-free software in a timely manner. Show how they can use their knowledge of PHP/MySQL to start using better tools or *GASP* even how to use PHP
I write a variety of software for machine controllers, CAD/CAM, to office management. Sometimes I don't get to work with the best langauge because of platform limitation. Sometime I have to work with assembly itself. But yet in all the platforms I use, I find my knowledge of using structured programming and other best practices applicable and helps me write good software.
When we hire other programmer I teach just because we have nothing but jump and conditional jumps in assembly doesn't mean that you stop using structured programming.
I would say that closed source would be liable as the customer is unable to inspect the code themselves and relying on the company or developer's reputation to say there isn't any bugs or security holes.
With open source software, the customer has the means to inspect for themselves whether the software can perform as advertised. So if the source code for the software is avaliable then the burden should shift to the customer as it is today.
One of keys to managing large projects is being able to break the project down into its component parts. VB.NET (or even VB6) allows you to do this easily by supporting multiple assemblies linked together. However to be fair this is a feature of the .NET environment so most .NET langauges (C# C++.NET) can make assemblies.
Other langauges can certainly create and use libraries but being able to do this is one of the explicit design goals of the .NET environment. In addition you will find the managed memory making you far more productive then environment like C++ where you have to manage memory yourself. Again to be fair Java certainly has memory management so this is not unique to the .NET environment.
Visual BASIC is verbose where C# is terse, I find this easier to read over the long term but to a experienced programmer it is a minor difference. There is virtually little difference between .NET assemblies and apps written in VB.NET and C#.
However if your app is meant to run in a constricted or resource limited environment like embedded applications then using VB.NET (or even VB6) will not be your best choise. You need to use C, C++, or even assembly. A langauge that will allow you control over every aspect over what resources your program uses.
Problems you will run into with .NET will be with the framework install and maintaining it in face of future Microsoft updates. I strongly recommend that you minimize reliance on 3rd party add-ons if this application is to be maintained over the long-haul. (Short-term or one-off projects are a different story).
Avoid storing assemblies in the global cache unless you have too as that force you into strict versioning rules. This was the bane of large projects in VB6 with the rules for COM DLL versioning. Plus using the global cache force you to register the assembly where otherwise it is a drag and drop situation with local assemblies.
Be aware of how much memory you are using. I have noticed with .NET application they tend to glup memory down like it is nothing. I learned this with VB6 (and later VB.NET) that despite the fact you have managed memory you don't create huge memory structures just because you can. Make sure you need that amount before designing it in.
As for my own personal experience I written a maintained a large CAD/CAM application that creates and runs parts for a metal cutting machine. I maintained this program through its original HP Workstation origin through DOS through VB6 and finally to VB.NET. It is has several hundred thousand lines of code organized using the model view presenter structure (http://www.martinfowler.com/eaaDev/ModelViewPrese nter.html) Also I maintain an open source simulation of the Program Mercury and Gemini capsule and rocket written in C++. So I had experience in both worlds. VB.NET (and VB6) was certainly up to the job of creating and maintain a large application.
Finally get Design Patterns and Refactoring Software these two books (and the othere they refer too) will help make the most out of .NET ability. (Plus the benifit of these applying to other langauge like Java)
http://www.amazon.com/gp/product/0201633612/sr=8-1 /qid=1149165698/ref=pd_bbs_1/002-2543787-3204834?_ encoding=UTF8
http://www.amazon.com/gp/product/0201485672/qid=11 49165751/sr=2-1/ref=pd_bbs_b_2_1/002-2543787-32048 34?s=books&v=glance&n=283155