attempting an actual game...

There is some middle ground -- but it lies closer to the "plan, design &
document" end of the spectrum than the "yeah, whatever" end.

In article <20306$4393e343$ca83a645$26556@saipan.com>,
"cr88192" <cr88192@NOSPAM.hotmail.com> wrote:

> "Alfie [UK]" <me@privacy.net> wrote in message
> news:7187p1l8nccanql9drc5cv3t426vm47sri@4ax.com...
> > On Mon, 5 Dec 2005 01:18:22 +0000 (UTC), Raghar <notfor@mail.com> wrote:
> >>"Alfie [UK]" <me@privacy.net> wrote in
> >>news:58d5p1phivc6ojh1ek9426dqu18ve9n07q@4ax.co m:
> >>> The way to keep focused, particularly on a large project like an
> >>> RPG game, is to have a good design document and stick to it
> >>> (unless re-design is actually required). The design doc should
> >>> be as complete as possible before you start coding.

This is a good goal. However, one should not NOT-code, simply because
there is some as-yet ambiguous part of their DD.

> >>Why something like this for RPG? It should be first at least mostly
> >>writen, then there should be writen design docs, if at all.
> >>(Actually writing a game is large task, you might forgot something
> >>so design docs are important when nearly all things are done.)

DDs are ESPECIALLY important on big jobs, especially something like an
RPG. Unless you're going to do something like "I want to write a game
that looks & plays exactly like XYZ-game, but using my own artwork", in
which case you already have a design-doc, it's just very short -- so
short that you can memorize it.

> > I have to disagree, how can you start coding before you know what you're
> > trying to achieve ?

> I do this all the damn time...
> what do I have now? what can I make next? what might be needed? ...
>
> code is cheap imo.
> of course, knowing what to code is good, I will agree to this...

You two are arguing "top down" vs "bottom up". But the problem is, even
with bottom up programming, you need a design. Otherwise, how will you
ever know if you're done? From what I've read, it seems that cr88192
suffers from a lot of "...but I never finish" syndrome -- perhaps that's
due to the lack of finishability inherent in no-design programming.

It's a fair bet that you're going to need some sort of graphics display
engine -- so it makes sense to maybe code a little on that. But how do
you decide if you're going to use sprites, or 3D, etc., without a
design? If 3D, how will your data/models be represented? What parts of
the code can be shared by client & server, etc? If sprites, how will do
you layer objects? How will you handle transparency and collisions?

These are simple questions with easy answers -- but the point is: you
need to ask & answer them before you can code, unless you just enjoy
writing throw-away code.

"Not that there's anything wrong with that..."

> > A design doc isn't just the paper you use to pitch
> > it to a distributor, the design doc should be your basis for what you're
> > doing. You lay out your ideas so you can see how it all hangs together,
> > what fits, what doesn't, what's the basic storyline, what features are
> > wanted, what are required by the story, what are nice to have but not
> > important, how is the player expected to interact, what does that do to
> > your requirements, etc, etc.

> yeah, me arguing with my brother. me wanting to take the utmost of lazy
> (going off to an alternate area with turn-based combat), combined with
> possibly randomly generated dungeons.
>
> my brother wants it to not suck...

Where do you stand on the "not-suck" issue?

How will the "alternate area" compare to the original, when players are
moved there for combat? Why not just play in the dungeon? *HOW* will
randomly generated dungeons be generated? What will they look like?
Have you prototypes any RDGs? (There's an instance where doing a little
coding before solidifying that part of the DD makes sense, btw.)

> > Without laying out a basic design you're just tooling around trying
> > ideas and hoping it will make a game at the end of it. The design doc
> > gives you direction, aims, keeps you on track.

> maybe...

Absolutely. You can't really argue that point. The part that's more
debatable is to what degree you find tooling around enjoyable and
acceptable. For some people, they are very goal-driven, keen on
finishing a project, and they want a plan to get there. For others, the
journey is 1/2 (or more) of the reward, so they don't mind taking a few
"sight-seeing trips" in code, only to throw it out and try something
different next week.

But you asked about how to write a game, and we all sort of read that as
implying "...and I'd like to actually FINISH writing the game, so that,
later, I can 'have written a game'" -- and the "plan & document"
approach is designed to help you, there.

Suggestion: Don't take the "fully-complete design document before a
single line of code" approach -- try to blend that in with your old
style. Do something along the lines of this:

* Make a high-level design that just talks about the basics of your game
in a mostly abstract way. Stuff like "2.5D side-scroller, with
isometric view and representational (vice "realistic") combat", or
whatever.

* Pick a small portion of your design, and think about how you might
want to code it up. Example: Character Generator.

* Make a few notes about what the CG might need: STR, CON, DEX, etc...
Race, Class. Hair color? Age? Height/weight? Maybe make some notes
about a clever way to store all this in a character file.

* Write the Character Generator. If you get to a point where you have
to stop & think during CG-coding, take a break & look at your design
notes. Maybe add to your notes. Look at the other parts of your design
and see how your CG-stuff will fit in with that. Get back to work on
the CG.

* Etc. Repeat this, adding levels of detail as needed.

This is not "ideal" in terms of design documentation, but it might give
you a feel for the advantages of doing it, without interrupting your
"normal flow" too much.

Luck!

--
Please take off your shoes before arriving at my in-box.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.

In article <58d5p1phivc6ojh1ek9426dqu18ve9n07q@4ax.com>, me@privacy.net
says...

> The way to keep focused, particularly on a large project like an RPG
> game, is to have a good design document and stick to it (unless
> re-design is actually required). The design doc should be as complete as
> possible before you start coding.

For an RPG, certainly you need something. Especially for a one-man
project, though, I don't think 'as complete as possible' is needed.
The more people involved, the more complete the document needs to be.

I think that the number of people may be more important than the
project size. A lone wolf always has a sort of document in his head
anyway. As soon as there are two, the head-documents have to be
aligned.

For a puzzle, OTOH, it may be best to just create a small prototype and
see how/if it plays, without necessarily writing down anything at all
first (except a one-liner in the ideas file such as "shapes fall to
make lines")

- Gerry Quinn

In article <3a04b$4393e5f1$ca83a645$27486@saipan.com>, cr88192
@NOSPAM.hotmail.com says...

> or, I could use my own code...
> I have written most of this before, so it would mostly just be code reuse in
> my case.
>
> I have written my own arithmetic coders (typically paq style, eg, processing
> a single bit at a time).
>
> I have also implemented things like bwt, lz77, variations on markov
> prediction, ...
>
> problem is, there is no point in most of them, I write it and, then what?...
> maybe another one or 2 days spent that I wont get back, on something
> unlikely to ever really have much use.

Implement a playable distributable Tetris or similar with high-score
table and difficulty levels (and NO clever code), and it will take you
infinitely further towards finishing your dream game than all the stuff
you have been talking about.

- Gerry Quinn

"Miss Elaine Eos" <Misc@*your-shoes*PlayNaked.com> wrote in message
news:Misc-AC52DB.05571605122005@newsclstr02.news.prodigy.com ...
> There is some middle ground -- but it lies closer to the "plan, design &
> document" end of the spectrum than the "yeah, whatever" end.
>
> In article <20306$4393e343$ca83a645$26556@saipan.com>,
> "cr88192" <cr88192@NOSPAM.hotmail.com> wrote:
>
>> "Alfie [UK]" <me@privacy.net> wrote in message
>> news:7187p1l8nccanql9drc5cv3t426vm47sri@4ax.com...
>> > On Mon, 5 Dec 2005 01:18:22 +0000 (UTC), Raghar <notfor@mail.com>
>> > wrote:
>> >>"Alfie [UK]" <me@privacy.net> wrote in
>> >>news:58d5p1phivc6ojh1ek9426dqu18ve9n07q@4ax.co m:
>> >>> The way to keep focused, particularly on a large project like an
>> >>> RPG game, is to have a good design document and stick to it
>> >>> (unless re-design is actually required). The design doc should
>> >>> be as complete as possible before you start coding.
>
> This is a good goal. However, one should not NOT-code, simply because
> there is some as-yet ambiguous part of their DD.
>
yes.

>> >>Why something like this for RPG? It should be first at least mostly
>> >>writen, then there should be writen design docs, if at all.
>> >>(Actually writing a game is large task, you might forgot something
>> >>so design docs are important when nearly all things are done.)
>
> DDs are ESPECIALLY important on big jobs, especially something like an
> RPG. Unless you're going to do something like "I want to write a game
> that looks & plays exactly like XYZ-game, but using my own artwork", in
> which case you already have a design-doc, it's just very short -- so
> short that you can memorize it.
>
ok.

>> > I have to disagree, how can you start coding before you know what
>> > you're
>> > trying to achieve ?
>
>> I do this all the damn time...
>> what do I have now? what can I make next? what might be needed? ...
>>
>> code is cheap imo.
>> of course, knowing what to code is good, I will agree to this...
>
> You two are arguing "top down" vs "bottom up". But the problem is, even
> with bottom up programming, you need a design. Otherwise, how will you
> ever know if you're done? From what I've read, it seems that cr88192
> suffers from a lot of "...but I never finish" syndrome -- perhaps that's
> due to the lack of finishability inherent in no-design programming.
>
possible, I have never been able to figure this out. the code path for any
non-trivial project becomes open-ended, with no clear end in sight...

> It's a fair bet that you're going to need some sort of graphics display
> engine -- so it makes sense to maybe code a little on that. But how do
> you decide if you're going to use sprites, or 3D, etc., without a
> design?

well, I thought of this, I will use 3D.
I did spec out basic ideas for things in text files on my computer, but they
are more "gathering of ideas" files, than a strict design per se.

> If 3D, how will your data/models be represented?

thought of this:
skeletal models are segmented.
skeleton exists in one file.
one file per anim sequence.
each mesh segment is also represented as a file.

all this is pulled together with a "model definition" file, that says:
use skeleton foo;
use anims bar*;
use meshes baz*.

tools are already written for this.
I could have used milkshape, but it was giving me problems, and it doesn't
treat things how I wanted.

I also dropped the smd format, partly because:
much of the format will go unused anyways;
eular angles cause me displeasure;
the format itself does not apparently support keyframing;
....

the skeleton/anim formats are custom in my case (line-oriented text), but
for the meshes themselves I am using the ac3d format (also line-oriented
text).
vertex-skinned (or whatever the apropriate term is) meshes may also be
needed, as some things (eg: slimes, ...) wouldn't work so well with
segmented models.

the tools still need a little work, particularly in terms of the ui, and a
few other basic features (ability to actually create/modify the skeleton,
rendering mesh textures, ...).

> What parts of
> the code can be shared by client & server, etc? If sprites, how will do
> you layer objects? How will you handle transparency and collisions?
>
for now, I am making it single player only.
sprites, if used at all, will not do anything fancy.

transparency? drawing back to front...
in a tile based world, this could be approximated by figuring about what
order to draw the tiles. objects can either be drawn with their respective
tiles, or be sorted by some other means.

but, for now, I am not worrying about this.

> These are simple questions with easy answers -- but the point is: you
> need to ask & answer them before you can code, unless you just enjoy
> writing throw-away code.
>
yeah, I do answer what I can...

> "Not that there's anything wrong with that..."
>
>> > A design doc isn't just the paper you use to pitch
>> > it to a distributor, the design doc should be your basis for what
>> > you're
>> > doing. You lay out your ideas so you can see how it all hangs together,
>> > what fits, what doesn't, what's the basic storyline, what features are
>> > wanted, what are required by the story, what are nice to have but not
>> > important, how is the player expected to interact, what does that do to
>> > your requirements, etc, etc.
>
>> yeah, me arguing with my brother. me wanting to take the utmost of lazy
>> (going off to an alternate area with turn-based combat), combined with
>> possibly randomly generated dungeons.
>>
>> my brother wants it to not suck...
>
> Where do you stand on the "not-suck" issue?
>
dunno.
I can't take things too seriously, as even if I succeed, a game that both
sucks and takes itself seriously just sucks...

> How will the "alternate area" compare to the original, when players are
> moved there for combat?

probably, vaguely at least...
different themes can be set up for alternate areas.
selection could possibly be set up for the map, or, possibly be based on the
floor texture or some other property.

> Why not just play in the dungeon?
this is possible as well.
the issue is not "set in stone" yet.

one thing though is that going off to an alternate area would at least allow
more modular code. there does not need to be much real interconnect between,
say, the map and the combat code.

> *HOW* will
> randomly generated dungeons be generated? What will they look like?

well, if used, I would need to figure this out.
I had figured possibly fairly randomly placing walls (by stepping along the
grid), and doing some basic checks (is this area reachable? would putting a
wall here make other areas unreachable? ...).

> Have you prototypes any RDGs? (There's an instance where doing a little
> coding before solidifying that part of the DD makes sense, btw.)
>
rdg?...

I did write up a prototype for the map-handling code and pathfinding.

I have yet to write any prototypes for the combat system.

>> > Without laying out a basic design you're just tooling around trying
>> > ideas and hoping it will make a game at the end of it. The design doc
>> > gives you direction, aims, keeps you on track.
>
>> maybe...
>
> Absolutely. You can't really argue that point. The part that's more
> debatable is to what degree you find tooling around enjoyable and
> acceptable. For some people, they are very goal-driven, keen on
> finishing a project, and they want a plan to get there. For others, the
> journey is 1/2 (or more) of the reward, so they don't mind taking a few
> "sight-seeing trips" in code, only to throw it out and try something
> different next week.
>
> But you asked about how to write a game, and we all sort of read that as
> implying "...and I'd like to actually FINISH writing the game, so that,
> later, I can 'have written a game'" -- and the "plan & document"
> approach is designed to help you, there.
>
ok, makes sense.
yeah, my point I guess is to try to finish one, at least so I will have
finished one, paving the way to more advanced projects.

> Suggestion: Don't take the "fully-complete design document before a
> single line of code" approach -- try to blend that in with your old
> style. Do something along the lines of this:
>
> * Make a high-level design that just talks about the basics of your game
> in a mostly abstract way. Stuff like "2.5D side-scroller, with
> isometric view and representational (vice "realistic") combat", or
> whatever.
>
yeah, doing this some already, for what issues I think up.

> * Pick a small portion of your design, and think about how you might
> want to code it up. Example: Character Generator.
>
stats rolling, yay...

you roll, it gives a certain (partly random) amount of points and
distributes them among the stats.

other issues, eg, race, ... would be selectable.

> * Make a few notes about what the CG might need: STR, CON, DEX, etc...
> Race, Class. Hair color? Age? Height/weight? Maybe make some notes
> about a clever way to store all this in a character file.
>
yeah.
probably need at least some basic obfuscation, as otherwise people might be
"too" tempted to go and edit their stats.

> * Write the Character Generator. If you get to a point where you have
> to stop & think during CG-coding, take a break & look at your design
> notes. Maybe add to your notes. Look at the other parts of your design
> and see how your CG-stuff will fit in with that. Get back to work on
> the CG.
>
ok.

> * Etc. Repeat this, adding levels of detail as needed.
>
> This is not "ideal" in terms of design documentation, but it might give
> you a feel for the advantages of doing it, without interrupting your
> "normal flow" too much.
>
ok, makes sense.

luckily, for me, last class of last day of semester.
will still be dropped off at normal time, so I have to wait around for about
4+ hours for my class.
maybe I can bring my laptop. I wanted on for a reason after all, as 4+ hours
of waiting, otherwise, is just lame (but, it is tolerable, twards the start
of the semester, I sat around doing nothing for about 7-8 hours, and started
to destabilize...).

> Luck!
>
> --
> Please take off your shoes before arriving at my in-box.
> I will not, no matter how "good" the deal, patronise any business which
> sends
> unsolicited commercial e-mail or that advertises in discussion newsgroups.

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1dfe6a98eba0cb4798a812@news1.eircom.net.. .
> In article <3a04b$4393e5f1$ca83a645$27486@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>
>> or, I could use my own code...
>> I have written most of this before, so it would mostly just be code reuse
>> in
>> my case.
>>
>> I have written my own arithmetic coders (typically paq style, eg,
>> processing
>> a single bit at a time).
>>
>> I have also implemented things like bwt, lz77, variations on markov
>> prediction, ...
>>
>> problem is, there is no point in most of them, I write it and, then
>> what?...
>> maybe another one or 2 days spent that I wont get back, on something
>> unlikely to ever really have much use.
>
> Implement a playable distributable Tetris or similar with high-score
> table and difficulty levels (and NO clever code), and it will take you
> infinitely further towards finishing your dream game than all the stuff
> you have been talking about.
>
too simple imo.

I would get done with this too quickly (a few hours maybe, or less), and
would be left feeling disappointed. this has happened in the past, eg, if
there is not enough work put in, when when I do "accomplish" something, I
feel disappointed, and I no longer care about it.

I have had this experience before.

> - Gerry Quinn

cr88192 wrote:

> too simple imo.
>
> I would get done with this too quickly (a few hours maybe, or less), and
> would be left feeling disappointed. this has happened in the past, eg, if
> there is not enough work put in, when when I do "accomplish" something, I
> feel disappointed, and I no longer care about it.
>
> I have had this experience before.

There is no possible way you could start and finish a Tetris clone in "a
few hours" or less unless you had a complete game framework ready to go
and were just implementing. I think this is a fundamental problem with
your approach; you're only counting the fun part as the effort required,
and ignoring the polishing, packaging, and finishing of a project. I
don't think there's much doubt that most of us would prefer jobs where
we only had to do the fun parts of programming rather than the
gruntwork, but the fact is most of the work involved in any software
task is boring gruntwork. And only that boring gruntwork is going to
get you to a shippable state.

Since you appear to have so much trouble finishing things, I submit this
is exactly the hurdle you need to overcome to have any hope of finishing
any project that you wish to work on. Unless you seriously attempt to
address this, it's highly unlikely you'll ever finish (in the sense of
having something done and presentable) anything.

Or, to put it another way, if you think that a Tetris clone is too
simple, then your RPG project is certainly far too complicated for you
to ever finish.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
I am an island / A little freak of melancholy
-- Lamya

"Erik Max Francis" <max@alcyone.com> wrote in message
news:7fadnUYAPOJzSQneRVn-oQ@speakeasy.net...
> cr88192 wrote:
>
>> too simple imo.
>>
>> I would get done with this too quickly (a few hours maybe, or less), and
>> would be left feeling disappointed. this has happened in the past, eg, if
>> there is not enough work put in, when when I do "accomplish" something, I
>> feel disappointed, and I no longer care about it.
>>
>> I have had this experience before.
>
> There is no possible way you could start and finish a Tetris clone in "a
> few hours" or less unless you had a complete game framework ready to go
> and were just implementing. I think this is a fundamental problem with
> your approach; you're only counting the fun part as the effort required,
> and ignoring the polishing, packaging, and finishing of a project. I
> don't think there's much doubt that most of us would prefer jobs where we
> only had to do the fun parts of programming rather than the gruntwork, but
> the fact is most of the work involved in any software task is boring
> gruntwork. And only that boring gruntwork is going to get you to a
> shippable state.
>

(game framework) in a sense yes, I call it "code that I have written
already". with this in place (typically copied from previous projects), one
can usually get things like basic 3d engines, various other kinds of
tools/apps, ... up and running in between a few minutes and a few hours (the
limit is how much work one wants to put into the codebase beforehand, eg,
"novelty factor").

in this case, I did a little more heavy editing (not wanting to drag along a
lot of code I largely wont need), so the work in setting up the initial
parts of the engine was a little more. but, this is still not that much in
total.


the more one has, and the more one remembers, the faster and easier it is to
accomplish tasks. even seemingly new problems are dealt with typically by
copying and editing old code.


now, what is tetris?
so basic squares to be drawn, maybe a few bit arrays, and shifting the bit
arrays (removing rows).

for example, if the screen is 16x32 blocks, each row fits nicely in a short:
for(i=0; i<31; i++)
if(row[i]==0xFFFF)
{
for(j=i; j<31; j++)
row[j]=row[j+1];
row[31]=0;
}

(for doing the row-shifting operation or such).


then, one has to worry about the current shape, but this shouln't be too
hard either (a set of bits can indicate squares that are part of the current
shape, flags can be tested, and it becomes a loop, a few ands, and a few
xors). when shifting down the shape, if it would intersect another shape (a
few ands maybe), the bits marking it as part of the current shape are
cleared, and a flag is set to indicate dropping the next shape. a few more
masks, and the new shape is added, ...

this does not seem like much work (or at least not enough to actually
dedicate a "project" to).


making a well-polished version, that is more work, I will agree to that at
least.


> Since you appear to have so much trouble finishing things, I submit this
> is exactly the hurdle you need to overcome to have any hope of finishing
> any project that you wish to work on. Unless you seriously attempt to
> address this, it's highly unlikely you'll ever finish (in the sense of
> having something done and presentable) anything.
>
> Or, to put it another way, if you think that a Tetris clone is too simple,
> then your RPG project is certainly far too complicated for you to ever
> finish.
>

my problem is not coding, that is easy. my problem is tasks not coding. I
think it is more related to avoiding getting too caught up in things
unrelated to the task.

easier is to go and deal with more of what I do already, but I can see where
that would go.

so on I go for now...

> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> I am an island / A little freak of melancholy
> -- Lamya

cr88192 wrote:

> my problem is not coding, that is easy. my problem is tasks not coding. I
> think it is more related to avoiding getting too caught up in things
> unrelated to the task.
>
> easier is to go and deal with more of what I do already, but I can see where
> that would go.
>
> so on I go for now...

As I've pointed out repeatedly, your problem appears to be finishing.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Men with empires in their purpose / And new eras in their brains
-- Lamya

"Erik Max Francis" <max@alcyone.com> wrote in message
news:zO2dnVl5z5NRcgneRVn-rQ@speakeasy.net...
> cr88192 wrote:
>
>> my problem is not coding, that is easy. my problem is tasks not coding. I
>> think it is more related to avoiding getting too caught up in things
>> unrelated to the task.
>>
>> easier is to go and deal with more of what I do already, but I can see
>> where that would go.
>>
>> so on I go for now...
>
> As I've pointed out repeatedly, your problem appears to be finishing.
>
oh, ok.

I had thought you were insulting my coding skill or something...

yeah, my "finishing" skills suck, I will admit that.

> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> Men with empires in their purpose / And new eras in their brains
> -- Lamya

On Tue, 6 Dec 2005 07:13:25 +1000, "cr88192"
<cr88192@NOSPAM.hotmail.com> wrote:
>"Miss Elaine Eos" <Misc@*your-shoes*PlayNaked.com> wrote in message
>news:Misc-AC52DB.05571605122005@newsclstr02.news.prodigy.com ...
>> There is some middle ground -- but it lies closer to the "plan, design &
>> document" end of the spectrum than the "yeah, whatever" end.
>>
>> This is a good goal. However, one should not NOT-code, simply because
>> there is some as-yet ambiguous part of their DD.
>>
>yes.

Agreed, when I said 'as complete as possible' I didn't mean you have to
have an almost complete DD before proceeding, sometimes it makes sense
to create some prototype code to see how your ideas mesh before deciding
the next step of design.

The problems I see some people having is because they don't have any
design beyond an idea in their head and they have to constantly refactor
as they add new ideas or find a piece of code doesn't do what they want.
>
>> You two are arguing "top down" vs "bottom up". But the problem is, even
>> with bottom up programming, you need a design. Otherwise, how will you
>> ever know if you're done? From what I've read, it seems that cr88192
>> suffers from a lot of "...but I never finish" syndrome -- perhaps that's
>> due to the lack of finishability inherent in no-design programming.
>>
>possible, I have never been able to figure this out. the code path for any
>non-trivial project becomes open-ended, with no clear end in sight...

This is why I suggested spending more time on design before getting
caught up in coding. Learning to formulate and set a goal, then achieve
it, should help you stay focused on that task.
>
>> It's a fair bet that you're going to need some sort of graphics display
>> engine -- so it makes sense to maybe code a little on that. But how do
>> you decide if you're going to use sprites, or 3D, etc., without a
>> design?
>
>well, I thought of this, I will use 3D.
>I did spec out basic ideas for things in text files on my computer, but they
>are more "gathering of ideas" files, than a strict design per se.

Sounds like you have the beginning of a features list. You can just
write those out as bullet points under the heading 'features' and that's
the start of your design, at it's most basic a DD is just a collection
of your thoughts on what you're going to be doing. I tend to think in
terms of project management as I used to be a PM at work, so I usually
start with the aim, scope, then brainstorm for features/aspects, etc...
>
>>> my brother wants it to not suck...
>>
>> Where do you stand on the "not-suck" issue?
>>
>dunno.
>I can't take things too seriously, as even if I succeed, a game that both
>sucks and takes itself seriously just sucks...

If brainstorming gets bogged down in trying to nail down features that
you do want, it's sometimes useful to brainstorm 'things that you don't
want', so try getting your brother to define what in his opinion makes
games suck. Write these down as bullet points under 'Dont want' or
something;

- Stupid AI - enemies that run straight at you even if there is cover
available or they are wounded or out of ammo
- Corridor shooter - player is guided down a very narrow game story with
limited scope to explore
- Unnecessary spawning - so areas you've cleared out are inexplicably
repopulated with bad guys out of nowhere
....etc

You should be able to see that this then gives you a bit more direction
in what you should do, turning negatives into positives, so adding to
your 'Feature' list;

- Tactical AI - AI agents should be able to use cover, retreat when
wounded or out of ammo
- Open play area - the player should be free to use more than one path
to beat a level, the player should be able to explore
- Limited spawning - spawning only takes place from areas that have a
believable spawn reason, such as a barracks, or another adjacent area
....etc
>
>> Have you prototypes any RDGs? (There's an instance where doing a little
>> coding before solidifying that part of the DD makes sense, btw.)
>>
>rdg?...

'Random Dungeon Generator' I think.

I agree with prototyping, particularly if an idea comes up with
something that you've never tried before, otherwise you won't know until
you start coding whether it will work or not.
--
Alfie
<http://www.delphia.co.uk/>
Connection error: insufficient breasts. This has caused an unexpected deflation of the apparatus.