[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: To cross develop or not - was Re: eBay WTH?

heuser.marcus@freenet.de wrote:

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.


Playing endlessly with micro-optimizations is an only occasionally
useful time sink.  ;-)

Fleshing out a design "on paper" is an excellent way of building
several generations of "virtual prototypes" so that less effort is
wasted going down major detailed blind alleys.

The trick for me is sustaining enthusiasm for a long time without
actually coding anything.  I find that putting pencil to paper is
both focusing and stimulating, but I'm sure folks differ in that
respect.  (My real wastebasket does tend to fill up with paper.  ;-)


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've always been mystified by how subtle changes in rules can
dramatically alter the strategy and play of a game.  It's safe
to say that I don't know how to design a game for "playability".


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.


I've found a "big crash" can be the best thing that ever happens to
a project, since it requires/permits a total reevaluation of everything.
That opens the door to the next "level" of design, since the solution
to the problem that caused the "crash" infuses the project with new
life and possibilities.

It's the "big" version of typing in a long program/article/story and
losing it all to a crash/power failure/error--putting the loss behind
you and re-entering it goes much faster than the original effort, and
with better results, as many improvements are made in the process!


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 ;-)


If you have fun and learn something, then your "failure" was a
splendid success--and if you succeed, it's all gravy!


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 ;-)


Excellent.


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.


Actually, it's Apple-resolution--560x192.  ;-)  Everything else is
smoke and mirrors.


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


I'm not sure how those two thoughts fit together.

AppleWin graphics are the usual "RGB-style" Apple graphics, which
are crisp to a fault (IMHO) and extremely limited in palette.

NTSC graphics (which I presume many of your users will see, but
who knows?) are much smoother and offer lots of dithered colors.

These are polar opposites, in the sense that "crisp" and "smooth"
don't go together.


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 ;-)


I notice the same effect.  I seldom reposition the cursor to correct
a line--I just backspace and re-type.  A music teacher would call that
"rehearsing" the correct keystrokes rather than an _ad hoc_ correction,
I suppose.


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.


Actually, creating data structures is one of the primary uses
for macros.  (I once even used more text-capable macros to create
the *documentation* for the structures!)


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


The only positive result of going public with your aspirations
(which you've already done ;-) is to create additional motivation
to complete the project.


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.


Don't we all!

More power to you.

-michael

AppleCrate II: An Apple II "blade server"!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."