Re: [all] Modern Development

Hallvard B Furuseth wrote:
Andrew Sidwell writes:
Xiong Changnian wrote:
* Define a standard API that meets the needs of all variants.
I fell into the trap you describe. I tried to figure this out. But
there is no API that will meet the needs of all variants. (And here
follows one of the "proofs of impossibility" you mentioned, from a
technical rather than gameplay perspective -- Andrew Doull did the latter.)

It would be interesting to see what this turned into before you gave up,
and what the showstoppers were (like the ones you list below). Do you
have any code or notes left from the exercise?

Well, quite a bit of the current code already has near-universal status
among variants. i.e. the basic inventory handling code, and the
low-level stuff (z-term, z-rand, ...).

I have nothing left over from it, but I spent a long time thinking about
it. I agree with the basic idea that it is good to have reusable
components, and that's one of the goals of current V development. I
don't agree that it will ever be practical to separate essential
gameplay components.

Here is a somewhat different approach (partly repeating what others have
said)...

I expect the biggest possible mistake would be to try to define
something so general that supposedly any variant can use it for
everything.

I understand that this is what Xiong is talking of. Hence my objection.

Better to shoot for that as some remote goal which isn't
intended to be ever reached, and just keep down the number of places
variants must modify the code.

Sounds good to me.


And I expect a major problem is that "API" here means "C API", and C is
not flexible. People have mentioned Lisp (langband) and Lua - good
tries, but it won't succeed unless the various maintainers like the
language. Also with langband, _everything_ must rewritten in Lisp...
C++ might be a bit better in this regard, despite the "yuck" factor.

Actually, Langband has some C code left, if I recall, or did in the
past. It's dead, though.

Or just pick specific parts of the code which can be described by a
language. Invent a simple language for that and a compiler which turns
it into tables, or C code, or whatever. Probably C code, and allowing
code in that language to contain chunks of C code, so variant
maintainers can insert C code for stuff the language doesn't support.
(Of course a cleaner solution would be for the variant maintainer to
extend the language, but that might make the task more difficult.
Though the language could slowly grow with such features.)

In the C code in the rest of Angband, I expect various hooks might be
useful. Macros/functions that are called at various places, some of
them #defined by compiling stuff written in some language.

And I suppose the difference between language and "angband library" can
be a bit vague.

I don't really understand the benefit of writing your own language, or
what it gains you over just branching a C file as it is. AFAICS, you
end up with a file that has to be compiled either way, except one is in
a well-understood language and the other isn't.

If you want a nice scripting language, there are a fair few about: Lua,
Python, whatever. I don't think there's a need to reinvent the wheel...

Take defining stats as an example. Does your game have six stats, four
stats, and what do they mean? Does it have secondary stats (i.e.
Fighting/Stealth), and how do these two stats interact with the combat
system? How do they interact with the inventory capacity? How does an
inventory system that makes uses of variable-size backpacks interact
with a stat system that expects to be able to set capacity based on
strength?

The first ones sound hairy, but I what's the problem with the latter?
Fixed-size backpack is a subset of variable-size backpack.

Triggering a change when strength is reduces gets hairier, but if you
define "events" which are invoked when various things change (in
practice just macros called at those times), the variant can #define the
strength-reduction macro to call the "check if pack is too heavy"
routine.

My real point here was to show the complexities when you get things
interacting. Yes, you can abstract things away enough to make
chop'n'change /possible/ at that level of granularity, but it doesn't
gain you anything much at all. You can't just add a new backpack system
and have things automatically balanced for it; any change ripples
outwards. So changing the backpack system may require changing item
weights, or adding new items, or whatever. You can keep these systems
in their own little boxes and pretend they're not all interconnected in
weird and wonderful ways, but they are, so you're going to a lot of
effort for some theoretical gain.

Then, assuming your UI is also modular, how do you make the UI
understand that you can display six stats on the main screen and two on
a character screen? How does the GUI assemble things in such a way as
to create a character screen at all? You need serious glue code, and
what's more, you need someone to write it for every combination of modules.

Definitely sounds like the "define a language/format" kind of thing.
(Which picks up what is displayed and defines event handlers from when
these things change.)

Well, exactly. You need glue code to hold this stuff together, and you
need it in oodles.

Then, what if you want to implement area-effects that occur over a
period of time (i.e. stinking cloud that lasts) and the API doesn't let
you do anything other than display terrain features and monsters over
the top of them?

Time for code surgery. Not a problem, as long as you don't feel locked
to the API.

It is a problem if you're constrained by an API. There is some point at
which the utopian vision breaks down into the nitty-gritty of the fact
that you can't significantly generalise gameplay mechanics, and you then
have to fork the code.


I am entirely in favour of coding in a more agile way; releasing more
often, getting more people on board, simplifying, unifying, documenting,
making it easier for people who want to make changes. I am in favour of
starting from the current base which already has interopability of UI
modules, fairly easy-to-replace line-of-sight calculations, and
well-defined APIs for various other low-level things, not to mention is
cross-platform.

I just really don't see the benefit of starting over.

(I happen to think the best way to a roguelike engine is essentially
writing the game in a dynamic language, e.g. Lua. Then variants can
override things at runtime in the all the right places. Trying to do
this in C, well, good luck. :)


Andrew Sidwell
--
http://angband.rogueforge.net/ -- the new home of Angband
http://entai.co.uk/projects/angband/opensource -- the GPL initiative

My email address changes monthly, and is the first three letters of the
month (in English), followed by the last two digits of the current year,
@entai.co.uk.
.

Relevant Pages

  • Re: java.util.zip Limitations
    ... language, believing less is more. ... With Java, the "API" is so large, and growing, it is approaching the ... ZipFile cannot be used ... right to "demand" reasonable behavior from the language developers, ...
    (comp.lang.java.programmer)
  • Re: java.util.zip Limitations
    ... language, believing less is more. ... With Java, the "API" is so large, and growing, it is approaching the ... ZipFile cannot be used ... right to "demand" reasonable behavior from the language developers, ...
    (comp.lang.java.programmer)
  • Re: How to get the current input language
    ... If you are referring to the language on a client pc, ... the only way I know of is to use an api. ... Dim oDW ' as object ... Dim sBuffer ' as string ...
    (microsoft.public.scripting.wsh)
  • Re: Just one more anecdote
    ... >> Marshall Spight wrote: ... I can model real world objects with sets, such as a purse. ... >> affect the APIs I'll be using (that I think you are calling a language, ... >> haven't seen a respectable API for this feature in any SQL-DBMS tools. ...
    (comp.databases.theory)
  • Re: Some questions; SHMenuBar, multilingual prog
    ... It's possible that any given API is specific to a given device or class ... > and the VCE language reference. ... one for German and one for English. ... I compile and get German, then enter a symbol for the resource ...
    (microsoft.public.windowsce.embedded.vc)
Loading