A couple of days ago, I finally managed to understand SSCrawl' 0.3.4's combat
model.  (Basically, high AC [damage reduction] is flaky even with heavy armor,
and it is very much not to be relied on for light-armor characters.  EV
corresponds to *band AC.)

So...time to write a metaduel simulator that I can use to try to balance both
SSCrawl and *bands.  But...which language?  C++ is out this time (don't have the
exact classes I need already developed).

The current candidates: Perl, Python (familiar), Lua (zero-knowledge, but had no
trouble installing) and Haskell (zero-knowledge; HUGS prebuilt binary, as
neither HUGS nor nhc98 install from C sources unmodified on my system.  This is
expected for nhc98.)

The ideal implementation language would
* let me define the game-specific functions in a file included/required/whatever
into the file defining the actual emulator
* have a clean emulation of 2-d arrays  (or arrays of arrays) that has
reasonable behavior when updated. (Neither Perl nor Python does, otherwise I'd
have already started.  Perl loses on syntax, Python on internal implementation.)

On 27 maalis, 08:37, Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com>
wrote:

What the heck are you talking about? You make classes
by what we developers call 'programming'.

Did you ate bad mushroom?

On Mar 27, 8:31 pm, Krice <pau...@mbnet.fi> wrote:

LOL - Nice post Krice

A.

On 2008-03-27 08:31:48, Krice <pau...@mbnet.fi> wrote:

I like my non-library C++ to have the expressiveness of Haskell, LISP, and
related languages.  This takes some work.

It's only an educated guess that a 4th-generation language is going to take less
time to bootstrap for this case.

On 27 maalis, 15:48, Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com>
wrote:

Well good luck with Haskell or Lisp. Those languages just rule
and everyone is making roguelikes with them.

Would you like to elaborate on what you mean with 'clean emulation of
2-d arrays'?

Krice, meet point. Point, meet Krice. I know you've never met each
other before, but I'm sure you'll get along just fine.

On this particular thread, he isn't talking about writing a roguelike;
he's talking about writing a tool for analysing the combat systems of
roguelikes.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
 \  /  are you the teachers of my heart? we teach old hearts to break
  \/    --- Leonard Cohen, "Teachers"

It seems that the classes you want are trivial. A class that
encapsulates 2D arrays with a nice syntax is easy enough, do you need
help with that? I'd only try a project like that on an unknown
language as a learning experience, never expecting to actually finish
it with all of the features I wanted.

Jotaf

On 2008-03-27 19:41:50, "jrareg...@gmail.com" <jrareg...@gmail.com> wrote:

I want:
* no worse than log-n access time in each dimension
* merely accessing doesn't cause unwarranted garbage collection
* assignment by value doesn't cause unwarranted garbage collection
* an access syntax that looks like one of point-value or dereferencing an array
twice.

If it only fully instantiates elements I actually access, that's even better but
not critical.

The basic acceptable approaches are a hash keyed by 2-d points (the hitpoints of
the player and the monster in the duel) or an array of arrays.

Perl:
* requires all elements of either an array, or a hash, to be scalars.
**  A hash keyed by 2-d points would have to go through string concatenation to
both create and parse the keys.  (Barely acceptable as string operations are
cheap in Perl, but keep in mind that Perl has two layers of memory allocation.)
**  A Perl array of arrays is actually an array of references to arrays, and the
syntax for this is in your face when coding.

Python:
* By design, cannot update an immutable sequence in place: the *whole* prior
sequence must be garbage collected.  The only mutable sequence (Python 2.5,
although generally true for earlier versions) is the list, which would be
expected to have some   sort of linear access time.  This strongly biases
against a sequence of sequences (array of arrays) implementation.
* has a reasonable tuple for representing n-d points, favoring a dictionary
(hash) implementation.  [A 2-element list is even better as the temporary could
be updated in-place, but lists are not allowed as dictionary keys.]  Tuples are
immutable objects, with the obvious consequences for garbage collection.

Lua:
* I have almost no clue about this language.  This would be an intentional
learning exercise.
* I think tables correspond to hashes (and arrays).  I suspect a table of tables
implementation may be cleaner than a table mapping some representation of
points, but don't have a good idea what a clean direct point representation
would be.  I expect actual element updates to be reasonably efficient.

Haskell:
* I have almost no clue about this language.  This would be an intentional
learning exercise.
* I don't see any data structure correponding to hashes, and have little idea
what the backend does in updating an array of arrays.

Kaya's arrays fit this one, I think.

Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com> writes:

arr[x][y]

In most cases this is true.

This would probably still apply, of course.

The implementation is array of arrays (you can do a hash keyed on a
pair of ints instead if you want, but the syntax is nowhere near as
nice).

--
Chris

On 2008-03-27 20:29:27, jota...@hotmail.com wrote:

Agreed.

No.

I need help understanding which language is not going to actively fight me when
actually coding this.  See other reply for what kind of analysis I'm doing.  I
have to be at least non-fluent in the language to do it right, so I only trust
my own analyses for Perl and Python.  Both Perl and Python are going to actively
fight me when implementing this.

I have already ruled out Oz (algorithm does not have a reasonable
non-deterministic rewrite), LISP (only lists as data structure) and ML
(prejudiced against modules rather than varying source files).  I'm willing to
consider any other fourth-generation language that both
* can handle at least one of hashes or arrays of arrays
* either knows natively what a loop data structure is, or supports
constant-space arbitrary depth recursion.

I prefer languages that have at least one implementation that should bootstrap
from one of C or C++, but this is not a requirement.

This is a feature-complete mini-project.  If this were C/C++, I would consider
this stage of project completed with a well-defined main() [the per-duel
configuration would be handled by an included header.]  A later stage would
involve programmatically generating that included header; that is as open-ended
as you suggest.