posted 06-30-99 03:40 PM ET        

Yang raises a LAND BRIDGE in early game so he can demand I surrender the tech to make land bridges. (!!!)

Miriam, with only one city and NO units, demand I surrender EVERYTHING to her.

Santi (#2) wants me (#1) to team up with her so we can destroy the weakest person on the map (Morgan #7).

Lal says lets be friends. Lets trade tech. Oh by the way, I hate you, let me hit you with 4 planet busters at once! (Out of range, btw) Now that I bombed you, lets be friends...

This game is nuts. Bring on the Russions and Zulus from Civ. At least they didn't try to be so smart that they were insane. They were just sneaky, underhanded bastards with no honor.

posted 06-30-99 03:53 PM ET            

They had three defenders and no city walls, so I couldn't take over the wonders without destroying them. I even irrigated for them so they'd grow, but they never built city walls and always grew a new warriors or phalanx faster than their pop growth.

I did everything I could to get them to be conquerable without destroying that damned city, and no dice, so I finally just wasted it.

Lets face it - this kind of insult to our intelligence, lazy, lard-assed Basic Programming 101 cheat BS is what Sid, Brian and most of the rest of the industry try to pass off to us slavering chumps as "AI."

Here's my AI suggestion for CivIII, Brian:
All AI grow in pop once per turn. AI can make any unit it wants - all take one unit of production. AI can build anything else it wants in one turn. AI units in combat with human get hidden +1000% (not a typo) die roll bonuses.

posted 06-30-99 04:13 PM ET            

Shouldn't you be hard at work on scoring 2000 on the Lal Scenario? Or writing MtG PentiumXIII's next installment?

Other fun things that happened that game... Santi pacted with me right off the bat. Now, I'm already biting my lip off about Miriam in an undefended national ONE city-state and having signed a trading truce (I told you, I was going for that peaceful game... I was serious). Santi and Miriam were constantly at a state of war/truce (probably why the Orange Orangatang didn't have anything), but Santi wouldn't move in and capture the New J. Even though it was undefended! She ran her rovers BACK to her side to stick in a transport to come bother me, her ALLY. She never asked me to back her against Miriam either.

And Santi IMMEDIATELY built a sea pod and set it down one sea tile diagonal from my Cap. Talk about long range planning. The kicker was... she didn't have Flexibility. I could offer her flex in trade for the next 100 turns! How the heck she managed that, I don't know, but then again, Lal PB'd me, and he didn't have Planet Buster capability.

There are some VERY serious bugs in Brian's "A"-non-"I" strategy code. Hope those get Black Flagged before they sneak into Civ3.

Well, at least the Opponent Engine's behaviour of moving its only defender out of a city is balanced by its behavior to not TAKE an undefended city when their are no minuses to it...

posted 06-30-99 06:26 PM ET            

Well then, DS, what are you complaining about? You've got play balance, Bryan Reynolds style!

Tell ya what though - I've bought nearly every TBS game since the original UMS, and I'm going to pass on Civ III unless and until gamers who I know have a tenth of a clue how to play say whether it's a good game.

SMAC was a great concept, has a potentially cool look and feel, and is a lot of fun in multiplay (once everyone gets the hang of the poor multiplay design), but it's garbage otherwise. Now if I start a game in SP, I don't go more than two or three turns before I say "so what" and quit. I still have more fun with playing Colonization or CivII, years later.

posted 07-01-99 03:18 PM ET            

And that is the same team putting Civ3 together, on the SMAC code. Or so they tell us.

posted 07-01-99 10:15 PM ET            

I like what the game *could* be, and *could* do - but the AI doing things it doesn't have the tech or the resources for, building and using impossible units (AAA armored transports), infinitely ranged missiles, suffering no planet penalties for it's landraping, etc. are just ridiculous.

Darkstar and I are veteran strategy gamers. (I'm a Candidate Master chess player, a 2 dan Go player, a 1 dan Shogi player, and do kickass Napoleonic and Civil War miniatures, in addition to dozens of TBS games over the years.)

Darkstar and I are also long tie code jockeys and app developers. The emphasis in gaming has been on eye candy, not AI, for years. The state of AI in SMAC is not really any better than the original Civ. There's more things that the game can do, so there's more tools, but the AI is still as dumb as ever. How do you get different levels - give the AI production bonuses, rather than smarter algorithms. What happens if the human gets ahead? Let the AI operate under a different set of rules.

Ever run the game with the scenario editor on? It's hilarious. In one game where I was PK, and the Hive was my closest thing to a rival, on another continent, I killed so many loaded transports with my ships that the AI stopped building ships of any kind, and started building missiles. What did it do with those missiles? Develop a fetish for one square 18 squares away (2 out of the normal range) where it didn't like me putting any formers - it ignored my vulnerable ships and plinked formers on that one square, or the size two city next to it.

Meantime, 30 hive units kept swirling around like the whirling dervishes because they all had go to orders to another irrelevant city on my continent - but they couldn't walk there, so they just wandered in circles, turn after turn.

You could hire a couple of high school kids who'd never seen a computer before his six months of courses at ITT Tech Institute, and not do a whole lot worse at game AI than Firaxis did.

I don't rant against the game, I rant at the half assed "we got their money and the game reviewers sucked up the demo because they don't want to offend EA, so who gives a ****" implementation of what could be an incredible game.

posted 07-01-99 10:25 PM ET            

(well, if not powerful, then profitable)

posted 07-02-99 03:08 AM ET            

MtG: I wish I didn't have to agree with you, but yes, we used to have a course here called EPM 1 (Engineering Principles and Methods) in which we taught Turbo Pascal 6 graphics (all our budget could afford for many years) in first semester to a class half of whom had never been near a computer before (so the first week was teaching them the DOS command line).

After the basic training, they were instructed to organise themselves in teams of four, and each team was asked to choose a graphics software project froma list of about thirty.

By mid-semester, they were really in the swing of designing, implementing and testing their programs, and by end of semester when they were assessed, most of them had product that stood up well to the software industry's standards.

So the students made us happy, and the professionals are a sad, sad case.

Sure, we pushed the students hard for quality of design, but many of them were able to innovate solutions that I'd never thought of, so doesn't this suggest that the industry is driven by all the wrong goals?

Incidentally, here is the best way I know how to code. It's fast, it's accurate, it's bug-resistant.

The brief points are these, in order of importance.

1. Document.
2. Analyse.
3. Validate data.
4. Design and code top-down.
5. Reuse code.

Expanded, the points become:

1. Write the documentation first. That's the most important point, and it applies _all_ the way through the process. This means document every thing you intend to do, before you do it. This is the _only_ way to ensure that (1) the documentation is accurate, and (2) the program is correct.

So that you, the programmers, know what you want to do next, use block comments to record to your fullest knowledge, in clear language, what the following code is intended to do, before you type a jot of code. (How easily one otherwise gets distracted and forgets!)

2. Analyse the problem with mathematical precision, that is with an eagle eye for structure and pattern. Once you see a pattern, study it! Generalise it, reuse it wherever applicable. Document your analysis every step of the way. Lots of simple but accurate diagrams, please.

3. Validate data! After the first round of analysis, we must have a clear picture of the outermost organisation of the intended program, the data structures that will be employed, and what operations they will use. If not, analyse more until you do.

Now that you've described your data, you know what it means, and what values it can have. And now that you've structured your program, you know where the data is entering and leaving each logical block or module. *So every time it does, check it for validity.*

"What?", I hear the traditional Sloppy Joe programmer asking, "our slick code cannot tolerate such an overhead". On the contrary, of course it can. Since you've structured your design wisely (you have, haven't you?), most of the processing of the data has occurred in between the entry and exit points of the module, so a little validity checking won't hurt you at all.

Besides, if you really desperately want faster code, then it's high time you investigated better algorithms. (And documented them thoroughly, before using them.)

The great advantage of these thorough checks is that the code self-tests. The moment something goes wrong, your software raises its own hand and says "Here is the bug! And this is what's wrong!", and traces the problem for you.

Sounds magical, but it works.

Data entry and departure also includes memory allocation and deallocation. Don't ever assume that memory has been successfully allocated - always check it! And never forget to free memory when you no longer need it.

How do you remember to do these checks everywhere? The same way you remember anything - by systematically documenting them before you code.

Some C functions must be forbidden in code that's intended to be stable: for example, the functions that access memory without checking for overruns. Their behavior is not well-controlled, so program-wise they are intrinsically evil. (Like Erratic Lal and the Impossible Planet Busters from Nowhere.)

4. Design and code top-down. This should be called "outside-in" design. We're designing from the most general outer shell of the program, inwards to the specific calls to pre-existing compiler and library functions.

This is the iterative process. Document your most general intentions, but in clear, precise language. Pseudo-code is OK here, but make sure your _motivation_ for each design choice is recorded completely. Write this in block comments.

Then, and only then, start coding. Code under the comment, and code only what you said you would. If you change your mind ("Oh! I can see a better way of doing this!"), then change the documentation first.

Use clear and obvious names for the functions and data, even if they're a bit longer than your lazy fingers feel comfortable with. Unpronounceable and mysterious handles are fine in newsgroups and forums; but in code, sloppiness wins you the Blue Screen Of Death.

Now that your documentation and coding of the outer layer of the software onion are written, consistent, accurate, and look quite neat, you can repeat the process on each of the functions.

5. Reuse code. In most projects, one sees patterns recurring. This is a hint that there's structure here. You should find what it is (nail the concept!), and make it into a function or module, or data type or class (if you're using Object Oriented programming).

Now that you have objectified it, use it. Use it everywhere the concept applies. Use it and only it, and use it consistently, so that your program behaves in reasonable ways.

Finally, remember: your reputation's at stake, so only the best will do. Emphasise Quality and Thoroughness in Documentation, Analysis, Design, Code and Testing at every stage.

Example: a strategy game has 7 players. Key concept: player. A player is conceptually distinct from the book-keeping mechanism underlying the game, and can only communicate with the game through a clean interface that is the same for every player. Therefore, the AI player obeys the same rules as the human player, and has access to the same information, by the same means.

posted 07-02-99 01:34 PM ET            

That is a QUITE common situation in the Business World of Software Design. Which is why there are other models that are as effective for those situations as the process you outlined.

And last... there is no correct way to do ANY programming. Except what yeilds a good product that meets all of your customer's needs and does so in a pleasant, efficent manner that is as easy to use and understand ("User Friendly") as possible.

posted 07-03-99 03:03 PM ET         

I haven't tested the strategic aspect too much, as I'm not a warmonger.

posted 07-03-99 03:18 PM ET            

I do agree with you. The Opponent Engine (Not AI!) is much better than when it was in Civ2. But my POINT in this thread is the title. I started out going for peaceful builder... I honored my word... yadda yadda yadda. And you know what? The OE (Opponent Engine) came after me hard. When I go after it, I don't have that problem. Odd, yes?

The rest was a bitch session. Oh dear. Used a naughty. Hope I don't get banned!

When I pick on Firaxis and SMAC, its on implementation details. I leave the other stuff to Michael the Greatest. He's newer to it, so has a larger fuel reserve for flaming on.

posted 07-03-99 04:01 PM ET            

I do AI programming among a few other things, so I rant on the basis of what I'm doing, not on the basis of my opinion. My biggest AI project is an operations analyzer for electric utility gas turnbines, that takes operating data streams from the instrumentation, and analyzes that in comparison with updates on parts life history, prior failures and operating patterns, and provides an early warning system superior to trained operators and supervisors for possible major maintenance problems.

It is a larger, longer process than SMAC design, but the point is I know how to do AI algorithm design for large scale, interactive, multi-thread and multi-tasking apps.

posted 07-04-99 11:13 PM ET            

I agree with mindlace about the opponent engine being better than civII, at least as soon as it builds a unit it doesn't send it down all by itself.

Yes, the "AI" does some seemingly crazy things, but look at the world around you...
Are all of our acts rational?

I do like the game overall, it has provided me with hours of entertainment even if at times you can't believe what the "AI" is doing.

MTG - I have used and built modules for many different "operations analyzers" and have yet to see and probably never will see a computer program superior to the humans who work with them and are familiar with their hiccups. This is not meant as a flame, but did it not take Deep Blue many tries and programmers tweaking around the clock to win a game of chess against Kasparov?

Sentient Algorithims are far up my tech tree.