Modding and Firaxis

[deanej]

It's a good thing I always use booleans for true/false instead of numbers. What's verbose syntax?

What could have possibly caused them to make global scope the default? That means you need to explicitly declare every single variable as local (I was taught that you should never use global variables, ever, unless you declare them as constant)!

 

[Afforess]

(I was taught that you should never use global variables, ever, unless you declare them as constant)!

There is nothing wrong with Global Variables; it's just that you have to make sure to use unique names and know the scope rules for that language.

 

[Chinese American]

Lua is not that different from Javascript in regards to global scope. I think it's very useful for things like hooking functions, table lookups, etc.

OTOH, other languages are just as annoying. PHP is annoying for having to list each and every global you want to use. In C++ you have externs and other workarounds.

It's intuitive for someone who's never programmed before because 99% of the time a person would would start counting at 1 (except for some notable exceptions like the floors of a building in Europe ware 1st floor is the one above the 'ground' floor). If a person has learned just about any other language they will be familiarized and habituated to the zeroth rule. I can only assume LUA designers chose to stray from that to make the language super newbie friendly.

thats because in other languages array lookup is low level. eg
for (i=0;i<array.length();i++){}

Lua it's more common to use iterators and not even use numbers, eg
for i,v in ipairs(t) do ... end

nowhere is there 0 or 1, so you're not even thinking about the difference. for numeric loops, it's more intuitive. eg

for i=1, #t do ... end
or
for i=1, SOME_CONSTANT do ... end

you don't worry about things like using the wrong comparison operator, etc.

 

[The_J]

This is now maybe the right time for this:

Spoiler :

There is nothing wrong with Global Variables; it's just that you have to make sure to use unique names and know the scope rules for that language.

I also have never understood, why globals are that wrong, but every professor should tell you, that they are evil like hell .

 

[oChuckles]

What's verbose syntax?

using words instead of symbols for things. Like in C you have {} and in lua you have "do end" and "if then elseif else end" etc.

at first you feel like you're just typing too much, and reading too much (it's harder to just glance at something verbose without having to actually parse and read the words as if they were english)

but you get used to it and the lack of having to hit shift kind of grows on you

What could have possibly caused them to make global scope the default? That means you need to explicitly declare every single variable as local (I was taught that you should never use global variables, ever, unless you declare them as constant)!

The development of the language is the answer to almost any odd thing in any language. Globals are not really a problem in small simple programs, and that's what lua was originally meant for. ( And honestly most Civ V mods will probably be < 1000 lines of code anyway.) I'm also pretty sure that lexical scoping was added later on in development, and they probably wanted to maintain some backward compatibility, so they added the local keyword. (citation needed )

Another important thing to keep in mind is that a function (unless this is outdated information... not sure) can only have 256 local variables. You shouldn't really ever design a function with that much responsibility, but the limitation is meaningful I guess. (could still be solved if they had a 'global' keyword instead)

A third important factor is in lua (like JavaScript) there's no difference between a "variable" and a "definition," there are only "variable"s and "value"s. So there's no difference between classes, containers, namespaces, or even instantiations of structs. They're all just "table"s. And all functions are first-class objects held in variables. So instead of having global definitions for abstract classes, you might have global prototypes which are actually instantiations in and of themselves (or global constructor functions.) So things that are technically "global variables" in lua would not be in a similar design in C++, despite the fact that in C++ it still crowds the global namespace just as much.

I guess the way you have to look at it is that "variable" means a lot more in lua than it does in C/C++, so "never use global variables" isn't quite as valid an idiom. "Never use global variables as anything but definitions" might be better?

Anyway, in lua there are still techniques to avoid crowding the _G table too much. Lua supports object-oriented and functional programming styles (usually used in a delightful mix.) And you do them with the 'local' keyword and the 'self/:' syntactic sugar. Everywhere. They've tried to mitigate this with the "module" system but I honestly think it's a bit (and uncharacteristically) clumsy... I dunno. Currently I just live with making almost every variable local.



P.S. anyone wanting to learn lua, I put my vote in for "Programming in Lua" by Roberto Ierusalimschy (the main architect of lua) It has an informal tone, includes tons of example code, and gives non-bare-bones tips and tricks at a pace that isn't overwhelming.

Additionally, Lua For Windows is a neat "batteries included" environment for playing with lua. It includes tons of useful libraries and an interactive guide to the language.

P.P.S. I swear I'm not a spokesperson... I just don't want such a wonderfully talented modding community to become frustrated.

 

[Impaler[WrG]]

I also have never understood, why globals are that wrong, but every professor should tell you, that they are evil like hell .

I think this is an outgrowth of the coding 'style' in vogue when most of our professors were in their formative years. The way programming teams were put together (or perhaps sub-divided) and the size of many projects necessitated strict discipline with regard to encapsulation and preventing name collisions. Shunning global variables become dogma, my understand is that go-to statements befell the same fate (though much more deservedly so). Today's more agile projects use smaller teams and discourage 'fencing off' code from other programmers. So the old dogma is much less true today.

 

[Wolle68]

I also have never understood, why globals are that wrong, but every professor should tell you, that they are evil like hell .

Professor fail. They should at least give reasons.

I don't think there's a problem with programs up to a few thousand lines, but in multi-threaded programs with tens or hundreds of thousands LOC they can give you problems:

1. They can cause unexpected changes in the middle of running an algorithm. This leads to all sorts of difficult to find errors.

2. They make it hard to see if fixing a bug in your code introduces an error in any of all the other peaces of code using the same global variable.

3. They are to easy to abuse - again leading to subtle errors in other parts of the code.

4. They are hard to change if you should suddenly discover that a global variable wasn't what you needed after all.

It's way to simplistic to say that global variables are or , but they do cause problems, and in a large project you'll have to deal with those problems somehow. (For instance by using a singleton.)

Loved the programming language comparison.

 

[Kid R]

I'm looking forward to having a play round with LUA - wacky, impractical languages can be a lot of fun! Civ 5 is a game after all and if modding it is kind of a game too that's great. A more well-designed language would make it seem too much like work

 

[The_J]

Another important thing to keep in mind is that a function (unless this is outdated information... not sure) can only have 256 local variables. You shouldn't really ever design a function with that much responsibility, but the limitation is meaningful I guess. (could still be solved if they had a 'global' keyword instead)

A third important factor is in lua (like JavaScript) there's no difference between a "variable" and a "definition," there are only "variable"s and "value"s. So there's no difference between classes, containers, namespaces, or even instantiations of structs. They're all just "table"s. And all functions are first-class objects held in variables. So instead of having global definitions for abstract classes, you might have global prototypes which are actually instantiations in and of themselves (or global constructor functions.) So things that are technically "global variables" in lua would not be in a similar design in C++, despite the fact that in C++ it still crowds the global namespace just as much.

I guess the way you have to look at it is that "variable" means a lot more in lua than it does in C/C++, so "never use global variables" isn't quite as valid an idiom. "Never use global variables as anything but definitions" might be better?

er...do i understand it right, that you say, that the globals are a problem in Lua, because they just decrease the maximum variable "capacity" of every function in the program?

I think this is an outgrowth of the coding 'style' in vogue when most of our professors were in their formative years. The way programming teams were put together (or perhaps sub-divided) and the size of many projects necessitated strict discipline with regard to encapsulation and preventing name collisions. Shunning global variables become dogma, my understand is that go-to statements befell the same fate (though much more deservedly so). Today's more agile projects use smaller teams and discourage 'fencing off' code from other programmers. So the old dogma is much less true today.

I don't think, that the group size is really smaller today (okay, i have no experience, but the projects are bigger now, aren't they?).

Professor fail. They should at least give reasons.

I don't think there's a problem with programs up to a few thousand lines, but in multi-threaded programs with tens or hundreds of thousands LOC they can give you problems:

1. They can cause unexpected changes in the middle of running an algorithm. This leads to all sorts of difficult to find errors.

2. They make it hard to see if fixing a bug in your code introduces an error in any of all the other peaces of code using the same global variable.

3. They are to easy to abuse - again leading to subtle errors in other parts of the code.

4. They are hard to change if you should suddenly discover that a global variable wasn't what you needed after all.

It's way to simplistic to say that global variables are or , but they do cause problems, and in a large project you'll have to deal with those problems somehow. (For instance by using a singleton.)

Loved the programming language comparison.

All the mentioned points seem to be more general problems, and nothing which really belongs only to globals.

 

[Chalks]

Globals should be avoided if they can be otherwise you'll end up stumbling over yourself.

They have their uses in many situations though and I disagree that significantly increasing the complexity of your code to compensate for some perceived risk of future incompetence is a good idea.

Try to avoid using them, but if it seems to make sense to use them over any alternative then it's probably fine.

 

[xienwolf]

I think of the issue with globals as being similar to the prolific use of iI, iJ and iK for loops in cIV which most modders have had issue with at some point or another. You add a loop into a heavily indented portion of code, forget that you are INSIDE a loop, and wind up using iI, causing an infinite loop in the parent loop if the new one is smaller, or breaking a loop from ever progressing past 0 if the parent loop is smaller than the new one.

With globals, you might accidentally use a variable name which HAPPENS to have already been used in ONE obscure file by Firaxis, and you just weren't aware of it. If, like cIV python, you only need to include the files you have actually changed, you cannot even do a simple "Find in Folder" search to verify a variable name is globally unique before you use it!

 

[deanej]

I imagine that would be a problem, unless Firaxis has cut back the use of scripting. The fact that they switched from a language great at handling strings to one based on tables suggests that the data interface between the XML and everything else has changed radically.

 

[Crazy George]

For a non-programer, this is a pretty high level discussion.

When I think easily modable, etc. as I hope Civ5 will be, I think of some sort of drag and click interface that any ol' non-tech fool can use.

You know, sort of like this here forum. Don't need to know code to do this.

Certainly if they are going to include a map builder, it should be easy enough (the non-programer said causally, almost invitingly) to include a unit builder, civ builder, building builder and so forth as well. I mean, isn't this how they made all of these things in the first place? And just fanning the flames a little here, if that isn't how they did it, why in the world not? It would seem to me that before one started building units, they would build a unit builder. Just an idea.

 

[Chalks]

For a non-programer, this is a pretty high level discussion.

When I think easily modable, etc. as I hope Civ5 will be, I think of some sort of drag and click interface that any ol' non-tech fool can use.

You know, sort of like this here forum. Don't need to know code to do this.

Certainly if they are going to include a map builder, it should be easy enough (the non-programer said causally, almost invitingly) to include a unit builder, civ builder, building builder and so forth as well. I mean, isn't this how they made all of these things in the first place? And just fanning the flames a little here, if that isn't how they did it, why in the world not? It would seem to me that before one started building units, they would build a unit builder. Just an idea.

I'm sure there will be, for basic stuff. It would certainly make sense for them to develop the unit builder alongside the actual units with a view to using the builder to create the later units (that's certainly a great way to test the builder prior to release, too).

You'd have assumed that if the game ships with any scenarios, they would have used visual editors to create maps, civs and techs for it too.

But more advanced stuff, such as creating whole new classes of units, or new upgrades, unique unit abilities, or even brand new dialogue windows are the sorts of things that cannot be produced with a simple drag and drop interface and require more advanced scripting.

 

[Impaler[WrG]]

I don't think, that the group size is really smaller today (okay, i have no experience, but the projects are bigger now, aren't they?).

I don't really have any experience either, movies like 'Office space' and books like 'The mythical man month' form most of my impression of programming in the 70's. Because both programmers (think Dilbert comics) and languages (Fortran if your lucky) were less efficient back then more people were needed to do the work now done by one programmer. And due to the high costs of doing ANY kind of programming most projects were huge client-specific databases for corporate clients which required big especially large team which constantly re-invented the wheel. Supposedly things were so bad that most projects failed to ever produce ANYTHING of value, it's hard to wrap the mind around IBM having a project failure rate higher then our own MODS. The industry is by comparison at least a thousand times more efficient in converting money into bug-free code now.

My impression is that by the early 90's this were efficient enough that a game like Civ could be programmed with each iteration of Civ had about as many programmer behind it as the number on the box, a small team by earlier standards.

 

[oChuckles]

I'm looking forward to having a play round with LUA - wacky, impractical languages can be a lot of fun! Civ 5 is a game after all and if modding it is kind of a game too that's great. A more well-designed language would make it seem too much like work

... I'm curious as to what you consider to be a "well-designed language."

I promise I won't respond though. This is not the time or place for a language flame war.

I imagine that would be a problem, unless Firaxis has cut back the use of scripting. The fact that they switched from a language great at handling strings to one based on tables suggests that the data interface between the XML and everything else has changed radically.

You realize lua has a string type as well as a table type right? (Lua's string library is actually pretty neat. Easier to use but not as powerful as some others. )

*global variable discussion*

I just want to reiterate and maybe explain more simply that in languages like lua or javascript there's a difference between "global variables" and "globals used as variables. (ie they're changed by multiple parts of the program and not just used as const values/definitions)" It's the second one that WILL cause larger programs to be hard to debug and confusing to learn. (the first one is only really an organization issue.)

It's also my opinion that structured/OO/functional programs are just more beautiful, easier to understand, and better designed than anything that uses "globals as variables", regardless of the size of the program.

I think this is an outgrowth of the coding 'style' in vogue when most of our professors were in their formative years. The way programming teams were put together (or perhaps sub-divided) and the size of many projects necessitated strict discipline with regard to encapsulation and preventing name collisions. Shunning global variables become dogma, my understand is that go-to statements befell the same fate (though much more deservedly so). Today's more agile projects use smaller teams and discourage 'fencing off' code from other programmers. So the old dogma is much less true today.

This is just plain incorrect. Agile programming methods with smaller subteams do not suddenly throw away good coding practices. Software development methodologies have almost nothing to do with the actual code and more to do with task assignments, priorities, and interpersonal work methods. The way Agile methods discourage 'fencing off' code is not by introducing coupling or globals or ignoring good coding principles in the code itself, but by literally sharing authorship of more code and working more closely with one another on a programmer level (as opposed to a code level.) (There's a lot more to Agile than that but I don't want to go into it. Long story short Agile arguably benefits MORE from having more modular less coupled code than other methodologies like Waterfall)

It infuriates me that this misunderstanding of Agile is so prevalent. It's what gives a good system a bad name.

 

[The_J]

For a non-programer, this is a pretty high level discussion.

When I think easily modable, etc. as I hope Civ5 will be, I think of some sort of drag and click interface that any ol' non-tech fool can use.

You're somehow mixing two things up here .
Sure we're talking about "complicated" things, but these things are not needed for a good mod.
We're talking about it, because we want to talk about the limits of Civ5 modding. Standard things will sure not be so complicated.

Because both programmers (think Dilbert comics) and languages (Fortran if your lucky) were less efficient back then more people were needed to do the work now done by one programmer.

[...]

My impression is that by the early 90's this were efficient enough that a game like Civ could be programmed with each iteration of Civ had about as many programmer behind it as the number on the box, a small team by earlier standards.

you can't say this for all things. On DOS sure less people worked than on Win7.
But for other things...well, maybe.
I'm just to young to say anything about it .

 

[Impaler[WrG]]

This is just plain incorrect. Agile programming methods with smaller subteams do not suddenly throw away good coding practices. Software development methodologies have almost nothing to do with the actual code and more to do with task assignments, priorities, and interpersonal work methods. The way Agile methods discourage 'fencing off' code is not by introducing coupling or globals or ignoring good coding principles in the code itself, but by literally sharing authorship of more code and working more closely with one another on a programmer level (as opposed to a code level.) (There's a lot more to Agile than that but I don't want to go into it. Long story short Agile arguably benefits MORE from having more modular less coupled code than other methodologies like Waterfall)

It infuriates me that this misunderstanding of Agile is so prevalent. It's what gives a good system a bad name.

I probably should have said 'leaner' as in small, I am actually not all that familiar with "THE" agile and was not trying to it describe it specifically, bad choice of words on my part. Nor was I trying to imply that modern development ignores good coding practices. I was speculating that the older project structures made global variables much much more dangerous because of the team size and the 'fenced off' of code which allowed one idiot misusing a global to screw-up a lot of other peoples work and worst of all for it to be stealthy. All of us can remember a professors that treats use of global variables as a habit students need to be sternly broken of lest they turn into that idiot who blows up the project.

 

[Kid R]

And due to the high costs of doing ANY kind of programming most projects were huge client-specific databases for corporate clients which required big especially large team which constantly re-invented the wheel.

...

My impression is that by the early 90's this were efficient enough that a game like Civ could be programmed with each iteration of Civ had about as many programmer behind it as the number on the box, a small team by earlier standards.

Both true. The 70's were actually populated by real people, it isn't just a fictional environment where they all walk around really fast and jerky in black and white clothes. Teams of people might be large or small just like 200 or 2000 years ago - prob the pyramids project was quite a large team for example

But the art of programming is twice as old now so it's natural the magnitude of what can be achieved per person is much greater. I would put that down to maybe 25% improvement in computer languages and project management, and 75% cultural, in that (a) people grow up using computers form an early age, and (b) computers are a central part of society as a whole - e.g. the internet.

... I'm curious as to what you consider to be a "well-designed language."

Hope I didn't insult anyone's favourite - like most of my posts I was trying to make a lame joke first and foremost. Seriously I've never used LUA but several posters were saying it's a bit unconventional so I'm curious. One I really enjoyed on the mainframe was "Filetab", which was a bit like creating a su-doku puzzle for the computer to solve at run time and achieve some objective as a by-product. Totally impractical and unreadable afterwards, even by yourself when you came to fix a problem 2 weeks later. Great fun to write though

Lots of modern languages are well designed. Object orientation has I hope now become de rigeur so that's important, but otherwise it has to be horses for courses. I'm a systems progammer so it's C++ 99% of the time, and I think it's close to perfect for that.

 

[LDiCesare]

isn't this how they made all of these things in the first place? And just fanning the flames a little here, if that isn't how they did it, why in the world not? It would seem to me that before one started building units, they would build a unit builder. Just an idea.

It's probably the way they'd make custom maps. But for buildings and units, a visual editor doesn't allow one to add new capacities (like throwing a fireball as was done in FfH). For advanced modding (stuff you couldn't do with an editor), a programming language is needed.

Global variables in lua are a problem. I work with lua and sometimes you forget a 'local'. It messes everything very very fast, in part because there is no variable declaration as in C. Particularly if you named your variable something common like 'nextObject', 'value' or 'i'.
Also on big projects, global variables can be a pain even today. When you have a global variable to a concrete class which is coupled to a lot of things (note this remark applies to badly used singletons too), then it becomes hard to test classes which use that global variable because you can't easily stub/mock said variable. It's far neater to pass the variable as an argument when needed, because you loosen coupling and make your program easier to test.