BattleTech PBeM Development Group From: bc@fccn01.fccn.pt (Luis Miguel Sequeira) Date: Thu, 26 Nov 1992 10:58:02 +0000 ******************************************************************* B A T T L E T E C H P B e M D E V E L O P M E N T G R O U P ******************************************************************* First of all, I must apologize to most of you. I'm currently completeley overswamped by mail with more and more suggestions, and, having also my work to think about (who doesn't, after all? :-), the thing is escaping my control, and I'm almost unable to manage it... :-) This isn't a complain! It's a good sign! It only means that there *is* real interest around there! Well, to get a few points noted: Currently there is an experimental account for the future development of the game. It's at <mechwars@wkux02.fccn.pt>. The machine is a VAXstation 3100 running Ultrix, an old one ('89) and quite slow, but it's the best I could get my hands on. It also hasn't much disk space left :-) There is a small mailer there (developed thanks to many ideas, suggests and comments, specially by Igor Divjak, who has patiently answered all my stupid questions until the thing worked properly... I owe you one, Igor!) which accepts requests for rules (put "rules" on the subject field), orders & subscriptions, but, of course, there isn't any game written yet, and even no rulebook (so you'll get a free .signature instead!! :-) )... The same account is an anonymous ftp server. This was a suggestion made by a few of you, to be able to directly make some contributions (and to have a laugh at my horrible programming style by ftp'ing the sources!!! :-) ). I'd like the source code of a suitable ftp daemon, so as to process ftp mail requests... if someone has such a thing, please let me know! (Presently, the best you can get is the rules, by ftp or mail - but as they aren't written anyway...) If you really have nothing to do, you can still try ftp'ing or mailing to the account above, just to test it. I'm sure it's still full of bugs for you to discover... complain! ---///--- Ok, back to work. I've received some suggestions on dropships & jumpships by Hunter Chen (you can now get them by ftp!), and some nice ideas about NPC (and PC?) stats! Thanks Jon (the Z). Also, I've begun a little discussion on implementation details, which I'm going to transcribe now: (starts here) Ok, hope I'm not starting a full-scale war on the subject of the programming language of choice! :-) But here some suggestions, and some reasons why I suggest them: 1) There are things that a traditional language (say, C) does better than a symbolic processing one (say, LISP and variants, or Prolog). For instance, to generate a map for the battlefield (I'll get to that on my next post to news). Of course, you *can* do it in LISP or Prolog. But it will be easier to get it right in C... So, for such things, and others, like interacting with the Unix operating system (i. e., automatic mail processing, etc.), I think (my opinion!!) that C is a good choice (one could also choose C++, or even Fortran, if you like. Or even Pascal... well, you know, that kind of languages, anyway). 2) However, complex database processing is something which is beyond C's "normal" capabilities. I say "normal", as of course you can get some of the thousands of C-written databases to work with. But smething like SQL would be nicer. After all, you want to get something like "list me all mechs currently at close combat on hex 101, on planet 4523, and with blue stripes on them". You NEED a database manager here! My first attempts at getting a PBM rolling were using a C-written database, as I said; I didn't like it. There simply wasn't enough flexibility. 3) Finally, on top of all this, you have the rules of the game! Getting the things just straight from the database manager isn't enough; you've got to fit them into the rules! Now here most database managers can't cope with it. Of course zillions of PMBs have been written that way. But, while you can easily fetch things from your database, and pretty print them as you like (difficult to do just in C...), the rules stuff are difficult to write! I didn't say it's impossible, I said it's difficult. Some brief parenthesis: I'm a C addict. My theory is (or was until recently), if you can't do it in Assembler, do it in C. If you can't do it in C, it isn't worth doing! (not an original quote, mind you) I still use C (and other stuff like C database managers and yacc & lex, etc.) to do almost everything - the hard way. So what? C is C, and you can do what you like with it. But sometimes C can be a hindrance. Say you've got an incredibly complex data structure, tree-based, and lots of pointers floating around. Perhaps you can answer the question on point 2 ("list me all mechs currently at close combat on hex 101, on planet 4523, and with blue stripes on them") just by snapping your fingers. However, you've done a tremenduous amount of work just to get there. And bugs are *so* easy to crawl into your system... and the next morning some player gripes at you: "no, no! MY 'mech hasn't got any blue stripes, just yellow-and-red ones". The database is easily changed; the rules NOT. That's where symbolic processing languages excel... rules & databases are for them the same thing, and it's so easy to change them as you like, that you can do it over and over again. Data structures are so simple even a child could understand them (and they do...) - and they are just rules, after all. Searching through the database for that damned mech with blue stripes (or was it yellow-and-red ones?) is as easy as on a database manager, but you can get rules so complex (but so simply written) that no database manager could cope with. I think you'll agree with me... 4) Ok, we won't implement "level 4" for now. "Level 4" is the "intelligent" NPC. That is, you want him to react to the situation around him as a human player would. As the game has its rules, and is closed (no "outside" common sense needed), you *could* do it. I. e., give your lance leader the order to fight a battle. Like a computerised chess player, he'd make his moves to win, as best as he could. Ok, C is definitely out for this kind of stuff (of course, you *could* do it, but the work... argh!). Now, as for LISP vs. Prolog... I must say, Prolog is *in* in Europe and LISP is *out* (as its variants), so I admit I'm in exactly the opposite situation: I know the basics of LISP (the "pure" versions; I saw things like Scheme & ML [liked that one a lot], but never really worked with them), have done some *very simple* programming on them, but not much more. Sorry, I admit I've got some prejudice against LISP: I'm still sticking with the notion that you do all with lists, but you don't do much more besides... Prolog isn't perfect, but it copes with lists as well as LISP... ;-) Well, I leave this issue open. I am, by no means, *NO* expert on Prolog! I also know the basics, have done some crazy stuff with it a couple of years ago (and invariably forgot most of what I've learned, judging by what I still understand from the programs I wrote...), but, sincerely, I am still shaky on the subject. However, I remember enough of it to know that the things which are *so* difficult to do in C are a child's play in Prolog (the reverse is also true for many other things, of course, but PBeMs, specially the rule coding part, are more akin to what Prolog is good for than C). So, what I'm going to do is to ask around if there are a few people wanting to do it in Prolog. Define a standard database format (simple text), which are just Prolog facts. You can load them directly on Prolog. This would allow me to write a few test programs myself which wouldn't take much time. On a second phase, if lots and lots of people want to do it on *their* favourite language (again I must underline that Prolog *isn't* my favourite language, even if it is one that I happen to like), they simply have to do a parser to read the database, dump it into an ordered array, and play with it. I can easily write something on yacc to do this, and I'm certain that most people could do it, too [or even forget yacc and do it directly with fscanf()]. For example, a simple format for a battlefield map: hex(planet(35), code(101), terrain(clear), height(0)). hex(planet(35), code(102), terrain(hills), height(1)). hex(planet(35), code(100), terrain(water), height(-2)). hex(planet(35), code(99), terrain(light_woods), height(0)). Or perhaps a "flat version", eg hex(35, 101, clear, 0), just to ease the C parsers for that. (Yes, I think I'll keep it flat.) C freaks had just to convert that into: typedef struct { int planet; int code; int terrain; int height; } hex; hex Battlefield[N]; Well, you see what I mean. Nothing spectacular here. You could even sort the database (with the Unix sort command), and hey presto, instant sorted C array... Ok, I'll get back to this on my next post on news. I won't start the language discussion by now, but I'll suggest a Prolog-like ASCII database to start with. (ends here) so, to define an "universal" ASCII database format: - Hexes on a battlefield - All lines are of the form: hex(PlanetCode, HexCode, Terrain_Type, Height_Level). where PlanetCode is the code of the planet for this battlefield. Prolog doesn't care about digits or letters, so I don't, too. HexCode A number representing the hex position. I'm using a totally numeric form just for ease: ____ ____ /0101\ /0301\ / \____/ \____ \ /0201\ /0401\ \____/ \____/ \ /0102\ /0302\ / / \____/ \____/ \ /0202\ / \____/ \____/ \ / \____/ Got it? I thought so. Terrain_Type clear, rough, hills, light_woods, dense_woods, water (these are strings) Height_Level As on BT; -N to N. What I'd love is to have something (written in C or something else) to randomly generate such a terrain (no need to be sorted), based on some stats from the planet. Other interesting and most useful program would be one which would load the database for a battlefield and draw nice little hexes (as above) with some useful info inside (PostScript version? Anyone...?), to be included as maps on the report... - planet database - planet(PlanetCode, Owner, Clear, Rough, Hills, Light_Woods, Dense_Woods, Water, Economic_Type, [Facilities]). where PlanetCode as above Owner Player ID, House ID, I still don't know Clear, Rough, Hills, Light_Woods, Dense_Woods, Water Percentages Economic_Type agrcultural, industrial, whatever [Facilities] a comma-separated, square-bracketed list of facilities of the form: [facility(Type, HexCode), facility(Type2, HexCode), ...] where Type is mech_factory, industry, base, starport, etc. I'd also like a random planet generator, using a system like on MegaTraveller or similar! Better still: someone who types all BT's planets on a file... (arrrgh! good luck on all that work...) Mechs could be something like: mech(MechName, Owner, Lance, WhereIs, MechWarrior, Stat1, Stat2...). where MechName Usual stuff Owner as above: Player, etc. Lance Lance to which it belongs to WhereIs Normally a HexCode, but could also be something like jumpship(JumpshipID), showing that it's aboard a vessel, etc. MechWarrior MechWarrior ID which pilots the '0mech Stat1, Stat2... Yet to be defined attributes... So, now I'm in a hurry and must leave, but you've got the general ideia. I'm coming back to this tomorrow. Bye, Luis Sequeira _________________________________________________________________________ / / _/ _/ _/ _/_/_/ Computer scientists do it byte by byte. _/ _/_/ _/_/ _/ _/ _/ _/ _/ _/_/_/ "Know your enemy before he knows you" _/ _/ _/ _/ - Sun Tzu misquote _/_/_/ _/ _/ _/_/_/ bc@fccn01.fccn.pt Luis Miguel Sequeira Laboratorio Nacional de Engenharia Civil Phone 351-1-8482131 Ext. 2752 Centro Informatica/Grupo Sistemas Centrais "Don't call me, I'll call you" Av. Brasil, 101 - 1700 Lisboa, Portugal / _________________________________________________________________________/ Up