[CCI] Roguelike Engines - why do they fail?

Archived from groups: rec.games.roguelike.development (More info?)

Hello all,

Many of you might have heard I started working on a new project (that
is not GenRogue ;-) ) recently, codenamed Carceri. Carceri has three
major goals:

1) Be a prelude to GenRogue's universe -- it will present some basic
setting information on GenRogue
2) Be a simple straightforward dungeon crawl -- which also means that
it will be not so realistic, and slightly powergaming oriented
3) Be an engine on which base one can create a dungeon crawl roguelike.

In this post (article?) I want to focus on point number 3.

Let's face the sad truth -- there *are* good roguelike engines out
there, but sadly nobody uses them to make games. I've browsed through a
lot of Roguelike Engine projects, and have finaly made up my mind on
*why* nobody uses them, and why I didn't use any of them in particular.

I'm going to talk about three subjects, that either are, or might be
considered Roguelike engines : T-Engine, H-World and Angband.

Let's talk about Angband first, and especialy about why I chose it as
an example. Well, Angband (FAngband particulary) was the beginning of my
voyage in the roguelike world. It was not quite long afterwards when I
discovered Angband info files, and the amount of variants out there. I
was stormed with the vision of my own variant (I didn't have the idea of
developing my own game then, yet) and jumped right into. But no matter
how many monsters I changed, no matter how many items I changed, it was
still Angband -- the same feel, the same items, the same shops, the same
monsters. Angband's database is *HUGE*. To make a full mod it takes
months. And you can't just cut out all the monsters you don't like
(especialy if they form 97% of the list). I wanted to make a Variant
that is shorter and more focused. Less items/monsters etc. Angband
didn't allow me to reduce that scale. Too bad.

Now we have ToME, you say. Well, I downloaded it and... don't know
where to start. ToME is bloated as much as original Angband is. There is
no "Rogue" skeleton there, just tons of data and lua scripts... Also,
maybe I'm a poor searcher (or didn't have much dedication), but I
couldn't run ToME in the traditional TextMode.

H-World, ToME and JRE also share a common problem too -- they advertise
that you can change almost everything thanks to all-powerful Lua (or
Java classes in case of JRE). But hell! Lua, Java or any other scripting
language you can think of is a *computer language*! If I can learn to
write in that language, why not make my own game in a language I fully
admire instead? You answer -- because you have already a foundation, and
need to add just additional scripts -- My answer - I can download any
roguelike sourcecode in my own language and do that as well. Neither
Lua, nor any other scripting language gives you (as a engine-based game
maker) much power. The reason why scripting is so popular in the
commercial game market is the fact, that

-- people don't want to be forced to recompile the whole huge game
because of a minor change
-- companies don't want to release the source code

Most potential modders are to lazy to learn a new script language, or
just don't want to mess with that. Info files are a lot greater thing
(Angband's were great) if only they would be more customizable and scalable.

Scripting is not the answer to everything.

Also, most game-engines boast that you can change their game logic by
for example overriding the attack procedure. Of course you can, but how
much work will that be? Modders would rather prefer a set of premade
rule possibilities that they could choose from and tinker with.

The third great problem with contemporary roguelike engines is the lack
of a simple, yet *complete* example. And mainly it's the lack of a
decent example *at all*. Most of the roguelike engine programmers focus
on adding additional functionality to the engine, and just add a single
instance of it into the sample game just for show. The sample games are
*unplayable*. How can a potential modder believe a good gae can be made
with that engine, if he doesn't see anything good written in it? RE
developers tend to think that if they make a enough great engine, then
modders will start to pop up from everywhere. WRONG. Of course this
doesn't apply to T-Engine which was build around a finished/playable
game, but it's own problem is the fact that you can't *easily* scale
down the original to a functional project. DarkGod -- if you want
T-Engine to be a seriously compelling to the general public, do ROGUE
with it. And make it available for download as a single, small, self
contained package.

Another problem, this time only with the I make a game and by the way
an engine approach is the lack of interface customizability. The first
thing a new modder like myself would like to change when creating a new
game is.... guess. The intro screen. The intro screen sets mood
immidately. Also the color scheme. Etc.

Well, that's why I decided to write Carceri. To right all that I
consider wrong in these approaches. To sum up, these are the design
goals of Carceri's engine part:

* module-driven -- a module is a game. Download modules (single files)
into you r module directory, and at start choose the module. Eachg
module will have it's own hall of fame, score file and saves.
* simple -- no need to create a 100-level giogantic dungeon game. You
can make a 5 level cofeebreak roguelike instead. Also this is a dungeon
crawl, you won't have to worry about possibilities you would never want
to use.
* functional -- a playable and enjoyable game will be written with it
-- Carceri
* completely data-driven -- if there will arise a need for scripts they
will be ridiculously simple based on a trigger approach similar to
StarCrafts editor.
* scalable -- Carceri Game will be written in it (which will be huge)
but also a simple game like Rogue will be available for download (or
already in the download package).
* interface-modifiable -- things like intro-screen, end-game screen,
mid-game screens all will be modifiable, as will the color scheme and
other atmosphere-related data.
* self-explanatory -- the data files will be enough clean to jump right
into editing. A full mod of the Rogue game could be done in an hour.
* rulesets -- decisions about game-logic will be able to be made by
changing a single flag in the modules ini files.

Phew. Back to coding for me. A first working version of Carceri might
be available after Summer break.

Nb. I once posted here (a long time ago) a post crying that I have
no proper name for GenRogue. Well it has finally got a proper name ;-)
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"It must be excellent code -- Mistress Compiler would not have
it any other way." -- Twisted One
160 answers Last reply
More about roguelike engines fail
  1. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:
    > Hello all,

    Hi, I am just snipping sentences out of context,
    and whack at them. Dont have time for a full response.

    >[RLE]but sadly nobody uses them to make games.
    There is at least 3 quite well featured games for T-Engine.

    >[Angband]And you can't just cut out all the monsters you don't like
    Bzzzt, that is what Steamband did.

    >Angband didn't allow me to reduce that scale.
    True, my variant 50band ( angband in 50 levels ) just doesnt scale
    well.

    >[Tome]There is no "Rogue" skeleton there
    There is the Scroll skeleton that has all you need

    >Also, maybe I'm a poor searcher
    Affirmative ;)

    >(or didn't have much dedication)
    Confirmed ;)

    >but I couldn't run ToME in the traditional TextMode.
    Did you ask any one ? This is a bizarre request you know ;)

    >If I can learn to write in that language, why not make my own game in a
    >language I fully admire instead?
    Hmmm, because I/O is already there ( for all major and a lot of minor
    platforms, perfected over the ages ), because FOV is there, because
    level generators are there ( if you want them ), because there is a
    good RNG implementation, because there is an efficient(!!) data
    structure for representing items,player, monsters etc. Basically
    because not everybody likes to reinvent the wheel ( hint hint )

    > Neither Lua, nor any other scripting language gives you (as a engine-based
    >game maker) much power.
    That can usually be blamed on a lack of hooks and creativity of the mod
    maker.
    Just look at what can be done with Kyle's Quest for example.

    >The third great problem with contemporary roguelike engines is the lack of a simple, yet *complete* example.
    Scroll for T-Engine.

    >The first thing a new modder like myself would like to change when creating a new
    > game is.... guess. The intro screen.
    Yes ? You can do this even in Angband, there is an ASCII text file for
    that,
    some color coded text file for ToME.

    > * completely data-driven -- if there will arise a need for scripts they
    > will be ridiculously simple based on a trigger approach similar to
    > StarCrafts editor.
    Okay, so how do I create my own level generators ??
    How do I create non-simple quests, how do I create a guild ( with
    ranking system ),
    how do I ... Either your data files will be bloated because you
    anticipate everything,
    or they will be too restrictive.

    <Large snip>

    Now for something constructive : I think perfection ( like beauty ) is
    in the eye of the beholder. So write your re for your target audience (
    you ? , rgrd ? ) and all will be well.

    >
    > Nb. I once posted here (a long time ago) a post crying that I have
    > no proper name for GenRogue. Well it has finally got a proper name ;-)

    Ah, on that topic I tried to subscribe to a GenRogue mailing list, but
    no
    reply came. Am I blacklisted, does the list not exist any more or are
    you
    getting too many requests to be added to this list ;)

    > --
    > At your service,
    > Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    > "It must be excellent code -- Mistress Compiler would not have
    > it any other way." -- Twisted One
  2. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:

    <snip>

    I think you really should consider adding in scripting support. Even
    if you don't like it, it's relatively simple to add, and will net you
    a larger user-base.

    Lua is a relatively clean, simple language, and has good Pascal
    support (or so I've been told), and it's really easy to get working.

    By all means, go with your datafile approach, but it couldn't hurt to
    tie in a scripting language. It could only help. That way,
    everyone's happy. Someone who wants to create a quick module over the
    weekend still can, and someone who wants to create a complex,
    scriptable adventure, can do it too.

    If your engine is designed flexibly in the first place, then I'm
    assuming the engine abstracts all game actions. In which case, it's a
    simple matter to hook all those functions into Lua, and, voila, you
    have a scriptable game.

    But, that's all just my opinion. I definitely find your
    datafile-driven approach to be appealing, but to remove all scripting
    capabilities as well just seems silly. I think part of the joy of
    engine building, is to see people do things with your engine, that you
    never thought of yourself. I don't think you'll be surprised a whole
    lot if you restrict modding to datafile tinkering only.


    --
    Read more about my three projects, SoulEaterRL,
    Necropolis, and a little toy RL.

    http://www.freewebs.com/timsrl/index.htm

    --
  3. Archived from groups: rec.games.roguelike.development (More info?)

    >> Hmmm, because I/O is already there ( for all major and a lot of minor
    >> platforms, perfected over the ages ), because FOV is there, because
    >> level generators are there ( if you want them ), because there is a
    >> good RNG implementation, because there is an efficient(!!) data
    >> structure for representing items,player, monsters etc. Basically
    >> because not everybody likes to reinvent the wheel ( hint hint )
    >
    >I've got Valkyrie for all that. And so will any Pascal developer in the
    >future. I could do Valkyrie in C++, but I don't like C++ ;-).

    I hope you're kidding. *cough* Mac OS X *cough* ;)

    T.
  4. Archived from groups: rec.games.roguelike.development (More info?)

    >>>> for all major and a lot of minor platforms, perfected over the ages
    >>>I've got Valkyrie for all that.
    >>I hope you're kidding
    >Hmpf
    ;)

    T.
  5. Archived from groups: rec.games.roguelike.development (More info?)

    Hey! Just a few quick comments...

    I'm quite interested in what the new version of ToME will look like.
    The current one has a lot of impressive options, though the
    documentation is way to sparse. It's difficult to get started in
    adding anything (or was last I checked). I agree - if it could be used
    to make simple games, and had some simple examples, it would be a huge
    benifit. If it had a library of different rule-sets, it would even be
    more cool. At moment though, it's more difficult to get started with
    it then it is to start making one from scratch it seems - like you
    said, scripting isn't enough, since you need to learn it, and the API,
    when it's almost the same as learning code.

    ALMOST though - I still think there are a lot of benifits to Lua, just
    depends greatly on the style it is used in, and what it's job is.


    Kornel Kisielewicz wrote:
    >
    > Good Pascal support? Wow. I never heard that. Anyway, it won't support
    > FPC classes I guess. Anyway, I don't like Lua, Lua looks too much like C
    > ;-D. If only I could embed Ruby, that would be another matter ;-).

    Ruby is embeddable, though I don't know if it can be done with Pascal.
    I used to love Pascal, it does as good as C most of the time. Nothing
    wrong with using what works. (C++/C#/Lua are now my favs)

    >
    > If someone want's to create a complex scriptable adventure, he can go
    > ahead and download Valkyrie and Carceri sources (they will be available
    > somewhere in the future) and go ahead. If he does know enough Lua to
    > write a "complex scriptable adventure" he surely can add Lua support to
    > the game, or learn FreePascal.

    That's true enough. I think one of the biggest attractions to Lua is
    the garbage collection, and lack of pointers though. It provides a low
    bar of entry for programming. If the hosting app provides good hooks,
    everything works well. There ARE of course complexities - if you want
    to allow people to add extra variables and such, it gets to be a pain
    for the host app. Nothing requires that though.

    WITHOUT those, or with limitations on those, it can be very easy to
    make a quick mod with it. I have a relatively low amount of code
    released for Lua (Egoboo, and RandEgoboo, EgoMap), but I was convenced
    early on that if crafted properly, Lua can save a huge amount of time.
    Especially if you auto-generate all of your bindings.

    Anyways. That's off topic. Data-driven is an excellent method. It
    provides for a way to modify the game in a limited way. Working within
    a set of limitations can provide for some more interesting results then
    having unlimited ones.

    > I am surprised at some of the possibilities that open already ;-).
    > Anyway, to have that sort of pleasure I need audience that wants to
    > write mods to my game. Lua-scripting audience has ToME and H-World, and
    > I'm not willing to go into so much work on Carceri as Hajo and DarkGod
    > did on ToME (I'd much more like to focus on GenRogue) so Carceri will be
    > never able to compete with those. To gain an audience tough I need to
    > appeal to a different group of modders -- to those who don't want to
    > learn/use scripting. And believe me, there are people like that.

    One thing about the current Lua available engines - Last I looked, they
    all took a fairly abstract approach to binding Lua to the game. It
    works, and that's the first way I originally did things. There's other
    ways that make lua more object-oriented, which makes things a LOT
    easier and more intuitive. It provides an Elegant look and use of
    script. Characters end up being self contained scripts, which is
    really a hibred of data-driven, and optional event-response. It's the
    best of both worlds. If done right, and with autogenerating bindings,
    it can be done faster even.

    Example:
    http://cvs.sourceforge.net/viewcvs.py/zippy-egoboo/egoboo/objects/chest.obj/script.lua?rev=1.1&view=auto

    I agree - a lot of people will like the data-driven approach though.
    If a few different rules are available for mixing and matching, a "new"
    feeling game can be made. If it's focused mostly towards
    action/dungeon crawling, it should work pretty nice. A lot like RPG
    Maker and those other kits.

    It just strikes me that coming up with a full data-file format is
    almost the same amount of work as making a scripting language, though
    much more limited in possibilities. (which, as mentioned previously,
    is sometimes a good thing - less ambition means more concentration on
    feel instead of features/simulation)

    Good luck on your new project!
  6. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz a écrit :
    > Hello all,
    >
    > Many of you might have heard I started working on a new project
    > (that is not GenRogue ;-) ) recently, codenamed Carceri. Carceri has
    > three major goals:
    >
    > 1) Be a prelude to GenRogue's universe -- it will present some basic
    > setting information on GenRogue
    > 2) Be a simple straightforward dungeon crawl -- which also means
    > that it will be not so realistic, and slightly powergaming oriented
    > 3) Be an engine on which base one can create a dungeon crawl roguelike.
    >
    > In this post (article?) I want to focus on point number 3.
    >
    > Let's face the sad truth -- there *are* good roguelike engines out
    > there, but sadly nobody uses them to make games. I've browsed through a
    > lot of Roguelike Engine projects, and have finaly made up my mind on
    > *why* nobody uses them, and why I didn't use any of them in particular.
    >
    > I'm going to talk about three subjects, that either are, or might be
    > considered Roguelike engines : T-Engine, H-World and Angband.
    >
    > Let's talk about Angband first, and especialy about why I chose it
    > as an example. Well, Angband (FAngband particulary) was the beginning of
    > my voyage in the roguelike world. It was not quite long afterwards when
    > I discovered Angband info files, and the amount of variants out there. I
    > was stormed with the vision of my own variant (I didn't have the idea of
    > developing my own game then, yet) and jumped right into. But no matter
    > how many monsters I changed, no matter how many items I changed, it was
    > still Angband -- the same feel, the same items, the same shops, the same
    > monsters. Angband's database is *HUGE*. To make a full mod it takes
    > months. And you can't just cut out all the monsters you don't like
    > (especialy if they form 97% of the list). I wanted to make a Variant
    > that is shorter and more focused. Less items/monsters etc. Angband
    > didn't allow me to reduce that scale. Too bad.
    >
    > Now we have ToME, you say. Well, I downloaded it and... don't know
    > where to start. ToME is bloated as much as original Angband is. There is
    > no "Rogue" skeleton there, just tons of data and lua scripts... Also,
    > maybe I'm a poor searcher (or didn't have much dedication), but I
    > couldn't run ToME in the traditional TextMode.
    >
    > H-World, ToME and JRE also share a common problem too -- they
    > advertise that you can change almost everything thanks to all-powerful
    > Lua (or Java classes in case of JRE). But hell! Lua, Java or any other
    > scripting language you can think of is a *computer language*! If I can
    > learn to write in that language, why not make my own game in a language
    > I fully admire instead? You answer -- because you have already a
    > foundation, and need to add just additional scripts -- My answer - I can
    > download any roguelike sourcecode in my own language and do that as
    > well. Neither Lua, nor any other scripting language gives you (as a
    > engine-based game maker) much power. The reason why scripting is so
    > popular in the commercial game market is the fact, that
    >
    > -- people don't want to be forced to recompile the whole huge game
    > because of a minor change
    > -- companies don't want to release the source code

    There are other reasons too :
    - Using a script language, modders don't have to worry about code
    portability and providing binaries for all the concerned platforms
    - Scripts can be made to work inside a sandbox and so, you can create a
    "download and play" functionality in the game without major security risks.
    - Game programers prefer to program in high level high quality but
    somewhat slow languages as much as possible and so, all the non critical
    code is ported to the scripts :) Of course, it's not like lua is a great
    language itself but there is worse and it sure beats C for a lot of tasks.

    > Most potential modders are to lazy to learn a new script language,
    > or just don't want to mess with that. Info files are a lot greater thing
    > (Angband's were great) if only they would be more customizable and
    > scalable.
    >
    > Scripting is not the answer to everything.

    Unfortunatel yes. You can't have Angband like configuration files but
    more customizable and scalable or they will became a defacto low level
    hidden programing language. This is the worse situation.

    > Also, most game-engines boast that you can change their game logic
    > by for example overriding the attack procedure. Of course you can, but
    > how much work will that be? Modders would rather prefer a set of premade
    > rule possibilities that they could choose from and tinker with.
    >
    > The third great problem with contemporary roguelike engines is the
    > lack of a simple, yet *complete* example. And mainly it's the lack of a
    > decent example *at all*. Most of the roguelike engine programmers focus
    > on adding additional functionality to the engine, and just add a single
    > instance of it into the sample game just for show. The sample games are
    > *unplayable*. How can a potential modder believe a good gae can be made
    > with that engine, if he doesn't see anything good written in it? RE
    > developers tend to think that if they make a enough great engine, then
    > modders will start to pop up from everywhere. WRONG. Of course this
    > doesn't apply to T-Engine which was build around a finished/playable
    > game, but it's own problem is the fact that you can't *easily* scale
    > down the original to a functional project. DarkGod -- if you want
    > T-Engine to be a seriously compelling to the general public, do ROGUE
    > with it. And make it available for download as a single, small, self
    > contained package.
    >
    > Another problem, this time only with the I make a game and by the
    > way an engine approach is the lack of interface customizability. The
    > first thing a new modder like myself would like to change when creating
    > a new game is.... guess. The intro screen. The intro screen sets mood
    > immidately. Also the color scheme. Etc.
    >
    > Well, that's why I decided to write Carceri. To right all that I
    > consider wrong in these approaches. To sum up, these are the design
    > goals of Carceri's engine part:
    >
    > * module-driven -- a module is a game. Download modules (single
    > files) into you r module directory, and at start choose the module.
    > Eachg module will have it's own hall of fame, score file and saves.
    > * simple -- no need to create a 100-level giogantic dungeon game.
    > You can make a 5 level cofeebreak roguelike instead. Also this is a
    > dungeon crawl, you won't have to worry about possibilities you would
    > never want to use.
    > * functional -- a playable and enjoyable game will be written with
    > it -- Carceri
    > * completely data-driven -- if there will arise a need for scripts
    > they will be ridiculously simple based on a trigger approach similar to
    > StarCrafts editor.

    :(

    > * scalable -- Carceri Game will be written in it (which will be
    > huge) but also a simple game like Rogue will be available for download
    > (or already in the download package).
    > * interface-modifiable -- things like intro-screen, end-game screen,
    > mid-game screens all will be modifiable, as will the color scheme and
    > other atmosphere-related data.
    > * self-explanatory -- the data files will be enough clean to jump
    > right into editing. A full mod of the Rogue game could be done in an hour.
    > * rulesets -- decisions about game-logic will be able to be made by
    > changing a single flag in the modules ini files.
    >
    > Phew. Back to coding for me. A first working version of Carceri
    > might be available after Summer break.
    >
    > Nb. I once posted here (a long time ago) a post crying that I have
    > no proper name for GenRogue. Well it has finally got a proper name ;-)
  7. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe wrote:
    > Kornel Kisielewicz a écrit :
    >> -- people don't want to be forced to recompile the whole huge game
    >> because of a minor change
    >> -- companies don't want to release the source code
    >
    >
    > There are other reasons too :
    > - Using a script language, modders don't have to worry about code
    > portability and providing binaries for all the concerned platforms

    Agreed. But also unimportant in case of a RE.

    > - Scripts can be made to work inside a sandbox and so, you can create a
    > "download and play" functionality in the game without major security risks.

    Agreed. And unimportant in case of a RE.

    > - Game programers prefer to program in high level high quality but
    > somewhat slow languages as much as possible and so, all the non critical
    > code is ported to the scripts :) Of course, it's not like lua is a great
    > language itself but there is worse and it sure beats C for a lot of tasks.

    Well, I prefer FreePascal to any scripting language ;-).

    >> Scripting is not the answer to everything.
    >
    >
    > Unfortunatel yes.

    Unfortunately no ;-).

    > You can't have Angband like configuration files but
    > more customizable and scalable or they will became a defacto low level
    > hidden programing language.

    Prove it. What's your reasoning behind this? Also, maybe you can't have
    full modding capabilities in a just data-driven architecture, but you
    *can* make progress compared to Angband. And many people do like the
    fact that Angband caan be changed just by changing the data-files -- so
    there's room for improvement, and there's an audience.

    GenRogue will also be data-driven. But to a far greater extent. I do
    have a few ideas on that, that havn't showed in any of the projects I
    saw. I'll also risk he statement, that only a fully data-driven
    architecture can provide us with the so-demanded dreamlike randomness of
    the world.

    >> * completely data-driven -- if there will arise a need for scripts
    >> they will be ridiculously simple based on a trigger approach similar
    >> to StarCrafts editor.
    >
    > :(

    Well, so tell me, why can't you assemple a roguelike quickly with ToME
    or H-World? Also, as I previously stated -- there's an audience, and
    there's room for improvement on that.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Gott weiss, Ich will kein Engel sein..." -- Rammstein /Engel/
  8. Archived from groups: rec.games.roguelike.development (More info?)

    konijn_ wrote:
    > Kornel Kisielewicz wrote:
    >
    >>Hello all,
    >
    > Hi, I am just snipping sentences out of context,
    > and whack at them. Dont have time for a full response.

    It's so easy to cut something out of context and then whack at it ;-P

    >>[RLE]but sadly nobody uses them to make games.
    >
    > There is at least 3 quite well featured games for T-Engine.

    Well? Show me them. And:

    -- Won't I be feeling like playing ToME when playing them?
    -- Is there any game that's definitvely smaller then ToME?
    -- Where is the discussion about them, the YASDs, the YAVPs?
    -- Prove to me that they are at least as popular as DoomRL (which isn't
    much)
    -- I don't talk about ToME variants, I talk about roguelike games.

    >>[Angband]And you can't just cut out all the monsters you don't like
    >
    > Bzzzt, that is what Steamband did.

    So? How much work was it after cutting all those monsters out to make
    the game playable again? If I cut out 95% monsters will Angband be still
    playable?

    >>Angband didn't allow me to reduce that scale.
    >
    > True, my variant 50band ( angband in 50 levels ) just doesnt scale
    > well.

    Now scale it to 20 screen sized levels.

    >>[Tome]There is no "Rogue" skeleton there
    >
    > There is the Scroll skeleton that has all you need

    Ok found it (not to mention the fact that it was hidden). It's no Rogue
    skeleton. It's just like Angband. I want 20 screen-sized levels. Scroll
    is still bloated with Angband stuff.

    By skeleton I mean the amount of data a single person is able to
    completely reedit in a single weekend.

    >>Also, maybe I'm a poor searcher
    >
    > Affirmative ;)

    Hiding the modules in the wiki section seems completely irrational.

    >>but I couldn't run ToME in the traditional TextMode.
    >
    > Did you ask any one ? This is a bizarre request you know ;)

    Not bizzare. I want fullscreen. It defocuses me when I have anything
    else on the screen but the game. And I never saw tiles that I wouldn't
    consider ugly.

    >>If I can learn to write in that language, why not make my own game in a
    >>language I fully admire instead?
    >
    > Hmmm, because I/O is already there ( for all major and a lot of minor
    > platforms, perfected over the ages ), because FOV is there, because
    > level generators are there ( if you want them ), because there is a
    > good RNG implementation, because there is an efficient(!!) data
    > structure for representing items,player, monsters etc. Basically
    > because not everybody likes to reinvent the wheel ( hint hint )

    I've got Valkyrie for all that. And so will any Pascal developer in the
    future. I could do Valkyrie in C++, but I don't like C++ ;-).

    >>Neither Lua, nor any other scripting language gives you (as a engine-based
    >>game maker) much power.
    >
    > That can usually be blamed on a lack of hooks and creativity of the mod
    > maker. Just look at what can be done with Kyle's Quest for example.

    ?

    >>The third great problem with contemporary roguelike engines is the lack of a simple, yet *complete* example.
    > Scroll for T-Engine.

    How much more simple is Scroll from Moria or Angband?

    >>The first thing a new modder like myself would like to change when creating a new
    >>game is.... guess. The intro screen.
    >
    > Yes ? You can do this even in Angband, there is an ASCII text file for
    > that, some color coded text file for ToME.

    Why I don't like ToME I already wrote. But nice that there is.

    >> * completely data-driven -- if there will arise a need for scripts they
    >>will be ridiculously simple based on a trigger approach similar to
    >>StarCrafts editor.
    >
    > Okay, so how do I create my own level generators ??

    You don't. You add data to the established dungeon generators (rooms,
    templates, layouts).

    > How do I create non-simple quests, how do I create a guild ( with
    > ranking system ),

    You don't. Carceri is a Dungeon Crawl. And I want a Dungeon Crawl engine.

    > how do I ... Either your data files will be bloated because you
    > anticipate everything, or they will be too restrictive.

    They will be neither. What is not explicitly stated is said to be
    non-existent. That way -- small game - small datafile, big game - big
    datafile. And also you will be able to scale it as you like.

    > <Large snip>
    >
    > Now for something constructive

    Ah, at last!

    > : I think perfection ( like beauty ) is
    > in the eye of the beholder.

    Someone wrote that on RGRD already ;-).

    > So write your re for your target audience (
    > you ? , rgrd ? ) and all will be well.

    The target audience is at least three people ;-). Since I learned about
    roguelikes I wanted to pull up a simple roguelike myself set in the
    universe of Shadows. Seeing how much engines there are I was full of
    hope but it turned out that none of those could accept a Rogue-size
    scale, nor would not demand programing skills. And all I realy wanted
    was a persistent-level, 20 level, screen-sized Angband. With maybe a few
    additions. There wasn't. I had no choice but to learn a programming
    language. And that's the reason I became a computer scientist :-D (ok
    I'm pushing it here). My target audience is people who want to come up
    with a new setting during the weekend and quickly make it into an
    interesting playable dungeon hack game. Or the ones who have plenty
    ideas for a setting, and want to make a huge dungeon crawl.

    Mind you -- Carceri is not meant for complicated plot, quests, overland,
    cities, etc . And because of this narrowing down of it's target use,
    it has chances of success.

    > Ah, on that topic I tried to subscribe to a GenRogue mailing list, but
    > no reply came. Am I blacklisted, does the list not exist any more or are
    > you getting too many requests to be added to this list ;)

    Oh, the gr-dev list is not open yet. Anyway subscribing is by sending
    the maintainer a mail with the reason why you want to join, anyway. The
    group will be an unpublic one, and will deal with things that aren't
    supposed to leak out.

    "Some thing's just cannot be programmed in a roguelike. For
    everything else, there's GenRogue ;-P
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    Carceri -- A prelude to GenRogue... Coming Soon
  9. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > Kornel Kisielewicz wrote:
    >
    > <snip>
    >
    > I think you really should consider adding in scripting support. Even if
    > you don't like it, it's relatively simple to add, and will net you a
    > larger user-base.

    I would have to add another target audience. And adding that other
    target audience would mean adding a *lot* of other stuff. And that would
    mean reducing the chance to complete Carceri. Creating roguelikes,
    except for vaporware-dreamlike-Genroguelikes is the art of compromise.

    > Lua is a relatively clean, simple language, and has good Pascal support
    > (or so I've been told), and it's really easy to get working.

    Good Pascal support? Wow. I never heard that. Anyway, it won't support
    FPC classes I guess. Anyway, I don't like Lua, Lua looks too much like C
    ;-D. If only I could embed Ruby, that would be another matter ;-).

    > By all means, go with your datafile approach, but it couldn't hurt to
    > tie in a scripting language. It could only help.

    You wan't to see Carceri finished? Do you? ;-P

    > That way, everyone's
    > happy. Someone who wants to create a quick module over the weekend
    > still can, and someone who wants to create a complex, scriptable
    > adventure, can do it too.

    If someone want's to create a complex scriptable adventure, he can go
    ahead and download Valkyrie and Carceri sources (they will be available
    somewhere in the future) and go ahead. If he does know enough Lua to
    write a "complex scriptable adventure" he surely can add Lua support to
    the game, or learn FreePascal.

    > If your engine is designed flexibly in the first place, then I'm
    > assuming the engine abstracts all game actions. In which case, it's a
    > simple matter to hook all those functions into Lua, and, voila, you have
    > a scriptable game.

    It's not action driven. It's data driven.

    > But, that's all just my opinion. I definitely find your datafile-driven
    > approach to be appealing, but to remove all scripting capabilities as
    > well just seems silly. I think part of the joy of engine building, is
    > to see people do things with your engine, that you never thought of
    > yourself. I don't think you'll be surprised a whole lot if you restrict
    > modding to datafile tinkering only.

    I am surprised at some of the possibilities that open already ;-).
    Anyway, to have that sort of pleasure I need audience that wants to
    write mods to my game. Lua-scripting audience has ToME and H-World, and
    I'm not willing to go into so much work on Carceri as Hajo and DarkGod
    did on ToME (I'd much more like to focus on GenRogue) so Carceri will be
    never able to compete with those. To gain an audience tough I need to
    appeal to a different group of modders -- to those who don't want to
    learn/use scripting. And believe me, there are people like that.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "From what I've read, a lot of people believe that GenRogue
    exists and will be released some day" -- Arxenia Xentrophore
  10. Archived from groups: rec.games.roguelike.development (More info?)

    konijn_ wrote:
    >>>Hmmm, because I/O is already there ( for all major and a lot of minor
    >>>platforms, perfected over the ages ), because FOV is there, because
    >>>level generators are there ( if you want them ), because there is a
    >>>good RNG implementation, because there is an efficient(!!) data
    >>>structure for representing items,player, monsters etc. Basically
    >>>because not everybody likes to reinvent the wheel ( hint hint )
    >>
    >>I've got Valkyrie for all that. And so will any Pascal developer in the
    >>future. I could do Valkyrie in C++, but I don't like C++ ;-).
    >
    > I hope you're kidding. *cough* Mac OS X *cough* ;)

    Hmpf? Sorry, I don't get it. My knowledge about Macs and related stuff
    is very limited.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    My opinions are my own. Share them at your own risk.
  11. Archived from groups: rec.games.roguelike.development (More info?)

    konijn_ wrote:
    >>>>>for all major and a lot of minor platforms, perfected over the ages
    >>>>
    >>>>I've got Valkyrie for all that.
    >>>
    >>>I hope you're kidding
    >>
    >>Hmpf
    >
    > ;)

    Ah, Mac OS X is no problem -- I had a friend run a Valkyrie test program
    on Mac OS X. It worked fine. Classic Macintosh may prove a problem, I
    don't know wether FP supports it. But for Linux, FreeBSD, Mac OS X,
    Darwin, DOS, Win32, OS/2, Novell NetWare, BeOS, NetBSD, AmigaOS it
    should compile without any modifications. Contrary to C++, FreePascal is
    quite portable y'know ;-). Core Valkyrie only uses two libraries -- FPC
    Keyboard and FPC Video, both of which are compatible on all FPC
    supported platforms. There are optional bindings for OpenGL, SDL Video,
    SDL Input, SDL Sound and FMOD, which portability has yet to be proven,
    but considering the portability of those libraries themselves I guess
    they will be portable (except MIDI playback unfortunately). Oh, and
    PalmOS for FP will be probably available, though I'm sure that would
    need several modificaions to Valkyrie, so I don't know wether it's worth
    it. As for the rest of the systems I doubt there'a a sufficient player
    base to be worrying about that...
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "The name of GenRogue, has become a warning against excessively
    complex design." -- RGRD FAQ
  12. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > But you know that I can't make games

    Why not?:)

    > If you ask me, H-World suffered from:
    > - too much work required for the graphics
    > - too complex data structures
    > - too complex scripting interface
    > - too complex file/module structures
    > - insufficient documentation
    > - lack of user level editing tools
    > - bad advertising

    Well, don't all roguelikes suffer from those?:) Except the first one,
    which is only graphical RL issue, and maybe scripting, because not
    all RL's have useless scripting junk... I still think you gave up
    too easily, but on the other hand I can understand if it become too
    much like work.

    > I guess that are enough problems to explain why noone tried/tries to
    > make modules for H-World.

    I think most of us know how hard it is to find people to do something
    for your project. Especially when you just wait for someone to get
    interested. That wont happen easily. You have to - yes, advertise:)
    Well, not just that, but try to find a person to be a part of the
    team and fully responsible for making that game module. Then it would
    probably work better.
  13. Archived from groups: rec.games.roguelike.development (More info?)

    Arakon wrote:
    > Hey! Just a few quick comments...
    >
    > I'm quite interested in what the new version of ToME will look like.
    > The current one has a lot of impressive options, though the
    > documentation is way to sparse.

    Oh, I forgot to mention that a good RE should have a ground up
    novice-leve tutorial :-)


    > It's difficult to get started in
    > adding anything (or was last I checked). I agree - if it could be used
    > to make simple games, and had some simple examples, it would be a huge
    > benifit.

    That's my whole point...


    >>Good Pascal support? Wow. I never heard that. Anyway, it won't support
    >>FPC classes I guess. Anyway, I don't like Lua, Lua looks too much like C
    >>;-D. If only I could embed Ruby, that would be another matter ;-).
    >
    > Ruby is embeddable,

    I know.

    > though I don't know if it can be done with Pascal.

    Probably yes. FreePascal has the sam linking capabilities minus the
    ability to link to C++ classes -- but they're working on it...

    > I used to love Pascal, it does as good as C most of the time. Nothing
    > wrong with using what works. (C++/C#/Lua are now my favs)

    Well, you should try FreePascal ;-). FreePascal to Turbo Pascal is like
    C++ to C...

    > That's true enough. I think one of the biggest attractions to Lua is
    > the garbage collection, and lack of pointers though.

    A data-driven engine won't have neither pointers nor the need for
    garbage collection y'know ;-).

    > Anyways. That's off topic. Data-driven is an excellent method. It
    > provides for a way to modify the game in a limited way. Working within
    > a set of limitations can provide for some more interesting results then
    > having unlimited ones.

    You're the only one to notice that up to date ;-).

    > I agree - a lot of people will like the data-driven approach though.
    > If a few different rules are available for mixing and matching, a "new"
    > feeling game can be made. If it's focused mostly towards
    > action/dungeon crawling, it should work pretty nice. A lot like RPG
    > Maker and those other kits.

    Yes.

    > It just strikes me that coming up with a full data-file format is
    > almost the same amount of work as making a scripting language, though
    > much more limited in possibilities. (which, as mentioned previously,
    > is sometimes a good thing - less ambition means more concentration on
    > feel instead of features/simulation)

    I want to make Carceri a testing ground for the new GR data-engine. GR
    design now encompasses a ridiculous amount of data-drivism, but I'm not
    sure wether it will work out well. But I may be on the edge of a
    revolution in my programming style... I'll give you just one example,
    try to imagine -- Data Driven Quests...

    > Good luck on your new project!

    Thank you :-)
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "It's much easier to make an army of dumb good people than to
    make one single smart good guy..." -- DarkGod
  14. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > I like to build sandboxes, areas, toys to play around in and with. This
    > is somewht similar to games, but not exactly games. Players seem to miss
    > tasks, guidelines, quests, at least I get that from teh past discussions.

    The actual gameplay content is very small in most roguelikes anyway,
    they are more sandboxes than games.
    My project Kaduria is also a sandbox stuff all the way:) I might add
    some quests just for the sake of it, but it's same scale as in
    Nethack for example: "fetch the amulet". Wow.. talk about game
    content:)

    > I'm not sure. H-World is definitely more complex in regards of the item
    > and monsters that structures than e.g. Angabdn or Nethack. I really
    > think it makes a difference.

    Maybe you could find a way to handle that complexity easier? I found
    out that abstracting things and data to higher level is better than
    trying to handle all objects separately.

    > I've been working 3 1/3 years on H-World. I don't think you can say I
    > gavce up too early

    I think that way, because H-World was looking so promising.
    I guess I'm different kind of person and can't understand that.

    > I should have stopped when the first complaints came in

    Maybe you are too sensitive about those comments. I have got
    comments about Kaduria, like that I will never finish it etc.
    I couldn't care less about comments like that.

    > I'm pretty sure my decision as right. I'm very sure that the next years
    > I'll not write any programs at all. I spent way too much time on
    > Simutrans and H-World in the past.

    The scale of those projects are large. You should really try to
    make a simple game (like classic Tetris:) if you haven't tried
    that before.

    > contacts to people who told me to be intersted but at the point when
    > they should have started working, they all disappeared.

    I know:) I have twice promised to make graphics to some projects,
    but it didn't work. There can be a lot of reasons. I think people
    just find something else to do and/or they loose their interest.
    Also, teams that are formed on internet aren't as good as real
    developer teams, where you work together in the same place.
  15. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:
    >
    > > I used to love Pascal, it does as good as C most of the time. Nothing
    > > wrong with using what works. (C++/C#/Lua are now my favs)
    >
    > Well, you should try FreePascal ;-). FreePascal to Turbo Pascal is like
    > C++ to C...

    It is too late for me now.. I've been corrupted by templates, multiple
    inheritence, and all of the base tools I use. It's nice to see it's
    still alive though.

    > > That's true enough. I think one of the biggest attractions to Lua is
    > > the garbage collection, and lack of pointers though.
    >
    > A data-driven engine won't have neither pointers nor the need for
    > garbage collection y'know ;-).

    That's true.. but you're also severely limited, even compared to a
    strict script implementation. Example - you have items that are used,
    and want to temporarilly adjust attributes. With data files, you could
    just specify a few. With a script, you could have it based on formulas
    linked to other attributes.

    Of course, the trick is: With a script implementation, everyone wants
    to over-enginier it, and make it so that -anything- can be done in that
    event response. They want it so each item can add it's own needed
    attributes, or create special time-based effects in script, etc.
    That's where development time is eaten, and complexities are added, and
    game play is never a focus.

    > > Anyways. That's off topic. Data-driven is an excellent method. It
    > > provides for a way to modify the game in a limited way. Working within
    > > a set of limitations can provide for some more interesting results then
    > > having unlimited ones.
    >
    > You're the only one to notice that up to date ;-).

    It makes sense to me. I've noticed it myself on personal projects. If
    I spend time developing a freeform engine, I have too many choices of
    what I -can- implement, and get caught up in all of the mechanics
    options for game instead of just choosing one and making it work well.

    > > It just strikes me that coming up with a full data-file format is
    > > almost the same amount of work as making a scripting language, though
    > > much more limited in possibilities. (which, as mentioned previously,
    > > is sometimes a good thing - less ambition means more concentration on
    > > feel instead of features/simulation)
    >
    > I want to make Carceri a testing ground for the new GR data-engine. GR
    > design now encompasses a ridiculous amount of data-drivism, but I'm not
    > sure wether it will work out well. But I may be on the edge of a
    > revolution in my programming style... I'll give you just one example,
    > try to imagine -- Data Driven Quests...
    >

    Data Driven Quests... Do you have some more ideas on that?
    The system that Joseph Hewitt was working on for the superhear game
    (Nova City?) seems to fit the bill pretty good. It seems like it would
    be coupled well with a strong scripting system though. :-)

    I'd be interested to hear more though?

    Would you just hard-code the different plot "types", and then have data
    files to configure parts (dialog, etc?) ? I've experimented with this
    method a little bit, and have had some success. It's based in Lua of
    course, but it'd be similar in a full language (Your point, from what I
    understand).
  16. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote::

    > The third great problem with contemporary roguelike engines is the
    > lack of a simple, yet *complete* example.

    You know that I can't do that. I hoped for someone else to provide a
    good example game for H-World but noone did.

    Anyways, the project is dead now. So it doesn't matter if engines are
    bound to fail or not :P

    I've learned a lesson, the hard way again, but surely I learned it well.
    I'll not make the same mistake again.

    --
    c.u. Hajo
  17. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:
    > Hello all,
    >
    > Many of you might have heard I started working on a new project
    > (that is not GenRogue ;-) ) recently, codenamed Carceri. Carceri has
    > three major goals:
    >
    > 1) Be a prelude to GenRogue's universe -- it will present some basic
    > setting information on GenRogue
    > 2) Be a simple straightforward dungeon crawl -- which also means
    > that it will be not so realistic, and slightly powergaming oriented
    > 3) Be an engine on which base one can create a dungeon crawl roguelike.
    >
    > In this post (article?) I want to focus on point number 3.
    >
    > Let's face the sad truth -- there *are* good roguelike engines out
    > there, but sadly nobody uses them to make games. I've browsed through a
    > lot of Roguelike Engine projects, and have finaly made up my mind on
    > *why* nobody uses them, and why I didn't use any of them in particular.
    >
    *SNIP*
    > H-World, ToME and JRE also share a common problem too -- they
    > advertise that you can change almost everything thanks to all-powerful
    > Lua (or Java classes in case of JRE). But hell! Lua, Java or any other
    > scripting language you can think of is a *computer language*! If I can
    > learn to write in that language, why not make my own game in a language
    > I fully admire instead? You answer -- because you have already a
    > foundation, and need to add just additional scripts -- My answer - I can
    > download any roguelike sourcecode in my own language and do that as

    I don't think this is it - H-World does actually save you a lot
    of work and gives faster results than the sourcecode option.

    > well. Neither Lua, nor any other scripting language gives you (as a
    > engine-based game maker) much power. The reason why scripting is so

    Patent nonsense in H-World's case... there is lots of power, in
    fact probably too much (see below).

    > popular in the commercial game market is the fact, that
    >
    > -- people don't want to be forced to recompile the whole huge game
    > because of a minor change
    > -- companies don't want to release the source code

    It's way easier for non-programmers.

    > Most potential modders are to lazy to learn a new script language,
    > or just don't want to mess with that. Info files are a lot greater thing
    > (Angband's were great) if only they would be more customizable and
    > scalable.

    Which is when it becomes a scripting language - or at least the
    same as one.

    > Scripting is not the answer to everything.

    It is not scripting that hurts H-World popularity in my view.
    Max Payne was not hurt by scripting for instance. H-World does
    however sit uncomfortably at the complex end of modding in which
    programmers will use their own language instead, and the basic
    user finds it too hard - thus thinning its audience to those right
    in the middle.

    You seem anti-scripting personally and so your views seem skewed.
    You also suggest a data file instead, which at a certain point of
    complexity is the same thing (rules are required to be known so that
    values don't break them) on top of a much more limiting structure -
    or worse a kludge with data values to give you more power.

    > Also, most game-engines boast that you can change their game logic
    > by for example overriding the attack procedure. Of course you can, but
    > how much work will that be? Modders would rather prefer a set of premade
    > rule possibilities that they could choose from and tinker with.
    >
    > The third great problem with contemporary roguelike engines is the
    > lack of a simple, yet *complete* example. And mainly it's the lack of a
    > decent example *at all*. Most of the roguelike engine programmers focus
    > on adding additional functionality to the engine, and just add a single
    > instance of it into the sample game just for show. The sample games are
    > *unplayable*. How can a potential modder believe a good gae can be made
    > with that engine, if he doesn't see anything good written in it? RE
    > developers tend to think that if they make a enough great engine, then
    > modders will start to pop up from everywhere. WRONG. Of course this
    > doesn't apply to T-Engine which was build around a finished/playable
    > game, but it's own problem is the fact that you can't *easily* scale
    > down the original to a functional project. DarkGod -- if you want
    > T-Engine to be a seriously compelling to the general public, do ROGUE
    > with it. And make it available for download as a single, small, self
    > contained package.

    Yes H-World would benefit from a good simple template to build a
    basic Angband game on (I started working on such a module). It would
    also benefit from a tutorial and an editor (difficulties in keeping
    that up to date etc).

    > Another problem, this time only with the I make a game and by the
    > way an engine approach is the lack of interface customizability. The
    > first thing a new modder like myself would like to change when creating
    > a new game is.... guess. The intro screen. The intro screen sets mood
    > immidately. Also the color scheme. Etc.
    >
    > Well, that's why I decided to write Carceri. To right all that I
    > consider wrong in these approaches. To sum up, these are the design
    > goals of Carceri's engine part:
    >
    > * module-driven -- a module is a game. Download modules (single
    > files) into you r module directory, and at start choose the module.
    > Eachg module will have it's own hall of fame, score file and saves.
    > * simple -- no need to create a 100-level giogantic dungeon game.
    > You can make a 5 level cofeebreak roguelike instead. Also this is a
    > dungeon crawl, you won't have to worry about possibilities you would
    > never want to use.

    This is probably good - over featured makes H-World more complex
    to mod, more powerful, but more complex - thus the double edged
    sword.

    > * functional -- a playable and enjoyable game will be written with
    > it -- Carceri
    > * completely data-driven -- if there will arise a need for scripts
    > they will be ridiculously simple based on a trigger approach similar to
    > StarCrafts editor.
    > * scalable -- Carceri Game will be written in it (which will be
    > huge) but also a simple game like Rogue will be available for download
    > (or already in the download package).
    > * interface-modifiable -- things like intro-screen, end-game screen,
    > mid-game screens all will be modifiable, as will the color scheme and
    > other atmosphere-related data.
    > * self-explanatory -- the data files will be enough clean to jump
    > right into editing. A full mod of the Rogue game could be done in an hour.

    Challenging to pull off - good luck!

    > * rulesets -- decisions about game-logic will be able to be made by
    > changing a single flag in the modules ini files.

    Again you will find data files limiting - but again if the goal
    is to limit the complexity this will actually work out good.

    > Phew. Back to coding for me. A first working version of Carceri
    > might be available after Summer break.
    >
    > Nb. I once posted here (a long time ago) a post crying that I have
    > no proper name for GenRogue. Well it has finally got a proper name ;-)

    One suggestion to prove your engine functionality - write DoomRL
    as a module to it!!!! :)

    Sounds really good - look forward to it - "glad you are not
    going"/"remember not to go" for something too lofty!!!

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  18. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > Kornel Kisielewicz wrote:
    >> already a foundation, and need to add just additional scripts -- My
    >> answer - I can download any roguelike sourcecode in my own language
    >> and do that as
    >
    > I don't think this is it - H-World does actually save you a lot
    > of work and gives faster results than the sourcecode option.

    So? Where are all those H-World modules that people keep making?

    >> well. Neither Lua, nor any other scripting language gives you (as a
    >> engine-based game maker) much power. The reason why scripting is so
    >
    > Patent nonsense in H-World's case... there is lots of power, in
    > fact probably too much (see below).

    Oh, you misunderstood me here. I was comparing the power of a scripting
    language to the power of a programming language. Reprogramming ToME
    using Lua to be exactly as DoomRL would be a lot harder then creating
    DoomRL from scratch.

    >> popular in the commercial game market is the fact, that
    >>
    >> -- people don't want to be forced to recompile the whole huge game
    >> because of a minor change
    >> -- companies don't want to release the source code
    >
    > It's way easier for non-programmers.

    Are you realy sure of that? I mean is scripting in QuakeC so much easier
    then programming? Except for the fact that you have a codebase...?

    >> Most potential modders are to lazy to learn a new script language,
    >> or just don't want to mess with that. Info files are a lot greater
    >> thing (Angband's were great) if only they would be more customizable
    >> and scalable.
    >
    > Which is when it becomes a scripting language - or at least the
    > same as one.

    No :-). That's my whole point!

    >> Scripting is not the answer to everything.
    >
    > It is not scripting that hurts H-World popularity in my view.
    > Max Payne was not hurt by scripting for instance.

    But Max Payne was a game people enjoyed, scripting or no scripting.

    > H-World does
    > however sit uncomfortably at the complex end of modding in which
    > programmers will use their own language instead, and the basic
    > user finds it too hard - thus thinning its audience to those right
    > in the middle.

    Just my point.

    > You seem anti-scripting personally and so your views seem skewed.

    No. I'm just doing a pro-data-driven campaign ;-).

    > You also suggest a data file instead, which at a certain point of
    > complexity is the same thing (rules are required to be known so that
    > values don't break them)

    That's the whole point -- they dont :-). As long as you know what each
    variable means -- go ahead, change it.

    >> * module-driven -- a module is a game. Download modules (single
    >> files) into you r module directory, and at start choose the module.
    >> Eachg module will have it's own hall of fame, score file and saves.
    >> * simple -- no need to create a 100-level giogantic dungeon game.
    >> You can make a 5 level cofeebreak roguelike instead. Also this is a
    >> dungeon crawl, you won't have to worry about possibilities you would
    >> never want to use.
    >
    > This is probably good - over featured makes H-World more complex
    > to mod, more powerful, but more complex - thus the double edged
    > sword.

    Carceri is intended to be simple, but powerful in the amount of possible
    variables it gives. For example there will be a *lot* of item/npc/etc
    flags to choose from. It is limited compared to scripting, that you
    can't write your own effect for the item, but is great for easiness and
    speed of mod development...

    >> * self-explanatory -- the data files will be enough clean to jump
    >> right into editing. A full mod of the Rogue game could be done in an
    >> hour.
    >
    > Challenging to pull off - good luck!

    I hope I'll not fail ;-);

    >
    >> * rulesets -- decisions about game-logic will be able to be made
    >> by changing a single flag in the modules ini files.
    >
    > Again you will find data files limiting

    Why?

    > - but again if the goal
    > is to limit the complexity this will actually work out good.

    True. Instead of puzzling how to rewrite that damage routine so it adds
    a pain affect, you just set PainEffect = TRUE; and PainLevel = 3.

    >> Nb. I once posted here (a long time ago) a post crying that I have
    >> no proper name for GenRogue. Well it has finally got a proper name ;-)
    >
    > One suggestion to prove your engine functionality - write DoomRL
    > as a module to it!!!! :)

    I guess this may possible to do that it looks like DoomRL, but
    ruleset-wise they wont be the same, because the easiness and simplicity
    of Carceri requires to use a single "RPG" system.

    > Sounds really good - look forward to it - "glad you are not
    > going"/"remember not to go" for something too lofty!!!

    Well, I hope to maybe see a "Carceri:Beyond" module someday ;-P

    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Kornel just won't release the code because his compiler is a jealous
    mistress and doesn't want any of Kornel's code ever being touched by
    another woman. ;)" -- Twisted One
  19. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-05-27, ABCGi <abcgi@yahoo.com> wrote:
    >> Most potential modders are to lazy to learn a new script language,
    >> or just don't want to mess with that. Info files are a lot greater thing
    >> (Angband's were great) if only they would be more customizable and
    >> scalable.
    >
    > Which is when it becomes a scripting language - or at least the
    > same as one.

    There's actually a formal concept called Turing completeness, which
    basically states whether some language can be considered a programming
    language or not. Scripting languages are programming languages, data
    files are not. A good rule of thumb might be: "If you can make an
    infinite loop in it, it's a scripting language".

    I'm not so sure adding scripting languages to any roguelike is
    necessarily a very easy operation. Let's assume that Nethack would have
    been developed using a scripting language from the very beginning. How
    much script code would it now have? Since Nethack rules are quite
    intertwined, how much would the scripts refer to each other and how easy
    would the scripting language make maintaining all this? How large an
    interface would be needed between the scripts and the core engine, and
    how much maintenance would this interface require? Would it be much
    easier for a novice user to add a script and observe all naming
    conventions, hooking procedures and other implicit best practices
    assumed by the developers to keep the masses of scripts maintainable
    than it would be to just dive straight in the C code?

    I guess the main point is that roguelikes can be innately complex, in
    which case modifiying them is also complex, regardless of the
    availability of a scripting system. I would guess the same complexness
    would make the scripting system hard to maintain and make it an
    attractive idea to keep all game logic in one language.

    --
    Risto Saarelma
  20. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote::

    > ABCGi wrote:
    >
    >> Kornel Kisielewicz wrote:
    >>
    >>> already a foundation, and need to add just additional scripts -- My
    >>> answer - I can download any roguelike sourcecode in my own language
    >>> and do that as
    >>
    >> I don't think this is it - H-World does actually save you a lot
    >> of work and gives faster results than the sourcecode option.
    >
    > So? Where are all those H-World modules that people keep making?

    I made three, maybe four depending on how you count. But you know that I
    can't make games, and finally two of them can't/couldn't/I didn't want
    to be released because of the theme and/or the contents. Although I
    presume that one of them would have attracted a big crowd to the project :P

    But if you really want, you can make new modules quickly. I seriously
    suspect that just noone but ABCGi and maybe Sheep really tried, and
    that's the reason why there are no modules.

    But, it's past. Explanations are a waste of time. H-World didn't get off
    the ground, although I think that only one of the listed reasons really
    holds, but that's maybe enough to cause all the problems.

    If you ask me, H-World suffered from:

    - too much work required for the graphics
    - too complex data structures
    - too complex scripting interface
    - too complex file/module structures
    - insufficient documentation
    - lack of user level editing tools
    - bad advertising

    The first four directly impact the ease of creating new modules, all add
    a some steepness to the early learning curve for users.

    The next two hinder users to be successful quickly.

    I guess that are enough problems to explain why noone tried/tries to
    make modules for H-World.

    --
    c.u. Hajo
  21. Archived from groups: rec.games.roguelike.development (More info?)

    Oh and I hope you are not going to use XML as your
    data file format... I find them very irritating to
    hand edit! And I don't see many benefits to using
    it in this particular case.

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  22. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > Oh and I hope you are not going to use XML as your
    > data file format... I find them very irritating to
    > hand edit! And I don't see many benefits to using
    > it in this particular case.

    "the data files will be enough clean to jump right into editing"
    XML? Come on ;-)

    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Come on, Kornel. 11 years and no binary? And it's not
    vapourware?" -- Mike Blackney
  23. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote::
    > Hansjoerg Malthaner wrote:
    >
    >>But you know that I can't make games
    >
    > Why not? :)

    I like to build sandboxes, areas, toys to play around in and with. This
    is somewht similar to games, but not exactly games. Players seem to miss
    tasks, guidelines, quests, at least I get that from teh past discussions.

    While I think I could add the things, I just don't want to.

    My current conclusiuon is that I don't want to work on things that I
    don't like or need by myself, and if noone likes what I do, it's better
    to do something else.

    >>If you ask me, H-World suffered from:
    >>- too much work required for the graphics
    >>- too complex data structures
    >>- too complex scripting interface
    >>- too complex file/module structures
    >>- insufficient documentation
    >>- lack of user level editing tools
    >>- bad advertising
    >
    > Well, don't all roguelikes suffer from those?:)

    I'm not sure. H-World is definitely more complex in regards of the item
    and monsters that structures than e.g. Angabdn or Nethack. I really
    think it makes a difference.

    Angband and NetHack have big user bases that also mostly have made good
    experiences, so advertising a variant is easy and a lot of people will
    at least stake a look.

    T-Engine seems to have good documentation.

    > Except the first one,
    > which is only graphical RL issue, and maybe scripting, because not
    > all RL's have useless scripting junk... I still think you gave up
    > too easily, but on the other hand I can understand if it become too
    > much like work.

    I've been working 3 1/3 years on H-World. I don't think you can say I
    gavce up too early, particularly in regard to amount of time that I
    spent on the project throughout these yers.

    I think I gave up way too late. I should have stopped when the first
    complaints came in, and it became visible that there is ammismatch
    between my aims and the expectations of most users/players.

    I ignore that for a while; some people here said, I shall do it if I
    like to do it. So I did, as long as there was a t least a little hope
    and fun.

    I'm pretty sure my decision as right. I'm very sure that the next years
    I'll not write any programs at all. I spent way too much time on
    Simutrans and H-World in the past.

    >>I guess that are enough problems to explain why noone tried/tries to
    >>make modules for H-World.
    >
    > I think most of us know how hard it is to find people to do something
    > for your project. Especially when you just wait for someone to get
    > interested. That wont happen easily. You have to - yes, advertise:)
    > Well, not just that, but try to find a person to be a part of the
    > team and fully responsible for making that game module. Then it would
    > probably work better.

    I couldn't find anyone. Maybe I didn't try hard enough, but I had some
    contacts to people who told me to be intersted but at the point when
    they should have started working, they all disappeared.

    You find a lot of people who tell how to do things right. Very few of
    them join you and actually help doing it.

    Also, I'm not really a team leader I guess.

    ABCGi was the one who helped most, actually I think he was the only one
    who used the engine to run his own modules.

    --
    c.u. Hajo
  24. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Fri, 27 May 2005 06:21:49 +0200,
    Kornel Kisielewicz napisal(a):

    > ABCGi wrote:
    >> Kornel Kisielewicz wrote:
    >> You also suggest a data file instead, which at a certain point of
    >> complexity is the same thing (rules are required to be known so that
    >> values don't break them)
    > That's the whole point -- they dont :-). As long as you know what each
    > variable means -- go ahead, change it.

    I think it would be even better if you could change it without knowing
    what it does, and see for yourself, and the change would be obvious.
    Obviously, it's not always possible...

    --
    Radomir @**@_ Bee! The quest for the Real World:
    `The Sheep' ('') 3 Try #2: goto -1
    Dopieralski .vvVvVVVVVvVVVvv.
  25. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote::

    > Hansjoerg Malthaner wrote:

    >>I'm pretty sure my decision as right. I'm very sure that the next years
    >>I'll not write any programs at all. I spent way too much time on
    >>Simutrans and H-World in the past.
    >
    > The scale of those projects are large. You should really try to
    > make a simple game (like classic Tetris:) if you haven't tried
    > that before.

    I made a few remakes of classic games, things that have ben finished in
    a week or two. (It's not that I would doubt my coding skills, and stoped
    H-World/Simutrans becuase of that).

    Two became Java applets and you can try them in a Java enabled browser:

    A simple boulder dash remake:
    http://www.simugraph.com/simutrans/applets/granite/JvGraniteTest.html

    A simple Trailblazer remake:
    http://www.simugraph.com/simutrans/applets/trail/roadblaster.html

    I wanted to see if Java is suitable for games - that's been before 2000
    when computers were much slower and Java much less performant.

    I hope the applet stil work with current Java versions, at least they
    did for me :)

    --
    c.u. Hajo
  26. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner a écrit :
    > Krice wrote::
    >
    >> Hansjoerg Malthaner wrote:
    >
    >
    >>> I'm pretty sure my decision as right. I'm very sure that the next years
    >>> I'll not write any programs at all. I spent way too much time on
    >>> Simutrans and H-World in the past.
    >>
    >>
    >> The scale of those projects are large. You should really try to
    >> make a simple game (like classic Tetris:) if you haven't tried
    >> that before.
    >
    >
    > I made a few remakes of classic games, things that have ben finished in
    > a week or two. (It's not that I would doubt my coding skills, and stoped
    > H-World/Simutrans becuase of that).
    >
    > Two became Java applets and you can try them in a Java enabled browser:
    >
    > A simple boulder dash remake:
    > http://www.simugraph.com/simutrans/applets/granite/JvGraniteTest.html
    >
    > A simple Trailblazer remake:
    > http://www.simugraph.com/simutrans/applets/trail/roadblaster.html
    >
    > I wanted to see if Java is suitable for games - that's been before 2000
    > when computers were much slower and Java much less performant.

    The Boulder dash remake is nearly unplayable here because it's too slow
    and I have far from a slow computer :) I wonder how you could even play
    it in 2000 ! And yes, I'm using a recent Java VM ( 1.4.2 I think )

    > I hope the applet stil work with current Java versions, at least they
    > did for me :)
  27. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe wrote::

    > Hansjoerg Malthaner a écrit :
    >
    >> Krice wrote::

    >> Two became Java applets and you can try them in a Java enabled browser:
    >>
    >> A simple boulder dash remake:
    >> http://www.simugraph.com/simutrans/applets/granite/JvGraniteTest.html
    >>
    >> A simple Trailblazer remake:
    >> http://www.simugraph.com/simutrans/applets/trail/roadblaster.html
    >>
    >> I wanted to see if Java is suitable for games - that's been before
    >> 2000 when computers were much slower and Java much less performant.
    >
    > The Boulder dash remake is nearly unplayable here because it's too slow
    > and I have far from a slow computer :) I wonder how you could even play
    > it in 2000 ! And yes, I'm using a recent Java VM ( 1.4.2 I think )

    I have no idea why it's slow for you, sorry. I developed it on a Pentium
    200 MMX back then, maybe that's a fast machine for you? It surely was
    playable.

    I take note of your findings, but I have no explanation. I'll also not
    take any action, these applet are really long past.

    I feel, I shouldn't have posted those links. I regret it already very much.

    --
    c.u. Hajo
  28. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > Kornel Kisielewicz wrote::
    >
    >> The third great problem with contemporary roguelike engines is the
    >> lack of a simple, yet *complete* example.
    >
    > You know that I can't do that. I hoped for someone else to provide a
    > good example game for H-World but noone did.

    This is as simple as taking a bunch of spoilers for Rogue and
    implementing them to the letter (no pun intended ;-) ).

    > Anyways, the project is dead now. So it doesn't matter if engines are
    > bound to fail or not :P
    > I've learned a lesson, the hard way again, but surely I learned it
    > well. I'll not make the same mistake again.

    I just wanted to make sure Hajo, that you don't take my harsh words in
    this article as aimed against you. I always admired your work, and you
    always stood as an example of profesional approach to me. I'm realy sad
    that you've abandoned H-World. And this article I wrote (and Carceri
    itself) would have never been possible if it weren't for you, for
    H-World, because most of what I learned about engines, and their
    downfall was on H-World's example. Which saved me, and maybe others from
    a similar fate... Thank you, Hajo.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "11 years and no binary. And it's not vapourware" -- Igor Savin
  29. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > Kornel Kisielewicz wrote::
    >
    >> ABCGi wrote:
    >>
    >>> Kornel Kisielewicz wrote:
    >>>
    >>>> already a foundation, and need to add just additional scripts -- My
    >>>> answer - I can download any roguelike sourcecode in my own language
    >>>> and do that as
    >>>
    >>>
    >>> I don't think this is it - H-World does actually save you a lot
    >>> of work and gives faster results than the sourcecode option.
    >>
    >>
    >> So? Where are all those H-World modules that people keep making?
    >
    > I made three, maybe four depending on how you count.

    *You* made. And that doensn't count :-(.

    > But you know that I
    > can't make games, and finally two of them can't/couldn't/I didn't want
    > to be released because of the theme and/or the contents.

    I still believe you live in some kind of delusion that you can't write
    content ;-).

    > Although I
    > presume that one of them would have attracted a big crowd to the project :P

    ?

    > But if you really want, you can make new modules quickly. I seriously
    > suspect that just noone but ABCGi and maybe Sheep really tried, and
    > that's the reason why there are no modules.

    But there must be a reason no one really tried...

    > But, it's past. Explanations are a waste of time.

    No they're not. Maybe for you they are, but I learn from every word you
    say...

    > If you ask me, H-World suffered from:
    >
    > - too much work required for the graphics

    You mean those overlays, that I didn't like?

    > - too complex data structures

    I remember when you first posted your png charts on RGRD. My God, I was
    impressed!

    > - too complex scripting interface
    > - too complex file/module structures
    > - insufficient documentation

    That's what pulled me away from scripting for it :-(.

    > - lack of user level editing tools

    Oh, I don't think that is much of a problem, as long as you can load
    them from text files.

    > - bad advertising

    This one can be helped. Although I will have a much smaller audience,
    for I target only roguelike fans, and you targeted cRPG fans as well.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "It must be excellent code -- Mistress Compiler would not have
    it any other way." -- Twisted One
  30. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > Well, not just that, but try to find a person to be a part of the
    > team and fully responsible for making that game module. Then it would
    > probably work better.

    Oh yes, I seriously second that!
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Some thing's just cannot be programmed in a roguelike. For
    everything else, there's GenRogue" -- Anubis
  31. Archived from groups: rec.games.roguelike.development (More info?)

    >
    >>> * self-explanatory -- the data files will be enough clean to jump
    >>> right into editing. A full mod of the Rogue game could be done in an
    >>> hour.
    >>
    >> Challenging to pull off - good luck!
    >
    > I hope I'll not fail ;-);

    Is this the first 60 Minute Roguelike?
  32. Archived from groups: rec.games.roguelike.development (More info?)

    Lochok wrote:
    >>>> * self-explanatory -- the data files will be enough clean to jump
    >>>>right into editing. A full mod of the Rogue game could be done in an
    >>>>hour.
    >>>
    >>>Challenging to pull off - good luck!
    >>
    >>I hope I'll not fail ;-);
    >
    >
    > Is this the first 60 Minute Roguelike?

    It's rather a 60 day roguelike ;-). But It may be possoble to do some
    clever things with the engine. Who knows maybe I'll make a competition
    for the best microroguelike doe with carceri :-D
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "If hackers will ever use virtual reality, it would show a bunch
    of text terminals floating around them..." -- The Sheep
  33. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:
    > ABCGi wrote:
    >
    >> Oh and I hope you are not going to use XML as your
    >> data file format... I find them very irritating to
    >> hand edit! And I don't see many benefits to using
    >> it in this particular case.
    >
    > "the data files will be enough clean to jump right into editing"
    > XML? Come on ;-)

    eggsactly

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  34. Archived from groups: rec.games.roguelike.development (More info?)

    Kornel Kisielewicz wrote:
    > ABCGi wrote:
    >
    >> Kornel Kisielewicz wrote:
    >>
    >>> already a foundation, and need to add just additional scripts -- My
    >>> answer - I can download any roguelike sourcecode in my own language
    >>> and do that as
    >>
    >> I don't think this is it - H-World does actually save you a lot
    >> of work and gives faster results than the sourcecode option.
    >
    > So? Where are all those H-World modules that people keep making?

    Not only missed my point but managed to insult the honour
    of H-World! I'm saying "I don't think this is" the reason
    it was not popular as an engine. That's all.

    >>> well. Neither Lua, nor any other scripting language gives you (as a
    >>> engine-based game maker) much power. The reason why scripting is so
    >>
    >> Patent nonsense in H-World's case... there is lots of power, in
    >> fact probably too much (see below).
    >
    > Oh, you misunderstood me here. I was comparing the power of a scripting
    > language to the power of a programming language. Reprogramming ToME
    > using Lua to be exactly as DoomRL would be a lot harder then creating
    > DoomRL from scratch.

    hehe true

    >>> popular in the commercial game market is the fact, that
    >>>
    >>> -- people don't want to be forced to recompile the whole huge
    >>> game because of a minor change
    >>> -- companies don't want to release the source code
    >>
    >> It's way easier for non-programmers.
    >
    > Are you realy sure of that? I mean is scripting in QuakeC so much easier
    > then programming? Except for the fact that you have a codebase...?

    Max Payne - case proved - next. True some implementation screw
    it up but the potential is always there to get it right.

    >>> Most potential modders are to lazy to learn a new script
    >>> language, or just don't want to mess with that. Info files are a lot
    >>> greater thing (Angband's were great) if only they would be more
    >>> customizable and scalable.
    >>
    >> Which is when it becomes a scripting language - or at least the
    >> same as one.
    >
    > No :-). That's my whole point!

    No that's my whole point!!!! :)

    >>> Scripting is not the answer to everything.
    >>
    >> It is not scripting that hurts H-World popularity in my view.
    >> Max Payne was not hurt by scripting for instance.
    >
    > But Max Payne was a game people enjoyed, scripting or no scripting.

    Another good point, H-World also needed The Jungle to
    take more notice of suggestions here for improved game
    play. However it is really quite good and has excellent
    potential in that regard.

    >> H-World does
    >> however sit uncomfortably at the complex end of modding in which
    >> programmers will use their own language instead, and the basic
    >> user finds it too hard - thus thinning its audience to those right
    >> in the middle.
    >
    > Just my point.

    You stole my point again :)

    >> You seem anti-scripting personally and so your views seem skewed.
    >
    > No. I'm just doing a pro-data-driven campaign ;-).

    hehe - H-World can actually support scripting that
    is more data driven, you just have the option of
    doing more in scripting if you want. True it would
    take some work to set up (and would involve scripting
    routines) - but you'll have to do programming work for
    that functionality too.

    >> You also suggest a data file instead, which at a certain point of
    >> complexity is the same thing (rules are required to be known so that
    >> values don't break them)
    >
    > That's the whole point -- they dont :-). As long as you know what each
    > variable means -- go ahead, change it.

    Right - so a limit on power and complexity - good.

    >>> * module-driven -- a module is a game. Download modules (single
    >>> files) into you r module directory, and at start choose the module.
    >>> Eachg module will have it's own hall of fame, score file and saves.
    >>> * simple -- no need to create a 100-level giogantic dungeon game.
    >>> You can make a 5 level cofeebreak roguelike instead. Also this is a
    >>> dungeon crawl, you won't have to worry about possibilities you would
    >>> never want to use.
    >>
    >> This is probably good - over featured makes H-World more complex
    >> to mod, more powerful, but more complex - thus the double edged
    >> sword.
    >
    > Carceri is intended to be simple, but powerful in the amount of possible
    > variables it gives. For example there will be a *lot* of item/npc/etc
    > flags to choose from. It is limited compared to scripting, that you
    > can't write your own effect for the item, but is great for easiness and
    > speed of mod development...

    This sounds good...

    >>> * self-explanatory -- the data files will be enough clean to jump
    >>> right into editing. A full mod of the Rogue game could be done in an
    >>> hour.
    >>
    >> Challenging to pull off - good luck!
    >
    > I hope I'll not fail ;-);
    >
    >>> * rulesets -- decisions about game-logic will be able to be made
    >>> by changing a single flag in the modules ini files.
    >>
    >> Again you will find data files limiting
    >
    > Why?

    Since your data values are supported by programming
    "locked" away - the data values can only be used in
    the ways you thought of in advance. With H-World part
    of that programming is also (or can be) exposed thus
    allowing flexibility for the modder (at the expense of
    complexity however as stated previously).

    Again your approach seems amiable for your goals and
    will be more popular as stated.

    >> - but again if the goal
    >> is to limit the complexity this will actually work out good.
    >
    > True. Instead of puzzling how to rewrite that damage routine so it adds
    > a pain affect, you just set PainEffect = TRUE; and PainLevel = 3.

    You can actually do this sort of thing in H-World modules
    too, once the initial work is done. Have you tried making
    a module in H-World - it would be valuable research for
    your project I think for both wrongs and rights. And now
    that the source is available doubly so.

    >>> Nb. I once posted here (a long time ago) a post crying that I
    >>> have no proper name for GenRogue. Well it has finally got a proper
    >>> name ;-)
    >>
    >> One suggestion to prove your engine functionality - write DoomRL
    >> as a module to it!!!! :)
    >
    > I guess this may possible to do that it looks like DoomRL, but
    > ruleset-wise they wont be the same, because the easiness and simplicity
    > of Carceri requires to use a single "RPG" system.

    Yes well, some sort of test where you have to produce two
    different RLs that still fall within your stated goals will
    be an excellent way of keeping you honest. I know when I
    started writing "Beyond H-World" (ironic title) there were
    a whole bunch of requests I made to Hajo that had not been
    needed or at least reached yet with "H-World: The Jungle"
    module.

    >> Sounds really good - look forward to it - "glad you are not
    >> going"/"remember not to go" for something too lofty!!!
    >
    > Well, I hope to maybe see a "Carceri:Beyond" module someday ;-P

    Hahahah - by the sounds of it, it should only take an hour :)
    Now as well as a coffee-break RL you are going to make a
    coffee-brake RL creator!!!! :)

    (the miss spelling is intended)

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  35. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > Kornel Kisielewicz wrote:
    >
    >> ABCGi wrote:
    >>
    >>> Kornel Kisielewicz wrote:
    >>>
    >>>> already a foundation, and need to add just additional scripts -- My
    >>>> answer - I can download any roguelike sourcecode in my own language
    >>>> and do that as
    >>>
    >>> I don't think this is it - H-World does actually save you a lot
    >>> of work and gives faster results than the sourcecode option.
    >>
    >> So? Where are all those H-World modules that people keep making?
    >
    > Not only missed my point but managed to insult the honour
    > of H-World!

    You know how much I admire Hajo's work. And how much I grieve at the
    loss of him as a roguelike developer.

    > I'm saying "I don't think this is" the reason
    > it was not popular as an engine. That's all.

    Ok, sorry, I misunderstood ;-).

    >>> Which is when it becomes a scripting language - or at least the
    >>> same as one.
    >>
    >> No :-). That's my whole point!
    >
    > No that's my whole point!!!! :)

    Gimme me back my point! It's mine! :-P

    >> But Max Payne was a game people enjoyed, scripting or no scripting.
    >
    > Another good point, H-World also needed The Jungle to
    > take more notice of suggestions here for improved game
    > play. However it is really quite good and has excellent
    > potential in that regard.

    I know. But the lack of those elements I mentioned makes it
    non-appealing for modders (at least not as die-hard ones as you ;-) ).

    >>> H-World does
    >>> however sit uncomfortably at the complex end of modding in which
    >>> programmers will use their own language instead, and the basic
    >>> user finds it too hard - thus thinning its audience to those right
    >>> in the middle.
    >>
    >> Just my point.
    >
    > You stole my point again :)

    Ha! And I won't give it back!

    >>> You seem anti-scripting personally and so your views seem skewed.
    >>
    >> No. I'm just doing a pro-data-driven campaign ;-).
    >
    > hehe - H-World can actually support scripting that
    > is more data driven, you just have the option of
    > doing more in scripting if you want. True it would
    > take some work to set up (and would involve scripting
    > routines) - but you'll have to do programming work for
    > that functionality too.

    And that's why a non-programmer wont be able to mod H-World...

    >> That's the whole point -- they dont :-). As long as you know what each
    >> variable means -- go ahead, change it.
    >
    > Right - so a limit on power and complexity - good.

    I don't know wether you wrote this as a sarcasm, but it truly is "good".

    >>>> * rulesets -- decisions about game-logic will be able to be made
    >>>> by changing a single flag in the modules ini files.
    >>>
    >>> Again you will find data files limiting
    >>
    >> Why?
    >
    > Since your data values are supported by programming
    > "locked" away - the data values can only be used in
    > the ways you thought of in advance.

    Yes.

    > With H-World part
    > of that programming is also (or can be) exposed thus
    > allowing flexibility for the modder (at the expense of
    > complexity however as stated previously).

    You know the KISS principle, do you? ;-).

    >> True. Instead of puzzling how to rewrite that damage routine so it
    >> adds a pain affect, you just set PainEffect = TRUE; and PainLevel = 3.
    >
    > You can actually do this sort of thing in H-World modules
    > too, once the initial work is done.

    "...once the initial work is done." -- that's the problem.
    Also in Carceri the Pain feature will be there, already bug-tested and
    somewhat balanced. Isn't that a great asset for a modder?

    >> I guess this may possible to do that it looks like DoomRL, but
    >> ruleset-wise they wont be the same, because the easiness and
    >> simplicity of Carceri requires to use a single "RPG" system.
    >
    > Yes well, some sort of test where you have to produce two
    > different RLs that still fall within your stated goals will
    > be an excellent way of keeping you honest.

    "honest"?

    > I know when I
    > started writing "Beyond H-World" (ironic title) there were
    > a whole bunch of requests I made to Hajo that had not been
    > needed or at least reached yet with "H-World: The Jungle"
    > module.

    Well yes. I plan to make three modules myself -- Carceri the game -- the
    primary complex and huge module, the Rogue module which mimicks
    traditional Rogue, and another small one, that is as different from
    Rogue as possible (maybe even with a tileset instead of ASCII --
    Valkyrie allows that without much hassle). Also my beta-testers will
    make their own modules (people from the outside provide a much better
    feedback especialy in engine construction) -- which is currently one
    great person -- Igor Savin. I may need another dedicated beta tester
    tough. Anyway when the first version of Carceri sees daylight I hope to
    have at least 2-3 different modules to show.

    >>> Sounds really good - look forward to it - "glad you are not
    >>> going"/"remember not to go" for something too lofty!!!
    >>
    >> Well, I hope to maybe see a "Carceri:Beyond" module someday ;-P
    >
    > Hahahah - by the sounds of it, it should only take an hour :)

    Depends on how much content one want's to add :-).

    > Now as well as a coffee-break RL you are going to make a
    > coffee-brake RL creator!!!! :)

    Well... actualy, that's the point :-)

    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "If hackers will ever use virtual reality, it would show a bunch
    of text terminals floating around them..." -- The Sheep
  36. Archived from groups: rec.games.roguelike.development (More info?)

    Risto Saarelma wrote:
    > On 2005-05-27, ABCGi <abcgi@yahoo.com> wrote:
    >
    >>> Most potential modders are to lazy to learn a new script language,
    >>>or just don't want to mess with that. Info files are a lot greater thing
    >>>(Angband's were great) if only they would be more customizable and
    >>>scalable.
    >>
    >>Which is when it becomes a scripting language - or at least the
    >>same as one.
    >
    > There's actually a formal concept called Turing completeness, which
    > basically states whether some language can be considered a programming
    > language or not. Scripting languages are programming languages, data
    > files are not. A good rule of thumb might be: "If you can make an
    > infinite loop in it, it's a scripting language".
    >
    > I'm not so sure adding scripting languages to any roguelike is
    > necessarily a very easy operation. Let's assume that Nethack would have
    > been developed using a scripting language from the very beginning. How
    > much script code would it now have? Since Nethack rules are quite
    > intertwined, how much would the scripts refer to each other and how easy
    > would the scripting language make maintaining all this? How large an
    > interface would be needed between the scripts and the core engine, and
    > how much maintenance would this interface require? Would it be much
    > easier for a novice user to add a script and observe all naming
    > conventions, hooking procedures and other implicit best practices
    > assumed by the developers to keep the masses of scripts maintainable
    > than it would be to just dive straight in the C code?
    >
    > I guess the main point is that roguelikes can be innately complex, in
    > which case modifiying them is also complex, regardless of the
    > availability of a scripting system. I would guess the same complexness
    > would make the scripting system hard to maintain and make it an
    > attractive idea to keep all game logic in one language.

    Interesting thanks...

    Examine the H-World scripting... for such a difficult problem (I
    agree) it is an excellent implementation really.

    One of the other things H-World currently lacks (take note Kornel)
    is a lack of good error and warning reporting. In your case it
    may be errors of invalid values, or warnings of conflicting
    values, or do you realise that boss monster can never be
    defeated etc. :) In H-World's case this takes a very powerful
    scripting language and adds extra time trying to debug it -
    it does do error reporting but it could do it better. For
    instance a pre-validation at load up of the module would be
    good (Max Payne did this and it was invaluable and yet not too
    intrusive).

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  37. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > Interesting thanks...
    >
    > Examine the H-World scripting... for such a difficult problem (I
    > agree) it is an excellent implementation really.
    >
    > One of the other things H-World currently lacks (take note Kornel)
    > is a lack of good error and warning reporting. In your case it
    > may be errors of invalid values, or warnings of conflicting
    > values, or do you realise that boss monster can never be
    > defeated etc. :)

    Yes, I know :-). Most of the time the system is safe -- if someone
    didn't define a value in an entity, it takes an reasonable default. If
    the value is critical then it produces an error at compile time. I try
    to get all the errors at compile time, but I know this is hard :-/. My
    main goal is a little more reasonable -- to make sure the module works
    and wont crash, if you manage to pass the first level.
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    My opinions are my own. Share them at your own risk.
  38. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > Kornel Kisielewicz wrote::
    >
    >> The third great problem with contemporary roguelike engines is the
    >> lack of a simple, yet *complete* example.
    >
    > You know that I can't do that. I hoped for someone else to provide a
    > good example game for H-World but noone did.
    >
    > Anyways, the project is dead now. So it doesn't matter if engines are
    > bound to fail or not :P
    >
    > I've learned a lesson, the hard way again, but surely I learned it well.
    > I'll not make the same mistake again.

    Hopefully Kornel can learn the H-World lessons ahead of time.
    I still think H-World can get somewhere with those improvements
    I've mentioned in the thread, rather than failings of H-World
    I consider them more on it's TODO list now that it is on
    SourceForge :)

    Random points;

    * I did start on that basic Angband module that could be used
    as a template...
    * those other jobs to improve H-World engine are a lot of work
    * There are ways in which the H-World engine kicks
    the ass of the Max Payne engine...
    * You could be very instructive to Kornel in his efforts...

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  39. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > Hansjoerg Malthaner wrote:
    >> I've learned a lesson, the hard way again, but surely I learned it
    >> well. I'll not make the same mistake again.
    >
    > Hopefully Kornel can learn the H-World lessons ahead of time.

    I've already learned a lot. Why do you think I have that "simple"
    aproach built-in, huh? :-)

    > I still think H-World can get somewhere with those improvements
    > I've mentioned in the thread, rather than failings of H-World
    > I consider them more on it's TODO list now that it is on
    > SourceForge :)

    I would love to see you and Sheep keep the project from falling apart...

    > * You could be very instructive to Kornel in his efforts...

    I would love to. But I'm afraid Hajo doesn't want to waste time on RLDev
    anymore, even as a consultant :-(
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "It must be excellent code -- Mistress Compiler would not have
    it any other way." -- Twisted One
  40. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > Kornel Kisielewicz wrote::
    >
    >> ABCGi wrote:
    >>
    >>> Kornel Kisielewicz wrote:
    >>>
    >>>> already a foundation, and need to add just additional scripts -- My
    >>>> answer - I can download any roguelike sourcecode in my own language
    >>>> and do that as
    >>>
    >>> I don't think this is it - H-World does actually save you a lot
    >>> of work and gives faster results than the sourcecode option.
    >>
    >> So? Where are all those H-World modules that people keep making?
    >
    > I made three, maybe four depending on how you count. But you know that I
    > can't make games, and finally two of them can't/couldn't/I didn't want
    > to be released because of the theme and/or the contents. Although I
    > presume that one of them would have attracted a big crowd to the project :P
    >
    > But if you really want, you can make new modules quickly. I seriously
    > suspect that just noone but ABCGi and maybe Sheep really tried, and
    > that's the reason why there are no modules.

    Yep I still have at least three modules on my hard drive;

    * Beyond H-World
    * 2D H-World (as opposed to isometric)
    * H-World Angband template

    > But, it's past. Explanations are a waste of time. H-World didn't get off
    > the ground, although I think that only one of the listed reasons really
    > holds, but that's maybe enough to cause all the problems.
    >
    > If you ask me, H-World suffered from:
    >
    > - too much work required for the graphics
    > - too complex data structures
    > - too complex scripting interface
    > - too complex file/module structures
    > - insufficient documentation
    > - lack of user level editing tools
    > - bad advertising

    Good list, taking note.

    > The first four directly impact the ease of creating new modules, all add
    > a some steepness to the early learning curve for users.
    >
    > The next two hinder users to be successful quickly.
    >
    > I guess that are enough problems to explain why noone tried/tries to
    > make modules for H-World.

    Perhaps H-World engine didn't reach a mature enough usable
    level. Anyway it's all very interesting.

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  41. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:

    > Christophe wrote::
    >
    >> Hansjoerg Malthaner a écrit :
    >>
    >>> Krice wrote::
    >
    >>> Two became Java applets and you can try them in a Java enabled browser:
    >>>
    >>> A simple boulder dash remake:
    >>> http://www.simugraph.com/simutrans/applets/granite/JvGraniteTest.html
    >>>
    >>> A simple Trailblazer remake:
    >>> http://www.simugraph.com/simutrans/applets/trail/roadblaster.html
    >>>
    >>> I wanted to see if Java is suitable for games - that's been before
    >>> 2000 when computers were much slower and Java much less performant.
    >>
    >> The Boulder dash remake is nearly unplayable here because it's too slow
    >> and I have far from a slow computer :) I wonder how you could even play
    >> it in 2000 ! And yes, I'm using a recent Java VM ( 1.4.2 I think )
    >
    > I have no idea why it's slow for you, sorry. I developed it on a Pentium
    > 200 MMX back then, maybe that's a fast machine for you? It surely was
    > playable.
    >
    > I take note of your findings, but I have no explanation. I'll also not
    > take any action, these applet are really long past.
    >
    > I feel, I shouldn't have posted those links. I regret it already very
    > much.

    Don't say that, even if a little slow it is still a cool thing :) I'm not
    asking you to release the source code or something.
  42. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > Krice wrote::
    >
    >> Hansjoerg Malthaner wrote:
    >>
    >>> But you know that I can't make games
    >>
    >> Why not? :)
    >
    > I like to build sandboxes, areas, toys to play around in and with. This
    > is somewht similar to games, but not exactly games. Players seem to miss
    > tasks, guidelines, quests, at least I get that from teh past discussions.
    >
    > While I think I could add the things, I just don't want to.
    >
    > My current conclusiuon is that I don't want to work on things that I
    > don't like or need by myself, and if noone likes what I do, it's better
    > to do something else.

    Absolutely.

    >>> If you ask me, H-World suffered from:
    >>> - too much work required for the graphics
    >>> - too complex data structures
    >>> - too complex scripting interface
    >>> - too complex file/module structures
    >>> - insufficient documentation
    >>> - lack of user level editing tools
    >>> - bad advertising
    >>
    >> Well, don't all roguelikes suffer from those?:)
    >
    > I'm not sure. H-World is definitely more complex in regards of the item
    > and monsters that structures than e.g. Angabdn or Nethack. I really
    > think it makes a difference.
    >
    > Angband and NetHack have big user bases that also mostly have made good
    > experiences, so advertising a variant is easy and a lot of people will
    > at least stake a look.
    >
    > T-Engine seems to have good documentation.
    >
    >> Except the first one,
    >> which is only graphical RL issue, and maybe scripting, because not
    >> all RL's have useless scripting junk... I still think you gave up
    >> too easily, but on the other hand I can understand if it become too
    >> much like work.
    >
    > I've been working 3 1/3 years on H-World. I don't think you can say I
    > gavce up too early, particularly in regard to amount of time that I
    > spent on the project throughout these yers.

    Wow.

    > I think I gave up way too late. I should have stopped when the first
    > complaints came in, and it became visible that there is ammismatch
    > between my aims and the expectations of most users/players.
    >
    > I ignore that for a while; some people here said, I shall do it if I
    > like to do it. So I did, as long as there was a t least a little hope
    > and fun.
    >
    > I'm pretty sure my decision as right. I'm very sure that the next years
    > I'll not write any programs at all. I spent way too much time on
    > Simutrans and H-World in the past.
    >
    >>> I guess that are enough problems to explain why noone tried/tries to
    >>> make modules for H-World.
    >>
    >> I think most of us know how hard it is to find people to do something
    >> for your project. Especially when you just wait for someone to get
    >> interested. That wont happen easily. You have to - yes, advertise:)
    >> Well, not just that, but try to find a person to be a part of the
    >> team and fully responsible for making that game module. Then it would
    >> probably work better.
    >
    > I couldn't find anyone. Maybe I didn't try hard enough, but I had some
    > contacts to people who told me to be intersted but at the point when
    > they should have started working, they all disappeared.
    >
    > You find a lot of people who tell how to do things right. Very few of
    > them join you and actually help doing it.
    >
    > Also, I'm not really a team leader I guess.

    I found you to be a great person and an inspiration.
    A terrific and generous contributor to the internet
    community.

    > ABCGi was the one who helped most, actually I think he was the only one
    > who used the engine to run his own modules.

    Yeah and it is a real shame I was not able to contribute more
    on the coding side. And I'm sorry for that. If work hadn't
    been so damn busy... :( I still hold out hope for the future
    and H-World SourceForge - maybe I'll get fired!!! :)

    It is not like I'm lazy/incapable, but at least I was able to
    provide a lot of modding feedback and reporting and interest,
    and build some modules and really understand what a technical
    marvel you have created. I would be proud of what you have
    built if I were you and thank you for it.

    I find most of your self-criticisms/self-deprecation totally
    invalid. Maybe you are too close to the project (or too sad)
    to accurately judge? And it must be hard for others to offer
    their opinions on the engine if they haven't used the engine
    in depth. They all played The Jungle though and had some great
    things to say about it, and some good constructive criticism too.

    I have said it before - but a piece by you, Hajo, on RL engines
    and development trade offs and when to stop/change tack would
    be a great article indeed for the various wikis/Bjorns RL dev
    site.

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  43. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote::

    > Hansjoerg Malthaner wrote:

    >> Also, I'm not really a team leader I guess.
    >
    > I found you to be a great person and an inspiration.
    > A terrific and generous contributor to the internet
    > community.

    Thanks :)

    >> ABCGi was the one who helped most, actually I think he was the only
    >> one who used the engine to run his own modules.
    >
    > Yeah and it is a real shame I was not able to contribute more
    > on the coding side. And I'm sorry for that. If work hadn't
    > been so damn busy... :( I still hold out hope for the future
    > and H-World SourceForge - maybe I'll get fired!!! :)

    No worries about that. The work is what pays your rent and feeds your
    family. H-World is a nice toy, but it's just that and not more.

    H-Worlds future is very open, everyone can go and continue if he wants.
    Let's hope someone does :)

    > It is not like I'm lazy/incapable, but at least I was able to
    > provide a lot of modding feedback and reporting and interest,
    > and build some modules and really understand what a technical
    > marvel you have created. I would be proud of what you have
    > built if I were you and thank you for it.

    Actually the projects, Simutrans and H-World were a tremendous training,
    in regards of design, coding, but also customer support and teamwork.

    I learned a lot about people and motivation, and I'm sure I wouldn't
    stand where I stand today if I had not tried those projects. I mean that
    in a positive sense.

    I know the time wasn't wasted and I hope the experiences will help me
    through my further path of life - the coding skills probably less, but
    the experiences with people probably quite a bit.

    > I find most of your self-criticisms/self-deprecation totally
    > invalid. Maybe you are too close to the project (or too sad)
    > to accurately judge?

    Surely there are a lot of emotions involved. Most likely if I as the
    same that I was a few years ago, I'd continue without much thought being
    spend.

    I changed, and my view on things changed. Last year a lot of things
    happened in my private life, some hurt me very much and I couldn't do
    anything to change it. Yet, they surely changed me and my ideas what's
    valuable, important and what's not.

    Last autumn the idea that my life needs a radical change came up in me.
    I was talking to some people that I consider close friends, but noone
    could really help me, quite some didn't even understand what the problem
    was.

    Quitting Simutrans and H-World are results of my wish for a change.
    Looking back, they indeed have been like enormous weights on my
    shoulders. I feel better since I quit.

    But that is really off topic here, and I must solve the problems by
    myself. I just want to tell, that you only see part of whats happing and
    therefore it's most likely difficult to understand.

    I'll use this metapher: I currently destroy a lot of old things to get
    room for new things, yet I don't know what they will be. I just think
    the old situation was unbearable any longer.

    > And it must be hard for others to offer
    > their opinions on the engine if they haven't used the engine
    > in depth. They all played The Jungle though and had some great
    > things to say about it, and some good constructive criticism too.
    >
    > I have said it before - but a piece by you, Hajo, on RL engines
    > and development trade offs and when to stop/change tack would
    > be a great article indeed for the various wikis/Bjorns RL dev
    > site.

    Maybe I can do that as a last favor for the RL community :)

    --
    c.u. Hajo
  44. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote:
    > I found you to be a great person and an inspiration.
    > A terrific and generous contributor to the internet
    > community.

    I truly second that!

    >> ABCGi was the one who helped most, actually I think he was the only
    >> one who used the engine to run his own modules.
    >
    > Yeah and it is a real shame I was not able to contribute more
    > on the coding side. And I'm sorry for that. If work hadn't
    > been so damn busy... :( I still hold out hope for the future
    > and H-World SourceForge - maybe I'll get fired!!! :)

    I wouldn't count on that ;-).
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Some thing's just cannot be programmed in a roguelike. For
    everything else, there's GenRogue" -- Anubis
  45. Archived from groups: rec.games.roguelike.development (More info?)

    Arakon wrote:
    > Kornel Kisielewicz wrote:
    >>>I used to love Pascal, it does as good as C most of the time. Nothing
    >>>wrong with using what works. (C++/C#/Lua are now my favs)
    >>Well, you should try FreePascal ;-). FreePascal to Turbo Pascal is like
    >>C++ to C...
    > It is too late for me now.. I've been corrupted by templates, multiple
    > inheritence, and all of the base tools I use. It's nice to see it's
    > still alive though.

    Ah, why it may not be too late! There's a advanced macro system for FPC
    being prepared -- compared to which the template system of C++ seems
    cheap. And instead of the buggy and error-prone muliple inheritance you
    have Java-like interfaces in FPC already :-) (not to mention that
    multiple inheritance is Evil ;-) ).

    >>A data-driven engine won't have neither pointers nor the need for
    >>garbage collection y'know ;-).
    >
    > That's true.. but you're also severely limited, even compared to a
    > strict script implementation. Example - you have items that are used,
    > and want to temporarilly adjust attributes. With data files, you could
    > just specify a few. With a script, you could have it based on formulas
    > linked to other attributes.

    True. But there is an enormous gain -- stability.

    > Of course, the trick is: With a script implementation, everyone wants
    > to over-enginier it, and make it so that -anything- can be done in that
    > event response. They want it so each item can add it's own needed
    > attributes, or create special time-based effects in script, etc.
    > That's where development time is eaten, and complexities are added, and
    > game play is never a focus.

    Which leads to project failure or overbloat...

    >>I want to make Carceri a testing ground for the new GR data-engine. GR
    >>design now encompasses a ridiculous amount of data-drivism, but I'm not
    >>sure wether it will work out well. But I may be on the edge of a
    >>revolution in my programming style... I'll give you just one example,
    >>try to imagine -- Data Driven Quests...
    >
    > Data Driven Quests... Do you have some more ideas on that?

    Yup ;-). But they need severe beta-testing. I can just tell you that if
    that what I plan will work, then random-quests will be just a question
    of randomizing a few values :-).
    --
    At your service,
    Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
    "Oh come on. We both know the truth about this game --
    vapourware." -- Anathiel about GenRogue
  46. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > Hansjoerg Malthaner wrote:
    *SNIP*
    >>I'm pretty sure my decision as right. I'm very sure that the next years
    >>I'll not write any programs at all. I spent way too much time on
    >>Simutrans and H-World in the past.
    >
    > The scale of those projects are large. You should really try to
    > make a simple game (like classic Tetris:) if you haven't tried
    > that before.
    *SNIP*

    Of course Hajo has done that before. Just a glance at his
    site would tell you that. But one thing is true, the larger
    the scale of the project, the harder it is - regardless of
    a very talented developer like Hajo.

    http://simugraph.com/en/projects.html

    If you haven't tried modding H-World yet maybe give it a go?
    It would be interesting to hear your experience.

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Fun RLs in rgrd that I have tested recently!
    DoomRL - DwellerMobile - HWorld - AburaTan - DiabloRL
    Heroic Adventure - Powder - CastlevaniaRL - TheTombs
  47. Archived from groups: rec.games.roguelike.development (More info?)

    ABCGi wrote::

    > Krice wrote:
    >
    >> The scale of those projects are large. You should really try to
    >> make a simple game (like classic Tetris:) if you haven't tried
    >> that before.
    >
    > *SNIP*
    >
    > Of course Hajo has done that before. Just a glance at his
    > site would tell you that. But one thing is true, the larger
    > the scale of the project, the harder it is - regardless of
    > a very talented developer like Hajo.
    >
    > http://simugraph.com/en/projects.html

    Drops is surely a thing I cannot recommend. I started it 1992, and it's
    very much patchwork put together over the years, last release was 2003 IIRC.

    It's stone age technology, the UI is nowhere close or similar to current
    standards, it's buggy and mots likely not useable by anyone but me ...
    so be warned :)

    If you want a painting tool, most likely everyting else will be better
    for you ;)

    --
    c.u. Hajo
  48. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Fri, 27 May 2005 15:33:41 +0200,
    Hansjoerg Malthaner napisal(a):

    > ABCGi wrote::
    >> Krice wrote:
    > Drops is surely a thing I cannot recommend. I started it 1992, and it's
    > very much patchwork put together over the years, last release was 2003 IIRC.
    >
    > It's stone age technology, the UI is nowhere close or similar to current
    > standards, it's buggy and mots likely not useable by anyone but me ...
    > so be warned :)

    Hey, 90% of Linux's application base used to be programs written by
    someone who just happened to need something like this, and thought it
    would be convenient to do it this way... ;)

    --
    Radomir @**@_ Bee! The quest for the Real World:
    `The Sheep' ('') 3 Try #2: goto -1
    Dopieralski .vvVvVVVVVvVVVvv.
  49. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote::

    > Dnia Fri, 27 May 2005 15:33:41 +0200,
    > Hansjoerg Malthaner napisal(a):
    >
    >
    >>ABCGi wrote::
    >>
    >>>Krice wrote:
    >>
    >>Drops is surely a thing I cannot recommend. I started it 1992, and it's
    >>very much patchwork put together over the years, last release was 2003 IIRC.
    >>
    >>It's stone age technology, the UI is nowhere close or similar to current
    >>standards, it's buggy and mots likely not useable by anyone but me ...
    >>so be warned :)
    >
    > Hey, 90% of Linux's application base used to be programs written by
    > someone who just happened to need something like this, and thought it
    > would be convenient to do it this way... ;)

    Yes, Drops is exactly like that - if I needed some crazy drawing tool
    function I just added it. Quicka nd dirty, because I wanted to use the
    function and as soon as it was minimally useable, Drops went from
    development to production again :)

    Sometimes I discover hotkey bindings to long forgotten functions,
    because even a menu entry would have meant too much work :)

    --
    c.u. Hajo
Ask a new question

Read More

Video Games