[help] java roguelike development insight needed

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

Hi,

I finaly decided to put my first roguelike together, i've put together
my world, What rules will be like ( like classes, skills, magic ...).
So it's kind of ready to be played in pen-and-paper fashion.

What i lack is experience in doing roguelikes (but not programing
overall ...).

So, can anyone point me to design pattens usefull for adom-like complex
game?

What dangerous structures are there waiting for me to discover, use and
loathe?

Now, i'm putting together some basics, like item data model, character
data model...

For example:

Items should all be descendands of object Item ... like Weapon class
and Armor inherits from Item class that has generics, but i don't want
Item class instrictally know how to work with Blessed or Cursed status,
and i don't want to implement it in all apliclable subclases ( that
code will be always the same ... ) and this goes to other stuff to (
Durability of item ... )

Another problem is how to handle ego items. Since i want to employ
Diablo II-like item model with socketable items, runeword-like
abilities, sets ... lots of customizations. All of this having lots of
triggers for special actions ( onBeingHit, onTargetDestroyed ... ).
Currently, having have each item list which contains Object of
MagicItemMod interface and another List which can contain other items
imlementing InsertableItem

(I know how to google for i.e. map generation or so ... i just want
real live answer)
47 answers Last reply
More about help java roguelike development insight needed
  1. Archived from groups: rec.games.roguelike.development (More info?)

    Filip Dreger wrote:
    > Probably you are going to loathe your Object Oriented approach :-)
    > This is one of the hot topics here, it got discussed a couple of
    > times; one of the last OO Java champions, Slash, used to have some
    > really cool posts on doing the OO stuff "the right way", but he seems

    > a lot quieter now; and just some time ago he posted a little advice
    in
    > the lines of "beware of overengineering".
    > The ideal OO structure for a roguelike seems way to complicated to
    > implement in a straightforward way, just by translating "sword" into
    a
    > "sword class" and having the "magic sword" inherit from it. It seems
    > better to have a generic "item" class.

    Well I found this out a long time ago. Now tell me how to make a
    generic class for items,beings and world cells :)) coz that seems even
    more sophisticated.

    regard,
    Kate
  2. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:

    > You may want to seriously rethink your choice of language.

    Not every RL developer is capable of speaking in every (computer)
    language in existance like you IMHO. I'm working mine on Java, and I
    like it that way so I'm sticking to it.

    Back to topic:

    My Java skill is too limited to lend you any insight, though. But as
    soon as you have some runnable classes, I'm glad to be a tester *grin*
  3. Archived from groups: rec.games.roguelike.development (More info?)

    You may want to seriously rethink your choice of language. For really
    complex roguelikes you want a functionalesque language with closures,
    comprehensions, or some such and dynamic typing. Smalltalk and Python
    are candidates; C's static typing makes it more problematic, and Java's
    rigid static typing makes it an even worse choice. If you're accepting
    the overhead in memory use and slowness that result from implementing
    your game on a virtual platform (i.e., it runs as bytecodes on some kind
    of VM or is otherwise interpreted) you may as well use Smalltalk or Python.

    Both let individual objects actually acquire new methods at run-time in
    fact, which can be very useful if, say, something can become Wearable
    all of a sudden. Smalltalks sometimes allow object mutation, and at the
    very least you can override doesNotUnderstand: to catch attempted calls
    to a method with no static implementation. (You'll end up with code for
    wielding like theItem isWearable ifTrue: [theItem isCursed ifTrue: [stuff]])

    Python makes it even easier since you just create a functional object
    (one that can be called like a function) with suitable parameters and
    assign it to some attribute of some object and presto: that object now
    accepts a new instance method!

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  4. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:
    > Python makes it even easier

    If it was that much easier then we would be probably all programming
    with Python. I think just any programming language is good if it's
    suitable for large projects and has good memory management.
    Like, say, C#.NET:)
  5. Archived from groups: rec.games.roguelike.development (More info?)

    Filip Dreger wrote:
    > Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
    > news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
    > > What dangerous structures are there waiting for me to discover, use

    > > and
    > > loathe?
    > Probably you are going to loathe your Object Oriented approach :-)
    > This is one of the hot topics here, it got discussed a couple of
    > times; one of the last OO Java champions, Slash,

    Lol, *blushes*

    > used to have some
    > really cool posts on doing the OO stuff "the right way", but he seems

    > a lot quieter now;

    I plant to get back to roguelike development mode in the next month...
    for now I just can't add another think thread to my head ;)

    > and just some time ago he posted a little advice in
    > the lines of "beware of overengineering".
    > The ideal OO structure for a roguelike seems way to complicated to
    > implement in a straightforward way, just by translating "sword" into
    a
    > "sword class" and having the "magic sword" inherit from it. It seems
    > better to have a generic "item" class.
    >
    SNIP
    >
    > regards,
    > Filip
  6. Archived from groups: rec.games.roguelike.development (More info?)

    Petr Prokop wrote:
    > Hi,
    >
    > I finaly decided to put my first roguelike together, i've put
    together
    > my world, What rules will be like ( like classes, skills, magic ...).
    > So it's kind of ready to be played in pen-and-paper fashion.

    Nice! any docs or are they *private*?

    (makes me think on that project... Greekie??? ;) )

    >
    > What i lack is experience in doing roguelikes (but not programing
    > overall ...).
    >
    > So, can anyone point me to design pattens usefull for adom-like
    complex
    > game?

    "adom-like complex game" ;)

    I can only think on a pattern based on patience and a lot of time :D

    >
    > What dangerous structures are there waiting for me to discover, use
    and
    > loathe?
    >
    > Now, i'm putting together some basics, like item data model,
    character
    > data model...
    >
    > For example:
    >
    > Items should all be descendands of object Item ... like Weapon class
    > and Armor inherits from Item class that has generics, but i don't
    want
    > Item class instrictally know how to work with Blessed or Cursed
    status,
    > and i don't want to implement it in all apliclable subclases ( that
    > code will be always the same ... ) and this goes to other stuff to (
    > Durability of item ... )

    This can be handled in a lot of ways...

    For example, you may consider weapons, armor, potions, scrolls etc...
    to be just Items, they all have common properties, and the thing that
    differentiates them is the use you put them into... this allows for
    example to make things such as attacking a monster with a scroll... the
    results of the attack will be dependant on the attributes of the scroll
    as a item, such as its mechanical strength, weight, material, etc...

    Subclassing has no real advantage here, as you will end up with ugly
    things such as :

    if (item instanceof Weapon)
    int damge = ((Weapon)item).getDamage();
    else
    throw GorillaException("You can't attack with that!");

    However, you may include attributes to each item that indicates their
    common uses, so that its easier for the UI (or the AI) to select them
    for each action (for example, if the AI controlled monster wants to
    drink something, he will first choose from these things that are
    normally drunk, then he may consider if he wants to drink that ugly
    looking sword :D )

    >
    > Another problem is how to handle ego items. Since i want to employ
    > Diablo II-like item model with socketable items, runeword-like
    > abilities, sets ... lots of customizations. All of this having lots
    of
    > triggers for special actions ( onBeingHit, onTargetDestroyed ... ).
    > Currently, having have each item list which contains Object of
    > MagicItemMod interface and another List which can contain other items
    > imlementing InsertableItem

    Or just a attribute set inside each item that defines the properties
    for an item to be allowed insertion into it, and a reference to the
    insertable which is just another Item with these special
    modifications... that way you could insert that bubblegum into your
    shield and make your enemy weapons stick over it :)

    I think generalization must be avoided here, because it really doesn't
    affect the functionality of the objects, only the attributes...

    >
    > (I know how to google for i.e. map generation or so ... i just want
    > real live answer)

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

    Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
    news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
    > What dangerous structures are there waiting for me to discover, use
    > and
    > loathe?
    Probably you are going to loathe your Object Oriented approach :-)
    This is one of the hot topics here, it got discussed a couple of
    times; one of the last OO Java champions, Slash, used to have some
    really cool posts on doing the OO stuff "the right way", but he seems
    a lot quieter now; and just some time ago he posted a little advice in
    the lines of "beware of overengineering".
    The ideal OO structure for a roguelike seems way to complicated to
    implement in a straightforward way, just by translating "sword" into a
    "sword class" and having the "magic sword" inherit from it. It seems
    better to have a generic "item" class.

    > Items should all be descendands of object Item ... like Weapon class
    > and Armor inherits from Item class that has generics, but i don't
    > want
    > Item class instrictally know how to work with Blessed or Cursed
    > status,
    > and i don't want to implement it in all apliclable subclases ( that
    > code will be always the same ... ) and this goes to other stuff to (
    > Durability of item ... )

    This is exactly why you do not want to inherit weapon from item :-)

    regards,
    Filip
  8. Archived from groups: rec.games.roguelike.development (More info?)

    SmartK8@gmail.com wrote:
    >Well I found this out a long time ago. Now tell me how to make a
    >generic class for items,beings and world cells :)) coz that seems even
    >more sophisticated.

    This seems an excessive abstraction to me. But then, I'm a
    procedural-with-some-OO-techniques programmer at heart; my reasons for
    contemplating learning Java are *entirely* mercenary.
    --
    Martin Read - my opinions are my own. share them if you wish.
    My roguelike games page (including my BSD-licenced roguelike) can be found at:
    http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
    bounce. bounce. bounce. bounce bounce bounce bounce.
  9. Archived from groups: rec.games.roguelike.development (More info?)

    tongHoAnh wrote:
    > Twisted One wrote:
    >
    >>You may want to seriously rethink your choice of language.
    >
    > Not every RL developer is capable of speaking in every (computer)
    > language in existance like you IMHO. I'm working mine on Java, and I
    > like it that way so I'm sticking to it.

    I said "may want to", not "absolutely must" ... :)

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  10. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One ha escrito:
    > SZDev - Slash wrote:
    > > throw GorillaException("You can't attack with that!");
    >
    > GorillaException?

    Yeah... haven't you every thrown one???

    >
    > > Or just a attribute set inside each item that defines the
    properties
    > > for an item to be allowed insertion into it, and a reference to the
    > > insertable which is just another Item with these special
    > > modifications... that way you could insert that bubblegum into your
    > > shield and make your enemy weapons stick over it :)
    >
    > Hold on. I have to call my stockbroker urgently.
    >
    > Hello Harry? Yes ... I'd like to buy some stock options. Teflon sword

    > futures, to be exact ...

    LOL :)

    >
    > --
    > http://www.gnu.org/philosophy/right-to-read.html
    > Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    > "One ring to rule them all, one ring to find them
    > One ring to bring them all, and in the darkness bind them."

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

    SmartK8@gmail.com wrote::

    > Filip Dreger wrote:

    >>"sword class" and having the "magic sword" inherit from it. It seems
    >>better to have a generic "item" class.
    >
    > Well I found this out a long time ago. Now tell me how to make a
    > generic class for items,beings and world cells :)) coz that seems even
    > more sophisticated.

    Items and beings can be unified if you extract the AI into separate
    structures. I would not advice to try to merge this with world cells,
    though.

    I you need example code, you could look at my project:
    https://sourceforge.net/projects/h-world/

    It uses unified classes for items and monsters.

    The CVS stats still say 0 files, but they are all there:
    http://cvs.sourceforge.net/viewcvs.py/h-world/

    > regard,
    > Kate

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

    tongHoAnh wrote:
    > Twisted One wrote:
    >
    >
    >>You may want to seriously rethink your choice of language.
    >
    >
    > Not every RL developer is capable of speaking in every (computer)
    > language in existance like you IMHO. I'm working mine on Java, and I
    > like it that way so I'm sticking to it.

    A lot of people use their RL development as a way of learning new
    languages, skills, and techniques. He never said not to use Java, he
    just suggested a couple of languages he felt better suited to the
    task. An especially valid suggestion, since both of those languages
    are worth learning, and making a small RL is a nice way to really give
    it a go.


    --
    SoulEaterRL... Coming soon!

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

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

    Krice wrote:
    > That is true, but you can try to be extra careful with C++ and
    > possibly avoid many problems with memory management.
    > I wouldn't recommend C for anyone, because (afaik) it lacks
    > those few good memory management techniques that C++ has.

    C doesn't lack anything that C++ has, aside from syntactic sugar and
    exceptions. Exceptions are the only thing a C runtime lacks that a C++
    runtime has, and they have nothing to do with memory management. Every
    use of a reference in C++ code can be a pointer in C. Any data structure
    you implement in either can then be implemented in the other. And so on...

    Well, C++ also has templates, but even if you can find a compiler and
    linker with proper template support (i.e. doesn't complain about
    multiple definitions or some other problem when any nontrivial project
    that instantiates templates is compiled, even if the code's all valid
    according to the ANSI standard) templates are just as orthogonal to
    memory management as exceptions.

    There might be coding tricks to deal with stuff more elegantly and in a
    way that's easier and less error-prone to code and later to maintain in
    C++, but the basic memory management primitives of new and delete are no
    more sophisticated than malloc and free, really, aside from the trivial
    difference that you get to write new foo[10] without needing sizeof,
    instead of writing malloc(10*sizeof(foo)).

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  14. Archived from groups: rec.games.roguelike.development (More info?)

    SZDev - Slash wrote:
    > throw GorillaException("You can't attack with that!");

    GorillaException?

    > Or just a attribute set inside each item that defines the properties
    > for an item to be allowed insertion into it, and a reference to the
    > insertable which is just another Item with these special
    > modifications... that way you could insert that bubblegum into your
    > shield and make your enemy weapons stick over it :)

    Hold on. I have to call my stockbroker urgently.

    Hello Harry? Yes ... I'd like to buy some stock options. Teflon sword
    futures, to be exact ...

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  15. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > tongHoAnh wrote:
    >> Twisted One wrote:
    >>
    >>> You may want to seriously rethink your choice of language.
    >>
    >> Not every RL developer is capable of speaking in every (computer)
    >> language in existance like you IMHO. I'm working mine on Java, and I
    >> like it that way so I'm sticking to it.
    >
    > A lot of people use their RL development as a way of learning new
    > languages, skills, and techniques. He never said not to use Java, he
    > just suggested a couple of languages he felt better suited to the task.
    > An especially valid suggestion, since both of those languages are worth
    > learning, and making a small RL is a nice way to really give it a go.

    Plus, learning Python might actually give you a marketable skill.
    (Smalltalk, on the other hand ... ;P)

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  16. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-05-18, Twisted One <twisted0n3@gmail.invalid> wrote:
    > and C++. Java scaling is iffy -- being forced at gunpoint to use
    > separate source files for every class leads to file multiplication. Once
    > you have more than 10 source files, you've exceeded most editors' MRU

    Nothing stops you from cramming lots of classes in a file. Java just
    requires that the only top-level public class defined in a source file
    has the same name as the source file itself. You can write many
    non-public classes, which might be accessible for example from factory
    methods in the public class.

    You can also do this:

    BigMainClass.java:

    public class BigMainClass {
    public static class Foo { ... }
    public static class Bar { ... }
    ...
    }

    and then refer to the subclasses as BigMainClass.Foo etc.

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

    Risto Saarelma wrote:
    > Nothing stops you from cramming lots of classes in a file. Java just
    > requires that the only top-level public class defined in a source file
    > has the same name as the source file itself. You can write many
    > non-public classes, which might be accessible for example from factory
    > methods in the public class.

    For a typical OO project, to keep the number of separate source files
    reasonable and to reasonably group related classes this way would
    require a lot of hoop-jumping and unnatural uses of inner classes and
    factory classes to export otherwise-private stuff. So, for all practical
    purposes, my assertion stands. And anyway, the naming requirement is not
    justified. If there was some facility for on the fly recompilation of
    changed source files I could see it as making it unambiguous where to
    find the source file, coupled with requirements on directory structure
    based on package name, but when the compiler is always handed the source
    file's location and name on a silver platter why should it care?

    > BigMainClass.java:
    >
    > public class BigMainClass {
    > public static class Foo { ... }
    > public static class Bar { ... }
    > ...
    > }
    >
    > and then refer to the subclasses as BigMainClass.Foo etc.

    I.e. a class full of inner classes as a pseudopackage, minus the
    readability advantage of being able to import the declarations and just
    refer to Foo. Which then leads to using BMC instead of BigMainClass as
    the name and still having a million senseless and bloating copies of the
    string "BMC" all over your sources. It's just plain ugly and gross.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  18. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:

    > Twisted One wrote:
    >> Python makes it even easier
    >
    > If it was that much easier then we would be probably all programming
    > with Python.

    Not really. There are quite a few reasons why it isn't the case. One of them
    beeing that a single language can hardly fit for every situation. A second
    beeing a massive inertia for programming languages but also for programming
    paradigms.

    > I think just any programming language is good if it's
    > suitable for large projects and has good memory management.
    > Like, say, C#.NET:)

    C# and Java have very good memory management but poor global ressource
    management. With C++ and RAII we have very good handling of open files,
    mutexes etc... and also good memory handling :)
  19. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe Cavalaria wrote:
    > C# and Java have very good memory management but poor global ressource
    > management. With C++ and RAII we have very good handling of open files,
    > mutexes etc... and also good memory handling :)

    C++? Good memory management? Are you mad? Unless by "good memory
    management" you mean "I can, indeed I must, micromanage memory" rather
    than "I can make really complicated data structures and freeing stuff,
    but not while it's still in use, is taken care of for me automagically,
    unlike C++ where it will be a royal pain to accomplish that due to
    having to do it myself and still there's bound to be leaks and
    segfault-causing bugs after years and several major revisions".

    I have yet to see any large production body of C or C++ code that
    doesn't leak like a sieve and occasionally crash under obscure and hard
    to reproduce conditions, even with many major revisions and years of
    development, field testing, and iterative fixing.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  20. Archived from groups: rec.games.roguelike.development (More info?)

    In article <d6fbkp$hsg$1@nemesis.news.tpi.pl>,
    Filip Dreger <fdreger@amiga.pl> wrote:
    >Uzytkownik "Petr Prokop" <zwei2stein@gmail.com> napisal w wiadomosci
    >news:1116415282.335718.264910@g44g2000cwa.googlegroups.com...
    >> What dangerous structures are there waiting for me to discover, use
    >> and loathe?

    Not a structure issue per se., but the one piece of advice I have for
    you is this:

    Don't plan.

    Or, at least, don't plan a lot.

    The big gotcha with me (and apparently with some other developers as
    far as I can tell) is to design a roguelike as the Greatest Roguelike
    Ever, one that requires a zillion lines of code, then only write have
    a zillion, resulting in something that won't actually run.

    So what I recommend is that you just wing it. Write something _now_,
    something that can be played and might perhaps be fun to do so, and
    put it on the web. I recommend setting yourself a short time limit.
    Seven days seems popular around here, although I think it's a bit
    short, personally. A month might be better.

    Once you've gotten that far, you can refactor your code and maybe
    retroactively design a cool, flexible architecture. At that point,
    you'll have a better understanding of the problem.

    It's a lot easier to fix a working program than an empty source file.

    >Probably you are going to loathe your Object Oriented approach :-)
    >This is one of the hot topics here, it got discussed a couple of
    >times; one of the last OO Java champions, Slash, used to have some
    >really cool posts on doing the OO stuff "the right way", but he seems
    >a lot quieter now; and just some time ago he posted a little advice in
    >the lines of "beware of overengineering".

    On the other hand, I've used the OO approach and haven't regretted
    it.

    It looks to me like the OO approach doesn't really pay off until
    you've got a pretty advanced game, one with unique monsters,
    artifacts, funky effects and so on. When you only have one kind of
    attack, monsters don't need to be different in any way except for some
    stats.

    Which means that you'll end up hand-coding a whole lot of monsters
    with individual stats in each one. The, you'll need to rebalance your
    game and have to hunt through a huge number of source files because
    half of them need an extra point of AC.

    You might want to consider just storing your game object data in a big
    text file and generating your class source code from it with a script
    each time you compile. Then, as you start adding wierd monsters (or
    artifacts, or whatever), you can remove them from the list and replace
    them with hand-coded classes that do the extra special things you care
    about.


    --Chris


    --
    Chris Reuter http://www.blit.ca
    "They that can give up essential liberty to obtain a little temporary safety
    deserve neither liberty nor safety." --Benjamin Franklin, 1759
  21. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:

    > Christophe Cavalaria wrote:
    >> C# and Java have very good memory management but poor global ressource
    >> management. With C++ and RAII we have very good handling of open files,
    >> mutexes etc... and also good memory handling :)
    >
    > C++? Good memory management? Are you mad? Unless by "good memory

    Keeping RAII in mind can help a lot in C++ memory management :) Allocate as
    much memory as possible by never calling new : Place all objets in STL
    containers or on the stack and you'll have a much easier time managing
    memory. If you really need to call new, make sure the resulting pointer is
    owned by a non-new using object and don't forget the virtual destructor. I
    don't speak about C here because you can't do without calling malloc and
    free.

    > management" you mean "I can, indeed I must, micromanage memory" rather
    > than "I can make really complicated data structures and freeing stuff,
    > but not while it's still in use, is taken care of for me automagically,
    > unlike C++ where it will be a royal pain to accomplish that due to
    > having to do it myself and still there's bound to be leaks and
    > segfault-causing bugs after years and several major revisions".
    >
    > I have yet to see any large production body of C or C++ code that
    > doesn't leak like a sieve and occasionally crash under obscure and hard
    > to reproduce conditions, even with many major revisions and years of
    > development, field testing, and iterative fixing.

    I think QT and KDE are big enouth C++ projects in themselves. They don't
    leak in any perceptible way and don't crash either.
  22. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe Cavalaria wrote:
    > Keeping RAII in mind can help a lot in C++ memory management :)

    I don't know what this RAII thing of yours is, so I basically just
    ignored it and assumed ANSI standard C++ is being used.

    > I think QT and KDE are big enouth C++ projects in themselves. They don't
    > leak in any perceptible way and don't crash either.

    Surely you jest. Even if this is true they are the exceptions that prove
    the rule. Most software is in C or C++. Most software seems to have
    serious showstopper bugs, including crashes that don't occur
    consistently in specific circumstances but seem random. Most software
    also seems to leak. If I use my computer for a few days without
    rebooting, any long-running tasks in Task Manager seem to slowly bloat,
    along with the total commit charge. If not all of them, then most. Of
    course, open source software of good repute and widespread usage tends
    to have better stability due to the salutary effects of peer review and
    sheer weight of eyeballs, but large projects tend to be nearly
    unmanageable and even with this sort of massive distributed effort cease
    to be kept completely free of memory management problems. The only thing
    your statement says about KT and QDE are that the problems they do have
    are relatively subtle, and that there are probably lots of double and
    triple checks to avoid double-deletes or misusing a null pointer
    somewhere. Crashes then turn into subtler problems such as something
    mysteriously not working now and again, or bogus "out of memory" errors
    when there's gobs of physical ram free and a 2GB swap partition, when
    all the added validation code catches something and handles it more
    gracefully. And, of course, a bit of slowness and bloat from said
    validation code.

    (Mind you, even Java doesn't seem to be immune to weird memory
    management bugs. I've seen Java apps leak, presumably by accumulating a
    dead weight of referenced but actually unused objects; I've also seen
    Java apps generate spurious out of memory errors when there was gobs of
    memory free. This, to me, suggests a bug in the VM (maybe with memory
    allocation from the OS or detecting low memory conditions in the
    underlying system), or (more likely) a lazy app programmer who decided
    to throw an OutOfMemoryError for every "can't happen" or unlikely sanity
    check assert instead of creating their own unchecked exception class for
    such occasions.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  23. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:
    > Christophe Cavalaria wrote:
    >
    >> Keeping RAII in mind can help a lot in C++ memory management :)
    >
    >
    > I don't know what this RAII thing of yours is, so I basically just
    > ignored it and assumed ANSI standard C++ is being used.
    >
    >> I think QT and KDE are big enouth C++ projects in themselves. They don't
    >> leak in any perceptible way and don't crash either.
    >
    >
    > Surely you jest. Even if this is true they are the exceptions that prove
    > the rule. Most software is in C or C++. Most software seems to have
    > serious showstopper bugs, including crashes that don't occur
    > consistently in specific circumstances but seem random. Most software
    > also seems to leak. If I use my computer for a few days without
    > rebooting, any long-running tasks in Task Manager seem to slowly bloat,
    > along with the total commit charge. If not all of them, then most. Of
    > course, open source software of good repute and widespread usage tends
    > to have better stability due to the salutary effects of peer review and
    > sheer weight of eyeballs, but large projects tend to be nearly
    > unmanageable and even with this sort of massive distributed effort cease
    > to be kept completely free of memory management problems. The only thing
    > your statement says about KT and QDE are that the problems they do have
    > are relatively subtle, and that there are probably lots of double and
    > triple checks to avoid double-deletes or misusing a null pointer
    > somewhere. Crashes then turn into subtler problems such as something
    > mysteriously not working now and again, or bogus "out of memory" errors
    > when there's gobs of physical ram free and a 2GB swap partition, when
    > all the added validation code catches something and handles it more
    > gracefully. And, of course, a bit of slowness and bloat from said
    > validation code.
    >
    > (Mind you, even Java doesn't seem to be immune to weird memory
    > management bugs. I've seen Java apps leak, presumably by accumulating a
    > dead weight of referenced but actually unused objects; I've also seen
    > Java apps generate spurious out of memory errors when there was gobs of
    > memory free. This, to me, suggests a bug in the VM (maybe with memory
    > allocation from the OS or detecting low memory conditions in the
    > underlying system), or (more likely) a lazy app programmer who decided
    > to throw an OutOfMemoryError for every "can't happen" or unlikely sanity
    > check assert instead of creating their own unchecked exception class for
    > such occasions.

    I'm currently running a laptop that has a mere 128MB of RAM, and it's
    running Red Hat 9. Pretty much every single piece of software I'm
    running is coded in C/C++. As of right now, my machine has been
    running for 37 days straight, without a single reboot. And it's still
    running as good as it did when it was first booted. I run my web
    browser, newsreader, word processor, several games, IDE, miscellaneous
    system tools, terminal, PDF viewer, video software, music players, and
    a variety of other apps. Given my low system specs, if C/C++ apps
    really leaked that much, my machine should be incapacitated by now.
    Yet it's not.

    I'm guessing you're experience is probably derived from the fact that
    you are using Windows. All MS-bashing aside, Windows apps seem much
    more likely to leak, from my experience. Probably due to the buggy
    nature of the environment those apps run in. I don't recall ever
    being able to run a Windows machine for longer than a few days before
    a reboot is necessary, whereas I once ran my Linux box for over 3
    months without a reboot. And even then it didn't really need a
    reboot, but I had to unplug it for moving day.

    Any competent C/C++ coder can avoid memory leaks. It just takes the
    patience to make sure your code is carefully written, and to ensure
    that all memory management is handled properly.


    --
    SoulEaterRL... Coming soon!

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

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

    Timothy Pruett wrote:
    > I'm currently running a laptop that has a mere 128MB of RAM, and it's
    > running Red Hat 9. Pretty much every single piece of software I'm
    > running is coded in C/C++. As of right now, my machine has been running
    > for 37 days straight, without a single reboot. And it's still running
    > as good as it did when it was first booted.

    That's because on unix, killing a task that's leaked and restarting it
    actually reclaims the leaked memory, and the kernel and all the little
    command line tools are simple and streamlined enough someone can
    actually feasibly program them with manual memory management and
    eventually clean up all the bugs in same, and since it's open source,
    someone actually has. Have you restarted anything big and complex in
    those 37 days, such as pretty much anything with a GUI? If you've run
    something of the sort for that time without restarting the app and
    without it leaking or crashing at all then praise the Lord it's a
    miracle! Two more and you're eligible for sainthood. Or the programmer
    is. Or the entire devteam. Or something like that. :)

    > I run my web browser,
    > newsreader, word processor, several games, IDE, miscellaneous system
    > tools, terminal, PDF viewer, video software, music players, and a
    > variety of other apps. Given my low system specs, if C/C++ apps really
    > leaked that much, my machine should be incapacitated by now. Yet it's not.

    The OS kernel doesn't leak in your case and lets you restart anything
    and everything else without a reboot. That's why.

    > Any competent C/C++ coder can avoid memory leaks. It just takes the
    > patience to make sure your code is carefully written, and to ensure that
    > all memory management is handled properly.

    In a complex enough project, my experience tells me this becomes
    impossible-to-downright-nontrivial. :) Eventually you end up with
    objects in a long running system that have no "primary" reference or
    ownership that is going to be the last one cleared, every time. At this
    point, whether something is "live" or not is no longer a simple matter
    of whether its container is, or whether some other thing is, or whether
    this is done yet or that, but for some "somethings" at bare minimum will
    depend on reference counting. This assumes you avoid circular data
    structures, circular structures have a clear-cut parent or a handle of
    some kind, or you have some system for deterministic symmetry breaking
    to consider for reference counting purposes any cycle as having a head
    and a tail and not counting the link between them. (The general rule
    with circular structures is: count = refs - # cycles participated in. If
    count == 0, reclaimable. Finding a general algorithm for keeping track
    of the # cycles for every object is left as an exercise for the reader.
    I'll be generous and leave you until the heat death of the universe
    rather than impose a stricter deadline; you actually might have long
    enough this way.) Of course, once you've got circular structures with no
    clear way to break symmetry with "weak" links in each you're into
    wanting to use a GC. And at that point, you may as well give up on using
    C or C++. You can either use Java or reimplement it, and I know which
    I'd pick. ;)

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  25. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:
    > Timothy Pruett wrote:
    >
    >> I'm currently running a laptop that has a mere 128MB of RAM, and it's
    >> running Red Hat 9. Pretty much every single piece of software I'm
    >> running is coded in C/C++. As of right now, my machine has been
    >> running for 37 days straight, without a single reboot. And it's still
    >> running as good as it did when it was first booted.
    >
    >
    > That's because on unix, killing a task that's leaked and restarting it
    > actually reclaims the leaked memory, and the kernel and all the little
    > command line tools are simple and streamlined enough someone can
    > actually feasibly program them with manual memory management and
    > eventually clean up all the bugs in same, and since it's open source,
    > someone actually has. Have you restarted anything big and complex in
    > those 37 days, such as pretty much anything with a GUI? If you've run
    > something of the sort for that time without restarting the app and
    > without it leaking or crashing at all then praise the Lord it's a
    > miracle! Two more and you're eligible for sainthood. Or the programmer
    > is. Or the entire devteam. Or something like that. :)

    My newsreader has only been closed twice, both times due to me
    accidentally closing it out instead of a different window. My browser
    has been open just as long. Hell, Gnome and X have been running this
    entire time, without a single restart.

    >> I run my web browser, newsreader, word processor, several games, IDE,
    >> miscellaneous system tools, terminal, PDF viewer, video software,
    >> music players, and a variety of other apps. Given my low system
    >> specs, if C/C++ apps really leaked that much, my machine should be
    >> incapacitated by now. Yet it's not.
    >
    >
    > The OS kernel doesn't leak in your case and lets you restart anything
    > and everything else without a reboot. That's why.

    I haven't restarted most of my programs. Since most modern apps have
    a slow startup time on my 333MHz machine, I tend to open something
    once, and leave it open, until I'm sure I won't be using it for a
    couple days or more. Dozens of programs, and no leakage.

    >> Any competent C/C++ coder can avoid memory leaks. It just takes the
    >> patience to make sure your code is carefully written, and to ensure
    >> that all memory management is handled properly.
    >
    >
    > In a complex enough project, my experience tells me this becomes
    > impossible-to-downright-nontrivial. :) Eventually you end up with
    > objects in a long running system that have no "primary" reference or
    > ownership that is going to be the last one cleared, every time. At this
    > point, whether something is "live" or not is no longer a simple matter
    > of whether its container is, or whether some other thing is, or whether
    > this is done yet or that, but for some "somethings" at bare minimum will
    > depend on reference counting. This assumes you avoid circular data
    > structures, circular structures have a clear-cut parent or a handle of
    > some kind, or you have some system for deterministic symmetry breaking
    > to consider for reference counting purposes any cycle as having a head
    > and a tail and not counting the link between them. (The general rule
    > with circular structures is: count = refs - # cycles participated in. If
    > count == 0, reclaimable. Finding a general algorithm for keeping track
    > of the # cycles for every object is left as an exercise for the reader.
    > I'll be generous and leave you until the heat death of the universe
    > rather than impose a stricter deadline; you actually might have long
    > enough this way.) Of course, once you've got circular structures with no
    > clear way to break symmetry with "weak" links in each you're into
    > wanting to use a GC. And at that point, you may as well give up on using
    > C or C++. You can either use Java or reimplement it, and I know which
    > I'd pick. ;)

    Certainly a well thought out idea, but I have to disagree with you
    here. Any *good* coder can handle keeping his memory allocations in
    order, and can handle any problem that can come along. As long as you
    ensure you always have a pointer to every object created on the heap,
    you're safe. It doesn't take a genius to realize that it's a bad idea
    to reassign or delete any non-NULL pointer, since that'll cause a
    leak. Also, most coders will keep the pointer to any long-lived
    object in a scope that will guarantee it doesn't get lost
    accidentally. It's not that hard to keep your memory straight in C++.
    I haven't yet encountered any memory leak problems, since my early
    coding days. And once I can get a beta of my game released, you're
    more than welcome to search for memory leaks. Methinks you won't find
    one. :-)


    --
    SoulEaterRL... Coming soon!

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

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

    Twisted One wrote:

    > Krice wrote:
    >> That is true, but you can try to be extra careful with C++ and
    >> possibly avoid many problems with memory management.
    >> I wouldn't recommend C for anyone, because (afaik) it lacks
    >> those few good memory management techniques that C++ has.
    >
    > C doesn't lack anything that C++ has,

    C lacks RAII. Look that in google RAII with I'm feeling lucky you'll find
    what it means.

    > aside from syntactic sugar and

    Hey, aren't all programing languages just syntaxic sugar on top of a turing
    computer ?
  27. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe Cavalaria wrote:
    >>C doesn't lack anything that C++ has,
    >
    > C lacks RAII.

    There is nothing in either the ANSI C or C++ standard called "RAII".

    > Hey, aren't all programing languages just syntaxic sugar on top of a turing
    > computer ?

    Who uses a turing computer nowadays? A turing computer is a function
    that runs and either hangs or returns a value. That's it. I, for one, am
    using a fairly typical modern interactive computer, and there are
    definitely things you can do in one language but not another. For
    example, Java can't directly access hardware or do manual memory
    management (aside from kludges using arrays or whatever to implement
    your own heap, malloc, and free); C and C++ can but their runtimes don't
    garbage collect for you; some academic/toy languages can't do graphics;
    a lot of academic/toy/scripting languages can't be turned into
    stand-alone, easily distributable executables and instead require any
    user to get, install, and configure a special runtime of some sort or
    another. And there's the system-dependent stuff, too -- C cannot
    portably do graphics, sound, or much of anything else than commandline
    utilities as a matter of fact, whereas Java cannot access a lot of
    OS-specific functionality; nothing on a Mac can return a status, pipe to
    anything, or log stuff to stderr since MacOS (prior to OS X anyway)
    lacks any of these concepts. (This doesn't mean you can't emulate a
    unixy system on one, but that if you compiled many unix utilities on a
    Mac C compiler they wouldn't work, because of the lack of any "command
    line" or "console" and the code's not creating a window or gui of any
    kind. Probably they would fail at the linking stage.) (MacOS X has
    reportedly added a console and other unix stuff under the hood, however.)

    And, of course, the finite memory capacity of real computers also
    distinguishes them from turing ones. :)

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  28. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:


    >>the poor memory management languages include C and C++.
    >
    >
    > That is true, but you can try to be extra careful with C++ and
    > possibly avoid many problems with memory management.
    > I wouldn't recommend C for anyone, because (afaik) it lacks
    > those few good memory management techniques that C++ has.

    The fully garbage collected languages, which include Java,
    Scheme, Lisp, Smalltalk, Python, and several others, negate
    the problem, but at the expense of a certain level of
    control and hardware-interface capability.

    The non garbage collected langauges, which include C, Pascal,
    and several others, rely on the programmer having sound
    memory management techniques and sticking to them.

    Most places inbetween (the refcount-GC languages that don't
    collect cycles, or the obligate-OO languages that require
    memory management to be done in specific ways and places
    not of the programmer's designing) I find less clear and
    useful than either of the extremes.

    The no-dynamic-memory languages such as FORTRAN IV, early
    BASICs, NewLisp, and cousins are a special case; they're hard
    to use as languages, but you won't get into memory management
    trouble.

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

    >
    > Once you've gotten that far, you can refactor your code and maybe
    > retroactively design a cool, flexible architecture. At that point,
    > you'll have a better understanding of the problem.
    >
    > It's a lot easier to fix a working program than an empty source file.

    Yep, i know this from other projects.

    > You might want to consider just storing your game object data in a
    big
    > text file and generating your class source code from it with a script
    > each time you compile. Then, as you start adding wierd monsters (or
    > artifacts, or whatever), you can remove them from the list and
    replace
    > them with hand-coded classes that do the extra special things you
    care
    > about.

    I planed to use XML - with help of Digester library, parsing it is
    piece of cake, and i think that its will be way better then hardcoding
    it directy into code (or then building code from hardcoded list), in my
    experience, hardcoding anything is evil and leads to doom...

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

    > > my world, What rules will be like ( like classes, skills, magic
    ....).
    > > So it's kind of ready to be played in pen-and-paper fashion.
    >
    > Nice! any docs or are they *private*?
    >
    > (makes me think on that project... Greekie??? ;) )
    >

    Well, some basic manual is done, (I actually playtested it with two
    friends), but i won't release it yet, since a lot is missing (= still
    in my head) and it is not that usable.

    >
    > I can only think on a pattern based on patience and a lot of time :D
    >

    :)


    > This can be handled in a lot of ways...
    >
    > For example, you may consider weapons, armor, potions, scrolls etc...
    > to be just Items, they all have common properties, and the thing that
    > differentiates them is the use you put them into... this allows for
    > example to make things such as attacking a monster with a scroll...
    the
    > results of the attack will be dependant on the attributes of the
    scroll
    > as a item, such as its mechanical strength, weight, material, etc...
    >
    > Subclassing has no real advantage here, as you will end up with ugly
    > things such as :
    >
    > if (item instanceof Weapon)
    > int damge = ((Weapon)item).getDamage();
    > else
    > throw GorillaException("You can't attack with that!");
    >
    > However, you may include attributes to each item that indicates their
    > common uses, so that its easier for the UI (or the AI) to select them
    > for each action (for example, if the AI controlled monster wants to
    > drink something, he will first choose from these things that are
    > normally drunk, then he may consider if he wants to drink that ugly
    > looking sword :D )
    >

    Hmm ... I'll metitate over this

    I generally wanted to avoid one Item class that would inevitably become
    really bloated ...

    And i guess that in some way, instanceof is invetiable ... if i dont
    want mz chraracter try to read armor or eat books

    Well, i could use interfaces instead if subclases, and have item object
    have its Weapon part as enclosed object (
    if (Item.getWeapon != null) {
    Item.getWeapon.attack(Creature);
    } else {
    say "Your attacks with " + Item.getName + " are furtile.";
    }

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

    Petr Prokop wrote:

    > I planed to use XML - with help of Digester library, parsing it is
    > piece of cake, and i think that its will be way better then
    > hardcoding it directy into code (or then building code from hardcoded
    > list), in my experience, hardcoding anything is evil and leads to
    > doom...

    Noob wondering, is making a class of 2000+ lines for Objects of
    Description evil?

    > say "Your attacks with " + Item.getName + " are furtile.";

    I'm personally against long messages. They make you skimming thru waves
    of messages, potentially skip important ones every time you cast an
    area spell.
  32. Archived from groups: rec.games.roguelike.development (More info?)

    Risto Saarelma wrote:
    > So as long as you keep your dynamically allocated memory inside smart
    > pointers, you never have to remember to call delete.

    I wasn't talking about smart pointers, they are way too complicated
    for me:)
    I was referring to data encapsulation. It's much safer than passing
    misc. things to C-functions or even using global variables. Also when
    you use classes it automatically forces to make better, more focused
    code.
  33. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-05-18, Twisted One <twisted0n3@gmail.invalid> wrote:
    >> and then refer to the subclasses as BigMainClass.Foo etc.
    >
    > I.e. a class full of inner classes as a pseudopackage, minus the
    > readability advantage of being able to import the declarations and just
    > refer to Foo. Which then leads to using BMC instead of BigMainClass as
    > the name and still having a million senseless and bloating copies of the
    > string "BMC" all over your sources. It's just plain ugly and gross.

    Not in Java 1.5, as far as I understand.

    You just write

    import static BigMainClass.*;

    at the top of your source file, and all the public static stuff inside
    BigMainClass is usable without the BigMainClass. prefix after that.

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

    On 2005-05-18, Twisted One <twisted0n3@gmail.invalid> wrote:
    > Krice wrote:
    >> I wouldn't recommend C for anyone, because (afaik) it lacks
    >> those few good memory management techniques that C++ has.
    >
    > C doesn't lack anything that C++ has, aside from syntactic sugar and
    > exceptions. Exceptions are the only thing a C runtime lacks that a C++

    The memory management technique Krice might be talking about are smart
    pointers. The idea is that you have a smart pointer object, which lives
    in the stack, and which points to dynamic memory allocated from the
    heap. The useful part is that when the smart pointer (or its last
    remaining copy or its latest copy, there are many possibilities here) is
    removed from stack, the smart pointer's destructor is called and it
    frees the dynamic memory. Since the smart pointer object itself isn't a
    heap object but a stack object, it doesn't need to be released with free
    itself. The smart pointer's * and -> operators are of course overloaded
    so that it behaves just like an ordinary pointer as those are used.

    So as long as you keep your dynamically allocated memory inside smart
    pointers, you never have to remember to call delete. Just throw away the
    smart pointer when you don't need it, and the memory gets freed. This is
    something that can't be done in C, as C has no way of defining custom
    destructors for stack objects.

    There is a smart pointer class named auto_ptr in the C++ standard
    library.

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

    tongHoAnh wrote:
    > Petr Prokop wrote:
    >
    > > I planed to use XML - with help of Digester library, parsing it is
    > > piece of cake, and i think that its will be way better then
    > > hardcoding it directy into code (or then building code from
    hardcoded
    > > list), in my experience, hardcoding anything is evil and leads to
    > > doom...
    >
    > Noob wondering, is making a class of 2000+ lines for Objects of
    > Description evil?)
    >

    Huh? Please, explain in more detail what you mean.

    >
    > > say "Your attacks with " + Item.getName + " are furtile.";
    >
    > I'm personally against long messages. They make you skimming thru
    waves
    > of messages, potentially skip important ones every time you cast an
    > area spell.

    Hey, it was just dummy example ...

    Anyway, I always liked idea of LogLevel - let player decide what amount
    of messages he wants. (And, even retroactively display more or less as
    he sees fit when viewing message log)
  36. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:
    > and C++. Java scaling is iffy -- being forced at gunpoint to use
    > separate source files for every class leads to file multiplication.
    Once
    > you have more than 10 source files, you've exceeded most editors' MRU

    > list capacities, which means you have to hunt around in the File Open

    > dialog every so often when the project grows big enough, resulting in
    a
    > sudden jump in workload. Combining these effects is particularly

    You propably never seen Ecplise in action. It's really strong IDE (I
    dare to say that its the best one nowadays.), it makes SmallTalk gui
    feel unconfortable, unnavigable, unfriendly. And SmallTalk has good IDE

    > pernicious. OTOH, a Smalltalk image can be used to develop
    arbitrarily
    > many classes without going to a file dialog once, while still
    organizing
    > them in a hierarchy browser inside the runtime. You can later file
    them
    > out -- all of your changes into one monolithic text file, or one per
    > class, or however you want.

    In eclipse, files go to back seat, you navigate by /definitions/ and
    /uses/, not by files or classes. Refactoring goes even better than in
    SmallTalk

    > And C, C++, and Python files can contain as
    > many statements, declarations, etc. that you wish. (In fact, Python

    And? this is not exactly what i would call advantage.

    > files and filed out Smalltalk code really consists purely of
    executable
    > statements. Class and method and other declarations in both languages

    > are actually executable statements, from which much flexibility
    derives.
    > And the potential for some truly spectacular foot bullets. ;))

    This flexibility comes at cost. Have you ever tried to participate in
    SmallTalk oss project? all that flexibility encourages rogue coding,
    perl-like constructs, namespace weirdness ... and oh ... forget about
    plugins.

    Makes me kinda think about _Self lagnugage which took this to extreme

    I like stricter languages more ...

    So, i'm sticking with Java
  37. Archived from groups: rec.games.roguelike.development (More info?)

    tongHoAnh wrote:
    > Petr Prokop wrote:
    >
    >>I planed to use XML - with help of Digester library, parsing it is
    >>piece of cake, and i think that its will be way better then
    >>hardcoding it directy into code (or then building code from hardcoded
    >>list), in my experience, hardcoding anything is evil and leads to
    >>doom...

    No, he didn't -- the article yours shows as a reply to, by Petr Prokop
    at 5:17 AM (roughly one hour before your post's timestamp), doesn't say
    a thing about XML.

    >>say "Your attacks with " + Item.getName + " are furtile.";

    But it does contain this. And numerous other typos. :)

    > I'm personally against long messages. They make you skimming thru waves
    > of messages, potentially skip important ones every time you cast an
    > area spell.

    Groups of identical messages definitely should be condensed, yes --
    instead of lots of "The orc screams in pain!" you can output "The orcs
    scream in pain!"; with a mixed bag of monsters "The monsters scream in
    pain!"; instead of a lengthy mix of "The orc is confused." and "The orc
    resists." you can say "15 out of 19 orcs are confused; the rest resist."

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  38. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One a écrit :
    > Christophe Cavalaria wrote:
    >
    >> Keeping RAII in mind can help a lot in C++ memory management :)

    I forgot that you were Google impaired. Here is the very first link you
    get on google when you search for RAII : http://www.hackcraft.net/raii/

    > I don't know what this RAII thing of yours is, so I basically just
    > ignored it and assumed ANSI standard C++ is being used.
    >
    >> I think QT and KDE are big enouth C++ projects in themselves. They don't
    >> leak in any perceptible way and don't crash either.
    >
    >
    > Surely you jest. Even if this is true they are the exceptions that prove
    > the rule. Most software is in C or C++. Most software seems to have
    > serious showstopper bugs, including crashes that don't occur
    > consistently in specific circumstances but seem random.

    Most software in a Linux distribution is in C, C++, Sh or Perl. You have
    to admit that most linux distributions don't either leak or crash
    randomly. If you go to the extreme and take a very conservative distro
    like Debian stable, it's even safer ( crashes less than something that
    doesn't crash :) )
  39. Archived from groups: rec.games.roguelike.development (More info?)

    Chris Reuter <cgreuter@csclub.uwaterloo.ca> wrote:
    > Not a structure issue per se., but the one piece of advice I have for
    > you is this:
    > Don't plan.
    > Or, at least, don't plan a lot.

    > The big gotcha with me (and apparently with some other developers as
    > far as I can tell) is to design a roguelike as the Greatest Roguelike
    > Ever, one that requires a zillion lines of code, then only write have
    > a zillion, resulting in something that won't actually run.

    I feel like planning and the problem of feature creep/obsurdly large
    design aren't so exclusive. If you don't have a plan, you'll have no
    end, and if you have no end, you'll never have a game. I think it's ok
    to have obsurdly large goals, but you have to realize that in order to
    release an actual playable game, you're going to have to sit down and
    set some boundries.

    I like OO programming, and think that roguelikes/crpgs are a good
    example of where OOP can be put to very good use. Tons of things are of
    type item. Then there are different types of armor (helms, body armor,
    gloves, etc) each of which CAN be its own class with different
    functions. However, after years of programming, when I decided to make
    something releaseable, in the end both weapons and armor have only two
    meaningful stats: weight and quality. So, now weapons and armor are all
    just items, with a weight and quality and an enumeration for what slot
    they can be worn on (head, on hands, in hands (one or both)) and wether
    they're a weapon or armor. I think this is a good example of where
    grandiose design meets practicality.

    On the other hand, I'm sure plenty of people release games without any
    planning at all. My biggest advice would be to just code your heart out,
    and post here whenever you have even the smallest question.

    --
    Jim Strathmeyer
  40. Archived from groups: rec.games.roguelike.development (More info?)

    "Krice" <paulkp@mbnet.fi> wrote:
    >I was referring to data encapsulation. It's much safer than passing
    >misc. things to C-functions or even using global variables. Also when
    >you use classes it automatically forces to make better, more focused
    >code.

    It is trivial to write awful, poorly focused code in any language capable
    of doing anything meaningful, including Java, C++, and the various
    nonstandard Pascals. Anyone who believes otherwise is tragically
    deluded.
    --
    Martin Read - my opinions are my own. share them if you wish.
    My roguelike games page (including my BSD-licenced roguelike) can be found at:
    http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
    bounce. bounce. bounce. bounce bounce bounce bounce.
  41. Archived from groups: rec.games.roguelike.development (More info?)

    Petr Prokop wrote:
    > You propably never seen Ecplise in action.

    No, and I probably won't, until I have a small supercomputer on this
    desk with several teraflobs and 4GB RAM. To see something "in action"
    requires it actually run at a perceptible speed, which large Java apps
    don't on my hardware, which is less than 2GHz Athlon and only 1GB RAM.
    :/ (Why do Java apps invariably have absurdly high system requirements,
    anyway? Other interpreted languages don't so it's not just VM/emulation
    overhead.)

    > In eclipse, files go to back seat, you navigate by /definitions/ and
    > /uses/, not by files or classes. Refactoring goes even better than in
    > SmallTalk

    Of course I can see that turning into a liability. When it comes time to
    distribute stuff (especially if as source rather than compiled
    executables) you do need to know what files to package. And if you
    grabbed a little of everything that might be every file on your system. :/

    >>And C, C++, and Python files can contain as
    >>many statements, declarations, etc. that you wish. (In fact, Python
    >
    > And? this is not exactly what i would call advantage.

    User freedom of choice is not an advantage?

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  42. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:
    > Petr Prokop wrote:
    > > You propably never seen Ecplise in action.
    >
    > No, and I probably won't, until I have a small supercomputer on this
    > desk with several teraflobs and 4GB RAM. To see something "in action"

    > requires it actually run at a perceptible speed, which large Java
    apps
    > don't on my hardware, which is less than 2GHz Athlon and only 1GB
    RAM.
    >

    AMD 1Ghz, 512 Mb RAM - it is running just fine (not to mention that I'm
    running Tomcat server and have other tools open at the same time ...)

    on other machine (1 GB RAM, 2.5 ghz), its like lightning.

    >
    > > In eclipse, files go to back seat, you navigate by /definitions/
    and
    > > /uses/, not by files or classes. Refactoring goes even better than
    in
    > > SmallTalk
    >
    > Of course I can see that turning into a liability. When it comes time
    to
    > distribute stuff (especially if as source rather than compiled
    > executables) you do need to know what files to package. And if you
    > grabbed a little of everything that might be every file on your
    system. :/
    >

    Files are inteligently moved/renamed when you refactor them ... and
    Eclipse wont mess with anything that it out of project scope

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

    Petr Prokop ha escrito:
    SNIP

    > > This can be handled in a lot of ways...
    > >
    > > For example, you may consider weapons, armor, potions, scrolls
    etc...
    > > to be just Items, they all have common properties, and the thing
    that
    > > differentiates them is the use you put them into... this allows for
    > > example to make things such as attacking a monster with a scroll...
    > the
    > > results of the attack will be dependant on the attributes of the
    > scroll
    > > as a item, such as its mechanical strength, weight, material,
    etc...
    > >
    > > Subclassing has no real advantage here, as you will end up with
    ugly
    > > things such as :
    > >
    > > if (item instanceof Weapon)
    > > int damge = ((Weapon)item).getDamage();
    > > else
    > > throw GorillaException("You can't attack with that!");
    > >
    > > However, you may include attributes to each item that indicates
    their
    > > common uses, so that its easier for the UI (or the AI) to select
    them
    > > for each action (for example, if the AI controlled monster wants to
    > > drink something, he will first choose from these things that are
    > > normally drunk, then he may consider if he wants to drink that ugly
    > > looking sword :D )
    > >
    >
    > Hmm ... I'll metitate over this
    >
    > I generally wanted to avoid one Item class that would inevitably
    become
    > really bloated ...
    >
    > And i guess that in some way, instanceof is invetiable ... if i dont
    > want mz chraracter try to read armor or eat books

    Then use an itemType attribute that won't allow it. =)

    >
    > Well, i could use interfaces instead if subclases, and have item
    object
    > have its Weapon part as enclosed object (
    > if (Item.getWeapon != null) {
    > Item.getWeapon.attack(Creature);
    > } else {
    > say "Your attacks with " + Item.getName + " are furtile.";
    > }

    But what makes different a weapon from another item types?? I guess
    only attributes, because the functionalty it provides must be based in
    the actors involved on its use...

    However, if you encapsulate the functionality inside the Weapon class,
    as in a 'void attack(Creature attacker, Creature defender)', if may be
    worthy to make Weapon an interface; and that would allow you to define
    different sort of attacks in a extensible way

    >
    > --
    > Petr

    --
    Slash
    http://peltkore.net/
  44. Archived from groups: rec.games.roguelike.development (More info?)

    SZDev - Slash wrote:
    >>And i guess that in some way, instanceof is invetiable ... if i dont
    >>want mz chraracter try to read armor or eat books
    >
    > Then use an itemType attribute that won't allow it. =)

    Yeah, but then later on you can bet you'll want to implement a new
    Termite race and it won't be able to eat an obvious source of sustenance!

    (Termite Warriors would of course be great. Warriors normally have no
    use for magic books; termite warriors do, though not the use the
    publisher probably had in mind. And we all know how fierce the fighting
    castes of hive insect species are in combat...and the advantages of a
    significant racial + to AC are pretty obvious.)

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  45. Archived from groups: rec.games.roguelike.development (More info?)

    Twisted One wrote:

    > Groups of identical messages definitely should be condensed, yes --
    > instead of lots of "The orc screams in pain!" you can output "The orcs
    > scream in pain!"; with a mixed bag of monsters "The monsters scream in
    > pain!"; instead of a lengthy mix of "The orc is confused." and "The orc
    > resists." you can say "15 out of 19 orcs are confused; the rest resist."

    Exactly, but the message log now have to update itself in a more
    dynamic way, and thus require more descripting sentences; making 15 out
    of 19 programmers feel lazy, the rest just give up. ;)

    About me 2000+ thingy:

    I made a library.class than store every single game data into giant 2d
    string/int arrays. Does that counts as evil?
  46. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:
    > So you're not alone on that path.


    Yokata!

    *switch to cmd*

    javac -g library.java
    java -Xmx128000000 sewer/main
  47. Archived from groups: rec.games.roguelike.development (More info?)

    tongHoAnh wrote::

    > I made a library.class than store every single game data into giant 2d
    > string/int arrays. Does that counts as evil?

    Yes, but H-World stores data as int/string objects in hashtables which
    isn't so much better :)

    So you're not alone on that path.

    --
    c.u. Hajo
Ask a new question

Read More

Development Video Games