Reply to thread

Message: <blockquote data-quote="Klintus Fang" data-source="post: 422269" data-attributes="member: 3580">I have a few more comments.  First, I don't see how having a cenralized server were data is stored and retrieved adds any value for the end user.  It's a cool idea, but I don't see how it adds any value.  If that data was subject to constant change, or if there was so much of it that it couldn't reasonable be stored on the end user's hard-drive then serving it from the net makes sense, otherwise, I don't see how it serves any useful purpose.  It just puts a potential obstacle in the end-users path (if the network connection is down).  I don't think any user would like that usage model.With respect to what towngen has said:  you keep going back to the "cross platform" argument for why tcp/ip is better than a dll/so file.  And then you use your towngen program as an example.  But your towngen program is a VB app so it won't run on anything but a Window's machine anyway so how is tcp/ip solving any sort of cross platform problem in your case?As far as dlls/so files go:  if you write them as non-gui based, number crunching applications there are almost no cross platform issues.  True you have to compile the code twice, once as an so file on linux and once as a dll on windows, but the exact same code will compile on both without changes (usually).  There are minor obstacles you might encounter if you use some non-standard libraries like linux's readline library, or if you use 64-bit integers with printf's, but aside from minor issues like that, the latest versions of most all compilers nowadays, can compile any code that is compliant with ANSI standards without difficulty.  I do it all the time.  Your code's not C or C++, that I understand.   It's VB.  That means it will only run on Windows.  There is no way around that.  But a VB app can communicate directly with C/C++ dll's.  I haven't done it personally but I know that is how a lot of applications are actually built:  write the computational core in C/C++ then plug into it with a VB frontend.As far as Java goes:  I've always disliked java, so I don't really know what is possible with it.  It would be interesting to find out if there is a way to export a dll/so interface in such a way that a java app can call it.  I don't know if that is possible.  If not then tcp/ip may be the only way to go for Java.Finally, I agree with Sm!rk in one very fundamental way:You may want to require that the user interact with towngen's user interface directly when a town is created (you at least seem to be implying that).  But it's not a good design choice, unless towngen is the most important application the user is using.  I've been working off and on on a kingdom generator and so I will eventually need to create scores of towns all at once.  In that case if the user has to interact with towngen directly to create those towns, towngen is essentially useless to me.</blockquote>

Verification