water@wheaton.UUCP (Paul Waterman) (11/21/90)
The summary line says it all. If I recall correctly, in February there
was a post that said that version 5.0 of conquer was already in beta
testing. Then, a little later, there was a post that proclaimed that
conquer version 5.0 would be coming out over the summer. At the end of
the summer, a post stated that it would be out in about two months.
Guys, it's been longer than that. Care to update us on what's going on
with version five? Will it ever come out? Will any messages that I
send to the author ever be answered?
No flame intended. I'm just in an interesting mood, and have a horde
of gamers here waiting for version five.
- Paul
--
.------------------------------------------------. Paul Waterman
| But I thought you said STRAITjackets and ties! | water@wheaton.UUCP
`------------------------------------------------' voice: (708) 260-5877cedman@golem.ps.uci.edu (Carl Edman) (11/22/90)
In article <2413@wheaton.UUCP> water@wheaton.UUCP (Paul Waterman) writes:
The summary line says it all. If I recall correctly, in February there
was a post that said that version 5.0 of conquer was already in beta
testing. Then, a little later, there was a post that proclaimed that
conquer version 5.0 would be coming out over the summer. At the end of
the summer, a post stated that it would be out in about two months.
2 good ways to find out:
1. Subscribe to the conquer-mailing list (Check your conquer 4.x
source for the address)
2. Anon ftp to cs.bu.edu. Everything for conquer which is available
becomes available there first. (I know, I check there about twice a
day :-). Last time I checked they Conquer 5.0 beta (a version not
changed since months, mouthwatering to look at, but not anything you'd
want to or be able to play) and Conquer 4.0 patchlevel 10.
Carl Edman
Theorectical Physicist,N.:A physicist whose | Send mail
existence is postulated, to make the numbers | to
balance but who is never actually observed | cedman@golem.ps.uci.edu
in the laboratory. | edmanc@uciph0.ps.uci.eduadb@cs.bu.edu (Adam Bryant) (11/27/90)
In article <2413@wheaton.UUCP> water@wheaton.UUCP (Paul Waterman) writes:
+
+ From: water@wheaton.UUCP (Paul Waterman)
+ Newsgroups: comp.sources.games.bugs
+ Summary: When?
+
+ The summary line says it all. If I recall correctly, in February there
+ was a post that said that version 5.0 of conquer was already in beta
+ testing. Then, a little later, there was a post that proclaimed that
+ conquer version 5.0 would be coming out over the summer. At the end of
+ the summer, a post stated that it would be out in about two months.
+
+ Guys, it's been longer than that. Care to update us on what's going on
+ with version five? Will it ever come out? Will any messages that I
+ send to the author ever be answered?
+
+ No flame intended. I'm just in an interesting mood, and have a horde
+ of gamers here waiting for version five.
+
+ - Paul
Ack. I am truly sorry that it has taken so long on the development of
conquer, but I am the only one working on it, and I have not had any
time until recently to work on it. [I guess you could think of it as
three months of writers block, phffttt]
The hardest part for me has been getting back into a programming
rhythm after having to stop work on it for about a month due to lack
of time.
Right now I am attempting to remedy that by reworking the source into
a more organized form so that I can more easily code it.
The current status of development:
- Version 5.x is a full rewrite of conquer, from the ground up.
This was done to allow an unlimited number of nations, armies,
navies, etc. through the use of new dynamic structures.
- There are now more display and highlight options.
- There are now more magical powers. [32 per class instead of 32 total].
- The world is cylindrical. [Wraps when moving east or west]
- Map coordinates are now relative. [Capitol of each nation is 0,0.
This make nation cooperation more realistic.]
- Raw materials are stored within city sectors and are usable only
on a local level, so they must be transported via caravans.
- The code is written using ANSI C, and automatically provides
prototyping for those compilers which support it.
- The mailing system is greatly enhanced and is much more usable
than the prior version.
- A more advanced, built in pager provides an easier method for
examining the documentation.
- The documentation is now written in roff source using macros which
handle output for both online and hardcopy. Preformated online
and hardcopy ready (postscript) documentation will be distributed
during the official release for those sites without roff. [nroff,
troff, or psroff]
- The data file will automatically use compress and zcat (or a
system equivalent) if your system supports it. This results in a
10 to 1 compression ratio, which can be rather handy.
- The compilation options which may affect the data file are grouped
together within the header.h file and are obviously marked to
allow better control of the compilation.
- The size of the world can now be 256x256 (or even greater if a
proper compilation option is set). For this version, the location
values and maps sizes are carefully monitored, and overflow is
prevented.
- The number of army units can be either > 250 (unsigned char to
hold the unit id number) or basically unlimited (unsigned short to
hold the unit id number) [default]. This is also a compilation option.
- The world generator is much more robust, with nicer looking land
and water formations.
And there are a bunch of other things which I can't think of right now
which have been written into the new version.
The things which I will complete before I post to comp.sources.games:
- Add a user customization system. [.conqrc file]
- Write the loading system for raw materials onto navies and
caravans. [Caravans are new land based transports]
- Write the magical power perusal / purchasing screen. [Almost
finished with this]
- Add a new combat system which will allow multi-way battles to take
place.
- Add more spells and a new spell casting method. [Almost completed]
So far the source code is much larger than version 4.x and it has been
written about 85 to 90 percent from scratch with the rest coming from
yanked 4.x code and some external contributions. Hopefully, I will be
able to get a fully functional version done by January, with the bugs
worked out a month or two after that.
Sorry for all of the delay (I guess I was a bit of an optimist), but I
only have two hands. :-)
adam
p.s. The beta code in the file "conquer/beta/conquer.tar.Z" should be
updated in about a week, but I can't guarantee anything. *sigh*
--
Adam Bryant INTERNET: adb@cs.bu.edu
Conquer Hack'n'Slasher BITNET: adb@buenga
list: conquer-news-request@cs.bu.edu UUCP: ...!harvard!bu-cs!adbdean@coplex.UUCP (Dean Brooks) (11/28/90)
water@wheaton.UUCP (Paul Waterman) writes: >The summary line says it all. If I recall correctly, in February there >was a post that said that version 5.0 of conquer was already in beta >testing. Then, a little later, there was a post that proclaimed that >conquer version 5.0 would be coming out over the summer. At the end of >the summer, a post stated that it would be out in about two months. It's still in Beta. The author is still working on this enormous project, but had a programming lapse for a couple of months. Apparently he wanted to escape to the "real" world for a while (-; >Guys, it's been longer than that. Care to update us on what's going on >with version five? Will it ever come out? Will any messages that I >send to the author ever be answered? Its should be soon now. From what I have heard from Adam Bryant, he has massively reorganized large portions of the code. In addition, all the new features are still being worked in. >No flame intended. I'm just in an interesting mood, and have a horde >of gamers here waiting for version five. Keep waiting! If you havent already seen Conquer 5.0 (PL2) Beta, it looks absolutely awesome. I cant wait for a playable version. If you haven't heard of Conquer at all, grab a copy of Conquer 4.0 (Patchlevel 10). It is far and away the best/most-portable UNIX war-strategy game available in the PD so far, IMHO. If you want to subscribe to the conquer mailing list, contact the mailing list at "conquer-news@cs.bu.edu" or for beta testing information, contact "conquer-beta@cs.bu.edu". -- dean@coplex.UUCP Dean A. Brooks Copper Electronics, Inc. Louisville, Ky UUCP: !uunet!coplex!dean
adb@cs.bu.edu (Adam Bryant) (11/28/90)
+ From: dean@coplex.UUCP (Dean Brooks)
+ Newsgroups: comp.sources.games.bugs
+ Date: 27 Nov 90 17:49:46 GMT
+
+ If you want to subscribe to the conquer mailing list, contact the
+ mailing list at "conquer-news@cs.bu.edu" or for beta testing information,
+ contact "conquer-beta@cs.bu.edu".
One quick correction on the addresses. Those are both the addresses
for the actual mailing lists, and while they will get the job done,
they will also get your message sent to more people than you intended.
Send your subscription requests either directly to me, or to
'conquer-news-request@cs.bu.edu'. Specify which mailing list your
would wish to join (general conquer news, or version 5 beta
information) or both, and I will place you on the proper list(s).
BTW, I neglected to mention before that the ftp site for conquer is
cs.bu.edu (128.197.2.1). Version 4.10 may be found in:
conquer/conquer.tar.Z
And the beta release of version 5 (currently at patch 2, wait a week
or two for the next update) is in:
conquer/beta/conquer.tar.Z
Sorry for the excess of messages on this topic.
Later,
adam
--
Adam Bryant INTERNET: adb@cs.bu.edu
Conquer Hack'n'Slasher BITNET: adb@buenga
list: conquer-news-request@cs.bu.edu UUCP: ...!harvard!bu-cs!adbkeithh@bwdls40.bnr.ca (Keith Hanlan) (11/29/90)
In article <ADB.90Nov26161923@cs.bu.edu> adb@cs.bu.edu (Adam Bryant) writes: >In article <2413@wheaton.UUCP> water@wheaton.UUCP (Paul Waterman) writes: > >Right now I am attempting to remedy that by reworking the source into >a more organized form so that I can more easily code it. I hope you are still soliciting input. I've made some annotations and some additional suggestions. I hope you find some of them useful. >The current status of development: > > - Version 5.x is a full rewrite of conquer, from the ground up. > This was done to allow an unlimited number of nations, armies, > navies, etc. through the use of new dynamic structures. I look forward to seeing the new game. > - There are now more display and highlight options. I can guess that you have probably already incorporated these but the modes I'd find useful include the following: o highlight for a specific country, not necessarily yourself. o highlight specific types and sets of armies (say all except scouts or all troops with flight...) > - There are now more magical powers. [32 per class instead of 32 total]. Perhaps you can let the player choose the power - either make it an compile option or offer the player the choice of a random selection for N Talons or a personally selected one at 2N Talons. > - The world is cylindrical. [Wraps when moving east or west] Errr... Why not wrap the horizontal edges too? If the world is cylindrical, it will still give too much defensive advantage to those countries at the North or South edges and too much expansion advantage to the others. > - Map coordinates are now relative. [Capitol of each nation is 0,0. > This make nation cooperation more realistic.] As long as there remains a method for changing to absolute reference so that players can still communicate. I'm not sure what you mean by "make nation cooperation more realistic" - on Earth, we use absolute (referred to the planet) lattitude and longitude. I'm not sure I follow what you are getting at here. Also, the idea of dealing with negative co-ordinates strikes me as an unnecessary user complication. Also, don't forget that capitols can be moved. All hell could break loose then if you make each country's capitol the centre of his own universe. > - Raw materials are stored within city sectors and are usable only > on a local level, so they must be transported via caravans. Great idea (we thought of it too :-)) Are goods automatically transported to the nearest city? Or do goods have to be transported from each and every production centre every single turn? This may be realistic but it is certainly going to make the game a hell for large countries. > - The code is written using ANSI C, and automatically provides > prototyping for those compilers which support it. > - The mailing system is greatly enhanced and is much more usable > than the prior version. Can it be configured to use a native mail system (such as unix mail) if the user chooses? > - A more advanced, built in pager provides an easier method for > examining the documentation. Great! > - The documentation is now written in roff source using macros which > handle output for both online and hardcopy. Preformated online > and hardcopy ready (postscript) documentation will be distributed > during the official release for those sites without roff. [nroff, > troff, or psroff] Great! > - The data file will automatically use compress and zcat (or a > system equivalent) if your system supports it. This results in a > 10 to 1 compression ratio, which can be rather handy. Can you turn this on/off at compile time? (Personally, I don't care what the data size is) > - The compilation options which may affect the data file are grouped > together within the header.h file and are obviously marked to > allow better control of the compilation. > - The size of the world can now be 256x256 (or even greater if a > proper compilation option is set). For this version, the location > values and maps sizes are carefully monitored, and overflow is > prevented. Great! > - The number of army units can be either > 250 (unsigned char to > hold the unit id number) or basically unlimited (unsigned short to > hold the unit id number) [default]. This is also a compilation option. Great! > - The world generator is much more robust, with nicer looking land > and water formations. Great! - display the production value of each sector: o the talons produced in the sector and the quantity of good (jewels/metal/food) produced o as additional (optional?) information displayed on the right-hand column for the current sector o in a printed report for each owned sector. o perhaps this could be an auxilary curses window that could be popped up at the press of a botton ((i)nfo for example). This would alleviate the need to manually calculate all the formalae detailed in the documentation. This window, as opposed to the extra information at the right edge, could also include such figures as projected civilian growth. - military extended commands should be expanded to include (D)isband - display of armies should be sorted by troop type instead of army number - smarter NPC nations? - better movement: So far, my biggest gripe has been the problem with nomads and other 'rape-and-pillage' groups. I'd like to see an update mechanism whereby nations can actually run down these murderous bastards. In particular, I'd like to see nations run into each other in the middle of movement. For example, say A and B are armies belonging to nations at war with each other. Now if A follow path one and B follows path two with the numbers representing 1/10's of movement completed: path one: path two: 0 2 . . . . . . . . 8 10 . . 4 6 . . . . . 6 . . . . . . 8 10 . . 2 . . . . . . . . . . 0 . . . . then the armies should collide midway through the season and, assuming the armies' statuses are appropriate, a battle should occur. In order for this to work easily for both the user and you, the programmer, I'd like to suggest the following convention: - adopt a 400 day year with 100 day seasons. - record movements on a sector by sector basis. - Each single unit of movement takes 100/(total-movement-of-army) days. - When an army passes through a sector with movment cost M, it will be considered to reside in that sector for 100M/(total-movement-of-army) days. - If, during any given day, both A and B reside in the sector, a battle resolution must occur. - battle resolution occurs exactly as normal. - Thus instead of performing movements and then battles on a seasonal basis, do it on a daily basis. - going to a daily increment opens up other interesting possibilities such as the weather on the day of battle. - you may choose to set army status to reflect that they should attempt to disengage from combat if intercepted. - If A is faster than B and is in a defensive mode, B should not be able to engage A in combat unless it successfully 'ambushes' A. An ambush requires a certain number of days of lead time to arrange and it there is always a chance that it can be noticed and then another chance that it can be avoided. I hope you find some of these ideas useful. >And there are a bunch of other things which I can't think of right now >which have been written into the new version. > >The things which I will complete before I post to comp.sources.games: > > - Add a user customization system. [.conqrc file] Great! > - Write the loading system for raw materials onto navies and > caravans. [Caravans are new land based transports] > - Write the magical power perusal / purchasing screen. [Almost > finished with this] > - Add a new combat system which will allow multi-way battles to take > place. Great! (But think very very carefully about the heuristics you use!) > - Add more spells and a new spell casting method. [Almost completed] Great! >So far the source code is much larger than version 4.x and it has been >written about 85 to 90 percent from scratch with the rest coming from >yanked 4.x code and some external contributions. Hopefully, I will be >able to get a fully functional version done by January, with the bugs >worked out a month or two after that. I'm looking forward to it! Keep up the great work! >Sorry for all of the delay (I guess I was a bit of an optimist), but I >only have two hands. :-) > >adam >p.s. The beta code in the file "conquer/beta/conquer.tar.Z" should be >updated in about a week, but I can't guarantee anything. *sigh* Keith Hanlan keithh@bnr.ca Bell-Northern Research, Ottawa, Canada 613-765-4645