public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Lincoln Peters <sampln@sbcglobal.net>
To: Xconq list <xconq7@sources.redhat.com>
Cc: xconq-developers@lists.sourceforge.net,
	 xconq-general@lists.sourceforge.net
Subject: Developer release of knightmare.g
Date: Mon, 03 Jan 2005 08:31:00 -0000	[thread overview]
Message-ID: <1104741096.402.269.camel@localhost.localdomain> (raw)

I've finally gotten knightmare.g to a point where I think it's ready for
release, at least in beta form.  You can download it at:

http://homepage.mac.com/lmpeters/knightmare.g

I hope to add even more features prior to releasing v1.0, but I know
that at least one person on this list has been eagerly awaiting a
developer release.

Some changes that have occurred since this game was last discussed on
the list:

* There are no longer multiple age categories of each type of dragon.
This caused two major problems: I couldn't figure out a reasonable (and
playable) way to make them grow more powerful, and I started getting
weird logic errors when I tried to implement the most powerful dragons
(which exceeded 20th level).  I may try again later.  Fortunately, with
a total of 274 units, I doubt anyone will miss them too much.

* Orc and kobolds no longer exist, as they proved to be either redundant
or pretty much useless (and I had to do a bit of trimming at one point
when I had to do an almost complete re-write of the GDL code).  Maybe
I'll re-introduce them before v1.0.

* I re-engineered the process by which a side acquires monstrous units.
Dragons are now produced by temples corresponding to their alignment
(lawful, chaotic, good, evil), and require extra advanced to be build
(the "Dragonkind" advance and at least one form of elemental magic).
Undead are now produced by "death temples", and there are now "life
temples" that can produce many natural (?) monsters that would otherwise
only be available by capturing or conjuring a lair specific to that
monster.


A few Xconq bugs that I uncovered while developing this module (all of
them have been posted at SourceForge):

* When a city or temple upgrades by changing type, the new type has a
longer reach than the old type.  However, the reach of the unit is
unchanged.  This drastically slows their growth.

* When a change-type occurs, the affected unit seems to lose materials
in the process.  Although with the supply and economy systems in place,
this bug may be hard to pin down.


I would encourage people to test this game and send me bug reports,
feature requests, comments, or anything else that would help me to
improve the game.

---
Lincoln Peters
<sampln@sbcglobal.net>

By protracting life, we do not deduct one jot from the duration of death.
		-- Titus Lucretius Carus

             reply	other threads:[~2005-01-03  8:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03  8:31 Lincoln Peters [this message]
2005-01-03 22:48 ` Elijah Meeks
2005-01-03 23:36   ` Lincoln Peters
2005-01-03 23:54     ` Elijah Meeks
2005-01-04  2:22     ` Eric McDonald
2005-01-04  2:00 ` Eric McDonald
2005-01-04  4:40   ` Lincoln Peters
2005-01-04 20:24     ` Elijah Meeks
2005-01-04 21:24       ` Lincoln Peters
2005-01-05  1:10         ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1104741096.402.269.camel@localhost.localdomain \
    --to=sampln@sbcglobal.net \
    --cc=xconq-developers@lists.sourceforge.net \
    --cc=xconq-general@lists.sourceforge.net \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).