attempting an actual game...

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1dfbc7885044abaa98a7fc@news1.eircom.net.. .
> In article <88e04$4390f425$ca83a6d2$7426@saipan.com>, cr88192
> @NOSPAM.hotmail.com says...
>
>> vague ancilary thoughts (need to get to eventually probably):
>> me thinking of redoing the internal file-system stuff.
>> I have my old system, which has been being dragged along since about the
>> late 90's, and has become an imo horrid mess that I no longer maintain.
>> considering rewriting it, but keeping about the same external interface.
>> right now I am using stdio's files, which I don't particularly like (I
>> have
>> to manually alter the names to reference crap in my resource directory).
>>
>> also considering a resources format. deciding if I should compress the
>> contents.
>> I could use zip (would need to write the code for zip files, luckily I
>> already wrote the inflate code when I wrote the png loader), but the zip
>> format is kind of ugly.
>> zip is de-facto, but I am not entirely sure if this matters in this case.
>>
>> I could do something custom, eg, a format similar to the pak format used
>> in
>> quake1/2.
>> then, I could decide whether or not to compress contents, possible is
>> arithmetic coding and a variation of bwt (the algo used in bzip2). the
>> code
>> would be fairly simple and elegant, and ratios would likely exceed those
>> of
>> zip+deflate, but speed would not be as good.
>>
>> then again, right now this would count as me getting distracted...
>
> Every single one of the things you suggest above count as you getting
> distracted, if your purpose is to complete a project - any project.
>
dunno, probably...

> - Gerry Quinn
>

"Nathan Mates" <nathan@visi.com> wrote in message
news:11p3hscko8vdmd4@corp.supernews.com...
> In article <88e04$4390f425$ca83a6d2$7426@saipan.com>,
> cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>>I could do something custom, eg, a format similar to the pak format
>>used in quake1/2. then, I could decide whether or not to compress
>>contents, possible is arithmetic coding and a variation of bwt (the
>>algo used in bzip2). the code would be fairly simple and elegant,
>>and ratios would likely exceed those of zip+deflate, but speed would
>>not be as good.
>
>>then again, right now this would count as me getting distracted...
>
> This is why using other people's libraries-- such as zlib, libpng,
> jpeg libs, etc-- is a *feature*, not a bug. By using them, you get the
> infrastructure in place, and quickly, and then you don't waste time
> reinventing the wheel a few dozen times. Even using other people's
> modeling, skinning formats will let you work on the gameplay that much
> sooner.
>
ok.

at least largely a lot of the code I was talking about has allready been
written in the past, would just need to be globbed together.

then again, that I went off and wrote my own versions of paq and bzip2
(errm, and zlib, libpng, numerous and some jpeg-like image formats, several
audio codecs, ...) also shows how ammazingly good of focus I have...

and then I wonder by what means some of my projects turn into several
hundred kloc monstrosities...

> Ultimately, this project of yours will succeed or fail depending on
> whether you can actually stop this bad habit of being distracted by
> any little issue that comes your way, and actually *finishing* a task
> before even considering another. If your aim is to merely learn, then
> knock yourself out with distractions. If your aim is to finish this
> project, you're going to need a major change in mindset. Even time
> spent with your blog-like postings of what you've done recently is
> also a distraction. Produce results, not attention-seeking posts.
>
yeah, makes sense.

afaik I have not posted here for a while now though.

all in all though, this is attempting to change away from obsessing solely
on technical issues. for around a year now, I had ended up obsessing
primarily on physics simulation, and, during this time, still not succeeding
in getting completely stable stacking behavior for what solid types actually
mattered (obbs and hulls).

this had reached a level to where, basically, the original project was going
nowhere as a result.

it is good enough though, it is probably more important that things look
"about" right, one can ignore the fact that stacks never really manage to
hold up on their own...

in an rpg, no one is likely to care either, stacks of objects and similar
are more modern-fps domain (and, even then, they are typically rare).

> Nathan Mates
> --
> <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
> # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
> # NOT speaking for Pandemic Studios. "Care not what the neighbors
> # think. What are the facts, and to how many decimal places?" -R.A.
> Heinlein

"Philippa Cowderoy" <flippa@flippac.org> wrote in message
news:Pine.WNT.4.61.0512031525350.1416@SLINKY...
> On Fri, 2 Dec 2005, cr88192 wrote:
>
>> yeah, before I had vaguely been trying for fps like stuff, but fps does
>> not
>> give much motivation to put really any real effort into the "game" part,
>> leading to a kind of ongoing obsession with the rendering and physics in
>> my
>> experience...
>>
>
> As a quick note, even after the source release I spent more time on
> gameplay-type things (including control physics) in Quake than rendering.
> It's a matter of having an active interest in such things - there're still
> experiences I'd like to get round to building sometime.
>

yeah, in my case, I cloned most of the quake engine, but that was pointing
itself out to be a pointless endevor. why clone the quake engine, when it
allready exists?...

so, then I wrote a physics engine, but, then again, there is already ode, so
not much compelling use there.

endless side projects, eg, messing around with different styles of
compressors. without a good use, there is not much use for them though. most
of the good and fast algos are already used by some vaguely mainstream tool.

that about sums up the last year or so.

things end up being half-assed clones of other things, but nothing really
worthwhile in its own right.


then I end up feeling like I exist by myself in a kind of void...

> --
> flippa@flippac.org
>
> Ivanova is always right.
> I will listen to Ivanova.
> I will not ignore Ivanova's recomendations.
> Ivanova is God.
> And, if this ever happens again, Ivanova will personally rip your lungs
> out!

On Fri, 2 Dec 2005 18:43:11 +1000, "cr88192"
<cr88192@NOSPAM.hotmail.com> wrote:
>"Erik Max Francis" <max@alcyone.com> wrote in message
>news:1PKdnWh7oL5afRLeRVn-tw@speakeasy.net...
>> cr88192 wrote:
>>
>>> I don't know, maybe I am on the wrong track here...
>>
>> Given your propensity for getting distracted and not finishing existing
>> projects, this one is a doozie. You're probably best off picking
>> something much smaller scale and much more manageable as a first serious
>> project.
>>
>yeah, keeping from getting distracted will definately be difficult.
>
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.

It will take a while to lay out a proper design doc, and if you're
working with someone else (your brother) then a lot of discussion to
round out the ideas and direction that you want to go. Once you have an
agreed design doc, you know what you need to focus on, it makes it
easier to set targets, track progress, and stay on track.

There is no set format for a design doc but they will all have similar
elements that outline the game, goals, story, targets, etc.

http://forums.cgsociety.org/showthre...ight=flowchart

http://www.ihfsoft.com/designdocuments.htm
http://www.gamasutra.com/features/19...design_doc.htm
http://www.gamedev.net/reference/pro...tures/techdoc/
--
Alfie
<http://www.delphia.co.uk/>
I almost had a psychic girlfriend but she left me before we met.

"Alfie [UK]" <me@privacy.net> wrote in message
news:58d5p1phivc6ojh1ek9426dqu18ve9n07q@4ax.com...
> On Fri, 2 Dec 2005 18:43:11 +1000, "cr88192"
> <cr88192@NOSPAM.hotmail.com> wrote:
>>"Erik Max Francis" <max@alcyone.com> wrote in message
>>news:1PKdnWh7oL5afRLeRVn-tw@speakeasy.net...
>>> cr88192 wrote:
>>>
>>>> I don't know, maybe I am on the wrong track here...
>>>
>>> Given your propensity for getting distracted and not finishing existing
>>> projects, this one is a doozie. You're probably best off picking
>>> something much smaller scale and much more manageable as a first serious
>>> project.
>>>
>>yeah, keeping from getting distracted will definately be difficult.
>>
> 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.
>
too late for that...
yeah, at least part of the engine is coded thus far.

I recently wrote crap for pathfinding around my tile-based maps (it was
difficult partly as I soon realized that a brute-force search wasn't going
to work so well, so with fudging and some limits set in, it works, for the
most part at least...).

partly, I did this as I had come to the realization that, with this style of
engine and pathfinding, I don't really need physics for now. things just
wont go through walls, because the engine wont find paths that go through
walls...

otherwise, I was going to start on visibility checking. maybe I would try
out having color-changing squares that chase down the blue square presently
representing the player...


but, yeah, I am designing some things at least. eg: I planned that I would
use tile-based maps. this implies a lot. I had just figured if I continued
trying to use bsp-based maps I wouldn't really get anything done (lower
level physics stuff dominates over higher-level movement tasks).


after this kind of thing is done, maybe I can start working on a combat
system, or integrating the disparate chunks of code that are presently
forming.


> It will take a while to lay out a proper design doc, and if you're
> working with someone else (your brother) then a lot of discussion to
> round out the ideas and direction that you want to go. Once you have an
> agreed design doc, you know what you need to focus on, it makes it
> easier to set targets, track progress, and stay on track.
>
maybe.

my brother's ideas have thus far been along the lines of:
kill monsters (eg: orcs) and their heads fly off;
have a suit that offers near invulnerability at the cost of near
immovability;
....

> There is no set format for a design doc but they will all have similar
> elements that outline the game, goals, story, targets, etc.
>
> http://forums.cgsociety.org/showthre...ight=flowchart
>
> http://www.ihfsoft.com/designdocuments.htm
> http://www.gamasutra.com/features/19...design_doc.htm
> http://www.gamedev.net/reference/pro...tures/techdoc/

game: some ideas, stated before I think;
goals: ?...

story: yeah, hopefully I don't have to come up with this, I don't presently
have much better than "vampiric drows are being all evil and stuff", and
"the wildlife is filled with gold and items".

targets: ?...

now, thinking, maybe combat will be turn based, though realtime might also
work, I don't know...

combat could go into its own area maybe (as in many rpgs...). or I could
not...

hmm...

> --
> Alfie
> <http://www.delphia.co.uk/>
> I almost had a psychic girlfriend but she left me before we met.
>

"Alfie [UK]" <me@privacy.net> wrote in
news:58d5p1phivc6ojh1ek9426dqu18ve9n07q@4ax.com:

> On Fri, 2 Dec 2005 18:43:11 +1000, "cr88192"
> <cr88192@NOSPAM.hotmail.com> wrote:
>>"Erik Max Francis" <max@alcyone.com> wrote in message
>>news:1PKdnWh7oL5afRLeRVn-tw@speakeasy.net...
>>> cr88192 wrote:
>>>
>>>> I don't know, maybe I am on the wrong track here...
>>>
>>> Given your propensity for getting distracted and not finishing
>>> existing projects, this one is a doozie. You're probably best
>>> off picking something much smaller scale and much more
>>> manageable as a first serious project.
>>>
>>yeah, keeping from getting distracted will definately be
>>difficult.
>>
> 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.
>
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.)

> It will take a while to lay out a proper design doc, and if
> you're working with someone else (your brother) then a lot of
> discussion to round out the ideas and direction that you want to
> go. Once you have an agreed design doc, you know what you need
> to focus on, it makes it easier to set targets, track progress,
> and stay on track.
>

It could be a long time of useless time spend by doing design docs,
that are neccessary to be completely rewriten before sucessful end
of the project. More important is doing GM, creativity, and a
writing talent.

For a two man team, it's more important ability of talking about it
in a reasonable constructive way, and ability to redirect the work
properly.

RPG is easy.
2.5 month game engine and game.
up to 4 months graphics.
And a ton of text. The problem with text is, it needs to be
consistently writen.

"cr88192" <cr88192@NOSPAM.hotmail.com> wrote in
news:88e04$4390f425$ca83a6d2$7426@saipan.com:

> then, I could decide whether or not to compress contents,
> possible is arithmetic coding and a variation of bwt (the algo
> used in bzip2). the code would be fairly simple and elegant, and
> ratios would likely exceed those of zip+deflate, but speed would
> not be as good.
>

If you want I could send you a my source files for "something like
arithmetic coding". It has been writen in Java, but you could port it
easily. Don't forget to set limit for model to 15 MB or so, or you
could end with 512 MB filled by data analisys.
Nothing fancy but nice proof that you could do a complex program by
trial and error, and you could get it working without understanding
the algorithm completely/at all.

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.com :
>> 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.
>>
>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.)

I have to disagree, how can you start coding before you know what you're
trying to achieve ? 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.

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.
>
>> It will take a while to lay out a proper design doc, and if
>> you're working with someone else (your brother) then a lot of
>> discussion to round out the ideas and direction that you want to
>> go. Once you have an agreed design doc, you know what you need
>> to focus on, it makes it easier to set targets, track progress,
>> and stay on track.
>
>It could be a long time of useless time spend by doing design docs,
>that are neccessary to be completely rewriten before sucessful end
>of the project. More important is doing GM, creativity, and a
>writing talent.

Design docs are always a work in progress, but you should write as much
as you can before coding. What happens if you get halfway into writing
your uber engine and your story guy runs out of ideas ? What happens if
your brainstorming leads to new ideas about character interaction
halfway through an engine build and you have to re-write the whole
engine to account for this new feature ?

Time spent on game design beforehand is less wasted time coding
(assuming you know your coding limits when in the design phase - no
point agreeing to an uber-feature and then finding out you don't know
how to implement it).
>
>For a two man team, it's more important ability of talking about it
>in a reasonable constructive way, and ability to redirect the work
>properly.
>
>RPG is easy.
>2.5 month game engine and game.
>up to 4 months graphics.
>And a ton of text. The problem with text is, it needs to be
>consistently writen.

It's taken me nearly 3 years to get the design nailed on my 1st/3rd
person sci-fi RPG, mostly because my story guy kept re-writing (he's in
the US I'm in UK so it's not easy to sit down and talk about issues, we
were both working real time jobs as well), and my fiancé passed away
last year.

Without the intervening hassles I would think we would not have reached
the current stage in less than 10 months, and there's probably another
4-6 months coding (and graphics) to go.

I'll second that the text needs to be consistent, a lot of the re-writes
have been because the story was adapted from a short story written 7
years ago and has needed to be updated and 'free-formed' to allow more
open character paths (which meant writing multiple story paths to allow
for player divergence from the basic plot lines).
--
Alfie
<http://www.delphia.co.uk/>
Everything can be filed under 'miscellaneous'.

"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.
>>>
>>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.)
>
> 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...

> 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...

> 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...

>>
>>> It will take a while to lay out a proper design doc, and if
>>> you're working with someone else (your brother) then a lot of
>>> discussion to round out the ideas and direction that you want to
>>> go. Once you have an agreed design doc, you know what you need
>>> to focus on, it makes it easier to set targets, track progress,
>>> and stay on track.
>>
>>It could be a long time of useless time spend by doing design docs,
>>that are neccessary to be completely rewriten before sucessful end
>>of the project. More important is doing GM, creativity, and a
>>writing talent.
>
> Design docs are always a work in progress, but you should write as much
> as you can before coding. What happens if you get halfway into writing
> your uber engine and your story guy runs out of ideas ? What happens if
> your brainstorming leads to new ideas about character interaction
> halfway through an engine build and you have to re-write the whole
> engine to account for this new feature ?
>
this, however, seems questionable. things even close to this have not really
occured in any of my projects (even during significant redesign and
rewriting, much of the code remains in tact).

even drastic changes, like for example moving from raw hardware to
userspace. much of my code was once an os, then I took the code, fused it
with quake, tore it back off, and thus have a lot of my modern codebase
(after gradually replacing bits of quake's code with different code). then,
after a few years, it reaches a few hundred kloc, having largely become a
huge pile of unmaintained crap...

some rather ugly things still reside in the code though. though, this
project is a lot closer to clean. then again, coding clean risks the
problems of "new code", eg, bugs and notable inflexibility. usually, code
gets better after being moved between a few projects and partly rewritten a
few times, but there are limits. "old code" can become very crufty, which is
part of my complaint about my file management code. this code is from my
middle school days, and during high school I did some rather questionable
things to it. so, this code may be replaced, as there are new things I think
I will need to do with it...


> Time spent on game design beforehand is less wasted time coding
> (assuming you know your coding limits when in the design phase - no
> point agreeing to an uber-feature and then finding out you don't know
> how to implement it).

yeah, knowing limits is good. that is why I set them fairly low for this
project. small goals means higher chance of success.

then again, for me I regard a few kloc as a fairly small piece of code, and
I would gather others disagree. this is maybe a day or so of "good" coding.
then again, as of late I have rarely been able to dedicate that much time to
my projects, which is lame...


>>
>>For a two man team, it's more important ability of talking about it
>>in a reasonable constructive way, and ability to redirect the work
>>properly.
>>
>>RPG is easy.
>>2.5 month game engine and game.
>>up to 4 months graphics.
>>And a ton of text. The problem with text is, it needs to be
>>consistently writen.
>
> It's taken me nearly 3 years to get the design nailed on my 1st/3rd
> person sci-fi RPG, mostly because my story guy kept re-writing (he's in
> the US I'm in UK so it's not easy to sit down and talk about issues, we
> were both working real time jobs as well), and my fiancé passed away
> last year.
>
thats not good...

I can say that is probably far worse than the lack of luck I have trying to
find anyone to begin with...
worse probably than having the person I would hope for come to somewhat hate
me... then again, this is nothing new.

if there is anything worse than my ability to keep on track with projects,
or preparing to be self-sufficient eventually (can't live with parents
forever, but too lazy to get a job), it is my luck with females. if I talk
to anyone, they end up hating me...

they can do whatever though. their lives, their choices, but I do feel alone
and vaguely fear remaining so...


> Without the intervening hassles I would think we would not have reached
> the current stage in less than 10 months, and there's probably another
> 4-6 months coding (and graphics) to go.
>
> I'll second that the text needs to be consistent, a lot of the re-writes
> have been because the story was adapted from a short story written 7
> years ago and has needed to be updated and 'free-formed' to allow more
> open character paths (which meant writing multiple story paths to allow
> for player divergence from the basic plot lines).

yeah.

I don't really get how this would effect the engine/code though.
usually, I would think, it is more simple things like deciding on world
structure and various design aspects.

after that, I would think most of the rest would be data?...

then again, I am not exactly aiming for "quality" either, just something I
can potentially get done. better can probably be done later, after I get the
general idea of working in the framework of a "whole" game vs just parts of
a game...

"pulling it all together" may be hard though.


> --
> Alfie
> <http://www.delphia.co.uk/>
> Everything can be filed under 'miscellaneous'.
>

"Raghar" <notfor@mail.com> wrote in message
news:Xns97231778095A8Raghar@195.250.128.45...
> "cr88192" <cr88192@NOSPAM.hotmail.com> wrote in
> news:88e04$4390f425$ca83a6d2$7426@saipan.com:
>
>> then, I could decide whether or not to compress contents,
>> possible is arithmetic coding and a variation of bwt (the algo
>> used in bzip2). the code would be fairly simple and elegant, and
>> ratios would likely exceed those of zip+deflate, but speed would
>> not be as good.
>>
>
> If you want I could send you a my source files for "something like
> arithmetic coding". It has been writen in Java, but you could port it
> easily. Don't forget to set limit for model to 15 MB or so, or you
> could end with 512 MB filled by data analisys.
> Nothing fancy but nice proof that you could do a complex program by
> trial and error, and you could get it working without understanding
> the algorithm completely/at all.

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.