Sign in with
Sign up | Sign in
Your question

[help] java roguelike development insight needed

Tags:
  • Development
  • Video Games
Last response: in Video Games
Share
Anonymous
May 18, 2005 8:21:22 AM

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)

More about : java roguelike development insight needed

Anonymous
May 18, 2005 9:45:44 AM

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
Anonymous
May 18, 2005 12:20:53 PM

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*
Related resources
Anonymous
May 18, 2005 2:08:56 PM

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."
Anonymous
May 18, 2005 2:24:43 PM

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:) 
Anonymous
May 18, 2005 5:02:45 PM

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
Anonymous
May 18, 2005 5:17:09 PM

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
Anonymous
May 18, 2005 6:10:56 PM

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
Anonymous
May 18, 2005 6:22:13 PM

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.ht...
bounce. bounce. bounce. bounce bounce bounce bounce.
Anonymous
May 18, 2005 6:40:38 PM

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."
Anonymous
May 18, 2005 6:48:51 PM

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
Anonymous
May 18, 2005 7:00:38 PM

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
Anonymous
May 18, 2005 9:13:02 PM

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

--
Anonymous
May 18, 2005 9:14:35 PM

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."
Anonymous
May 18, 2005 9:19:29 PM

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."
Anonymous
May 18, 2005 9:28:38 PM

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."
Anonymous
May 18, 2005 11:22:42 PM

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
Anonymous
May 18, 2005 11:22:43 PM

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."
Anonymous
May 18, 2005 11:39:40 PM

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 :) 
Anonymous
May 18, 2005 11:39:41 PM

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."
Anonymous
May 19, 2005 2:01:08 AM

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
Anonymous
May 19, 2005 4:02:27 AM

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.
Anonymous
May 19, 2005 4:02:28 AM

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."
Anonymous
May 19, 2005 4:02:29 AM

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

--
Anonymous
May 19, 2005 4:02:30 AM

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."
Anonymous
May 19, 2005 4:02:31 AM

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

--
Anonymous
May 19, 2005 4:06:07 AM

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 ?
Anonymous
May 19, 2005 4:06:08 AM

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."
Anonymous
May 19, 2005 4:40:48 AM

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
Anonymous
May 19, 2005 5:58:35 AM

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
Anonymous
May 19, 2005 6:17:04 AM

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
Anonymous
May 19, 2005 7:24:24 AM

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.
Anonymous
May 19, 2005 7:43:59 AM

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.
Anonymous
May 19, 2005 11:19:28 AM

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
Anonymous
May 19, 2005 11:45:05 AM

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
Anonymous
May 19, 2005 12:40:05 PM

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)
Anonymous
May 19, 2005 12:58:19 PM

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
Anonymous
May 19, 2005 2:49:04 PM

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."
Anonymous
May 19, 2005 3:07:28 PM

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 :)  )
Anonymous
May 19, 2005 3:22:58 PM

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
Anonymous
May 19, 2005 4:19:32 PM

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.ht...
bounce. bounce. bounce. bounce bounce bounce bounce.
Anonymous
May 19, 2005 5:40:21 PM

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."
Anonymous
May 20, 2005 6:45:08 AM

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
Anonymous
May 20, 2005 11:08:04 AM

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/
Anonymous
May 20, 2005 6:50:25 PM

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."
Anonymous
May 30, 2005 6:38:48 AM

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?
Anonymous
May 30, 2005 7:09:45 AM

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
Anonymous
May 30, 2005 3:48:43 PM

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
!