Re: Is top-down design feasible for a coffee-break roguelike?



On Mar 13, 6:21 am, Cuboidz <Dieter.Be...@xxxxxxxxx> wrote:
In fact, this would seem like a fun way to design a roguelike: you
play lots of different roguelikes, write down what you like, and then
go sit at the drawing board, and think about how to piece everything
together. After a few months, you can start programming with a
purpose, in stead of just toying around with the technology, until
you're satisfied with the result.

I'm in the apparent minority who is with you on this. Well, mostly. "A
few months" seems like an awfully long time to spend planning a
roguelike, but "a few days" seems pretty reasonable to me.

I have a roguelike under development that is at the moment completely
playable and pretty fun to play. I'm told one of my friends basically
plays it all day at work, for whatever that's worth. It's got a pretty
cool feature-set too, I think... colored dynamic light sources, good
algorithms for monster scent-following, attacking, wandering and
intelligently fleeing (i.e. not straight into the nearest corner),
some interesting items and varied monster types, and a level
generation algorithm I'm really proud of -- no long and twisty
passages, completely passable levels, subterranean lakes of water and
lava, chasms, surface features like funguses, piles of bones and
different kinds of splattered blood from combat, etc. It's certainly
no Nethack in terms of complexity, but it is starting to look like
what I envisioned, and I'm very happy with it so far. It's also the
first roguelike I've ever built, and I built it absolutely from
scratch (though with the benefit of having examined the Rogue source
code in years past, and reading on RogueBasin how various algorithms
worked in qualitative terms -- no copy/pasting).

My method was to work on features I was interested in working on for
as long as I was interested in working on them. Coding this thing
isn't a job; it's for my own enjoyment, and I want the process to be
enjoyable. So I spent literally two to three months just playing with
level generation, before I even implemented any items, creatures or
the player. You'd start the program up, it would generate a level, and
then it would quit. I would admire the level, generate five or ten
more, and then decide what I wanted to do differently and spend a few
hours doing it.

I spent a couple of hours implementing the player, movement, and a
single monster type with a single behavior (run straight at the player
until one is dead), and then spent another week or so playing with
colored lighting. Torches on the walls, glowing fungus and lava, and
an implicit "miner's light" that the player carries with him, which
gradually decreases in radius as he gets deeper into the dungeon. Each
gets dimmer toward the edge of its radius and can have flickering
color and radius. For a square to be visible, it must be both in the
line of sight and lit.

Anyway, I'm starting to ramble, but my point is that I spent tons of
time implementing features I enjoyed implementing and ignored features
I didn't feel like dealing with at the moment. At one point, I had a
game with gorgeous levels and beautiful dynamic lighting but no items
and only a single kind of monster. But at that point, the motivation
materialized to implement those since it is pleasurable to watch your
new features interact with a world that you're proud of.

So yeah. I say plan out the stuff that's exciting for as long as you
like, and then dive into the coding. Don't treat it like a job, and
only work on a feature when you want to work on that feature. I'm
happy with the results I've gotten from that method.
.



Relevant Pages

  • Re: IVAN roguelike
    ... roguelike I'd want to play. ... For example let the player decide if he wants ... The sudden dying in roguelikes is something I don't ...
    (rec.games.roguelike.development)
  • Re: Meaningful complexity
    ... The first play is more enjoyable. ... The game must be replayable. ... Its possible to have simplicity and complexity in a roguelike at once ... existance actually makes sense (ie its silly only allowing a player to ...
    (rec.games.roguelike.development)
  • Re: Keep it simple, stupid!
    ...  Writing a roguelike should never be this complicated. ... Also people tend to compare their games against the "current standard" ... features while I was still struggling with basic AI. ... should play your game instead of the established ones. ...
    (rec.games.roguelike.development)
  • Re: Media Player upgrade matrix?
    ... Conflicts start where information lacks. ... For now we will stick with player 10 because there is no information given ... I need more than that to add it to a corporate desktop image. ... > listing of the features side by side. ...
    (microsoft.public.windowsxp.general)
  • Re: Innovative New Roguelike?
    ... the features I listed on the wiki), I have a pretty good idea of how I ... On one level, I admit, my suggested roguelike is ... Easy (I've dealt with coding monsters before, ... on the wiki, I don't think I'll have a problem with making the game, ...
    (rec.games.roguelike.development)

Loading