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

On 13 Mar, 18:31, David Ploog <pl...@xxxxxxxxxxxxxxx> wrote:
I am not sure agree. (Of course, I may be biased by being a non-coding
designer.) Many specific details should be left for later, but some
fundamental design decisions should be settled before doing (much) coding..
For example:
* Do you want line of sight? If so, which metric? (Brent Ross once
   experimented with the max(|p.x-q.x|,|p.y-q.y|) metric, which leads to
   square sight area, for reasons I do understand by now.)

Is that really top-down? The way I see it, deciding on whether or not
to use Chebyshev distances for FOV (or any other type, for that
matter) is something you have to do prior to coding, thus part of the
bottom-up approach (although it's clearly visible from the top-down
perspective as well in this particular case). Plus, in this case, it
is strongly linked to the game mechanics itself. Chebyshev distances
assume that diagonal movement is possible and its walking cost is the
same as in case of orthogonal movement. Manhattan is diamond-shaped.
If you decide to use it, it's not just because it looks cool or
uncool, but simply because it assumes diagonal movement is disallowed.
A fine example of this logic might be Slash's 1kBRL LUCK!, which
disallows diagonal movement and thus uses Manhattan distances to
calculate FOV; I doubt Slash's primary idea was to use Manhattan
distances from the beginning, but rather a logical step after deciding
against allowing diagonal movement. The anti-example would be ADoM. It
uses Chebyshev distances for movement, but not for FOV (for the
curious: it uses a sum of Chebyshev and Manhattan shifted right by one
bit, resulting in an octagonal FOV: [max(|p.x-q.x|,|p.y-q.y|)+|p.x-q.x|
+|p.y-q.y|]>>1), resulting in the ability to see further (game-wise)
in orthogonal directions than in diagonal. This is a top-down
decision. Thomas Biskup valued more the visual aspect than the
underlying mechanics.

Ultimately, we might agree that pure top-down or bottom-up approach is
quite impossible and you'll be forced to mix the two at some step. For
instance, if you plan to use a specific feature, you'll be likely to
direct your coding towards the possibility of implementing it later,
thus we can't affirm that the top-down approach has no influence on
coding. Still, the end user won't be aware of how you resolve a
specific pointer issue or how you decide to structure your map. He'll
just see the final appearance of the game, which is a purely top-
bottom approach (or rather just "top", hehe).

* Do want healing by waiting, or in any other form?
* I think it helps to spend some time thinking on the interface before
   implementing, say, any spellcasting.

Technically, you're right. You have to know what you want to implement
before actually implementing it. The problem is, the top-down approach
tends to desribe the exterior appearance, while bottom-up is rather
about the underlying mechanics. Your examples appear to be somewhere
in between :).

Look at these examples (I think they're right):

A1 (top-down): I want a "lightning bolt" spell. It should be a yellow
straight line from the PC to the target, dealing X damage to an
opponent.
A2 (bottom-up): The "lightning bolt" spell will use a visual effect
based on Bresenham algo, drawing a straight line from the caster to
the target. Each map cell, although containing a character, will have
to be forced to display a yellow asterisk. After the visual effect is
over, the bolt's trajectory is redrawn again, using previous
characters and colours. The effect will be draining X mana points from
the caster and Y health points from the target. How long will the
visual effect last? How do I display it without putting too much
burden on the CPU? What will be taken into account when calculating
the damage (metal objects worn/wielded by the target, resistances, and
so on).

B1 (top-down): I want the caves to be blob-like, with "tentacles"
spreading from the centre of the map outwards, with no large open
spaces to improve gameplay.
B2 (bottom-up): I should use cellular automata/Perlin noise/CA erosion/
fractional Brownian motion+Dijkstra/whatever to create such a cavern.
How do I come up with the necessary calculations? What's the correct
threshold to use when determining wall/floor placement based on, say,
noise values? Experiments and trial and error will be necessary to
achieve a visually appealing and proper gameplay guaranteeing map.

We may argue endlessly here and try to prove that one or the other
approach should have more weight when making a game than the other,
but in the end, everything needs to be programmed, right? Programming
is the most bottom-up part of the process. In other words, an
architect may design a house, but the builders won't be able to start
the construction from the roof anyway. The thing is knowing what is
our project's roadmap and don't design in advance elements that will
need to be coded last. Ideas are prone to evolve. The code at the very
core of the game isn't that flexible and is getting even less so as
the project gets more complex.

Note that I'm not trying to prove that the top-bottom approach is bad.
It's not and in many cases it helps or even is plainly necessary. I
also have many ideas written down, heck, I even have an entire
background story and some intro narration recordings made in a
professional recording studio! But these are simply waiting for their
turn to be implemented. My point is that one should limit the top-down
approach to a sensible minimum, focusing rather on making the game
work and putting more effort in the challenges that need to be tackled
immediately instead.

Mingos
.

Relevant Pages

  • Re: sub-novice wants to design game
    ... > I want to design and build an online multiplayer strategy game (not ... but I know next to nothing about programming or coding. ... > Graphics requirements will be more-or-less minimal. ... 2- Learn some basic design patterns, ...
    (comp.games.development.programming.misc)
  • Re: attempting an actual game...
    ... >>> be as complete as possible before you start coding. ... >>writen, then there should be writen design docs, if at all. ... >>(Actually writing a game is large task, ... the design doc should be your basis for what you're ...
    (comp.games.development.programming.misc)
  • Re: truly-optimized coding styles & design patterns in C#?
    ... grokking design patterns but try to find practical examples of each pattern ... apps you've written and seek out the simplest and most elegant ways to ... creating a small utility app vs coding something that has to fit into ... > exceptions classes, none of that. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Commenting the source code.
    ... > Do you comment your source code while coding or after coding. ... break down the design to be more specific ... write, document, compile and debug debug fuctions. ... Whereas successfull means dedect bugs, ...
    (comp.lang.c)
  • Re: DAB+ to use UEP - Homer Croiset exclusive
    ... the spec to be released to find out what the new error correction ... correction coding. ... called me an idiot for being stupid and not understanding economics. ... You don't design a ...
    (alt.radio.digital)