My wish: CLR as gaming scripting engine for Civilization
I'm a big fan of Sid Meier's Civilization series. One thing I would love to see is for them to use the CLR as back-end scripting engine. Alpha Centauri (SMAC) had some good automation, but you could really work some wonders if you had a full scripting engine. One immediate practical benefit of the CLR would be that you could script your units and governors in your favorite language (whether C#, IronPython, VB.Net, or LUA). In fact, I wouldn't be surprised if some enterprising soul would then come up with a .Net language specifically targetted for writing Civ AIs.
I believe the lack of good automation makes it too cumbersome to run a large civilization. Thus I'd love to see some serious automation that lets me then scale a civilization game to 100s of cities. Some specific things I would love to be able to script (using SMAC terminology) would include:
- automated settling on an island. That includes coordinating a transport + colony pod (settlers) to go to the island, build the city, and then have that city spawn across the rest of the island. Once the island is sufficiently colonized, then be able to issue commands to the entire collection of cities such as "build this wonder" (where 1 city builds the wonder, and then all the other cities build caravans that support the wonder) or "generate as much positive cash flow as possible".
- the ability to premark places that I'd like to place cities, and then script an AI to build the colony pods and deliver them to those locations.
- smarter governors. One of my concerns about the automated city governors is that they tend to waste resources. For example, if I let a small outpost city hurry production, I fear it will drain the treasury of the rest of civilization building stupid things that won't help the outpost and have high maintenance costs. So I'd like advanced governor options, such as giving governors a "hurry production" budget or preventing the governor from doing anything that would be a financial drain on the rest of the civilization.
- automated mobilization for war. I'd like to be able to have global state such as a global build queue ("I want 30 military units of type X and I want them to move to city Y")
- things that coordinate amongst multiple units or cities.
- things that allow me to issue high-level directives. For example "build up city X" which would tell my pool of automated formers to all focus on improving city X as fast as possible; while also giving city X authority to hurry production, and maybe also telling nearby city Y to provide military units for city X's defense so that X doesn't need to waste time building military items.
- automated report generation. For example, calculate "how much trade do I have with each other civilization?", "how many resource squares are currently under-developped?", "how good is my road infrastructure", "which city has the most potential for (production / research / money / etc)".
And I'm sure more ideas would come as I think about it longer. If Civilization had a decent enough scripting engine, I think a community for such scripts would develop overnight ("Hey, check out this script that does XYZ"). Folks may even script the enemy AIs. I could see competitions between different AIs. Bottom line is that it would be very very cool. (I personally think it would be much better than multiplayer - though you may even be able to build multiplayer on top of a good scripting story by having an enemy AI that takes input from a client across the internet).
And since my primary area of expertise is debugging services, I must pointed out that if you use the CLR for your gaming scripting engine, you get free debugging services!
Comments
- Anonymous
July 25, 2005
They're using Python as a scripting engine, so once released I'm sure someone will write a .NET-Python interfacing module for Civ. But yeah, it'd be awesome if it was CLR initially. - Anonymous
July 25, 2005
Personally I think the CLR is too big and bloated for this kind of thing.
Now don't get me wrong, .NET is great, but I think theres several issues to using it as a scripting engine for a game.
1. The runtime size. The installation is 20mb, installed it's well over 60mb.
2. It's not standalone. You can't distribute it as a simple dll or even embedded in your app like you do with lua and python.
3. What about .NET upgrades? Sure, you can install side-by-side, at least currently, but what about when the user uninstalls 1.1, because he/she just installed 2.0? Now your game suddenly doesn't work anymore.
4. The memory consumption and JITting would probably not fit well for scripting in a game.
I know theres games out there using Managed DirectX and is written entirely in a .NET language, but I dont think it's reasonable to have a runtime of this size combined with the memory and JITting overhead just for scripting.
Now, If you have a solution to the issues in items 2. and 3. I'd love to hear them, but unless you can get around that, I dont think it's a viable solution for something thats not written entirely in .NET. - Anonymous
July 25, 2005
Thomas - great points.
Re 1: you're talking disk size, right? I don't see that as a big obstacle.
Re 2: I see this has the same problem as Direct X. The apps can install the redist. Also, it will likely already be installed with the OS in most cases. (I think it also gets pulled down with windows update).
Re 3: The whole side-by-side (SxS) thing means 1.1 is still there even once you install 2.0. So the game can lock into a version and future installs / upgrades won't touch that version.
Re 4: I don't have the expertise to speak about perf comparisons between the virtual machines. The CLR takes perf very very seriously (I think at one point, half of our architects were perf related), so I certainly hope it's competitive.
Maybe my wishful thinking is getting the best of me... - Anonymous
July 26, 2005
I think the problem with installing the redist is that you can uninstall .NET again by going to add/remove programs. You can't do that with DirectX (similar for OpenGL - even if you unisntall your gfx driver, theres still the standard windows opengl driver).
It's not so much depending on .NET thats a problem if you redist it with your app, it's more that the user can go and uninstall it, as it's a seperate installation from your game.
But then, theres the same issues with 100% .NET applications, so whether it's really a problem or if I'm just being a purist is arguable. - Anonymous
June 07, 2008
I'm a big fan of Sid Meier's Civilization series. One thing I would love to see is for them to use the CLR as back-end scripting engine. Alpha Centauri (SMAC) had some good automation, but you could really work some wonders if you had a full scriptin