A New Roguelike needs your ideas...

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
38 answers Last reply
More about roguelike ideas
  1. 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:)
  2. 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
  3. 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...
  4. 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
  5. 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..! ;)
  6. 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?
  7. Archived from groups: rec.games.roguelike.development (More info?)

    here is a screenshot.

    i will write back again later but i dont have time now.

    http://www.foresightsagas.com/software/chazm/pic1.bmp
  8. 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
  9. 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
  10. 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.
  11. 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)
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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!
  18. 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.
  19. 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)
  20. 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.
  21. 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
  22. 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.
  23. 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.
  24. 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.. .
  25. 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.
  26. 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)
  27. 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
  28. 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
  29. 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.
  30. 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
  31. 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.
  32. 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
  33. 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
    >
    >
    >
  34. 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
  35. 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.. .
  36. 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
  37. 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
    >
    >
    >
  38. 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
Ask a new question

Read More

Development Video Games