From: Living in the fair city of Melbourne, Australia
But an even bigger con is that in many cases these variables are used in different ways throughout the code and the code is very complex. Without access to the code itself you cannot see all the effects that a minor change in this or that setting will have on the various aspects of the game. If you make a change to setting A because you want X but you have no way of changing the way A is used in Y then you are going to end up being satisfied with X but disappointed with Y. So to make it work you really need access to the code so you can adjust the way it impacts Y.
That's a very fine point, Dave. As I was thinking a bit more on this I realized that taken to its logical consequences, either the sources needed to be make public (which is a no-no) or rather, exposing the algorithms where those variables are involved, so users can override them with their own routines. This would require from them some programming ability, perhaps in some high-level, easy to learn, scripting language such as Python.
Besides that, it would be a major architectural undertaking in the engine, providing interfaces to load these user-defined routines at run-time. I have personal experience providing such interfaces into agent-based simulations, and it's an extremely work intensive thing and a major investment in highly-specialized (i.e. expensive) programming hours. It would also have quite an impact on run-time, reducing performance in a significant way.
And last, but not least, this would amount to introduce a third "leg" in the data that composes an scenario besides the terrain model (the map) and the forces model (the estab), which as you point out, it might well be a nightmare to manage if released into the wild. Another thing is that there was in place some sort of centralized effort to keep consistency, taking pains to steward a repository of internally consistent terrain, force and "parameters" databases. I've only seen this to work - most of the time - in the GRASS/GIS community, and it's subject to the vagaries of funding of academic or public agencies.
As Sabin cleverly points out, the major difference between tabletop wargames and computer wargames is that the former doesn't require specialized technical skills in order to tweak the model, just a reasonable command of English and elementary Math. This statement is very true now, in my opinion. However, seeing current trends I think that in a generation a significant amount of the population will have had some exposure to programming skills (seeing programming courses in Python or Visual Basic to crop up in Secondary School makes my heart feel warm & fuzzy). And, after all, wargaming is a hobby for the overeducated, isn't it?
< Message edited by Bletchley_Geek -- 3/26/2013 1:02:44 AM >