Sign in with
Sign up | Sign in
Your question

A New Roguelike needs your ideas...

Last response: in Video Games
Share
Anonymous
June 28, 2005 5:03:10 PM

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

Hey,

First time poster, a few weeks reader, a few years nethack player.

I am posting to get people's ideas for my roguelike "CHAZM".

I have played Nethack off and on for 5-8 years or so (but am not very
good :)  ) and have tried halfheartedly over the years to write a
roguelike in QBASIC (of all things!) and have never gotten much past
"What race would you like to be?_"

It has been a few years sence i tired and in looking for a new project
a few months ago to fill my spare time, i stumbled upon this old idea.
I have done several months of planning and it has been in my constant
thought. Now that in the last few days i have begun to program the
interface and get the project started for the summer, i thought it
would be a good idea to find out what players want...

I guess that i will probably just list out some of my ideas and
questions and you can tell me what you think about them. I am sure ill
miss some stuff so i may add on later. You may also notice that many of
my ideas are vary developed while other equally improtant aspects are
so undecided that it may be surprising that i am already coding. I
decided that i has determined the general structure of my game enough
to start and if not now i would never really be able to plan it well
enough to justify starting later...

I am sure also that my ideas will seem overly ambitious and i will
reply with two statements:
> yes, i know ...and...
> I have planned this game for months and finally only as of this
month honestly think i can pull this off in full... and i know that
this is a huge project

I was also very surprised that there are other roguelikes i knew abotu
nethack, hack, rogue, and recently heard of a game called ADOM (i think
thats it) but it seems like dozens of people on this forum are trying
there hand. I would be itnerested to know what the sucess rate is and
if most people are experimenting or really serious about starting
something new...
Thanks for not falling asleep though my rambling and... here goes:

1) probably a very nethack like premise though, of all things, the
premise is very undeveloped. Something like 30 levels of normal decent
and then 5-10 levels of Hell before performing some task and winning
the game... i really need ideas on this one.

2) Should you immidiatly start in level 1 of the dungeon or should
you start in a village or above ground and have to find the caverns...
If i have the dungeon randomly generated (I have given this a ton of
thought...) then should the hypothetical above ground be set... i
imagine that might get boring after a while having to complete the same
opening every time you die before it gets random again.

3) I am planning on having all of the elemental planes (+ a few
others!) but they will not (probably) be an essental part of the game.
With spells or planar gates you can get there and find things you
couldn't anywhere else. You could also go there just so that you could
fight elementals for experiance...

4) Each level is going to be much bigger then in nethack and wont
fit on the screen. Instead the player is always displayed in the center
of the screen and a moving circle of terrain will move past them as
they walk. Also this makes your sight range (like if you are a dwarf
and thus have darkvision) more important. The levels will be anywhere
from 2x2 to 12x12 times as large as the ones in nehack. (dont worry i
do think i know a way to make this all work out very nicely)

5) My spell system will be like this: manna regenerates over time
in the wizard and through practice of divine worship in a cleric (and
how do you think in a druid?). Only a wizard can cast arcane spells
which can be learned from a spellbook or cast once from a scroll and
the cleric and druic gain spells as special abilities that cost manna
as their levels increase. For the most part my game is unique in its
gameplay but a lot more then in others its rules are based (Losely) on
3rd edition AD&D.

6) the classes/hp are Barbarian/12, Fighter/10,
Cleric/8or9?,Druid/7-9?,Rogue/6,and Wixard or mage / 4. The classes are
in a order of most powerful in raw strength (not the ability) to most
powerful in stratigic strngth. the cleric acts as a balence he/she can
act as a fighter with 8 hp and do well in melee combat but also has
divine power to back him/her up.

7) All terrain is destroyable and have hp and resistances just
like a creature. All items have hp and their resistences are determined
on whether or not they are magic and the material they are made from.
Items can be repared through a skill or by taking the item to a
storekeeper specailist.

8) I am going to have a skill system. Every levelup you gain an
added reserve of you classes base points (BAR=1,WIZ=~3,ROG=6, etc) +
your INTMOD (INTMOD = floor((INT-10)/2.0)) and you can get more also by
reading and performing intelligent activities. You can at any time
expend or invest your skill points on a particular skill at the expense
of 10 or so of your turns and of course the point itself. some skills
will be universal like swimming or weapon repair (though a fighter
might start with 2 on that) while others will be much more expensive
for cirtain classes (e.g. the druid can 'buy' skills on Alchemy and
brew potions at a 1:1 ratio but any other class must spend 3 skill
points for every 1 they actually get on alchemy... 3:1 ratio), finally
others like pick pocket and picklock, and disarm trap will be only for
the, for example, rogue and cannot be purchased at all by any other
class. These skills are important and act as modifiers to rolls made
while using the skill. Each skill could act differently though (e.g.
swimming increaces the weight you are carrying at which you drown while
8 on weapon craft might allow you to always repar a dirk... etc (that
is hypothetical of course thats not really what swimming or
weaponsmithing would do)).

I have to wrap it up now but...

7) I am using a moves system where you are gifted moves at the
begining of a turn as use them up with actions... I do have a system
setup though so this does not slow you down when walking down and empty
coradore that i can expalin in detail if anyone wants.

8)I have a good system for two hand combat i can explain later.. i
have to go but ill write back and answer questions.

I hope that everyone can add their own comments and ideas for this
page. you all can still help shape this new roguelike!

Thanks ahead of time!!

-Thomas

More about : roguelike ideas

Anonymous
June 28, 2005 5:25:07 PM

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

comments@foresightsagas.com wrote:
> and have tried halfheartedly over the years to write a
> roguelike in QBASIC (of all things!)

Don't do that. Learn C++.
And start small:) 
Anonymous
June 28, 2005 6:19:46 PM

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

Whoops... sorry forgot to mention:

I am programing this in Object Oriented C++. I am pretty well learned
in C++, there are cirtainly things ill need to learn with this program
but mostly the programing knowledge is all there but otherwise. I
absolutly agree with you. QBasic doesent work. I was far to idealistic
back then and thought i could do the whole thing with gosubs...

No it will be O-O c++. I am rather surprised that many other roguelikes
arn't done in a very object oriented way... i suppose thats becuase
most are 15 years old...

Thanks for the input, the programing ability is all there, the ideas
are what is needed!

Thanks.

-Thomas
Related resources
Anonymous
June 28, 2005 6:52:17 PM

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

Thanks 4 the input. I will probably still proceed with making chazm
except that I will take it slowely and start with just the basics.
Maybe ill scrap it later. Most of my programing experiance is in
similar situations and i really do feel comfortable writing this. It
wont be easy by any means but i am determined to see it though. Also i
think about this a lot and have some experiance writing them. I have
tried writing a few before in both basic and C. You could say that Ive
already done what you just said and now i am ready to do a large one.
There are problems with my layout but i am not the type of person just
to start hacking. I have already designed most of my controls and Class
Objects in a Class diagram on notecards. The specifics and dynamics of
some of the inner class working are still being developed but all class
interfaces are finished and my general layout is done. What I need the
most is help with the ideas and playablity of my game. Later I may need
help from cpp programers on how to say... avoid RTTI and stuff like
that but for the most part, now, i just need help knowing what people
think of the ideas ive listed above. I hope mostly that we can have a
brainstorm and i can get some feedback on my ideas.

I guess we will all see if my game works out in the end... and i will
keep your advice in mind... i can always use this as practice and
restart if needed... Thanks.

-Thomas

P.S. Your english is not bad. "I truly recommend to start small" could
be changed to "I would recomend you start small", but otherwise its
just fine. I would imagine english is very hard to learn...
Anonymous
June 28, 2005 8:08:28 PM

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

<OffTopic>
Yeah...
Frankly i would count europians lucky in that they are generally much
more widely literate in different languages. The last sentance just
proves it :) 
</OffTopic>

Oh i completely agree with you on that. Its amazing how many times i
have had to do things over. I wrote an expression parser like this

"4-6*sin(0)" becomes the number 4

4 times before succeding finally with a very slow but accurate, with
pretty code, parser just 3 months ago. It wasn't difficult once i
really sat down and was able to plan out a good solution. My last
version was one fuction encpsulated by a handling class. The third one
was mostly functional with 2-3 bugs and was like... 8 global functions!

I will keep in mind that i may need to restart and wont be too attached
to this version but honestly unlike all the other tiems... i can really
feel that this is going to work and i would appreciate some help on the
ideas. I will also keep in mind, because you both seem to think it
would be a good idea, that i might just write a draft that defignitly
WONT be the final version but will be practice. Ill keep the idea
kicking around up there :) 

For now can we just agree that because i already have written several
failed versions (two where you could at least walk around and see walls
and stuff) I am prepared to take on the big preject. This way we can
get down to buseness and work out some of the ideas.

If i ever need advice on how to create demos to practice for a software
project ill know where to come... :) 

Thanks. and lets get on with it. (Though if you want to stay on the
topic of the development of a project itself instead of the projects
content then i did ask a question above about the sucess and purpose of
other people's projects in my first post...)

Thomas
Anonymous
June 28, 2005 8:09:49 PM

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

<OffTopic>
Yeah...
Frankly i would count europians lucky in that they are generally much
more widely literate in different languages. The last sentance just
proves it :) 
</OffTopic>

Oh i completely agree with you on that. Its amazing how many times i
have had to do things over. I wrote an expression parser like this

"4-6*sin(0)" becomes the number 4

4 times before succeding finally with a very slow but accurate, with
pretty code, parser just 3 months ago. It wasn't difficult once i
really sat down and was able to plan out a good solution. My last
version was one fuction encpsulated by a handling class. The third one
was mostly functional with 2-3 bugs and was like... 8 global functions!

I will keep in mind that i may need to restart and wont be too attached
to this version but honestly unlike all the other tiems... i can really
feel that this is going to work and i would appreciate some help on the
ideas. I will also keep in mind, because you both seem to think it
would be a good idea, that i might just write a draft that defignitly
WONT be the final version but will be practice. Ill keep the idea
kicking around up there :) 

For now can we just agree that because i already have written several
failed versions (two where you could at least walk around and see walls
and stuff) I am prepared to take on the big preject. This way we can
get down to buseness and work out some of the ideas.

If i ever need advice on how to create demos to practice for a software
project ill know where to come... :) 

Thanks. and lets get on with it. (Though if you want to stay on the
topic of the development of a project itself instead of the projects
content then i did ask a question above about the sucess and purpose of
other people's projects in my first post...)

Thomas

PS: Please excuse my bad english, I probably sound like i dont actaully
know it..! ;) 
Anonymous
June 28, 2005 10:02:16 PM

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

***Yeah... Thats pretty much everything anyone else has mentioned.

So let me start with questions for you.

1) are nethack, adom, angband, and the such just the ones that really
worked out well and other peoples pet projects just havent or are there
others that are popular... Does a very well made NEW roguelike have a
chance really?

2) would the game be better with .5-3 hours of gameplay in a set
on-earth environment before the player finds the dungeon? I dont think
so but maybe if the level could be built (set) so complex and intricet
with details added with versions such that new discoveries could be
made even after many many games. Also that many parts of the level such
as people and items would be randomized. Hmm, I dont know, it has a
cirtain appeal but it could ruin the game if it were boring. .5-3 hours
of bordom before the fun would make a lot of people quit early.

What does everyone think?
Anonymous
June 29, 2005 12:47:01 AM

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

The screenshot has some problems... it is mostly for testing the
display module. If you hadn't noticed it is a maximized windows form.

The green things in the display are actually just #'s that are green. A
display error im fixing put a vertical black line through them.

if you have any ideas for my game you can write them in. Thanks.

-Thomas
Anonymous
June 29, 2005 5:22:44 AM

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

comments@foresightsagas.com wrote:
> Thanks for the input, the programing ability is all there, the ideas
> are what is needed!

Oh, and another one if nobody mentioned it yet -- "Start small".
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"It must be excellent code -- Mistress Compiler would not have
it any other way." -- Twisted One
Anonymous
June 29, 2005 7:13:10 AM

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

comments@foresightsagas.com wrote:
> Does a very well made NEW roguelike have a chance really?

If it "starts small" then it has a chance to become a real game.
It's really easy for beginners to list features they want in their
game, but what they don't realize is how hard it is to make those
features. If you don't know it yet, you'll learn it sooner or later.
People here are only friendly when they suggest to start small. You
can then extend the gameplay much easier. If you put lots of
features from the beginning you become exhausted by the number of
data that must be handled. That is exactly what happened to me.
Anonymous
June 29, 2005 11:09:42 AM

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

comments@foresightsagas.com wrote:
> ***Yeah... Thats pretty much everything anyone else has mentioned.
>
> So let me start with questions for you.
>
> 1) are nethack, adom, angband, and the such just the ones that really
> worked out well and other peoples pet projects just havent or are there
> others that are popular... Does a very well made NEW roguelike have a
> chance really?

It takes a long time for roguelikes to develop. By a long time I mean
years, not months.

The fact you list ADOM there should be your own answer.

> 2) would the game be better with .5-3 hours of gameplay in a set
> on-earth environment before the player finds the dungeon? I dont think
> so but maybe if the level could be built (set) so complex and intricet
> with details added with versions such that new discoveries could be
> made even after many many games. Also that many parts of the level such
> as people and items would be randomized. Hmm, I dont know, it has a
> cirtain appeal but it could ruin the game if it were boring. .5-3 hours
> of bordom before the fun would make a lot of people quit early.
>
> What does everyone think?

Concentrate on making a fun main dungeon. Only then add stuff.
Successful roguelikes all share the feature that they grew organically
into their current state. Trying to make a roguelike which *starts*
with the complexity of Nethack would be a very forbidding task.
(Unless one branched from the Nethack source, that is)

I agree with all of the "Make it Simple" crowd. I do not necessarily
agree with the "throw out your early attempts" crowd. There is no
reason why you can't take your early barebones roguelike and slowly
rearchitect it into your dream roguelike.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Anonymous
June 29, 2005 2:10:52 PM

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

comments@foresightsagas.com wrote:
> ***Yeah... Thats pretty much everything anyone else has mentioned.

I don't know if you got the joke -- yes, I know.

> So let me start with questions for you.
>
> 1) are nethack, adom, angband, and the such just the ones that really
> worked out well and other peoples pet projects just havent or are there
> others that are popular... Does a very well made NEW roguelike have a
> chance really?

Yes. DoomRL, Gearhead and Dweller are all good examples -- they all have
strong fanbases. Personally I can only talk about DoomRL (for it's my
child) -- I get about one new fanmail every 2-3 days. In the prime time
it was almost 2-3 fanmails per day. People care. And that makes me happy.

Recently my friend stumbled around it. By accidend. Imagine how huge was
my surprise when he recently IMed me and said "Man! Because of your
DoomRL I failed my exam session -- this thing is addictive!". I think
DoomRL was successful -- it was meant to be only a "start
small"-concept-of-proof -- it was never intended to be a game. And look
what happened.

> 2) would the game be better with .5-3 hours of gameplay in a set
> on-earth environment before the player finds the dungeon? I dont think
> so but maybe if the level could be built (set) so complex and intricet
> with details added with versions such that new discoveries could be
> made even after many many games. Also that many parts of the level such
> as people and items would be randomized. Hmm, I dont know, it has a
> cirtain appeal but it could ruin the game if it were boring. .5-3 hours
> of bordom before the fun would make a lot of people quit early.

Exactly. You need to catch the players intrerest during the first five
minutes, or else (unless he's a determinated type) he'll remove your
game from his HD afterwards if nothing draws his attention.
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Oh come on. We both know the truth about this game --
vapourware." -- Anathiel about GenRogue
Anonymous
June 29, 2005 2:12:12 PM

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

comments@foresightsagas.com wrote:
> here is a screenshot.
>
> i will write back again later but i dont have time now.
>
> http://www.foresightsagas.com/software/chazm/pic1.bmp

DON'T post screenshots in BMP format. It's a HUGE waste of bandwith.
(not to mention that nobody will want to download them). There are free
programs that will convert it to GIF, PNG or JPG.
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Some thing's just cannot be programmed in a roguelike. For
everything else, there's GenRogue" -- Anubis
Anonymous
June 29, 2005 2:51:38 PM

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

> 1) are nethack, adom, angband, and the such just the ones that really
> worked out well and other peoples pet projects just havent or are there
> others that are popular... Does a very well made NEW roguelike have a
> chance really?

Kornel mentioned DoomRL, Dweller, and Gearhead.
I will mention others that have held my attention
in the past, some quite simple, some quite sloppy:
Omega, Alphaman, Powder, Decker, IVAN, and Lost
Labyrinth. The latter three are deliberately
limited in scope, but quite interesting and fun
to play. I agree with what another poster said,
"Start small."

There are several roguelikes written about here
that are on the brink, I feel, of becoming very
fun, compelling games. Umbra, for instance,
needs only a jot of content, even in that
haphazard Omega style, and a few interface
tweaks and I would play it regularly.
I've seen several great ideas that only
need a little follow-through and polish,
such as the Egyptian pyramid game that
features door puzzles and ever-growing
level sizes, as well as that robot game,
which had a timing error. I would be much
more likely to play a focused game than
play Gearhead, which is sprawling and
non-linear. I've already tackled
NetHack, and it'll be awhile before
I invest that much time in a game
again.

Respectfully,
Bryce McQuern
Anonymous
June 29, 2005 3:19:32 PM

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

In article <d9tkuf$o67$2@inews.gazeta.pl>, kisielewicz@gazeta.pl
says...
> comments@foresightsagas.com wrote:
> > here is a screenshot.
> >
> > i will write back again later but i dont have time now.
> >
> > http://www.foresightsagas.com/software/chazm/pic1.bmp
>
> DON'T post screenshots in BMP format. It's a HUGE waste of bandwith.
> (not to mention that nobody will want to download them). There are free
> programs that will convert it to GIF, PNG or JPG.

In this instance, BMP run-length-encoding would have reduced it to 46K
(a factor of 50!).

- Gerry Quinn
Anonymous
June 29, 2005 4:50:56 PM

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

Yeah. I have looked at the nethack source but was soon confused by all
of the global veriables and macros. I can mostly read the code but
doubt i could ever modify it... nor do i wish to.

I think my planning already has pretty much destroyed the organic
grownth but i am sure even if all of my wildest plans are implemented
correctly there will be more to "organicly follow."

I think that I will start small in the sense that all i write to begin
with is a 3 level bigroom style dugeon with two types of monsters and a
couple of items for a player to walk around it and then ill expand. I
wont be writing:

class Boots: public Armor {
...
}

or

class Conversation_Plate: {
private:
vector<Conversation_Link> choices
AnsiString response;
... ... etc...
}

anytime soon, but if i dont PLAN to expand and know how I want that to
work.... i am just making it harder for myself.

I dont think anyone has told me yet what they think about the moves
system... It will make the game more strategic and, if done right, not
much slower outside of battle... but it will need a lot of work for it
to flow well... What does everyone think about that... or anything else
for that matter.

Thanks for all of the help.

-Thomas
Anonymous
June 29, 2005 4:54:22 PM

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

Also,

I would have uploaded a JPG but i was in such a hurry i forgot to
switch the type of file it was outputing...

I hope that didn't hurt anyone with a slow connection... :(  sorry

ill upload JPG's (or gif) in the future... as i usually do.

-Thomas

PS: if you want to see some of my smaller projects they are at
www.foresightsagas.com/software

thanks!
Anonymous
June 29, 2005 5:36:11 PM

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

Quoting <comments@foresightsagas.com>:
>1) are nethack, adom, angband, and the such just the ones that really
>worked out well and other peoples pet projects just havent or are there
>others that are popular... Does a very well made NEW roguelike have a
>chance really?

Crawl was new when those were well-established, and Crawl now has a fairly
dedicated fan base.

>2) would the game be better with .5-3 hours of gameplay in a set
>on-earth environment before the player finds the dungeon? I dont think
>so but maybe if the level could be built (set) so complex and intricet
>with details added with versions such that new discoveries could be
>made even after many many games.

No, because then people working from the spoilers just have a lot of
donkey work to do before starting the game.
--
David Damerell <damerell@chiark.greenend.org.uk> flcl?
Today is First Thursday, Presuary.
Anonymous
June 29, 2005 8:33:47 PM

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

comments@foresightsagas.com wrote:
> Yeah. I have looked at the nethack source but was soon confused by all
> of the global veriables and macros. I can mostly read the code but
> doubt i could ever modify it... nor do i wish to.

Could you please keep some context when you reply? It is not clear
what you are referring to when your message just starts with "Yeah".

> I think that I will start small in the sense that all i write to begin
> with is a 3 level bigroom style dugeon with two types of monsters and a
> couple of items for a player to walk around it and then ill expand. I
> wont be writing:
>
> class Boots: public Armor {
> ...
> }

I don't think you should *ever* write that class. That relationship
belongs in definition files, not source.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Anonymous
June 30, 2005 3:09:39 AM

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

Jeff Lait wrote:
> I agree with all of the "Make it Simple" crowd. I do not necessarily
> agree with the "throw out your early attempts" crowd. There is no
> reason why you can't take your early barebones roguelike and slowly
> rearchitect it into your dream roguelike.

Depending on how much you already know about programming, and making a
successful design. I guess I had to throw out my first 2 attempts
because of bad design and a lack of general programming knowledge. I
had to throw out my third attempt because I was using Python (don't get
me wrong, I still think it's a beautiful language to write and read...
but I want it to run at acceptable speed on the computers I pick up off
the side of the street, and that's not what Python does).
My current project, on the other hand... I knew when I began that I had
the design concepts down, and if that had been the case on the first
attempt, there'd have been no chance of me having to start over. But as
for game content, indeed, it is always necessary to start small and
then develop, no matter how much you know about program design.
Having said that, it's good to have an idea of your eventual scope when
building the framework.
--jude hungerford.
Anonymous
June 30, 2005 4:39:03 AM

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

Yep, I am pretty much agreeing with you, start small but develop as
much as possible on paper first so you know where you are expanding to.

What does everyone think about conversation. I mean like baulders gate
style conversation. like...:

Elderly Villager: Yeah, I've heard of a dragon in that forest.. blah
blah...

a) you say: "Thanks for all your help"
b) you say: "What else do you know?"
c) You say: "Is that all you've heard old man!"
d) you look bored and walk away (end conversation)
e) ...
etc

Now, I am sure that ppl are going to tell me that i am going to fail if
i am looking at stuff that conplex but I am trying to develop a
conceptual design so that i can be sure that i am able to implement
this LATER... MUCH, YEARS, LATER.

Does anyone have anythoughts on this...

Has anyone ever tried to create actual random conversation generation
for a RL? with a back and forth and the possibility of them giving you
things and you finding out stuff about the gungeon?

It would be hard... If i could get this to work i would probably run
all shops and shopkeepers through this system. They tell you their
store inv and the approx prices and you tell then what you want to buy.

Any thoughts (please... no: "dont even think about that now" unless you
think it is absolutly impossable! I am really just brainstorming
this... :)  thanks)

-Thomas
Anonymous
June 30, 2005 7:39:45 AM

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

I didn't run the profiler. Having learnt Ocaml, I'd never want to go
back to a pure OO language for this sort of project, but it's true that
if I'd been committed to using Python I probably could have done it.
Attempt #2 was naively written. Attempt #3 reused significant parts
of #2, but fixed areas of bad structure and inefficiency. I do believe
fast(ish) Python code is achieveable, but I wanted to have minimum
system requirements *slower* than my development platform, which was a
PIII 500 MHz. Half-second turns on that machine... even if I could
double or quadruple the speed of the logic, that was never going to run
acceptably on a 100MHz machine, because the screen refreshes through
Pygame were just taking too long. I could have changed the display
specs so that less of the screen actually needed to change, but I
didn't want to change my design specs for a language deficiency. One of
the beautiful things about roguelike games, to me, is that they run as
fast as I can type; no waiting for silly animations or other such
garbage (no offense to anyone who has an animated roguelike, but it's
just not my style).
Plus, I like things to compile to proper native code: I'll
reconsider Python, perhaps, when someone makes a nice optimising
compiler for it. The freezing process just didn't satisfy me.
Basically, I wanted to learn Objective Caml, and I'm glad I did. :) 
Python is still a good alternative to shell scripts for sysadmin stuff,
but it doesn't meet my desires for my roguelike right now.
--jude hungerford.
Anonymous
June 30, 2005 8:03:50 AM

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

Thomas wrote:
> Has anyone ever tried to create actual random conversation generation
> for a RL? with a back and forth and the possibility of them giving you
> things and you finding out stuff about the gungeon?

I believe GearHead has a random conversation system, that might be a
good place to look for ideas on this.

> It would be hard... If i could get this to work i would probably run
> all shops and shopkeepers through this system. They tell you their
> store inv and the approx prices and you tell then what you want to buy.

I don't think I would enjoy this system. Maybe if there were some
conversation accompanied by a clear menu system, but I generally would
prefer only to read conversation if it's conveying something which
could not be handled by menus (as with shops in Moria/Angband) or
symbols on the ground (as with shops in ADOM/NetHack).
The flavour text in shops in Moria was pretty cool, but incidental most
of the time- you only had to pay attention to whether your haggling
offers were causing serious offense.

The Sheep wrote:
> In extreme, you could move the slow parts to C and still use most of the
code you already have.

This is true, but I'm afraid I'm a bit stupid when it comes to C.
Stupid, or unwilling, or something - I just don't like it. Also, I'm
not convinced I would code it more efficiently than the person who
wrote the Python internal equivalent.
I have utmost respect for those who are proficient with either C or
C++. I'm just not one of them right now.
The Ocaml version is now developed almost up to the point the Python
version was when I ditched it- and compiles to native code without
worrying about optimisation in other languages.

--jude hungerford.
Anonymous
June 30, 2005 12:42:28 PM

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

At 29 Jun 2005 23:09:39 -0700,
jude hungerford wrote:

> Jeff Lait wrote:

> I
> had to throw out my third attempt because I was using Python (don't get
> me wrong, I still think it's a beautiful language to write and read...
> but I want it to run at acceptable speed on the computers I pick up off
> the side of the street, and that's not what Python does).

Why not?
Don't get me wrong, I don't want to start a flame war, but I really don't
think that the Python interpreter is so slow. Maybe the code you wrote
could be improved?
In extreme, you could move the slow parts to C and still use most of the
code you already have.

--
Radomir `The Sheep' Dopieralski @**@_
<..> ] 0110110?
. . . ..v.vVvVVvVvv.v.. .
Anonymous
June 30, 2005 3:05:31 PM

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

jude hungerford a écrit :
> Depending on how much you already know about programming, and making a
> successful design. I guess I had to throw out my first 2 attempts
> because of bad design and a lack of general programming knowledge. I
> had to throw out my third attempt because I was using Python (don't get
> me wrong, I still think it's a beautiful language to write and read...
> but I want it to run at acceptable speed on the computers I pick up off
> the side of the street, and that's not what Python does).

Did you try running a profiler to find what parts where running slow ?
Maybe it was just a problem with your implementation.

I was able to get a basic roguelike in Python with very acceptable
performance including : dungeon generation, rendering and FOV raytracing
( naive and slow floating point algorithm ). Of course, now i'll be
working instead on integration C code to make it faster just because I
can do it in a easy way :)  Although I'm still not decided on whever I
should use Pyrex or hand code the thing in C.
Anonymous
June 30, 2005 4:17:52 PM

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

Thanks, I agree with everything said but i think that most of the
conversation would be generated not randomly picked.... it would be
compiled from skeleton conversation plates that could be strung
together by a temperment sorting engine.

Its like how 10 swords are really almost like 100 if they can be
blessed, +1,2, cursed, rusty, etc...

A conversation might be

#person has a temperment toward #event

becomes

Villager speaks in a #moodlookup tone and #feeling the recent slaying
of a beast

Villager in an angry tone: "I Hated that #random_tough as much as
anyone else but why did it have to be slayed... now four brave soldiers
have lost their lives to it!"

inquires

=

Villager in an angry tone: "I Hated that Dragon as much as anyone else
but why did it have to be slayed... now four brave soldiers have lost
their lives to it!"

hmmm... i geuss its hard to explain.. i think what i am trying to do
will be incredably complicated but if i plan it out and wait for a
solid version of my game to be done to implement it could be cool

-tom

P.S. just to be sure you knew, its BG style but is randomely created,
not randomly spawed... it is generated entirly.. from a list of
skeleton plates but still very real and very unique to every situation!

(Plate = one stage in a conversation like she says: "... ... ..." you
can say a,b,c,d,e,f,g)
Anonymous
June 30, 2005 5:05:23 PM

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

Gerry Quinn wrote:
> In article <d9tkuf$o67$2@inews.gazeta.pl>, kisielewicz@gazeta.pl
> says...
>
>>comments@foresightsagas.com wrote:
>>
>>>here is a screenshot.
>>>
>>>i will write back again later but i dont have time now.
>>>
>>>http://www.foresightsagas.com/software/chazm/pic1.bmp
>>
>>DON'T post screenshots in BMP format. It's a HUGE waste of bandwith.
>>(not to mention that nobody will want to download them). There are free
>>programs that will convert it to GIF, PNG or JPG.
>
>
> In this instance, BMP run-length-encoding would have reduced it to 46K
> (a factor of 50!).

When I was really young I used to draw 16 color pictures in Windows 3.1
Paint. I had a directory of those about 45MB of size. Then when I was a
little older I discovered pkzip. My directory shrinked to 210KB. That
was the first major CS lesson I learned ;-D
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Shadows universe is non-heroic, unfair, cruel and designed to
start playing on your nerves and sanity." -- Anubis
Anonymous
June 30, 2005 5:09:01 PM

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

comments@foresightsagas.com wrote:
> Yep, I am pretty much agreeing with you, start small but develop as
> much as possible on paper first so you know where you are expanding to.
>
> What does everyone think about conversation. I mean like baulders gate
> style conversation. like...:
>
> Elderly Villager: Yeah, I've heard of a dragon in that forest.. blah
> blah...
>
> a) you say: "Thanks for all your help"
> b) you say: "What else do you know?"
> c) You say: "Is that all you've heard old man!"
> d) you look bored and walk away (end conversation)
> e) ...
> etc

The main problem with this is the amount of Dialogs you will have to
write. Out of which during a typical gameplay session the average player
will read 5-10%. BG had dozens of people working on Dialogs. You have
just one. And even worse, that one person is also responsible for
everything else.

> Has anyone ever tried to create actual random conversation generation
> for a RL? with a back and forth and the possibility of them giving you
> things and you finding out stuff about the gungeon?

Yes.

> It would be hard... If i could get this to work i would probably run
> all shops and shopkeepers through this system. They tell you their
> store inv and the approx prices and you tell then what you want to buy.

That one's really simple. Things start to get interesting when you
tailor the random dialog system to the random quest system 8->
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Oh come on. We both know the truth about this game --
vapourware." -- Anathiel about GenRogue
June 30, 2005 6:02:45 PM

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

comments@foresightsagas.com wrote:
> Yep, I am pretty much agreeing with you, start small but develop as
> much as possible on paper first so you know where you are expanding to.
>
> What does everyone think about conversation. I mean like baulders gate
> style conversation. like...:
>
> Elderly Villager: Yeah, I've heard of a dragon in that forest.. blah
> blah...
>
> a) you say: "Thanks for all your help"
> b) you say: "What else do you know?"
> c) You say: "Is that all you've heard old man!"
> d) you look bored and walk away (end conversation)
> e) ...
> etc
>
> Now, I am sure that ppl are going to tell me that i am going to fail if
> i am looking at stuff that conplex but I am trying to develop a
> conceptual design so that i can be sure that i am able to implement
> this LATER... MUCH, YEARS, LATER.
>
> Does anyone have anythoughts on this...
>
> Has anyone ever tried to create actual random conversation generation
> for a RL? with a back and forth and the possibility of them giving you
> things and you finding out stuff about the gungeon?
>
> It would be hard... If i could get this to work i would probably run
> all shops and shopkeepers through this system. They tell you their
> store inv and the approx prices and you tell then what you want to buy.

I use a conversation dialog system for Guild (guildgame.com). Easy
enough to implement but takes a while to write the dialogue.

I don't use it for shops as it is a bit longwinded - here I use a more
Angband-style interface.

But I don't see why you'd want to make the conversation generation
random??

A.
Anonymous
June 30, 2005 7:44:42 PM

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

In article <1120111779.241841.232550@g43g2000cwa.googlegroups.com>, "jude hungerford" <lichen678@popmail.com> wrote:
> I
>had to throw out my third attempt because I was using Python (don't get
>me wrong, I still think it's a beautiful language to write and read...
>but I want it to run at acceptable speed on the computers I pick up off
>the side of the street, and that's not what Python does).

Just curious, is that version posted anywhere for download? Would just
like to compare it to some of my own experiments.

Alan
Anonymous
June 30, 2005 10:10:58 PM

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

Yes, the site still seems to be there; it's not the most recent version
I developed, though, and may be from the Attempt #2 series. It's
horribly ugly, and there are some things I know I changed in later
versions (for example, this one is not yet even using a flyweight
pattern for its terrain objects, and for some reason I gave every floor
tile a slightly different ugly colour).
Right now you can look at
http://aristharid.canadianwebs.com/
and if you're not immediately turned off by its ugly display (and if
it's possible, even uglier website) and bad coding, ask and I'll see if
I can dig out the more recent sources.
It needs to be unzipped (on Linux) with the -L (lowercase) option,
because I was developing on Windoze at the time, using DOS editing and
archiving tools.
--jude hungerford.
Anonymous
July 4, 2005 6:15:02 PM

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

Uzytkownik "jude hungerford" <lichen678@popmail.com> napisal w
wiadomosci
news:1120111779.241841.232550@g43g2000cwa.googlegroups.com...

> I
> had to throw out my third attempt because I was using Python (don't
> get
> me wrong, I still think it's a beautiful language to write and
> read...
> but I want it to run at acceptable speed on the computers I pick up
> off
> the side of the street, and that's not what Python does).

There must have been something wrong or unpythonish about your design.
I am using Python in my RL and it is very fast (even much faster than
I expected and was prepared to accept).
Misuse of Python is very common, especially among people who use some
other languages, like Java on a daily basis. The errors include
overusing OOP, translating idioms from other languages (like writing
custom getters and setters), building multi-leveled class hierarchies,
using nested namespaces, and so on.
Umbra is a good example of a Python slow roguelike that could be made
much faster (by "much" I mean "a couple of times or more") if its
author (a very good programmer, indeed) only had a little more heart
for Python ways (Mark is now working on a Java roguelike, I am sure it
will be great).
regards,
Filip Dreger
Anonymous
July 4, 2005 6:15:03 PM

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

In article <dab9hs$mv4$1@nemesis.news.tpi.pl>, fdreger@amiga.pl says...

> There must have been something wrong or unpythonish about your design.
> I am using Python in my RL and it is very fast (even much faster than
> I expected and was prepared to accept).
> Misuse of Python is very common, especially among people who use some
> other languages, like Java on a daily basis. The errors include
> overusing OOP, translating idioms from other languages (like writing
> custom getters and setters), building multi-leveled class hierarchies,
> using nested namespaces, and so on.

But what use are language features if you can't use them effectively in
programs?

- Gerry Quinn


> Umbra is a good example of a Python slow roguelike that could be made
> much faster (by "much" I mean "a couple of times or more") if its
> author (a very good programmer, indeed) only had a little more heart
> for Python ways (Mark is now working on a Java roguelike, I am sure it
> will be great).
> regards,
> Filip Dreger
>
>
>
Anonymous
July 5, 2005 4:18:00 AM

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

> But what use are language features if you can't use them effectively
> in
> programs?
They are anti-features. Things that are possible to do, but should
never be done, because there are better ways to achieve the same
results.
I mean... You _could_ write a procedural program in Java and then
complain about the language, but this would be wrong. Java is not
meant to write procedural programs.
Same with Python. It's not "just an interpreted Java", it's not a
purely OO language. You _can_ write java-like programs in it and
complain about the speed, but it's you who is making a mistake, not
Guido.
A short example. The following code comes from a real RL and is
written in Python by a Java programmer (and it shows).

class Item(Thing.Thing):
def __init__(self, name, sprite, shoptype):
Thing.Thing.__init__(self, name, os.path.join("item",
sprite) )
self.__cost=0
self.resale=HALF_PRICE
self.effect=None
self.shoptype=shoptype

def cost(self):
return self.__cost

def resaleValue(self):
return int(self.resale * self.cost)

def setCost(self, amount):
self.__cost = amount

How to speed up the code _and_ make it more pythonic?
1. Discard all the setters/getters. They make no sense in Python,
since it is dynamicaly typed and setters can be added on-the-fly, as
they are needed. Adding empty setters/getters serves no real purpose,
_and_ each of them costs an additional look-up in a hash table. So the
code should go like:

class Item(Thing.Thing):
def __init__(self, name, sprite, shoptype):
Thing.Thing.__init__(self, name, os.path.join("item",
sprite) )
self.__cost=0
self.resale=HALF_PRICE
self.effect=None
self.shoptype=shoptype

def resaleValue(self):
return int(self.resale * self.cost)

2. Why make "Item" a subclass? Python allows you to add custom
attributes/methods to any objects, you do not need subclasses for
that. Additionally, when Python looks for an attribute, it starts with
the original class, and omly after failure checks its superclasses.
Since most item attributes remain in the Thing class, it will take one
costly hash table look-up more to find them. And there is no
additional gain (the classes take only the memory they need anyway).
The nice way to do items would be to simply add:

def turn_into_item(self,shoptype)
self.__cost=0
self.resale=HALF_PRICE
self.effect=None
self.shoptype=shoptype

def resaleValue(self):
return int(self.resale * self.cost)

to the "Thing" class.

There are many more things that you can do to make the above code even
better. The two minor tweaks introduced above made the code two times
shorter and two times faster, and got rid of one additional file and
one additional namespace, which will result in even more savings. And
by making some wider changes I think I could make the code even faster
and shorter (probably four times than the original), while keeping it
more compact and readible.

Python is a powerful tool, but you must know how you use it. If you
use a chainsaw without turning it on, you can not expect it to show
any advantages over an ordinary saw.

regards,
Filip Dreger
Anonymous
July 5, 2005 10:59:17 AM

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

At Tue, 5 Jul 2005 00:18:00 +0200,
Filip Dreger wrote:

> The nice way to do items would be to simply add:
<snip>
> to the "Thing" class.
Or to use a decorator on the Thing constructor :) 

--
Radomir `The Sheep' Dopieralski @**@_
(*+) 3 Sparkle
. . . ..v.vVvVVvVvv.v.. .
Anonymous
July 5, 2005 3:18:12 PM

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

U¿ytkownik "The Sheep" <thesheep@ sheep.prv.pl> napisa³ w wiadomo¶ci
news:slrndckbu2.7u5.thesheep@atos.wmid.amu.edu.pl...
> At Tue, 5 Jul 2005 00:18:00 +0200,
> Filip Dreger wrote:
>
>> The nice way to do items would be to simply add:
> <snip>
>> to the "Thing" class.
> Or to use a decorator on the Thing constructor :) 
The program in question was based on Python 2.2 :) 
regards,
Filip
Anonymous
July 5, 2005 4:06:29 PM

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

In article <daccsc$q7s$1@nemesis.news.tpi.pl>, fdreger@amiga.pl says...

> > But what use are language features if you can't use them effectively
> > in
> > programs?

> They are anti-features. Things that are possible to do, but should
> never be done, because there are better ways to achieve the same
> results.

Some of them are things that one might want to do for reasons other
than familiarity with Java. If it is too costly to access members by
way of functions, fine - but that means you throw away some
encapsulation ability, and increase the chance of breaking things when
your representation changes.

If Python makes a virtue of being OO, it has no cause for complaint
when people take it at its word.

Personally I will stick with C++...

- Gerry Quinn


> I mean... You _could_ write a procedural program in Java and then
> complain about the language, but this would be wrong. Java is not
> meant to write procedural programs.
> Same with Python. It's not "just an interpreted Java", it's not a
> purely OO language. You _can_ write java-like programs in it and
> complain about the speed, but it's you who is making a mistake, not
> Guido.
> A short example. The following code comes from a real RL and is
> written in Python by a Java programmer (and it shows).
>
> class Item(Thing.Thing):
> def __init__(self, name, sprite, shoptype):
> Thing.Thing.__init__(self, name, os.path.join("item",
> sprite) )
> self.__cost=0
> self.resale=HALF_PRICE
> self.effect=None
> self.shoptype=shoptype
>
> def cost(self):
> return self.__cost
>
> def resaleValue(self):
> return int(self.resale * self.cost)
>
> def setCost(self, amount):
> self.__cost = amount
>
> How to speed up the code _and_ make it more pythonic?
> 1. Discard all the setters/getters. They make no sense in Python,
> since it is dynamicaly typed and setters can be added on-the-fly, as
> they are needed. Adding empty setters/getters serves no real purpose,
> _and_ each of them costs an additional look-up in a hash table. So the
> code should go like:
>
> class Item(Thing.Thing):
> def __init__(self, name, sprite, shoptype):
> Thing.Thing.__init__(self, name, os.path.join("item",
> sprite) )
> self.__cost=0
> self.resale=HALF_PRICE
> self.effect=None
> self.shoptype=shoptype
>
> def resaleValue(self):
> return int(self.resale * self.cost)
>
> 2. Why make "Item" a subclass? Python allows you to add custom
> attributes/methods to any objects, you do not need subclasses for
> that. Additionally, when Python looks for an attribute, it starts with
> the original class, and omly after failure checks its superclasses.
> Since most item attributes remain in the Thing class, it will take one
> costly hash table look-up more to find them. And there is no
> additional gain (the classes take only the memory they need anyway).
> The nice way to do items would be to simply add:
>
> def turn_into_item(self,shoptype)
> self.__cost=0
> self.resale=HALF_PRICE
> self.effect=None
> self.shoptype=shoptype
>
> def resaleValue(self):
> return int(self.resale * self.cost)
>
> to the "Thing" class.
>
> There are many more things that you can do to make the above code even
> better. The two minor tweaks introduced above made the code two times
> shorter and two times faster, and got rid of one additional file and
> one additional namespace, which will result in even more savings. And
> by making some wider changes I think I could make the code even faster
> and shorter (probably four times than the original), while keeping it
> more compact and readible.
>
> Python is a powerful tool, but you must know how you use it. If you
> use a chainsaw without turning it on, you can not expect it to show
> any advantages over an ordinary saw.
>
> regards,
> Filip Dreger
>
>
>
Anonymous
July 5, 2005 9:17:47 PM

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

> Some of them are things that one might want to do for reasons other
> than familiarity with Java. If it is too costly to access members
> by
> way of functions, fine - but that means you throw away some
> encapsulation ability, and increase the chance of breaking things
> when
> your representation changes.

No, it's not "very costly". It costs one look-up in a hash table per
level of checking (one level means one namespace or one nested level
of virtual class hierarchy).
And why on earth would you want to access your attributes with
functions that do nothing but access your attributes? It makes no
sense in Python! People do it in Java and C++ all the time, but it's
just because these languages won't allow them to change an attribute
into a method later on. Python allows me to do this without changing
the syntax of calls (it is transparent from programs point of view),
so making empty setters and getters in Python is plain stupid. It
serves _no_ purpose and it makes accessing members twice as slow, as
it could be. It does not matter if they are costly or not, it's pure
lunacy! you end up with code that's:
- 3 times longer (3 lines versus 1 line)
- 2 times slower (2 look-ups versus 1)
- less readible (class definition stops fitting into one screen)
- does not have a single benefit (the encapsulation and handling of
the code is exactly the same)

> If Python makes a virtue of being OO, it has no cause for complaint
> when people take it at its word.

There is more to OO than Java and C++ offer. The OO model that Python
represents is slightly different (so is Smalltalk's, so is Ruby's),
it's more like the prototype-based inheritance model (not quite, but
similiar). It gives you different ways to do things. The ways have
their drawbacks and their advantages - if you try to use Python
exactly the way you would use C++, you only get the former. If I tried
to use C++ the way I use Python, I would also run into serious
problems, but - since C++ is less flexible - I would notice the
problem sooner. The problem with Python is that most of programmers
who misuse it do not know it, and blame Python for their own lack of
knowledge.

> Personally I will stick with C++...

I would never think of converting anyone to Python. Too much of a
responsibility :-)

regards,
Filip Dreger
!