[ann] Fourth rewrite of Kaduria

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

I'm hereby announcing the fourth rewrite of my RL project. Just wanted
to
share this with you guys. Share my pain:) It's kind of bad when you
have
to rewrite and see the old code washed away. The code you spent so
many hours writing and thought it was the final version this time.

The object system is rewritten to be object-oriented, having one base
class and derived classes for each object type. When I discovered
what a virtual function is I was excited, because it offered a clear
answer for separating the object types without checking for the
type and writing if-else-blocks. Needless to say that I discovered the
benefits of object-oriented model way too late. After these ten
years of development.

I'm also re-writing GUI parts to classes. Text, windows and menus.
Now they are becoming more consistent and class implementation
allows easier future extensions such as moving the windows and
menus to user defined locations.

After I began to study OOP there has been a (dramatic) change in
my programming style. Class implementation makes the source
code arrange itself almost automatically. One thing is done in one
place, and what is more important it's done in the proper place.
I don't know if I can avoid re-writing after this time, but I
believe it will be easier with classes.
21 answers Last reply
More about fourth rewrite kaduria
  1. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > I'm hereby announcing the fourth rewrite of my RL project. Just wanted
    > to
    > share this with you guys. Share my pain:) It's kind of bad when you
    > have
    > to rewrite and see the old code washed away. The code you spent so
    > many hours writing and thought it was the final version this time.

    Sometimes there's no choice hehe

    You gotta post this on the 'Rewrite' page of roguebasin! ;)

    SNIP

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

    copx wrote:
    > You don't HAVE to do it, you know. It seems that what you really want is
    > learning OOP or having beautyful code to look at i.e. creating a game is not
    > your primary goal.

    Well, I'm more game designer than programmer, really. And in the
    past I was maybe too much game designer who didn't think about better
    ways to write code. In large projects it's essential to organize
    the code and OOP helps in that because the way it works. There are
    less room for quick hacks (which can lead to disaster in large
    scale projects...)

    > At least that's my experience (I have used the same
    > code base since the days of Goodfire M0 - my first RL release ever)

    Maybe you got it right the first time. Some people are better
    programmers, they can even live without OOP:)
  3. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > Just be careful not to overdo it, though. With OOP, it's *way* too easy
    > to get excited and make everything an object, and this just isn't a good
    > idea.

    I'll be careful.

    > Also, it becomes easy to over-generalize everything, and overuse
    > inheritance and other features.

    I know. In fact I try to avoid inheritance as much as possible
    and make classes out of things that really benefit from the class
    (multiple instances).

    > There's no good reason
    > to inherit monsters from the same base class as potions.

    Why not, if the base class has shared methods for all object types?
  4. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > I'm hereby announcing the fourth rewrite of my RL project. Just wanted
    > to
    > share this with you guys. Share my pain:) It's kind of bad when you
    > have
    > to rewrite and see the old code washed away. The code you spent so
    > many hours writing and thought it was the final version this time.
    >
    > The object system is rewritten to be object-oriented, having one base
    > class and derived classes for each object type. When I discovered
    > what a virtual function is I was excited, because it offered a clear
    > answer for separating the object types without checking for the
    > type and writing if-else-blocks. Needless to say that I discovered the
    > benefits of object-oriented model way too late. After these ten
    > years of development.
    >
    > I'm also re-writing GUI parts to classes. Text, windows and menus.
    > Now they are becoming more consistent and class implementation
    > allows easier future extensions such as moving the windows and
    > menus to user defined locations.
    >
    > After I began to study OOP there has been a (dramatic) change in
    > my programming style. Class implementation makes the source
    > code arrange itself almost automatically. One thing is done in one
    > place, and what is more important it's done in the proper place.
    > I don't know if I can avoid re-writing after this time, but I
    > believe it will be easier with classes.

    Yeah, learning new things is frequently the cause of (at least partial)
    rewrites for me, too. However, over time, I find more and more of my
    old code reusable, making each subsequent rewrite less painful.

    Since you're using an OOP model, try and make certain routines
    (graphics, sound, input, etc.) as generic as possible. If you do,
    there's a good chance that they will be reusable in any future rewrites,
    and, they should be useable in other projects as well.

    Just be careful not to overdo it, though. With OOP, it's *way* too easy
    to get excited and make everything an object, and this just isn't a good
    idea. Also, it becomes easy to over-generalize everything, and overuse
    inheritance and other features. You don't really need to inherit every
    object in the game from some base Entity class. There's no good reason
    to inherit monsters from the same base class as potions.

    In other words, be careful, have fun, and good luck with rewrite #4!
  5. Archived from groups: rec.games.roguelike.development (More info?)

    "Krice" <paulkp@mbnet.fi> schrieb im Newsbeitrag
    news:1127297912.281034.15210@o13g2000cwo.googlegroups.com...
    > I'm hereby announcing the fourth rewrite of my RL project. Just wanted
    > to
    > share this with you guys. Share my pain:) It's kind of bad when you
    > have
    > to rewrite and see the old code washed away. The code you spent so
    > many hours writing and thought it was the final version this time.
    [snip]

    You don't HAVE to do it, you know. It seems that what you really want is
    learning OOP or having beautyful code to look at i.e. creating a game is not
    your primary goal. That's fine but if you ever want to get something done
    stop this rewrite BS. It's never necessary 'cause there's nothing a little
    refactoring can't solve. At least that's my experience (I have used the same
    code base since the days of Goodfire M0 - my first RL release ever)

    Rewrites kill! See:
    http://www.joelonsoftware.com/articles/fog0000000069.html


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

    copx wrote:
    > "Krice" <paulkp@mbnet.fi> schrieb im Newsbeitrag
    > news:1127297912.281034.15210@o13g2000cwo.googlegroups.com...
    >
    >>I'm hereby announcing the fourth rewrite of my RL project. Just wanted
    >>to
    >>share this with you guys. Share my pain:) It's kind of bad when you
    >>have
    >>to rewrite and see the old code washed away. The code you spent so
    >>many hours writing and thought it was the final version this time.
    >
    > [snip]
    >
    > You don't HAVE to do it, you know. It seems that what you really want is
    > learning OOP or having beautyful code to look at i.e. creating a game is not
    > your primary goal. That's fine but if you ever want to get something done
    > stop this rewrite BS. It's never necessary 'cause there's nothing a little
    > refactoring can't solve. At least that's my experience (I have used the same
    > code base since the days of Goodfire M0 - my first RL release ever)
    >
    > Rewrites kill! See:
    > http://www.joelonsoftware.com/articles/fog0000000069.html

    Sure, rewrites aren't always necessary. But sometimes, they are. I
    can't make an accurate judgement in Krice's case as to whether or not
    his project merited a rewrite, but I've worked on several projects that
    could not be saved, without scrapping the codebase and recreating it all
    from scratch. In my experience, the larger a project gets, the more and
    more problems and bugs spring up. Eventually, the entire project can
    collapse under the weight of these nasty problems. Granted, if done
    right, this shouldn't happen, but rarely does everything always go
    according to plan.
  7. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > Timothy Pruett wrote:
    >
    >>Just be careful not to overdo it, though. With OOP, it's *way* too easy
    >>to get excited and make everything an object, and this just isn't a good
    >>idea.
    >
    >
    > I'll be careful.
    >
    >
    >>Also, it becomes easy to over-generalize everything, and overuse
    >>inheritance and other features.
    >
    >
    > I know. In fact I try to avoid inheritance as much as possible
    > and make classes out of things that really benefit from the class
    > (multiple instances).
    >
    >
    >>There's no good reason
    >>to inherit monsters from the same base class as potions.
    >
    >
    > Why not, if the base class has shared methods for all object types?
    >

    Agred. Both monsters and items might share a few things in a roguelike,
    like HP, weight or a generic AttributeSet class/structure etc. Storing
    them in a base class along with methods to modify them seems logical.

    BR,
    Björn
  8. Archived from groups: rec.games.roguelike.development (More info?)

    copx <invalid@invalid.com> wrote:
    > You don't HAVE to do it, you know. It seems that what you really want is
    > learning OOP or having beautyful code to look at i.e. creating a game is
    > not
    > your primary goal. That's fine but if you ever want to get something done
    > stop this rewrite BS. It's never necessary 'cause there's nothing a
    > little
    > refactoring can't solve.

    IMO there are two good reasons to rewrite:

    1) You are still learning, and have something more to learn from a
    rewrite. This was the case in my first (and possibly second) rewrite,
    before I had learnt to write code with refactoring in mind.

    2) You have decided to switch languages. When I decided to ditch Python
    and move to Objective Caml, the only thing to be saved from my previous
    attempt was some design concepts.

    Indeed, it's good to learn to write your code such that it can be
    refactored rather than rewritten. Sometimes that learning process
    requires one last rewrite, because refactoring code which has a broken
    underlying structure can be more work than rewriting.

    --
    --jude hungerford.
  9. Archived from groups: rec.games.roguelike.development (More info?)

    edward@lore.net wrote:
    > Indeed, it's good to learn to write your code such that it can be
    > refactored rather than rewritten. Sometimes that learning process
    > requires one last rewrite, because refactoring code which has a broken
    > underlying structure can be more work than rewriting.

    What I'm doing is more re-factoring actually and that was the case
    in earlier "re-writes" too. This time I'm replacing the game object
    and GUI code with class implementations. Because the game object
    system is such a big part of the project it's heavy re-factoring
    and in some parts total re-writing of the source code.

    I had prepared for this re-factoring when I began to add member
    functions to the old object class, which was just a plain
    struct back then. Even after this preparation I was amazed how
    much work this re-factoring requires. In the beginning it seemed
    to be an impossible task. It's going to take several weeks just
    to get the project to compile and run again.
  10. Archived from groups: rec.games.roguelike.development (More info?)

    In article <1127471932.041428.152770@g49g2000cwa.googlegroups.com>,
    Krice <paulkp@mbnet.fi> wrote:
    ...
    >I had prepared for this re-factoring when I began to add member
    >functions to the old object class, which was just a plain
    >struct back then. Even after this preparation I was amazed how
    >much work this re-factoring requires. In the beginning it seemed
    >to be an impossible task. It's going to take several weeks just
    >to get the project to compile and run again.

    Do you use source code control? I've found it makes it much easier
    to make big changes, psychologically speaking.

    -Mike


    --
    http://www.mschaef.com
  11. Archived from groups: rec.games.roguelike.development (More info?)

    MSCHAEF.COM wrote:
    > Do you use source code control?

    What IS source code control?:)
  12. Archived from groups: rec.games.roguelike.development (More info?)

    "Krice" <paulkp@mbnet.fi> writes:

    > MSCHAEF.COM wrote:
    >> Do you use source code control?
    >
    > What IS source code control?:)

    Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.

    <http://en.wikipedia.org/wiki/Version_control_system>

    sherm--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
  13. Archived from groups: rec.games.roguelike.development (More info?)

    At 23 Sep 2005 10:47:55 -0700,
    Krice wrote:

    > MSCHAEF.COM wrote:
    >> Do you use source code control?
    >
    > What IS source code control?:)

    Version control, maybe? ;)

    --
    Radomir `The Sheep' Dopieralski @**@_
    (==) 3 Yawn?
    . . . ..v.vVvVVvVvv.v.. .
  14. Archived from groups: rec.games.roguelike.development (More info?)

    Krice:

    > MSCHAEF.COM wrote:
    > > Do you use source code control?
    >
    > What IS source code control?:)


    Sounds like some discipline of Jedi training.


    P.S. sorry, couldn't resist.
  15. Archived from groups: rec.games.roguelike.development (More info?)

    In article <m2br2j6486.fsf@Sherm-Pendleys-Computer.local>,
    Sherm Pendley <sherm@dot-app.org> wrote:
    >"Krice" <paulkp@mbnet.fi> writes:
    >
    >> MSCHAEF.COM wrote:
    >>> Do you use source code control?
    >>
    >> What IS source code control?:)
    >
    >Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.
    >
    > <http://en.wikipedia.org/wiki/Version_control_system>

    I'm a big fan of Subversion myself, although I don't use 90% of the
    features.

    -Mike
    --
    http://www.mschaef.com
  16. Archived from groups: rec.games.roguelike.development (More info?)

    At 24 Sep 2005 12:32:56 -0700,
    aerton@ngs.ru wrote:

    > Krice:
    >> MSCHAEF.COM wrote:
    >> > Do you use source code control?
    >> What IS source code control?:)
    > Sounds like some discipline of Jedi training.
    > P.S. sorry, couldn't resist.

    What planet is this?

    --
    Radomir `The Sheep' Dopieralski @**@_
    (Uu) 3 Sigh!
    . . . ..v.vVvVVvVvv.v.. .
  17. Archived from groups: rec.games.roguelike.development (More info?)

    Sherm Pendley wrote:
    > Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.
    > <http://en.wikipedia.org/wiki/Version_control_system>

    I don't know why you need that in one man project? Seems to be
    just more work in top of everything else..
  18. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe wrote:
    > Krice a écrit :
    > > Sherm Pendley wrote:
    > >
    > >>Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.
    > >> <http://en.wikipedia.org/wiki/Version_control_system>
    > >
    > >
    > > I don't know why you need that in one man project? Seems to be
    > > just more work in top of everything else..
    >
    > Myself I find it very important. Even in a one man project you sometimes
    > have to :
    >
    > - remember why you made that change 6 months ago
    > - compare your currently modified code to the latest working version
    > - drop your currently modified code to get back the latest working version

    - can backup your project by backing up the repository, without having
    to copy object files or worry about not picking up all the things you
    need.
    - spawn new copies of your project on new machines by just checking out
    a baseline.
    - not get hopelessly confused if you are working on your project from
    multiple locations.
    --
    Jeff Lait
    (POWDER: http://www.zincland.com/powder)
  19. Archived from groups: rec.games.roguelike.development (More info?)

    Krice a écrit :
    > Sherm Pendley wrote:
    >
    >>Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.
    >> <http://en.wikipedia.org/wiki/Version_control_system>
    >
    >
    > I don't know why you need that in one man project? Seems to be
    > just more work in top of everything else..

    Myself I find it very important. Even in a one man project you sometimes
    have to :

    - remember why you made that change 6 months ago
    - compare your currently modified code to the latest working version
    - drop your currently modified code to get back the latest working version

    And when you start releasing the project, you might even make use of the
    branching feature if you want to create the new version of the game
    while still correcting remaining bugs in the released version :)
  20. Archived from groups: rec.games.roguelike.development (More info?)

    Christophe wrote:
    > Krice a écrit :
    >
    >> Sherm Pendley wrote:
    >>
    >>> Version control - CVS, BitKeeper, Subversion, Visual Sourcesafe, etc.
    >>> <http://en.wikipedia.org/wiki/Version_control_system>
    >>
    >>
    >>
    >> I don't know why you need that in one man project? Seems to be
    >> just more work in top of everything else..
    >
    >
    > Myself I find it very important. Even in a one man project you sometimes
    > have to :
    >
    > - remember why you made that change 6 months ago
    > - compare your currently modified code to the latest working version
    > - drop your currently modified code to get back the latest working version
    >
    > And when you start releasing the project, you might even make use of the
    > branching feature if you want to create the new version of the game
    > while still correcting remaining bugs in the released version :)

    Agreed. Version control is soooooo important. Once you start using it
    you can't live without it (even in a one man project).

    BR,
    Björn
  21. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-09-26, Krice <paulkp@mbnet.fi> wrote:
    >> <http://en.wikipedia.org/wiki/Version_control_system>
    >
    > I don't know why you need that in one man project? Seems to be
    > just more work in top of everything else..

    I've got just about all the files I work on under Subversion, not just
    source code. The basic idea is backup safety. As long as the repository
    is intact, I can accidentally wipe out all my local work files and
    suffer no data loss beyond the changes I've made after the last
    check-in. Even if I'm not using the older versions, it's a simple way of
    keeping things backed up and synchronized between multiple machines.

    --
    Risto Saarelma
Ask a new question

Read More

Development Video Games