"Unprecedented Modding Tools"

[EmperorFool]

First thing to mention here is sure perl.

I'm pretty sure I read that wrong. Perl? PERL?! The most cryptic procedural programming language out there, Perl would be horrible as a modding language. I won't elaborate because I'm still pretty sure you didn't just suggest Perl.

In what way is it harder to set up a compiler than in interpeter?

As phungus420 answered, the compiler is harder because you don't have to set up the Python interpreter at all to do modding. Heck, you can even modify most of the Python modules on-the-fly and see your changes in Civ4 without restarting it.

 

[Afforess]

I installed Visual Studio 2003. I opened up the project. I compiled using the built-in menu.

Huh? Does the VsProject file even work? I tried opening it before, but it never compiled for me. Getting Civ to compile on VS 2008 was not trivial.

 

[Dale]

Huh? Does the VsProject file even work? I tried opening it before, but it never compiled for me. Getting Civ to compile on VS 2008 was not trivial.

Civ4 was develop on VS2003. The project file is as pointed out earlier, simply install VS2003, open project file, compile. No errors.

VS2005 & VS2008 are different library sets, so of course they're going to be complicated.

 

[Chazcon]

Have you ever set up the compiler for Civ4? Try it and tell me a novice could do it.

1) If you own VS 2003, it's a snap. Like others have said, just open the file... Do YOU know how to use VS 2003?

2) If you don't own VS 2003, there is a long-standing thread on these forums describing in detail how to use the free version of VS 2005 or VS 2008.

 

[Chazcon]

To me, avoiding Python due to its use of whitespace for indentation is like turning down a free Testarosa because it's not red.

Why would you want a Testarossa if it wasn't red? *grin*

 

[deanej]

1) If you own VS 2003, it's a snap. Like others have said, just open the file... Do YOU know how to use VS 2003?

2) If you don't own VS 2003, there is a long-standing thread on these forums describing in detail how to use the free version of VS 2005 or VS 2008.

If the people requesting modding be easier were willing to read tutorials, there would be a lot less people requesting modding be easier.

 

[The_J]

I'm pretty sure I read that wrong. Perl? PERL?! The most cryptic procedural programming language out there, Perl would be horrible as a modding language. I won't elaborate because I'm still pretty sure you didn't just suggest Perl.

Guess it, i don't really know anything about Perl .
I've just mentioned it, because it's mentioned together with python when somebody talkes about scripting languages.

I have a perl script here, it looks not that good readable like python, but it shouldn't be hard for a coder to learn it.
And i just hope, that, if there'll be a scripting language included, it will be one, where the intendation doesn't matter. Would debuging (not for me, debuging other people's merges) make a lot easier.

 

[Chazcon]

Guess it, i don't really know anything about Perl .
I've just mentioned it, because it's mentioned together with python when somebody talkes about scripting languages.

I have a perl script here, it looks not that good readable like python, but it shouldn't be hard for a coder to learn it.
And i just hope, that, if there'll be a scripting language included, it will be one, where the intendation doesn't matter. Would debuging (not for me, debuging other people's merges) make a lot easier.

I've seen some INSANE programs written in scripting languages. Awesome stuff.

So don't 'write off' script languages

 

[r_rolo1]

Perl? If the idea is to make things unworkable for 99% of the amateur coders , better go to the basics and sugest ForTran

 

[Yakk]

for k, v in d:
    print k, v

What's the equivalent code in C++? Exactly.

template<typename Container>
void print_container( Container const& container )
{
  for (Container::const_iterator it = container.begin(); it != container.end(); ++it)
  {
    stdout << it->first << ", " << it->second << "\n";
  }
}

Note that the above does full type-checking when you compile the code.

The python code compiles and runs ... until it hits the point where something went wrong. It then fails catastrophically, because the type of d wasn't what you thought it was.

Delayed type checking has a cost, especially when you are working in an environment where your test harness is a fully running game of Civ, and the code is called at a nearly arbitrary part within it.

Of course the STL simplifies makes writing C++ code easier. I couldn't imagine writing my own C++ data structures. But that's not the point. Someone above suggested using C++ in place of Python, and you simply cannot convince me that C++ even with the STL is easier for amateurs to learn than Python.

*nod*. But Python keeps the 10 to 100 fold slowdown problem, which is important when your AI relies on a combinatorial examination of options to determine what it wants to do.

AI in civ4 was the slow part of "next turn".

 

[EmperorFool]

AI in civ4 was the slow part of "next turn".

This is why the AI is in C++ and the interface is in Python (except hover text). Sure, there are Python callbacks and events as a modding extension point, but nothing forces the modder to use that. You are free to do it all in C++.

 

[croxis]

But that is why python can be extended and/or embedded with c/c++. Python is not very fast with heavy math. For that you either create a C++ module with python bindings or alter the sdk code.

 

[Afforess]

AI in civ4 was the slow part of "next turn".

Technically correct, but not totally true. There are/is 2 major bottlenecks for turn times in Civ4.

1.) Python callbacks. Don't use them. Disable those in the SDK that Firaxis didn't add callbacks for. The python to C++ parser they used was slowww...

2.) Units. Unit pathfinding, unit grouping, unit decision making.... The sheer number of units late game really hurts the time. It's one reason I'm optimistic about Civ5's 1 unit per tile rule, there will be a lot less units, and that basically eliminates this problem entirely. They could use the Civ4 engine again (I'm not saying they are or will), and get 50-75% boosts in speed.

 

[Afforess]

But that is why python can be extended and/or embedded with c/c++. Python is not very fast with heavy math. For that you either create a C++ module with python bindings or alter the sdk code.

None of the python in Civ4 is used for much math, other than simple counting. If you're using python for heavy math, you're doing it wrong.

 

[mjs0]

2.) Units. Unit pathfinding, unit grouping, unit decision making.... The sheer number of units late game really hurts the time. It's one reason I'm optimistic about Civ5's 1 unit per tile rule, there will be a lot less units, and that basically eliminates this problem entirely.

Moving from squares to hexes will make a big difference in pathfinding as well, dropping from 'up to 7' to 'up to 5' choices of direction may not seem like much but over the course of a long path it will be very significant.

I am also hopeful that on top of a reduction in the number of units the long term planning component of the AI should result in far fewer calls to lengthy 'what should I do with this unit' methods (for every unit on every turn) as the AIs and thus their units become committed to a preplanned course of action until some event or trigger causes a reevaluation.

 

[Afforess]

Moving from squares to hexes will make a big difference in pathfinding as well, dropping from 'up to 7' to 'up to 5' choices of direction may not seem like much but over the course of a long path it will be very significant.

I am also hopeful that on top of a reduction in the number of units the long term planning component of the AI should result in far fewer calls to lengthy 'what should I do with this unit' methods (for every unit on every turn) as the AIs and thus their units become committed to a preplanned course of action until some event or trigger causes a reevaluation.

Yes, and hopefully they can make the Unit AI much more map aware in Civ5 because of all this extra time.

 

[The_J]

If you're using python for heavy math, you're doing it wrong.

If you're still talking about Civ, and don't count algorithms into math, you're right .

 

[Yakk]

Naw, dropping from squares to hexes won't help much, especially with infantry move increasing to 2 (and hence every other unit getting faster).

The real thing that will help is if they rework their A* algorithm to (A) cache smarter, and (B) give up when the path gets too long (passed-in parameter).

There is lots of ugly code that basically is about keeping the pathing search space small, and every time the ugly code springs a leak, things get slow again.

 

[mjs0]

Naw, dropping from squares to hexes won't help much, especially with infantry move increasing to 2 (and hence every other unit getting faster).

The real thing that will help is if they rework their A* algorithm to (A) cache smarter, and (B) give up when the path gets too long (passed-in parameter).

There is lots of ugly code that basically is about keeping the pathing search space small, and every time the ugly code springs a leak, things get slow again.

Why would the movement speed of units negatively affect the computational speed of pathing algorithms?

I can see that their A* might be poorly written or inefficient (hopefully the phrase 'an astonishing new engine built from the ground-up' means this has been fixed!) but I just don't see how increasing a units move to 2 tiles from 1 would affect the time it takes to find a path.

Reducing the number of choices at each node on the path on the other hand would clearly have a significant effect since the number of computations for n choices at each node on a path of length x is more closely related to x^n than x*n

Sorry if I am being dense.

 

[Yakk]

Why would the movement speed of units negatively affect the computational speed of pathing algorithms?

In the Civ4 AI, units explore a certain multiple of their speed to find a target.

The faster they move, the larger the area they have to search to find targets they could attack in a round or two.

I can see that their A* might be poorly written or inefficient (hopefully the phrase 'an astonishing new engine built from the ground-up' means this has been fixed!) but I just don't see how increasing a units move to 2 tiles from 1 would affect the time it takes to find a path.

Because they have to search a larger radius of area for valid paths.

Reducing the number of choices at each node on the path on the other hand would clearly have a significant effect since the number of computations for n choices at each node on a path of length x is more closely related to x^n than x*n

What you care about is how many tiles there are in a radius of n away from a location.

Now, as unit velocity goes up, n goes up.

As the branching factor of the game goes up, the base goes up.

On a square map, the number of squares within distance n is (2n+1)^2 = 4n^2 + 4n + 1

On a hex map, the number of squares within distance n is ...
http://en.wikipedia.org/wiki/Hexagonal_number
(2n+1)(2(2n+1)-1)
=(2n+1)(4n+1)
=8n^2+6n+1
That isn't quite right. It should be 1 7 19 37 (+6, +12, +18) or so, as opposed to 1 9 25 49. (+8,+16,+24, etc).

But in any case, it will end up also being an O(n^2) number. Hexagonal ends up being about 3/4 the volume at a given radius, but with unit velocity being faster, the search space blowup from a 50% to 100% boost in speed (for the same number of turn lookahead) is a factor of 2 to 4.

Worst case pathing situations (where you have problems reaching your target) end up having to search a volume whose radius is roughly proportional to n. The fact that one is a hexagonal tiled, and the other is square tiled, won't matter much.