Side project
Krice
I'd like it to be somewhat old and written in C, because I would
like to change it to OOP and also tile based with SDL.
It could be easier (and interesting) to work with that kind
of project than starting a new one.
Elsairon
news:1183299369....@n2g2000hse.googlegroups.com...
You have probably seen this website but just in case
http://www.graveyard.roguelikedevelopment.org/
Hope you find what you're looking for.
Krice
> You have probably seen this website but just in casehttp://www.graveyard.roguelikedevelopment.org/
Yes. Many of abandoned RL's seem to be written in Pascal...
If I don't find anything else I'll probably have to take
over Star Hammer:)
Timofei Shatrov
everyone with this message:
>I'd like it to be somewhat old and written in C, because I would
>like to change it to OOP and also tile based with SDL.
You are a brave man, Krice. The very thought of looking at an old, unmantained C
code makes my skin crawl.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Krice
> The very thought of looking at an old, unmantained C
> code makes my skin crawl.
Nethack's source code is actually quite bad, but then it's
much bigger project than what I want. Star Hammer
is cool, but it's scifi and I don't know what to do with
scifi. It's alien to me.
Corremn
Oh how funny!
Maybe you could find a project you liked (now dead) and ask the author
if you could take it over. I think that people would love to see
their project actually finished rather than never see the light of
day.
Of course you may be able to team up with someone as well, as long as
you can compliment each other.
Radomir 'The Sheep' Dopieralski
Krice wrote:
Maybe you could e-mail the author of Caduria and ask him if
he'd share his source code, as the project is clearly abandoned.
--
Radomir 'The Sheep' Dopieralski
"I'm sure that there has to be some reasonable, rational, sane explanation
for this but I can't quite think of one at the moment."
Krice
> Maybe you could find a project you liked (now dead) and ask the author
> if you could take it over.
If such project exist which I like.. I really hate when authors
stop making the project and then don't even release the source
code. What's the purpose of doing so? All that work wasted
when the source code stays closed.
For example Legend Of Saladir. The source was never
released. One possible explanation is that the author died.
> I think that people would love to see their project actually
> finished rather than never see the light of day.
I don't know about that, but I like to optimize source code.
Re-factoring C to C++ is ideal for that purpose. Then someone
could continue developing the game content, because it would
be easy and joyful to maintain source code which I wrote.
> Of course you may be able to team up with someone as well, as long as
> you can compliment each other.
I don't compliment anything.
Krice
wrote:
> Maybe you could e-mail the author of Caduria and ask him if
> he'd share his source code, as the project is clearly abandoned.
You can hardly call that a small side project.
Patric Mueller
> On 3 heinä, 03:07, Corremn <corr...@dodo.com.au> wrote:
>> Maybe you could find a project you liked (now dead) and ask the author
>> if you could take it over.
>
> If such project exist which I like.. I really hate when authors
> stop making the project and then don't even release the source
> code. What's the purpose of doing so? All that work wasted
> when the source code stays closed.
Well, sometimes the code would have better stayed closed.
For example trying to use the code of the original Netscape Navigator
only wasted time until the developer decided to start from scratch.
>> I think that people would love to see their project actually
>> finished rather than never see the light of day.
>
> I don't know about that, but I like to optimize source code.
> Re-factoring C to C++ is ideal for that purpose. Then someone
> could continue developing the game content, because it would
> be easy and joyful to maintain source code which I wrote.
You make it sound like creating content is much easier than
programming the framework of the game.
Bye
Patric
--
Random fortune cookie:
Ut desint vires, tamen est laudanda voluntas
Slash
> On 3 heinä, 03:07, Corremn <corr...@dodo.com.au> wrote:
>
> > Maybe you could find a project you liked (now dead) and ask the author
> > if you could take it over.
>
> If such project exist which I like.. I really hate when authors
> stop making the project and then don't even release the source
> code. What's the purpose of doing so? All that work wasted
> when the source code stays closed.
> For example Legend Of Saladir. The source was never
> released.
It was his work, and it was his choice. So, don't hate him just
because he didn't release his source. At least he released a playable
build.
>One possible explanation is that the author died.
Don't joke about it... that's not funny.
>
> > I think that people would love to see their project actually
> > finished rather than never see the light of day.
>
> I don't know about that, but I like to optimize source code.
> Re-factoring C to C++ is ideal for that purpose. Then someone
> could continue developing the game content, because it would
> be easy and joyful to maintain source code which I wrote.
Yes, please tell me when you are done "optimizing" the source code.
I'd love to live through the magnificent and joyful experience of
mantaining a source code written by you.
>
> > Of course you may be able to team up with someone as well, as long as
> > you can compliment each other.
>
> I don't compliment anything.
Off course you dont
--
Slash (Castlevania, Drash, Metroid and Zelda Roguelikes)
The Villa of Darkness: [http://www.santiagoz.com/web]
Temple of The Roguelike: [http://www.roguetemple.com]
Krice
> You make it sound like creating content is much easier than
> programming the framework of the game.
(Hope this works this time..)
Well, I think for someone it is easier, because there are
creative people who aren't that good programmers, and
good programmers who are in trouble when it's time to
create some content.
Krice
> So, don't hate him just because he didn't release his source.
Why not?
> >One possible explanation is that the author died.
> Don't joke about it... that's not funny.
I'm not joking.
He seems to have disappeared from internet which is a bad
sign I guess. No web pages, blog or anything as far as
I know.
> I'd love to live through the magnificent and joyful experience of
> mantaining a source code written by you.
If I find a good project to take over then I'm going to
release the source.
Gamer_2k4
>>> you can compliment each other.
>> I don't compliment anything.
> Off course you dont
Complement != compliment. Just throwing that out there.
--
Gamer_2k4
Gamer_2k4
> programming the framework of the game.
In my experience, it is. For my main project, I have pages and pages
of content planned, but the framework isn't done yet. For my 7DRL,
Magic Monsters, adding content is a breeze now that the framework IS
done.
Then again, maybe I'm more creative than programmatic. (Yes, I know
it's not a word.)
--
Gamer_2k4
Slash
He doesnt compliment anything
>
> --
> Gamer_2k4
--
Slash
Nik Coughlin
Corremn
Obviously I meant complement, compliment and krice are mutually
exclusive.
Björn Ritzl
Don't be too hard on Krice. I sense a change is his way of expressing
himself lately. More modest and not as "aggressive" (this will probably
come back and bite me).
/Björn
Krice
> Complement != compliment. Just throwing that out there.
Nice.
By the way, the author of Saladir could be worse than dead.
What I fear happened is that he sacrificed himself to work
and became a worker ant for some high tech company like Nokia.
It's pretty common in Finland that we live to work and
worship the false god Nokia.
Slash
I have been trying hard to track him, with no luck.
His last post here was around '03, after being gone from '99 or so...
none of the two email adresses I have are working. He seemed to have a
music band or something but that seems to be inactive. I hope it is
just what you say... it is weird to just disappear like that..
Ido Yehieli
> I wonder is there abandoned RL project that I could continue?
> I'd like it to be somewhat old and written in C, because I would
> like to change it to OOP and also tile based with SDL.
Krice
> http://caverover.rogueforge.net/
Hey, it's written by you. I don't want to hurt your
feelings, but the source code is.. not good.
It's quite interesting and it's small enough not to
become too much work. If I decide to try then first
thing I'm going to do is get rid of curses and libfov...
Ido Yehieli
no prob. I think it was one of the first c programs I've written, so
it doesn't surprise me that it's not a shining beacon of proper c
programming.
What did you find bad about it?
-Ido,
Slash
I don't want to hurt your feelings, but the last thing I would ever do
would be letting you work on the source code of one of my projects :)
Patric Mueller
>> You make it sound like creating content is much easier than
>> programming the framework of the game.
>
> In my experience, it is. For my main project, I have pages and pages
> of content planned, but the framework isn't done yet. For my 7DRL,
> Magic Monsters, adding content is a breeze now that the framework IS
> done.
In my experience the hard part about programming is acknowledging your
limits. A lot of failed programming projects are due to the
programmers trying things they barely understand let alone would be
able to maintain.
With programming, in contrast to content, simpler is usually better.
Although combining programming and content to a good gameplay is a
completely different beast.
> Then again, maybe I'm more creative than programmatic. (Yes, I know
> it's not a word.)
That's just creative usage of the language. :)
Bye
Patric
konijn_
Oh boy, you asked that publicly ;)
Well, first is magical constants:
attron(COLOR_PAIR(5));
Then, assuming screen will always be 80 wide:
mvaddstr(4,60,"Hit Points:");
Then,
void display_attribute(char * attribute, char * value, int line) {
mvaddstr(line,60,attribute);
mvaddstr(line,61+strlen(attribute)," ");
attron(COLOR_PAIR(5));
mvaddstr(line,61+strlen(attribute),value);
attroff(COLOR_PAIR(5));
}
60 and 61 are linked logically but not codewise,a constant with +1
could be better.
Then, you have spelling mistakes in variable names ( experiance )
Then,
enemy->symbol= prototype->symbol;
enemy->color= prototype->color;
enemy->hp=prototype->hp;
enemy->damage=prototype->damage;
enemy->hear_radius=prototype->hear_radius;
enemy->view_radius=prototype->view_radius;
enemy->angle=prototype->angle;
enemy->experiance=prototype->experiance;
enemy->speed=prototype->speed;
enemy should have a pointer to prototype so it doesnt have to store
symbol,color,maxhp,radiuses, experience and maybe some more.
All in all, your code is not bad, you do have a good fov and its seems
to work for more than 1 OS, which is pretty good I like to think. Oh,
and COMMENT your code!
T.
>
> -Ido,
Krice
> What did you find bad about it?
It's pretty unreadable.. in fact I have difficulties to
read it. I think it could be easier just start from scratch..
Ray Dillinger
> Then,
> enemy->symbol= prototype->symbol;
> enemy->color= prototype->color;
> enemy->hp=prototype->hp;
> enemy->damage=prototype->damage;
> enemy->hear_radius=prototype->hear_radius;
> enemy->view_radius=prototype->view_radius;
> enemy->angle=prototype->angle;
> enemy->experiance=prototype->experiance;
> enemy->speed=prototype->speed;
>
> enemy should have a pointer to prototype so it doesnt have to store
> symbol,color,maxhp,radiuses, experience and maybe some more.
Actually, you're objecting to a standard mechanism for instance-
based OO. The initializer copies the values from a prototype
and the instance stores locally the values of things that can
be overridden individually by a later initializer (specializer).
Multiple inheritance can then be expressed on a single-object
basis simply as the sequence of initializers called on the
instance.
I'm guessing you've only ever seen type-based OO?
Bear
Andrew Sidwell
The source code is small enough that I can get a decent idea of how it
all fits together in a few minutes browsing via the SVN interface.
Reading the code isn't hard at all; perhaps a more liberal use of
whitespace would help, but I don't understand in what way "it's pretty
unreadable".
--
Andrew Sidwell
http://rephial.org/ -- the home of Angband
My email address changes monthly, and is the first three letters of the
month (in English), followed by the last two digits of the current year,
@entai.co.uk.
Radomir 'The Sheep' Dopieralski
Krice wrote:
Maybe you should learn some C first? ;)
Gerry Quinn
kon...@gmail.com says...
Magic numbers are not good, but they are not the greatest of sins as
regards making code usable IMO.
> Then, you have spelling mistakes in variable names ( experiance )
Not too much of a problem in statically-typed languages with early
binding, such as C.
> Then,
> enemy->symbol= prototype->symbol;
> enemy->color= prototype->color;
> enemy->hp=prototype->hp;
> enemy->damage=prototype->damage;
> enemy->hear_radius=prototype->hear_radius;
> enemy->view_radius=prototype->view_radius;
> enemy->angle=prototype->angle;
> enemy->experiance=prototype->experiance;
> enemy->speed=prototype->speed;
>
> enemy should have a pointer to prototype so it doesnt have to store
> symbol,color,maxhp,radiuses, experience and maybe some more.
Maybe... maybe not. I did something similar to the above in my game
too. It allows for variation among individual enemies, and it allows
you to construct enemies that do not have prototypes. While I did not
implement either, I like to retain the freedom to do so.
Also, suppose you take something out of the prototype at a later stage
- for example you might decide to allow the maximum HP to vary between
different individuals.
Unless you use access functions like GetMaxHP() even in the code
belonging to the class whose max HP it is, you'll have to pick through
the code looking for references to prototype->maxHP, and changing them.
- Gerry Quinn
--
Lair of the Demon Ape
http://indigo.ie/~gerryq/lair/lair.htm
konijn_
Myeah, except that experience learns that some values will never be
overridden, thus making it pointless to copy everything over ( waste
of time and memory ).
> I'm guessing you've only ever seen type-based OO?
I wouldnt know, I dont care enough to wikipedia that and confirm or
deny your guess ;)
Note that the only serious object oriented roguelike ( tyrant ) , also
does not copy all values. When a value is needed, it uses the get
method of the super class if it cannot find a value instead of
containing all values.
Cheers,
T.
>
> Bear
Jeff Lait
> In article <1183595293.607008.130...@c77g2000hse.googlegroups.com>,
> kon...@gmail.com says...
>
> > On Jul 4, 12:13 pm, Ido Yehieli <Ido.Yehi...@gmail.com> wrote:
> > > no prob. I think it was one of the first c programs I've written, so
> > > it doesn't surprise me that it's not a shining beacon of proper c
> > > programming.
>
> > > What did you find bad about it?
>
> > Oh boy, you asked that publicly ;)
>
> > Well, first is magical constants:
> > attron(COLOR_PAIR(5));
>
> > Then, assuming screen will always be 80 wide:
> > mvaddstr(4,60,"Hit Points:");
>
> > Then,
> > void display_attribute(char * attribute, char * value, int line) {
> > mvaddstr(line,60,attribute);
> > mvaddstr(line,61+strlen(attribute)," ");
> > attron(COLOR_PAIR(5));
> > mvaddstr(line,61+strlen(attribute),value);
> > attroff(COLOR_PAIR(5));
> > }
>
> > 60 and 61 are linked logically but not codewise,a constant with +1
> > could be better.
>
> Magic numbers are not good, but they are not the greatest of sins as
> regards making code usable IMO.
They are still a sin, however. The author did ask for feedback.
Whenever possible, use enums. When enums are not possible, use const
int or #defines. enums have the nice advantage of being type-checked
in C++ so if you have:
#define ITEM_BOOK 5
#define MOB_SLUG 3
MOB *createMob(int mobid);
You could accidentally type
mob = createMob(ITEM_BOOK);
and have it compile just fine.
enum ITEM_NAME
{
ITEM_BOOK = 5,
};
enum MOB_NAME
{
MOB_SLUG = 3,
};
MOB *createMob(MOB_NAME mobid);
mob = createMob(ITEM_BOOK);
is now properly a compiler error as one would expect.
This might seem a really silly example, but consider the case of a
function that takes both a mob id and an item id for which you forget
which order to pass the parameters in.
> > Then, you have spelling mistakes in variable names ( experiance )
>
> Not too much of a problem in statically-typed languages with early
> binding, such as C.
Agreed, this isn't that serious of a problem. Especially if you are
consistent. The danger is, of course, you end up with
class MOB
{
..
int myExperiance;
...
int myExperience;
...
};
> > Then,
> > enemy->symbol= prototype->symbol;
> > enemy->color= prototype->color;
> > enemy->hp=prototype->hp;
> > enemy->damage=prototype->damage;
> > enemy->hear_radius=prototype->hear_radius;
> > enemy->view_radius=prototype->view_radius;
> > enemy->angle=prototype->angle;
> > enemy->experiance=prototype->experiance;
> > enemy->speed=prototype->speed;
>
> > enemy should have a pointer to prototype so it doesnt have to store
> > symbol,color,maxhp,radiuses, experience and maybe some more.
>
> Maybe... maybe not. I did something similar to the above in my game
> too. It allows for variation among individual enemies, and it allows
> you to construct enemies that do not have prototypes. While I did not
> implement either, I like to retain the freedom to do so.
Gerry has the right of it here, IMHO. Making copies of the prototype
data is a good idea if you plan on that data being dynamic. There is,
of course, a trade off. In POWDER I am reluctant to move stuff out of
the prototype because of the memory cost associated with it.
Extracted from POWDER's source code:
mob->myDefinition = definition;
mob->myExpLevel = glb_mobdefs[definition].explevel;
mob->myExp = 0;
mob->myHitDie = glb_mobdefs[definition].hitdie * 2;
mob->myHP = rand_dice(glb_mobdefs[definition].hp);
mob->myMaxHP = mob->myHP;
mob->myMagicDie = glb_mobdefs[definition].mpdie * 2;
mob->myMP = rand_dice(glb_mobdefs[definition].mp);
mob->myMaxMP = mob->myMP;
Note that some things are extracted directly from the prototype
(myExpLevel) while others are a function of the prototype (HP is a
result of rolling the dice structure in the hp structure of the
prototype)
You'll also notice that I do keep a "pointer" to the prototype around
to get all of the extra data that isn't dynamic.
> Also, suppose you take something out of the prototype at a later stage
> - for example you might decide to allow the maximum HP to vary between
> different individuals.
>
> Unless you use access functions like GetMaxHP() even in the code
> belonging to the class whose max HP it is, you'll have to pick through
> the code looking for references to prototype->maxHP, and changing them.
And here we disagree. You should already be using access functions
like getMaxHP(), even in the code belonging to the class in question,
for this very reason.
Again, directly from POWDER:
int getHP() const { return myHP; }
int getMaxHP() const { return myMaxHP; }
void incrementMaxHP(int amount);
void setMinimalHP() { myHP = 1; }
void setMaximalHP() { myHP = myMaxHP; }
void forceHP(int hp) { myMaxHP = myHP = hp; }
int getHitDie() const { return myHitDie / 2; }
I am very careful never to directly manipulate myMaxHP within the
code, by going through these functions I can ensure it is always done
in a consistent fashion. You will notice some of these look silly -
getHP(), for example. However, getHitDie() shows where it comes in
use - when I switched to fractional hit dice, the internal integer
myHitDie started to refer to twice the conventional hit dice, thus the
need to divide by two.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Ido Yehieli
> It's pretty unreadable.. in fact I have difficulties to
> read it. I think it could be easier just start from scratch..
Well in case you change your mind (or anyone else would want to change
something) I think the subversion server is configured to allow
anonymous commits (at least I don't remember ever having to enter a
password to commit anything), so feel free to correct whatever part
you feel needs correcting :)
Slash
> On Jul 5, 9:06 am, Gerry Quinn <ger...@indigo.ie> wrote:
>
>
>
> > In article <1183595293.607008.130...@c77g2000hse.googlegroups.com>,
> > kon...@gmail.com says...
>
SNIP
> };
> > > Then,
> > > enemy->symbol= prototype->symbol;
> > > enemy->color= prototype->color;
> > > enemy->hp=prototype->hp;
> > > enemy->damage=prototype->damage;
> > > enemy->hear_radius=prototype->hear_radius;
> > > enemy->view_radius=prototype->view_radius;
> > > enemy->angle=prototype->angle;
> > > enemy->experiance=prototype->experiance;
> > > enemy->speed=prototype->speed;
>
> > > enemy should have a pointer to prototype so it doesnt have to store
> > > symbol,color,maxhp,radiuses, experience and maybe some more.
>
> > Maybe... maybe not. I did something similar to the above in my game
> > too. It allows for variation among individual enemies, and it allows
> > you to construct enemies that do not have prototypes. While I did not
> > implement either, I like to retain the freedom to do so.
>
> Gerry has the right of it here, IMHO. Making copies of the prototype
> data is a good idea if you plan on that data being dynamic. There is,
> of course, a trade off. In POWDER I am reluctant to move stuff out of
> the prototype because of the memory cost associated with it.
>
> Extracted from POWDER's source code:
>
SNIP
>
> Note that some things are extracted directly from the prototype
> (myExpLevel) while others are a function of the prototype (HP is a
> result of rolling the dice structure in the hp structure of the
> prototype)
In my games I keep a reference to the definition and only copy the
fields that I know are bound to change, and I access the rest of them
via the definition, something like this
Monster(MonsterDefinition def){
myDefinition = def;
setMaxHP(def.getMaxHP());
setAttack(def.getAttack());
/*etc*/
}
Appearance getAppearance(){
return myDefinition.getApperance();
}
int getMaxHP(){
return maxHP;
}
>
> You'll also notice that I do keep a "pointer" to the prototype around
> to get all of the extra data that isn't dynamic.
I think that's equivalent to the way I make it?
> > Also, suppose you take something out of the prototype at a later stage
> > - for example you might decide to allow the maximum HP to vary between
> > different individuals.
SNIP
> int getHitDie() const { return myHitDie / 2; }
>
> I am very careful never to directly manipulate myMaxHP within the
> code, by going through these functions I can ensure it is always done
> in a consistent fashion. You will notice some of these look silly -
> getHP(), for example. However, getHitDie() shows where it comes in
> use - when I switched to fractional hit dice, the internal integer
> myHitDie started to refer to twice the conventional hit dice, thus the
> need to divide by two.
In this case, the hitDie attribute depends on a formula (division by
2), you can also find the case of attributes that dont really exist as
member variables but instead are calculated based on other attributes.
It is then where the usefulness of "get" methods is fully shown.
--
Slash
R. Dan Henry
wrote:
>Krice wrote:
>> On 4 heinä, 19:13, Ido Yehieli <Ido.Yehi...@gmail.com> wrote:
>>> What did you find bad about it?
>>
>> It's pretty unreadable.. in fact I have difficulties to
>> read it. I think it could be easier just start from scratch..
>
>The source code is small enough that I can get a decent idea of how it
>all fits together in a few minutes browsing via the SVN interface.
>Reading the code isn't hard at all; perhaps a more liberal use of
>whitespace would help, but I don't understand in what way "it's pretty
>unreadable".
Perhaps you are simply much more clever than Krice when it comes in
reading code? In fact, if this is an area where he has unusual troubles,
it would explain his obsession with "code quality" over actually
producing playable games.
--
R. Dan Henry = danh...@inreach.com
If you wish to put anything I post on your website,
please be polite enough to ask first.
Jude H
> It's pretty unreadable.. in fact I have difficulties to
> read it. I think it could be easier just start from scratch..
Based on the idea "It's easier to write code than to read code", I think
it's always easier to start from scratch than to inherit someone else's
mistakes. That is, unless their mistakes come with huge benefits as
well.
--
--j hungerford
Krice
> but I don't understand in what way "it's pretty
> unreadable".
I mean lines like this:
next_step= (!is_blocking_cell(player.x-movment, player.y-movment,
enemy_blocks)) ? -1*movment:0;
Besides the entire structure is so clumsy, I would never
write code like that.
Gerry Quinn
torespon...@hotmail.com says...
> On Jul 5, 9:06 am, Gerry Quinn <ger...@indigo.ie> wrote:
> > In article <1183595293.607008.130...@c77g2000hse.googlegroups.com>,
> > Unless you use access functions like GetMaxHP() even in the code
> > belonging to the class whose max HP it is, you'll have to pick through
> > the code looking for references to prototype->maxHP, and changing them.
>
> And here we disagree. You should already be using access functions
> like getMaxHP(), even in the code belonging to the class in question,
> for this very reason.
>
> Again, directly from POWDER:
>
> int getHP() const { return myHP; }
> int getMaxHP() const { return myMaxHP; }
> void incrementMaxHP(int amount);
> void setMinimalHP() { myHP = 1; }
> void setMaximalHP() { myHP = myMaxHP; }
> void forceHP(int hp) { myMaxHP = myHP = hp; }
> int getHitDie() const { return myHitDie / 2; }
>
> I am very careful never to directly manipulate myMaxHP within the
> code, by going through these functions I can ensure it is always done
> in a consistent fashion. You will notice some of these look silly -
> getHP(), for example. However, getHitDie() shows where it comes in
> use - when I switched to fractional hit dice, the internal integer
> myHitDie started to refer to twice the conventional hit dice, thus the
> need to divide by two.
So why doesn't the fifth function read:
void SetMaximalHP(){ myHP = GetMaxHP(); }
..or, indeed:
void SetMaximalHP() { SetHP( GetMaxHP() ); }
It's just a question of degree.
- Gerry Quinn
Jeff Lait
> Gamer_2k4 <gamer...@gmail.com> wrote:
> >> You make it sound like creating content is much easier than
> >> programming the framework of the game.
>
> > In my experience, it is. For my main project, I have pages and pages
> > of content planned, but the framework isn't done yet. For my 7DRL,
> > Magic Monsters, adding content is a breeze now that the framework IS
> > done.
>
> In my experience the hard part about programming is acknowledging your
> limits. A lot of failed programming projects are due to the
> programmers trying things they barely understand let alone would be
> able to maintain.
I'd say the exact same thing about content. A lot of the
overambitious roguelikes suffer as much from their explosion of
content requirements as they do from their explosion of programming
requirements. If they seem to fail due to programming limitations all
the time, I think that is just because, when faced with an
insurmountable content problem, so many developers figure they'll just
write a program to automagically generate said content.
> With programming, in contrast to content, simpler is usually better.
I couldn't disagree more. Needless complexity in content is the
surest way to fail. As Bear says, if you mix enough colours together,
you always get Brown. (Mind you, I like brown, but that is another
issue...)
Jeff Lait
> In article <1183642011.009625.285...@57g2000hsv.googlegroups.com>,
> torespondisfut...@hotmail.com says...
>
> > Again, directly from POWDER:
>
> > int getHP() const { return myHP; }
> > int getMaxHP() const { return myMaxHP; }
> > void incrementMaxHP(int amount);
> > void setMinimalHP() { myHP = 1; }
> > void setMaximalHP() { myHP = myMaxHP; }
> > void forceHP(int hp) { myMaxHP = myHP = hp; }
> > int getHitDie() const { return myHitDie / 2; }
>
> > I am very careful never to directly manipulate myMaxHP within the
> > code, by going through these functions I can ensure it is always done
> > in a consistent fashion. You will notice some of these look silly -
> > getHP(), for example. However, getHitDie() shows where it comes in
> > use - when I switched to fractional hit dice, the internal integer
> > myHitDie started to refer to twice the conventional hit dice, thus the
> > need to divide by two.
>
> So why doesn't the fifth function read:
>
> void SetMaximalHP(){ myHP = GetMaxHP(); }
Yes, it should read that. Just because I'm careful doesn't mean I
succeed :>
> ..or, indeed:
>
> void SetMaximalHP() { SetHP( GetMaxHP() ); }
There is no setHP() function because I don't want it invoked. Damage
must all go through one specific code path.
> It's just a question of degree.
Very true. I don't intend to advocate blindly following rules. There
is a balance between the two extremes. I tend to think it lies very
close to the "accessor for everything" extreme.
DarkGod
Yeah never writing code is a good way to not produce horrible
lines, continue your on the right path!
Slash
> On Jul 5, 12:20 pm, Andrew Sidwell <j...@entai.co.uk> wrote:
>
> > but I don't understand in what way "it's pretty
> > unreadable".
>
> I mean lines like this:
>
> next_step= (!is_blocking_cell(player.x-movment, player.y-movment,
> enemy_blocks)) ? -1*movment:0;
Whats wrong with that? that's perfectly readable...
> Besides the entire structure is so clumsy, I would never
> write code like that.
Never say never.. perhaps you will do so when you start mantaining it!
--
Slash
Sherm Pendley
> many developers figure they'll just
> write a program to automagically generate said content.
That sounds like an interesting project! Of course, shipping a finished
game isn't on my todo list anyway - I use RL projects as the next step
after "hello world" when learning new languages.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jeff Lait
> On Jul 6, 6:58 am, Krice <pau...@mbnet.fi> wrote:
>
> > On Jul 5, 12:20 pm, Andrew Sidwell <j...@entai.co.uk> wrote:
>
> > > but I don't understand in what way "it's pretty
> > > unreadable".
>
> > I mean lines like this:
>
> > next_step= (!is_blocking_cell(player.x-movment, player.y-movment,
> > enemy_blocks)) ? -1*movment:0;
>
> Whats wrong with that? that's perfectly readable...
1) It line wraps, so those of us with 80 column minds shiver.
2) ? :, like goto and global variables, should be used sparingly.
3) The negation of is_blocking_cell is questionable. This is a ?:
anyways, just reverse the sense of the final component and save
concern when a future reader glosses over the !.
4) Whitespace is incorrectly used. There should be whitespace around
the : to make the operator precedence clear in a casual read. As
written, the :0 looks like a modifier to movement.
5) Debugging this sort of code drives one mad. Line-by-line stepping
in debuggers means you get the line or you don't, no way to trace one
particular path.
6) Movement is spelled wrong.
This is how I would have written that code:
next_step = -1 * movement;
if (is_blocking_cell(player.x-movement, player.y-movement,
enemy_blocks))
next_step = 0;
> > Besides the entire structure is so clumsy, I would never
> > write code like that.
>
> Never say never.. perhaps you will do so when you start mantaining it!
Can we please tone down the sniping of Krice? I should remind people
he *has* released versions of Kaduria. Last one was 0.4.6 in June
2005. Unfortunately, he has chosen to pull the release from his
website pending his current refactor. Unlike Shockfrost, he can and
has actually written real code. His current OOP crusade stems not
from some random book learning, but from his own experience
refactoring Kaduria.
My concern is that this sniping is going to convince Krice that he can
only release Kaduria when it is "perfect". We all, however, realize
roguelikes never reach that stage. I'd rather see the next work-in-
progress release occur sooner than later.
Slash
> On Jul 6, 10:08 am, Slash <java.ko...@gmail.com> wrote:
>
> > On Jul 6, 6:58 am, Krice <pau...@mbnet.fi> wrote:
>
> > > On Jul 5, 12:20 pm, Andrew Sidwell <j...@entai.co.uk> wrote:
>
> > > > but I don't understand in what way "it's pretty
> > > > unreadable".
>
>
> My concern is that this sniping is going to convince Krice that he can
> only release Kaduria when it is "perfect". We all, however, realize
> roguelikes never reach that stage. I'd rather see the next work-in-
> progress release occur sooner than later.
I posted a reply but seems the google monster ate it :P
> --
> Jeff Lait
> (POWDER:http://www.zincland.com/powder)
--
Slash
R. Dan Henry
<torespon...@hotmail.com> wrote:
>Unlike Shockfrost, he can and
>has actually written real code.
Shockfrost also produced some code (although surely not so much as
Krice, at least in the RL area). An inability to code does not appear to
have been Shockfrost's problem. Rather it was an inability to think
incrementally. Krice's problem as far as producing anything appears to
be his obsession with a "perfect" roguelike -- both in terms of code and
in terms of being the greatest thing ever. If he was just sitting around
*not writing code* and not sinking all that time into it, it wouldn't be
so unfortunate that he has failed to release something. And no, I don't
count something I'm told was briefly available, but which is now gone.
Krice recalled it, so he himself obviously feels it was not worthy of
release.
Krice
> Krice's problem as far as producing anything appears to
> be his obsession with a "perfect" roguelike -- both in
> terms of code and in terms of being the greatest thing ever.
I don't know why you would have to "produce" games all
the time, especially when they are not full scale
roguelike games. Producing games doesn't mean a thing
if those games are crap. It's like writing bad poetry
all the time and not realizing it's just meaningless
crap. Instead one could really try hard to write good
poems using a lot of time to create them. To perfect them.
Martin Read
>I don't know why you would have to "produce" games all
>the time, especially when they are not full scale
>roguelike games.
Rogue is a full scale roguelike game.
>Producing games doesn't mean a thing
>if those games are crap. It's like writing bad poetry
>all the time and not realizing it's just meaningless
>crap. Instead one could really try hard to write good
>poems using a lot of time to create them. To perfect them.
I shall, at this point, invoke the example of an education establishment
whose pottery instructor carried out an experiment in marking.
It was decreed that half the class (selected at random) should be marked
according to the quality of the single best pot they threw in the
semester, and the other half according to the number of usable pots they
threw in the semester.
The best pots were almost exclusively thrown by the group marked on
quantity rather than quality, because they were throwing and firing as
many pots as the rules on access to the wheels and kilns would allow,
while the group marked on quality were obssessing over getting each pot
perfect.
--
\_\/_/ you take a mortal man and put him in control
\ / and watch him become a god watch people's heads roll
\/ --- Megadeth, "Symphony of Destruction"
Krice
> Rogue is a full scale roguelike game.
I prefer ADOM and Nethack. They are bigger and better.
> The best pots were almost exclusively thrown by the group
> marked on quantity rather than quality
What that has to do with roguelikes?
That wasn't even an analogue. Show me 7DRLs that are better
roguelikes than ADOM for example. You can't, because that
kind of game doesn't exist. You need to make it big and
real roguelike to have any chance against major roguelikes.
Slash
>
> > On Jul 6, 6:58 am, Krice <pau...@mbnet.fi> wrote:
>
> > > On Jul 5, 12:20 pm, Andrew Sidwell <j...@entai.co.uk> wrote:
>
> > > > but I don't understand in what way "it's pretty
> > > > unreadable".
>
> > > I mean lines like this:
>
> > > next_step= (!is_blocking_cell(player.x-movment, player.y-movment,
> > > enemy_blocks)) ? -1*movment:0;
>
> > Whats wrong with that? that's perfectly readable...
I will reply again, risking my former post bubbles up and makes me
feel like a fool.
> 1) It line wraps, so those of us with 80 column minds shiver.
Your better version of the code line wraps as well. I suggest you
update your mindset :)
> 2) ? :, like goto and global variables, should be used sparingly.
I use them a lot, I agree they may not be clear enough for open source
or team based projects. I wouldnt put them at the same level of goto
and global variables though--
> 3) The negation of is_blocking_cell is questionable. This is a ?:
> anyways, just reverse the sense of the final component and save
> concern when a future reader glosses over the !.
I expect the readers of my code to be able to invert their logic at
will when reading it
> 4) Whitespace is incorrectly used. There should be whitespace around
> the : to make the operator precedence clear in a casual read. As
> written, the :0 looks like a modifier to movement.
It looks like an emoticon more than anything else
> 5) Debugging this sort of code drives one mad. Line-by-line stepping
> in debuggers means you get the line or you don't, no way to trace one
> particular path.
> 6) Movement is spelled wrong.
True
> This is how I would have written that code:
>
> next_step = -1 * movement;
> if (is_blocking_cell(player.x-movement, player.y-movement,
> enemy_blocks))
> next_step = 0;
Off course, it looks much better
That doesnt mean the first one was unreadable
> > > Besides the entire structure is so clumsy, I would never
> > > write code like that.
>
> > Never say never.. perhaps you will do so when you start mantaining it!
>
> Can we please tone down the sniping of Krice? I should remind people
> he *has* released versions of Kaduria. Last one was 0.4.6 in June
> 2005. Unfortunately, he has chosen to pull the release from his
> website pending his current refactor.
Can he please tone down the sniping of all the hard work of people
producing new playable games? I should reming him telling all games
are crap and not "Real" compared to his project is rude and
definitively not appropiate.
I know that's just the way he is, and from time to time I felt like
having some fun from some of his sentences, specially the senseless
ones. I wish however he could be more consistent on what he wants...
sometimes he says games are too complicated and he just won't read
some simple tips, then he says games are too simple compared to
Kaduria. One day he says GPL is evil and then he rises complaining an
author folding his source code is fool... I could go on and on...
> Unlike Shockfrost, he can and
> has actually written real code.
Shockfrost released a prototype of his medal idea IIRC
That's nothing compared to the point at which Kaduria was when it was
folded though
> His current OOP crusade stems not
> from some random book learning, but from his own experience
> refactoring Kaduria.
We all know OOP crusades fail when you don't listen to war stories
from fellow veterans that have already been through them
> My concern is that this sniping is going to convince Krice that he can
> only release Kaduria when it is "perfect". We all, however, realize
> roguelikes never reach that stage. I'd rather see the next work-in-
> progress release occur sooner than later.
Krice, my only word is... release something even if it is not
perfect... and accept feedback from people, your own evaluation on the
game will never be enough, even if your are a perfectionist you only
have one way to see things, which can be aided by different eyes...
I hope google doesnt eat my post this time
> --
> Jeff Lait
> (POWDER:http://www.zincland.com/powder)
--
Slash
Slash
> On Jul 7, 1:47 pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
>
> > Rogue is a full scale roguelike game.
>
> I prefer ADOM and Nethack. They are bigger and better.
No, you don't like Nethack, else you are going against your previous
posts.
Besides, it is too simple compared to Kaduria
> > The best pots were almost exclusively thrown by the group
> > marked on quantity rather than quality
>
> What that has to do with roguelikes?
> That wasn't even an analogue.
> Show me 7DRLs that are better
> roguelikes than ADOM for example.
That wasn't even an analogue. 7DRLs have been developed for 7 days,
ADOM is been on and off for almost thirteen years now. Is that even
fair? roguelike development is a question of sacrifice, willpower and
time.
That doesnt prevent them from being Real Roguelikes, many things on
then are much better than your "bigger and better" games; for instance
ZeldaRL as a randomly generated overworld with themed dungeons on
it... does ADOM have it? AliensRL has the dark mood and the survival
factor that NetHack lacks... Letter Hunt! now that was fun and
challenging, is there any angbandish grind on it? do you think these
things are worthless?
> You can't, because that
> kind of game doesn't exist. You need to make it big and
> real roguelike to have any chance against major roguelikes.
That's where you fail, you don't need to make it big, just make it
better
--
Slash
Krice
> We all know OOP crusades fail when you don't listen to war stories
> from fellow veterans that have already been through them
What stories? I think no one has ever said that OOP
was a wrong solution.
> Krice, my only word is... release something even if it is not
> perfect...
I will. I'm keeping a break from Kaduria and programming
for that map generator contest. It's like making a 7DRL
but you don't have to make a game! It's cool. The good
thing about that contest and 7DRLs is that you can try
different solutions for problems, even though 7DRLs don't
become good games.
> even if your are a perfectionist
I'm not. I'm still using C strings and not std::string
and I'm also using C style file routines instead of
C++ streams.
Andrew Sidwell
> I wonder is there abandoned RL project that I could continue?
> I'd like it to be somewhat old and written in C, because I would
> like to change it to OOP and also tile based with SDL.
> It could be easier (and interesting) to work with that kind
> of project than starting a new one.
Moria? :)
(You could have grabbed Angband a while ago, but you missed your chance
there.)
Slash
> Krice wrote:
> > I wonder is there abandoned RL project that I could continue?
> > I'd like it to be somewhat old and written in C, because I would
> > like to change it to OOP and also tile based with SDL.
> > It could be easier (and interesting) to work with that kind
> > of project than starting a new one.
>
> Moria? :)
>
> (You could have grabbed Angband a while ago, but you missed your chance
> there.)
Oh my. That made my heart almost break.
seriously! :D
>
> --
> Andrew Sidwellhttp://rephial.org/-- the home of Angband
>
> My email address changes monthly, and is the first three letters of the
> month (in English), followed by the last two digits of the current year,
> @entai.co.uk.
--
SLash
Krice
> That doesnt prevent them from being Real Roguelikes,
> many things on then are much better than your "bigger
> and better" games;
What "many" things? You can't be serious.
> ZeldaRL as a randomly generated overworld with themed
> dungeons
So what? That doesn't make it good.
> AliensRL has the dark mood and the survival factor
How about the rest of the game?:)
Martin Read
YOu're confusing "perfectionism" with "purism" here :)
>and I'm also using C style file routines instead of
>C++ streams.
Good idea; while there's some good functionality in iostreams, the
syntax makes me want to remove Bjarne's brain with a rusty spork.
Jeff Lait
> On Jul 6, 10:20 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> > This is how I would have written that code:
>
> > next_step = -1 * movement;
> > if (is_blocking_cell(player.x-movement, player.y-movement,
> > enemy_blocks))
> > next_step = 0;
>
> Off course, it looks much better
>
> That doesnt mean the first one was unreadable
It is merely a matter of degree then. Reading code is harder than
writing code, so why make it any harder than absolutely necessary?
I wouldn't call the original code unreadable either. However, I would
not consider it acceptable either.
Your comments about being good enough for open source is irrelevant.
Even closed source, only seen by me, code will be read by me in six
years when I'll have forgotten even the smallest scrap about it. It
is for that future self that I endeavour to keep my code clean. (Mind
you, I shan't claim to do a great job of it. I'm sure one could find
many atrocious things in my 7DRLs, for example.)
> > > > Besides the entire structure is so clumsy, I would never
> > > > write code like that.
>
> > > Never say never.. perhaps you will do so when you start mantaining it!
>
> > Can we please tone down the sniping of Krice? I should remind people
> > he *has* released versions of Kaduria. Last one was 0.4.6 in June
> > 2005. Unfortunately, he has chosen to pull the release from his
> > website pending his current refactor.
>
> Can he please tone down the sniping of all the hard work of people
> producing new playable games? I should reming him telling all games
> are crap and not "Real" compared to his project is rude and
> definitively not appropiate.
Agreed, this behaviour of Krice is inappropriate. The reason I picked
on you, however, is that I have hope that you can rise to the
challenge of looking past. It is a sort of compliment :>
> I know that's just the way he is, and from time to time I felt like
> having some fun from some of his sentences, specially the senseless
> ones.
I was prompted to post because it has seemed like more constant than
time-to-time recently. Again, do with my comments as you wish. I am
no shining example of ignoring flame bait.
> > Unlike Shockfrost, he can and
> > has actually written real code.
>
> Shockfrost released a prototype of his medal idea IIRC
He released a character generator that had you repeatedly select from
a huge list of skills until it quit and saved something meaningless to
a save file. There wasn't even an @ on the screen.
Jeff Lait
> and I'm also using C style file routines instead of
> C++ streams.
This is very wise. C++ streams are such horrible piles of garbage that
I cannot even provide a proper description.
R. Dan Henry
>On Jul 7, 7:47 am, Krice <pau...@mbnet.fi> wrote:
>> What that has to do with roguelikes?
>> That wasn't even an analogue.
>> Show me 7DRLs that are better
>> roguelikes than ADOM for example.
Any 7DRL that doesn't crash beats buggy ADOM for me.
>That wasn't even an analogue. 7DRLs have been developed for 7 days,
>ADOM is been on and off for almost thirteen years now. Is that even
>fair? roguelike development is a question of sacrifice, willpower and
>time.
Proper comparison would be to the 7DRLs someone was creating after 13
years of doing 7DRLs as often as possible. And ADOM was created
incrementally, with public releases and feedback from a large group of
players, so it doesn't reflect Kaduria development process any better
than a 7DRL does.
>> You can't, because that
>> kind of game doesn't exist. You need to make it big and
>> real roguelike to have any chance against major roguelikes.
Really? I don't play Nethack or ADOM. I do play DoomRL. Okay, DoomRL has
had more than a week put into development, but it isn't big and complex,
as you think roguelikes need to be.
>That's where you fail, you don't need to make it big, just make it
>better
Agreed. In fact, with Crawl's Stone Soup adding entrance vaults to
dungeon branches, I'd say all of the major roguelikes have produced
serious flaws in pursuing the "more is better" philosophy.
Which is not to say that I dislike large, complex games. I just don't
confuse size with quality.
dpeg
> On Sat, 07 Jul 2007 15:24:43 -0000, Slash <java....@gmail.com> wrote:
>>That's where you fail, you don't need to make it big, just make it
>>better
>
> Agreed. In fact, with Crawl's Stone Soup adding entrance vaults to
> dungeon branches, I'd say all of the major roguelikes have produced
> serious flaws in pursuing the "more is better" philosophy.
Do you think the entry vaults are in general a bad idea or that are badly
desgined? Too hard?
The goal was to add flavour, make the entries less obscure. I feel that
increasing difficulty a bit after very early game is also called for.
Also note that we actively try to fight the more is better notion
(subconciously, it sits probably somewhat in each of us): we have just
removed to races.
David
Timofei Shatrov
tried to confuse everyone with this message:
>Also note that we actively try to fight the more is better notion
>(subconciously, it sits probably somewhat in each of us): we have just
>removed to races.
(assuming to=two)
For the love of Xom why??? They were already there, they didn't hurt no one, why
remove them? I hate it when removing features is passed as a feature. Chances
are, there were people who enjoyed playing those races for roleplaying or other
reasons.
Down with "less is more" Web 2.0 bullshit!
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Haran Pilpel
> On Sun, 08 Jul 2007 10:31:16 +0200, dpeg <pl...@zio.mathematik.hu-berlin.de>
> tried to confuse everyone with this message:
>
>>Also note that we actively try to fight the more is better notion
>>(subconciously, it sits probably somewhat in each of us): we have just
>>removed to races.
>
> (assuming to=two)
>
> For the love of Xom why??? They were already there, they didn't hurt
> no one, why remove them? I hate it when removing features is passed
> as a feature. Chances are, there were people who enjoyed playing
> those races for roleplaying or other reasons.
Crawl philosophy says that distinct races should provide distinct
gameplay experiences. Otherwise, we would just allow a 'choose your
own aptitudes' race.
If the difference between two races is mainly cosmetic, then it's just
confusing, and makes it harder to play actually different games. Such
races should be removed.
For the same reason, some of the Crawl (and Angband...) options get
removed, if practically no one ever changes them.
Haran
Timofei Shatrov
confuse everyone with this message:
>gr...@mail.ru (Timofei Shatrov) writes:
>
>> On Sun, 08 Jul 2007 10:31:16 +0200, dpeg <pl...@zio.mathematik.hu-berlin.de>
>> tried to confuse everyone with this message:
>>
>>>Also note that we actively try to fight the more is better notion
>>>(subconciously, it sits probably somewhat in each of us): we have just
>>>removed to races.
>>
>> (assuming to=two)
>>
>> For the love of Xom why??? They were already there, they didn't hurt
>> no one, why remove them? I hate it when removing features is passed
>> as a feature. Chances are, there were people who enjoyed playing
>> those races for roleplaying or other reasons.
>
>Crawl philosophy says that distinct races should provide distinct
>gameplay experiences. Otherwise, we would just allow a 'choose your
>own aptitudes' race.
Then make those races different. Removing them is not an appropriate solution.
>For the same reason, some of the Crawl (and Angband...) options get
>removed, if practically no one ever changes them.
How would you know? For example I always use easy_armour=false, yet it
has been removed from init.txt for some reason. Accidentally dropping worn
armour is one of the most annoying things that can happen. It just shouldn't
be true by default. Yet you remove it because it's apparently useless and no one
ever changes it, even though it's not true as my example demonstrates.
Darshan Shaligram
> On Sun, 08 Jul 2007 14:38:36 +0300, Haran Pilpel <har...@gmail.com>
> tried to confuse everyone with this message:
>>Crawl philosophy says that distinct races should provide distinct
>>gameplay experiences. Otherwise, we would just allow a 'choose your
>>own aptitudes' race.
> Then make those races different. Removing them is not an appropriate
> solution.
We happen to disagree.
>>For the same reason, some of the Crawl (and Angband...) options get
>>removed, if practically no one ever changes them.
> How would you know? For example I always use easy_armour=false, yet
> it has been removed from init.txt for some reason.
easy_armour has not been removed.
--
Darshan Shaligram <scin...@gmail.com> Deus vult
Haran Pilpel
> On Sun, 08 Jul 2007 14:38:36 +0300, Haran Pilpel <har...@gmail.com> tried to
> confuse everyone with this message:
>
>>Crawl philosophy says that distinct races should provide distinct
>>gameplay experiences. Otherwise, we would just allow a 'choose your
>>own aptitudes' race.
>
> Then make those races different. Removing them is not an appropriate
> solution.
That requires content creation. Designer time is finite. Would you
want 174 races of which 154 are boring?
>>For the same reason, some of the Crawl (and Angband...) options get
>>removed, if practically no one ever changes them.
>
> How would you know? For example I always use easy_armour=false, yet
> it has been removed from init.txt for some reason. Accidentally
> dropping worn armour is one of the most annoying things that can
> happen. It just shouldn't be true by default. Yet you remove it
> because it's apparently useless and no one ever changes it, even
> though it's not true as my example demonstrates.
easy_armour is still there. Its default name is now easy_unequip
(since it now also handles jewellery), but easy_armour is accepted as
an (admittedly undocumented, and deprecated) alias. This is all
in docs/crawl_options.txt.
Do you have a different example? We've been trying very hard to
make the interface as convenient as possible.
Haran
dpeg
> On Sun, 08 Jul 2007 10:31:16 +0200, dpeg
> <pl...@zio.mathematik.hu-berlin.de> tried to confuse everyone with this
> message:
>
>>Also note that we actively try to fight the more is better notion
>>(subconciously, it sits probably somewhat in each of us): we have just
>>removed two races.
>
> For the love of Xom why??? They were already there, they didn't hurt no
> one, why remove them?
Because they weren't designed well enough. Just differing in some aptitudes
is not enough. We discussed about making Hill Dwarves more interesting but
couldn't get something substantial. More races to kick were discussed but
we decided to leave them in. Also, there are ideas to add further races -
would you want that we add stuff endlessly without reevaluating what's
already there? Their seats will (slowly) be taken by two much more
interesting species, I hope.
> I hate it when removing features is passed as a
> feature. Chances are, there were people who enjoyed playing those races
> for roleplaying or other reasons.
It is a feature here. Just keeping it because someone might like it is also
not enough. We have to decide which are the meaningful choices: the one
between HD and MD was not. If someone comes up with a cool defining idea
for a new dwarven race, we're all ears.
> Down with "less is more" Web 2.0 bullshit!
I have no idea what you are talking about. The slogan and Eeb 2.0 are alien
to me.
In my experience, most things in this world suffer from the 'bigger and
better' slogan. Getting an outcry when doing the opposite surprised me.
David
R. Dan Henry
>R. Dan Henry wrote:
>
>> On Sat, 07 Jul 2007 15:24:43 -0000, Slash <java....@gmail.com> wrote:
>
>>>That's where you fail, you don't need to make it big, just make it
>>>better
>>
>> Agreed. In fact, with Crawl's Stone Soup adding entrance vaults to
>> dungeon branches, I'd say all of the major roguelikes have produced
>> serious flaws in pursuing the "more is better" philosophy.
>
>Do you think the entry vaults are in general a bad idea or that are badly
>desgined? Too hard?
I've only seen enough for Orc and Lair to judge, but they are often
harder than the first few levels of the branch, which is silly. If I
have to wait until I can handle a heavy onslaught of some of the tougher
creatures, then the branch itself will be too easy at first.
>The goal was to add flavour, make the entries less obscure. I feel that
>increasing difficulty a bit after very early game is also called for.
They aren't as bad as the choice to make orcs more interesting by giving
them blowguns (and hey, about the same time, we upgrade blowguns with
the curare needles). Orc Mines used to be a good choice if you were not
finding poison resistance and needed a branch to go to. Now you need
poison resist in Mines more than main Lair.
>Also note that we actively try to fight the more is better notion
>(subconciously, it sits probably somewhat in each of us): we have just
>removed to races.
Consolidation of plain/High/Grey Elves, I hope. I'd rather see the two
Dwarves made distinct than just lose one. Whereas dropping Elves from 5
races to 3 still leaves them pretty numerous.
Krice
> YOu're confusing "perfectionism" with "purism" here :)
I tried std::string for first time when making
town generator for that contest.. it's cool when you have
to construct text from pieces. Just append("text") to
the string. However I had problems when I tried to save
the text with a routine that takes unsigned char*
pointer. Here is how I finally managed to do it:
---
long fs=(long)out.length(); //size of the string
char *out_char=new char[fs]; //needs plain char array for saving
//convert the normal pointer to string type pointer
string::pointer sptr=out_char;
out._Copy_s(sptr,fs,fs,0); //use string's copy function
//we still need reinterpret_cast to unsigned char
pac_file->Save("Dungeon.html",
reinterpret_cast<unsigned char*>(out_char),fs);
---
It's a bit complex isn't it? I didn't know how to
use c_str of std::string..
Obnoxious User
> On Jul 7, 9:28 pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
>> YOu're confusing "perfectionism" with "purism" here :)
>
> I tried std::string for first time when making
> town generator for that contest.. it's cool when you have
> to construct text from pieces. Just append("text") to
> the string. However I had problems when I tried to save
> the text with a routine that takes unsigned char*
> pointer. Here is how I finally managed to do it:
>
> ---
> long fs=(long)out.length(); //size of the string
>
> char *out_char=new char[fs]; //needs plain char array for saving
> //convert the normal pointer to string type pointer
> string::pointer sptr=out_char;
>
> out._Copy_s(sptr,fs,fs,0); //use string's copy function
I'd guess portability isn't a major concern of yours, or are
you aware that _Copy_s is a microsoft specific library extension?
> //we still need reinterpret_cast to unsigned char
> pac_file->Save("Dungeon.html",
> reinterpret_cast<unsigned char*>(out_char),fs);
> ---
>
> It's a bit complex isn't it? I didn't know how to
> use c_str of std::string..
std::vector<unsigned char> v(out.begin(),out.end());
pac_file->Save("Dungeon.html",&v[0],v.size());
But why would a save-function even need to modify the data?
--
Obnoxious User
Krice
> std::vector<unsigned char> v(out.begin(),out.end());
> pac_file->Save("Dungeon.html",&v[0],v.size());
Nice one!
> But why would a save-function even need to modify the data?
It doesn't modify, but I'm not const correct, because it's
so confusing. If something is const then it seems like
everything has to be const and that is not a realistic
option.
Keith H Duggar
> On Jul 8, 7:24 pm, Obnoxious User <O...@127.0.0.1> wrote:
>
> > std::vector<unsigned char> v(out.begin(),out.end());
> > pac_file->Save("Dungeon.html",&v[0],v.size());
>
> Nice one!
Quick warning, &v[0] above will generate undefined behavior
if v is .empty() which will happen above if out is .empty().
> > But why would a save-function even need to modify the data?
>
> It doesn't modify, but I'm not const correct, because it's
> so confusing. If something is const then it seems like
> everything has to be const and that is not a realistic
> option.
It is essentially impossible to avoid some degree of const
correctness in C++. Hence it's desirable to practice const
correctness where feasbile even if you judiciously decide
to avoid it elsewhere.
In the case of pac_file->Save, assuming reasonable semantics
and behavior, I can see no difficulty in defining it to take
unsigned char const *. Better still, being as how your are
practicing with std::string, provide an overload for Save:
Save ( string const & fname, string const & data ) ;
By the way, what type is pac_file? Is it a type defined in
your or a 3rd party library? If you have the source we
could rewrite it to be more C++ friendly.
KHD
Slash
> On Jul 4, 3:55 am, Krice <pau...@mbnet.fi> wrote:
>
> > On 3 heinä, 23:33, Gamer_2k4 <gamer...@gmail.com> wrote:
>
> > > Complement != compliment. Just throwing that out there.
>
> > Nice.
> > By the way, the author ofSaladircould be worse than dead.
> > What I fear happened is that he sacrificed himself to work
> > and became a worker ant for some high tech company like Nokia.
> > It's pretty common in Finland that we live to work and
> > worship the false god Nokia.
>
> I have been trying hard to track him, with no luck.
>
> His last post here was around '03, after being gone from '99 or so...
> none of the two email adresses I have are working. He seemed to have a
> music band or something but that seems to be inactive. I hope it is
> just what you say... it is weird to just disappear like that..
Good news... the man is still alive! :)
He's just been busy with work and stuff... I'm glad I was able to
contact him back :D
--
Slash (Castlevania, Drash, Metroid and Zelda Roguelikes)
The Villa of Darkness: [http://www.santiagoz.com/web]
Temple of The Roguelike: [http://www.roguetemple.com]
Krice
> He's just been busy with work and stuff...
That "and stuff" must be wife and kids! His wife
probably told him to stop making "that silly
computer game".