Re: [Alephmodular-devel] Developer Rant #1 :)

[Woody Z. I. <woo...@sb...>]

(Sorry if the first few responses seem snippy, try to take them as 
merely "concise" instead.  :) )

On Tuesday, January 14, 2003, at 10:53  AM, Br'fin wrote:

> Since I haven't really gotten myself organized, I'm going to give the 
> list a little bit of an earful.

You're not the first ;)

> I have to admit that the #1 priority on the top of my list is to 
> continue to keep Marathon running nice and happily on my machine.

If you only care about your machine, I don't see where you're going to 
get help (assuming you want it at some point).

>  I've now carbonized Marathon twice and I want something that runs 
> really nice and well.

And now it sounds like you're expecting others to re-IPify, 
re-OpenGLify, re-SDLify, etc. your code, when these tasks (well maybe 
not IPification - not sure) are bigger tasks than Carbonification.

>  And I want updated networking. which I suppose could be odd seeing as 
> I've rarely had chances to play Marathon on a LAN :)

What are you looking for from AM that A1 doesn't have, networking-wise?  
NAT-friendliness?  Ring-to-star?  Text chat before, during, and after 
the game?  Cooperative saved-games?  Latency-hiding?  I think many of us 
want these things, and I think they'll gradually appear.  I'm not sure 
how AM could be a better platform for them than A1 is (except maybe for 
latency-hiding, where low-level support along the lines I recently 
discussed could make things much easier... but adding that low-level 
support might be nearly as painful in AM as in A1).

> Second of all, I want to open up the code in way that it isn't just one 
> monolithic beast. While it may or not ever materialize, I would like to 
> use this code to support other development efforts. This includes tools 
> for itself (map making and such) and game changes beyond scenario and 
> physics making.

Makes sense.

> Then around third is being cross-platform. Yes, I admit it, 
> cross-platform is less important to me than having a kick-ass game of 
> Marathon. However, I do agree that it is important and I will support 
> it. Calls for standardizing on this or that, while good arguments, do 
> not necessarily mesh well with my first two goals. Accept that your 
> platform of choice will be treated as a separate platform, take 
> ownership of it and make sure it remains kick ass too.

Hope you can find people to do that.  From my point of view, it's not 
worth it to try to replicate all that work if we're just going to end up 
in the same place as A1 (which we are, if the cross-platform code 
(standard libraries and SDL) is not tapped as the preferred branch).

But I'd encourage somebody else to do it so I can enjoy the benefits.  ;)

Every line of Mac OS-specific code written or debugged serves only to 
close up AM further and make it less useful to a general audience.  OTOH 
every line of open code (SDL, standard libraries, OpenGL, etc.) serves 
to make AM accessible and useful to a wider audience, to bring it into a 
more modern age, and to ensure its longevity and relevance.  But place 
your priorities where you will.

> With respect to staying in sync API-wise, we should be discussing 
> issues like that to begin with. And include appropriate tracking or 
> document matters on Sourceforge. If something UI-wise gets implemented 
> on one platform and applies to the others, they should get stubbed 
> interfaces if necessary to compile and someone should be responsible 
> for filling out the specific platform.

What I think I'm hearing here is that new additions to the code will be 
more rigorously evaluated and integrated, which is probably a good thing 
as long as it doesn't put a serious clamp on innovation/experimentation.

OTOH I hear a lot of "someone will be expected to" or "someone will be 
responsible for" or "someone will be required to", and I don't know how 
well that will fly in a volunteer effort.  Sure it could work for 
something like gcc that's vitally important to millions of people, but 
for a game with a current worldwide audience of perhaps 50 occasional 
users?  When there's already another project that seems further along in 
most regards?  Well, I guess time will tell.

> Does this mean we should be making wrappers around set control/read 
> control/hit control? Or should we just be doing 
> PLATFORM_GUI->do_preferences(PrefObject)? I admit I both haven't 
> decided and haven't yet had a chance to research this. I'd love a 
> decent run down of the pros and cons of each.

All I'm saying is, it makes sense to me to have the largest amount of 
code possible be shared, so that new development is more likely to work 
on all platforms, so that a given portion of the code base is used by 
more folks and is thus more rigorously tested, and so that things 
generally stay clean and consistent rather than messy and fragmented.

So my opinion (as I think has been clearly stated here) is that the 
split between platforms should come in the implementation of 
set_control_value(), enable_control(), etc. and not higher up.  If you 
want proof that it's viable and useful, "the proof is out there".  Go 
read A1's network_dialogs.cpp.  There are some #ifdefs in there still, 
yes, which is somewhat unpleasant, but that's because the different 
platforms still have different features and mechanisms that need 
slightly different UI configurations (though I hope an upcoming 
"cleaning" review of the network subsystem will remove most of those).  
You'll find that the vast majority of code is shared.

If one dialog box (or part of one box) is radically different on 
different platforms or something, then that one segment can be split 
higher up the tree.  But when almost all the logic for managing the 
dialog is identical, doesn't it make sense to share the code?

(Of course this is essentially the same argument as for using standard 
library calls and SDL instead of Mac OS calls whenever possible, though 
they are different issues.  Shared code, not separate branches.  Shared 
code, not separate branches!!)

> I should point out that addressing the platform issues directly is why 
> I haven't polished the interface of the OSX builds yet. Yes, the lists 
> of all the gui glitches in fading in and out and menu buttons are good. 
> I'm just not trying to polish that aspect of the game yet. Not until 
> the framework underneath has been revamped. Likewise for the mouse. 
> Right now I can use AlephModular to play Marathon 2. It confirms that 
> the game core and such are all still working. For this stage in the 
> project I find this to be an acceptable 'almost shippable' state.

Agreed and well-understood.  I think AM is progressing nicely and is an 
exciting project, else I wouldn't waste^H^H^H^H^Hspend so much time 
blathering^H^H^H^H^H^H^H^H^H^Hoffering suggestions here.  ;)

> This doesn't mean that I'm ignoring all bugs, just the ones relating to 
> the GUI in its current state. Crashing bugs or other glitches within 
> the game core are definitely a priority. I find it interesting that in 
> recent days I've patched several bugs in AM that either are still 
> noticeable in AO if you know where to look or have been addressed only 
> relatively recently. Make of my focus what you will.

I don't suppose you've considered sharing your findings with the A1 
project so that it can also benefit...?  Or are you only talking about 
that close-monsters-disappearing thing?

> I should remind folks that once we have cross-platform support, I am 
> going to want and need folks to do the release builds for other 
> platforms. We aren't going to have a random mac release here and a 
> random linux release over there which happens to be using code from a 
> different date. I want that Sourceforge release page to have the 
> AlephModular release and below that the current version release and 
> below that the builds packaged for different platforms.

If AM becomes a compelling alternative to A1, I think you'll get 
builders.  And I don't think that asking for timely releases for 
supported platforms is out of line (subject to the 'volunteer project' 
stuff outlined above)... *especially if most code is shared so all 
platforms get features/fixes at the same time*.  ;)  (broken record...)

> I admit I've been having some visions of things I'd like to see. 
> Whether as proof of concept or samples of what we can do when we get 
> there, I don't know.

> For instance, how about a Replay to Quicktime converter? It ditches the 
> UI and renders the whole game out to a full 30 fps Quicktime.mov. 
> Possibly several movies if the replay had multiple players. then people 
> can watch your vidmaster epics even if on a slow computer or without 
> needing AM, the map, the sounds and so forth.

This could be cool; you could use iMovie to edit your replays down to 
highlights and lay down a pulsing soundtrack.  :)

> Or multi-part monsters. Like a unified squad of Pfhor, or a long 
> segmented worm.

Or anything anyone can think of, because the idea is that AM will be an 
easier and more rewarding environment to work in than A1.  Right?  I 
don't think there have been any suggestions contrary to these goals.

Anyway the bottom line is, I think you have good intentions and are 
doing good work, even if I disagree with a few of the paths you seem to 
be wanting to take.  (I think I agree with you on many others.)  It's 
your project, and in truth I'll probably be going into Aleph* 
hibernation again in another week or so, so my opinions don't really 
matter a whole lot.  As I see it, my job is to make sure you consider as 
many relevant options as possible; the decisions are yours.

I still wonder whether AM is necessary, or whether restructuring A1 
would be as effective at achieving the AM goals while maintaining all 
the nice features of A1.  I don't know that answer, and it's moot anyway 
since we have someone working on AM and nobody doing the corresponding 
work for A1.  :)

Woody