Re: eBay WTH?

[heuser.marcus@freenet.de]

On Aug 22, 3:25 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> heuser.mar...@freenet.de wrote:
>
> Sometimes its for the code--in fact, sometimes it's even for the
> hardware!  The "wastebasket" applies at every level of abstraction
> in design.
>
> Sometimes you only learn that a given coding approach is the
> hard/big/slow/wrong way to go by going there.  Often, you learn
> what is important by ignoring it until it bites you.

I want to avoid the really big mistakes (think macroeconomic) while
the unavoidable smaller mistakes and experiments inevitably wander
into a "waste basket". In my case it's more of a storage basket -
who knows when they'll come in handy? Code optimizations are a prime
example for this, too.

> No matter how much thinking and planning you put into a project,
> there will *always* be things that crop up that you either didn't
> or couldn't have foreseen that require course changes.
>
> When this happens, you will face a moment of truth:  keep the
> structure you have expended so much effort on and kludge in the
> needed functionality, or throw things out and change it (with
> correspondingly more effort) into the system you wish you had
> fully foreseen from the beginning.
>
> There are arguments and situations favoring each fork of this
> dilemma.  In industry, pragmatism usually triumphs and the entropy
> of the system grows continually until it is simply unmanageable.
> For my own projects, I usually find a way to come back and do it
> right, since *how* I did something is as important to me as *what*
> I did.  ;-)

You are certainly right with the above points and your example
illustrates this well.
To clarify: Nobody produces (always) faultless code or designs - if
that were the case then learning by accident wouldn't happen. My game
will definitely need a testing and balancing phase in which I will
have to correct errors and tweak parameters.
This is natural as I - like all designers - can't anticipate how the
players will use and abuse the system.

I have some advantages, however:

Firstly, I'm not a part of an industry so thankfully I don't have any
financial or time restrictions on my side. I expect people to be
entertained by the product and try to make their experience as best
as I can - if all it needs is a kludge then a kludge it is.

Secondly, I want to avoid the "big crash", you said it beautifully -
the moment of truth - and that's where your NadaNet comes into play:
It's pioneering work, while my game surely isn't.
Ok - it will have some moments and -I hope- some innovations (at least
for the Apple II platform) but I don't exactly design the wheel here.

Of course I may ultimately fail with the experience I try to provide.
But I don't start with a big (but thankful) audience in the first
place so my failing won't go into the annals of gaming ;-)

> Although there are excellent arguments for waiting to start coding
> until a design is fully worked out (in fact, *I've* occasionally
> urged that!), there is also much to be said for getting something
> running early, to create something concrete and to inspire further
> development.

I know what you mean but ATM I'm inspired enough ;-)

> It's unfortunate that it can't be resized to, say, 2x size...  But I
> find that development is quite easy even on the small screen.  After
> all, it's not like there's any more information on a bigger version
> of the small screen.  ;-)

The AppleWin window resolution is how big? 640x480? Doubling it
would be very pleasant in my opinion. I'm happy that I'm not alone
on this.
Also, the AppleWin screen doesn't look anywhere near the finished
result on a TV-set/monitor of yore.
I understand that most guys worked years with old TV sets and are
fed up with that and want crystal clear, pixellized VGA screens
(the discussion pops up regularly) but my position for that project
is different. I don't want it to look authentic - including NTSC
and all of it's "unplanned color nuances" (don't know a better
wording for it).

> When I get into "development mode", all the details of the
> environment--the screen, the keystrokes, the multiple edits
> and recompiles--all disappear in the passion to get the result.
> The "rituals" of all the manual steps actually don't bother me
> at all.  In fact, I think they play the same role as background
> music for some developers.  ;-)

The interesting thing for me is that I got fast enough on the
keyboard in the recent years (I can now type blindly). I guess,
that's what you get when you often discuss in usenet groups or
send email and can't type as fast as you want.
Back then, in the eighties, I was very slow and hacking in code
was a chore and not fun at all.
Now it's easier to type a sentence anew instead of correcting it -
which is good in your waste basket scenario, too ;-)

> > It seems that I have to create some sort of simple scripting
> > language just to save memory but I this isn't really comparable.
>
> And it is well-supported by Merlin macros, as well.  ;-)

That's what I thought (for data structures, not for 6502-code).
Starting addresses, strings, 8 and 16 bit integers - all available.

> I like that--no promises, just deliveries!

I would hate being added to the list of people publishing their work
on the net, building hype and even a "fanbase", that awaits the coming
of the new messiah - and then being unable to continue/deliver.
I don't think that people are getting a kick out of the information
that somebody is working somewhere on something...

Also, the game will have lots of (hopefully) nice surprises and
enjoyable moments that make it worthwhile - even for people usually
not interested in that kind of stuff and only collect disk images.

I thought about blogging it, but found that too many arguments are
against that and too few advantages for *my* project. Additionally,
there are several blogs already in existance giving more people
(PC platform!) enough to read/think about. I know because I read
some of them ;-)

All of this doesn't forbid me to discuss coding and other technical
stuff here, which I do enjoy and need because I have still a lot to
learn.

bye
Marcus