JULIAN WALDBY | 12 Oct 2011 05:22
Picon
Favicon

netrek-forever@... - 25 Messages in 2 Topics

I heard the big guys get the core code working and then all these attractive brunette grapho artiste s throw artwork after artwork at them.  Can we follow something similar?

Julian


To: netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
From: netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: [netrek-forever] Digest for netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org - 25 Messages in 2 Topics
Date: Tue, 11 Oct 2011 22:42:41 +0000

Group: http://groups.google.com/group/netrek-forever/topics
    ahn <ahn-bKUKPKru15Adnm+yROfE0A@public.gmane.org> Oct 10 10:05PM -0700 ^
     
    The quality of Netrek code is unimportant. So is the metaserver
    delisting issue. The real problem with Netrek for the last decade or
    more has been that no new leaders have stepped up to fill the void
    that us old geezers left behind when we moved on to real life. It's a
    shame that the FOCS/history/blame/whatever is being used to discourage
    contribution at a time when any contribution at all could be helpful.
     
    If you have the time and inclination to do something, I suggest you
    just do it. There is no need to ask for permission or to convince the
    community. If your ideas work, then the results will reflect that.
    That's how it was done in Netrek's prime. Start with something that
    can have the largest impact with the least effort. This Netrek app is
    a great example. Too many have proposed grand ideas only to quit
    shortly thereafter (or never even start).
     
    Preserving the classic Netrek game should be the least concern. The
    servers and the code will persist, but the other component that makes
    the game classic is long gone - the players who understand its true
    depth. So, the players of today and tomorrow should drive the
    evolution of Netrek into a form that they will enjoy. Gain enough
    critical mass, and the original depth will be rediscovered.
     
    Toumal Rakesh <toumaltheorca-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Oct 11 12:02PM +0200 ^
     
    > that us old geezers left behind when we moved on to real life. It's a
    > shame that the FOCS/history/blame/whatever is being used to discourage
    > contribution at a time when any contribution at all could be helpful.
     
    /sign
     
    Note that my point was not to dwell on that one issue, but to point out that
    rewriting the server does make sense.
     
     
     
    > If you have the time and inclination to do something, I suggest you
    > just do it.
     
    Thanks for the encouragement.
     
    Many years ago, I worked on Deranged Raid (
    http://www.playspoon.com/wiki/index.php?title=Game_Info) which was entirely
    written in C, and 99% of it by myself.
     
    As I said I do not have the time available to build a prototype from
    scratch, but I can contribute if others are willing too. As it happens I
    have written a 2D game library for java which handles most aspects like
    sprites, input and such. It's not complete but it could be a starting point.
    I'd strongly suggest apache mina for the netcode.
     
    I have experience developing distributed and client/server architectures.
    For a new Netrek, I'd suggest having a decoupled network code that transmits
    and handles updates independent of framerate. So while the framerate would
    be something like 60 fps, net updates could be set to something like 10
    ticks per second. Clients would continue to move entities along their speed
    vector, overwriting the position with the one transmitted by the server
    whenever such data is available. Since entity visibility is not a factor,
    clientside hit detection would probably suffice, with the server just
    verifying that the range is sane and that there's been a sufficient cooldown
    between "hit" updates by a client. If a ship is cloaked, the entity could be
    effectively removed for the others so as to prevent modified clients to show
    cloaked ships.
     
    In the CAP Theorem, we'd be A+P. The system would be
    "eventually-consistent". Newly joining or reconnecting players would receive
    a snapshot, so the netcode has to handle that too.
     
    I'd suggest keeping the server and the client separate for now. Starting a
    server from within the client can be added later anyway.
     
    As for project stuff, I can set up a build server too (comes in handy pretty
    soon, if you don't believe me ask the guys running http://ci.bukkit.org )
    and I can make the whole thing webstart-enabled from the start so even the
    earliest prototypes will work both as standalone executables and in your
    browser.
     
    As a first prototype goal I'd suggest getting the basic application going,
    with a ship moving around and firing torps. I'd suggest the next prototype
    goal to be network play right thereafter.
     
    I'll gladly write the entire masterserver and serverlist update stuff and
    contribute heavily for the general netcode and other things.
     
     
    I guess the only question to ask is... who else is interested?
     
    Zachary Uram <netrek <at> gmail.com> Oct 11 07:50AM -0400 ^
     

    > I guess the only question to ask is... who else is interested?
     
    What will the implementation language be?
     
     
    --
    Zach
    http://www.fidei.org
     
    Andrew Szczeszynski <andrew3z-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> Oct 11 04:51AM -0700 ^
     
    Hi Toumal,
     
      I think what you're doing is a great idea - I am in complete agreement that all the code needs a rewrite, but that the game is timeless and could become big again.  I'm actually trying to do the same thing, to bring Netrek to the masses, but I'm taking a more liberal approach - I'm trying to change the game to make it less complicated (yes, it's a new game - not Netrek - but it's basically what you get if you try to simplify Netrek enough to make it accessible - http://www.galacticcombat.com/).  I originally thought I would use the netrek code - but it is too much of a mess, I couldn't use it.  Even after I wrote my code, I wanted to contribute back some stuff (for instance, some improved AI dogfighting), but I just couldn't make it work - the code is too complex - a rewrite would encourage people  (like myself) to grow it again.
     
      What I want to point out is some of my experiences with my version that might stear you in the right direction (I don't know what that direction is - I'll let you make your mind up).  I took the approach of a flash game because it satisfies the problem of making it easy to install, but also distribution - I could just post it on all the flash game sites and it would work.  The downside, though, is that flash doesn't really support UDP - which is a big drag.  I did actually go live with the game, but hit the problem that people needed a single player 'training/mission' mode - it was too complicated to just jump in, even though it is insanely simplified... so people left in frustration before quorom was hit.  I'm trying to solve this now - add a single player/mission mode that will keep people interested long enough for quorom, and to also provide basic training (and of course, I got insanely busy with real work and now it's on the back burner for
    last 3 months).
     
      I guess my point is that if the goal is to make it accessible and make it a hit game again (which is what I would love), then it probably won't be enough to make it simply easy to install - it will need to have some kind of training mode to ease people into the game - that would allow the 'word' to spread.  As such, make sure that whichever direction you choose, it should be compatible with your end goal (I don't expect you to do all this work - that would be discouraging - but at least allow others to contribute in that direction).  And yes, it is absolutely impossible to get everyone to agree - you'll get a heck of a lot of no's - but if you build it, and it is kinda netrekie, they will come.
     
      As far as technical questions: absolutely decouple frame rate - clients should predict vectors, as you stated.  Note that predicting collisions is not really necessary, and when the predicition is wrong, it goes very wrong.. its very hard to do client side detection because different clients will get different answers - you need an authority - not sure if trying to solve this issue is worth it.
     
      Good luck!
    - Andrew
     
    -----------
    Dilbert: "If we migrate our enterprise applications to the web, and outsource our sales and product development, the entire company can be managed by one monkey..... plus a second monkey to look at the powerpoint slides from the first monkey."
     
    Toumal Rakesh <toumaltheorca-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Oct 11 02:22PM +0200 ^
     
    Java, optionally Scala.
    The big upside is that the core could be written in Java/Scala and the
    gameplay logic/AI/highlevel stuff could be implemented via Groovy, Scala,
    Beanshell or other scripting languages.
     
     
     
     
    Toumal Rakesh <toumaltheorca-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Oct 11 02:28PM +0200 ^
     
    Hey there, I tried to take a look at your game a while back actually but
    couldn't reach the server, is it still up?
     
    I completely agree that the game should be playable even while not in
    T-mode. This could be done either via bots that can play T-mode, or via
    alternative objectives like "invade planet X" which would essentially be
    small coop-missions for the connected players.
     
    Heck, even a full coop T-mode would rock. It's certainly not easy to do (I
    spent several years writing the first bot AI for Starsiege Tribes, called
    "Spoonbot", and I know there's a lot more to it than most people think), but
    would go a long way towards a game where people actually fill up a server
    after a while, because they have something fun to do in the meantime. And it
    would be a great way to do a live tutorial of sorts.
     
     
     
     
    "John R. Dennison" <jrd <at> gerdesas.com> Oct 11 07:55AM -0500 ^
     
    On Tue, Oct 11, 2011 at 02:28:17PM +0200, Toumal Rakesh wrote:
    > Hey there, I tried to take a look at your game a while back actually but
    > couldn't reach the server, is it still up?
     
    This conversation has moved far off-topic for this list. If you want to
    contribute back to netrek, fine. If you want to talk about some
    non-netrek variant this is the wrong place to continue.
     
     
     
     
    John
    --
    Be in charge of your own destiny, or some one else will.
     
    -- John Francis "Jack" Welch, Jr. (1935-), past Chairman
    and CEO of General Electric
     
    Toumal Rakesh <toumaltheorca-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Oct 11 03:27PM +0200 ^
     

    > This conversation has moved far off-topic for this list. If you want to
    > contribute back to netrek, fine. If you want to talk about some
    > non-netrek variant this is the wrong place to continue.
     
    I was waiting for "not netrek" to come up again, I guess "non-netrek" will
    have to do ;)
     
    Well if you want me to unsubscribe from this mailinglist then by all means.
    Because if the only allowed discussion is the patching of existing code,
    then no. Maybe you should consider renaming the mailinglist from
    "netrek-forever" to "netrek-maintenance".
     
    I'm not claiming to be the most awesome coder or anything like that. But if
    the one and only netrek is the one based on age-old grown C code filled with
    quirky idiosyncrasies, if you think having less servers gets you more
    players, then no, I do not want to contribute to that. Feel free to dismiss
    my points as the rants of a clueless nameless coder on the internet. That's
    ok with me, I don't have anything to prove here.
     
    I have neither the time nor inclination to convince others of the benefits
    of clean code, concepts like dependency injection, OO in general, or even
    stuff like test driven development (or unit tests in general) and continuous
    integration. I'm happy to see that the majority of developers is catching on
    by now, finding out that the short-term extra investment pays off bigtime in
    the long run. The rest either passed the age of sufficient learning
    capability, or never reach that level of proficiencies to understand the
    reasons for their own misery, or even see that they are in misery to begin
    with. Heck 10 years ago I dismissed Java and unit testing and all that evil
    pointless stuff myself, give me lean C code or give me death, I thought. It
    took me years of painful learning to realize the extent of just how wrong I
    was. I'm not saying I'm perfectly right now, but I certainly grew out of
    these old prejudices.
    I fear the programmer who thinks his code is perfectly fine, just as I fear
    people with an overdeveloped do-what-it-takes attitude.
     
    With that, I wish you the very best. If some people on this list are
    interested in a proper revival, you have my email, feel free to contact me.
    I still love this game and I'm certain it will live on, in one way or
    another. Even if it's "not netrek".
     
     
    Take care!
     
    ahn <ahn-bKUKPKru15Adnm+yROfE0A@public.gmane.org> Oct 11 06:48AM -0700 ^
     
    Ok, one more follow up before I head back to my grave.
     
    Rewriting the entire code base doesn't solve Netrek's problems. Even
    if we had had a redesign and reimplementation of the code 10 years
    ago, the outcome would not have changed. If you want to help Netrek
    and you want to have the most impact, I suggest you focus on the
    player-facing client and its usability, look for ways to expose the
    game to new players, and flatten the learning curve for any that try
    the game for the first time.
     
    I can recall about half a dozen "next-generation" (after Paradise)
    forks/derivatives of Netrek that have been attempted. If these people
    had been more welcomed in the Netrek community, their efforts could
    have been channeled back to improve and evolve the game, or at least
    its software. Instead, their work ended up as programming exercises
    for the authors.
     
    This conversation is far off-topic for this thread, but it is not yet
    off-topic for this list. Create your own thread, and discuss until
    you conclude whether you wish to contribute to Netrek or to fork a
    derivative. Ignore the pessimism, but do listen to constrictive
    criticism.
     
    Good luck.
     
    Andrew Szczeszynski <andrew3z-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> Oct 11 08:31AM -0700 ^
     
    John,
     
     
      I think you are being way out of line.  We are conversing precisely about Netrek - Toumal is wanting to contribute and trying to get ideas about what kind of platforms or technologies to use, as well as ideas about where to go with the game.  Your comment is tantamount to saying 'anyone can discuss contributing to netrek, as long as they don't get/discuss ideas from anywhere else'.   If someone said 'I would love to add 'status' messages in netrek that work just like twitter', would you ban the comment as 'off-topic' because it mentions Twitter?  Loosen up with that trigger button, you're being unfair.
     
    - Andrew
     
    Paul Berker <paul <at> paulberker.com> Oct 11 10:38AM -0500 ^
     
    I know some of you may balk at this, but I think this would really draw
    new players.
     
    I client that had a 3-D view option. The game would still be 2-d, but
    give the view angle something
    other than top down and give the ships 3D shapes and effects.
    Also maybe a mode that just followed your ship from above and behind
    looking forward.
    You would still have the main top down play field on the side panel to
    look at.
    (this would not require any server code changes)
    It could really enhance the playing experience (I know this from playing the
    old Star Fleet Command on Pc's in the w95-w98 era in league play.. it
    was only
    2D but looked 3D)
    I am not talking about 3D glasses etc.. just some perspective.
     
    MaxFerret
     
    On 10/11/2011 8:48 AM, ahn wrote:
     
    "Kurt Siegl" <kurt.siegl <at> hargelsberg.at> Oct 11 07:59PM +0200 ^
     
    Paul Berker sagte:
     
    > I client that had a 3-D view option. The game would still be 2-d, but
    > give the view angle something
    > other than top down and give the ships 3D shapes and effects.
     
    In principle I say this are ideas are worth being considered, but coming
    back to the topic, I thing what really would help will be an iPAD and
    Android 3 client implementation.
     
    Of coarse one would need to completely rethink the whole navigation to
    gestures, but IMHO this are nowadays the devices where this kind of games
    will be played by the mass.
     
    Just my thoughts
    Kurt (007)
     
    Jared Thirsk <jthirsk <at> shaw.ca> Oct 11 12:23PM -0600 ^
     
    From: ahn <ahn-bKUKPKru15Adnm+yROfE0A@public.gmane.org>
    > player-facing client and its usability, look for ways to expose the
    > game to new players, and flatten the learning curve for any that try
    > the game for the first time.
     
    I second this, and think Andrew's Galactic Combat game is a great case study. 
    Even though it is too simplified to be the netrek we know and love,
    it does a lot of the things I think would be helpful in client usability and attractiveness.
    (And I wonder if some hurt it: like lack of netrek physics, phasers.)
    Andrew "gets it" when it comes to client.  Now the trick is to apply some of the same lessons to actual netrek.   (BTW, great work Andrew!)  
     
    > This conversation is far off-topic for this thread, but it is 
    > not yet off-topic for this list.
     
    I agree.  I can see people not wanting Galactic Combat-specific chat on this list, but I definitely think GC is within scope as a case study for how to improve the netrek user experience.
     
    Jared
     
    Zachary Uram <netrek <at> gmail.com> Oct 11 02:36PM -0400 ^
     

    > Of coarse one would need to completely rethink the whole navigation to
    > gestures, but IMHO this are nowadays the devices where this kind of games
    > will be played by the mass.
     
    I think an iPad or even Kindle Fire client would be lots of fun. Take
    advantage of the technology, the built-in gyroscope can be used for
    turning left or right, for more precise turns which are needed in
    dogfighting you can have them touch the screen and just move their
    finger in the angle they need, to fire torps single tap finger, to
    fire phasers double tap or something. I had an idea where distance
    would be used to calculate acceleration (and speed) based on a
    distance vector. The shorter the distance from A to B, determined by
    pressing a button and then tapping or whatever, the slower the
    acceleration will be. So if you tap all the way across galaxy, which
    would be very quick on a touch pad device, you will get the maximum
    acceleration and reach warp 9. That way a user can intuitively learn
    how to control speed through distance vectors and you don't need to
    worry about defining speed keys.
     
    --
    Zach
    http://www.fidei.org
     
    Toumal <toumaltheorca <at> gmail.com> Oct 11 07:36AM -0700 ^
     

    > Rewriting the entire code base doesn't solve Netrek's problems.  Even
    > if we had had a redesign and reimplementation of the code 10 years
    > ago, the outcome would not have changed.  
     
    I think this one deserves an answer.
     
    First of all, how do you know? Also, the history of netrek is one of
    rewrites, otherwise you guys would be playing Empire (or Conquest for
    that matter)
     
    Second of all, the thing is that this is not just about rewriting the
    server at all cost, but there are real reasons for it. If all you
    concentrate on is the client, you're missing the big picture. For
    example, can you make new interesting pre-T-mode gameplay without
    modifying the server? No. Any gameplay change will require server
    modifications. So making that more maintainable is definitely a task
    worth doing.
     
    Doing a cross-platform client should be a no-brainer. If I can run the
    same game on Linux, Windows and Mac, AND in the browser, that's the
    ideal situation. It's what made Minecraft a success while nobody even
    remembers the .net-jailed Infiniminer (Yes there's mono, I know...
    good luck with that)
    And if the client is, for example, Java - then that's all the more
    reason to use the same language for the server. A fresh start also
    means gaining the benefit of recent developments and insights. Heck
    even the theory has advanced a lot from the 1980s, knowing Brewer's
    CAP theorem goes a long way in understanding what can be done and what
    isn't possible - avoiding the usual half-solutions that result in
    undesired behavior. Someone brought up collision detection and how
    there are several ways of dealing with it in a client/server
    architecture - that's exactly the kind of problem I'm talking about.
     
    If you want to concentrate on the client, all you'll get is prettier
    sprites, maybe better controls and perhaps a nicer UI. You still have
    multiple clients that look and feel different on every platform, and a
    webstart-enabled client, or a client that can spawn its own local
    server transparently for the user is something you can only dream of.
    Sure, the server works, but so do the currently available clients. By
    that rationale, there should be no change at all.
     
    My last suggestion is that you folks decide what you want. The ones
    who don't want change obviously can keep using their old stuff, the
    others could move on. Making nicer explosions or better keybinds in
    Netrek client XYZ is not going to yield a revival of Netrek.
     
     
    Take care!
     
    Zachary Uram <netrek <at> gmail.com> Oct 11 02:47PM -0400 ^
     
    > interested in a proper revival, you have my email, feel free to contact me.
    > I still love this game and I'm certain it will live on, in one way or
    > another. Even if it's "not netrek".
     
    Toumal I love your enthusiasm and discussion of close netrek variants
    is within the list guidelines. I have updated the boilerplate to
    reflect this:
     
    Description
     
    Discussion relating to netrek and organic variants:
     
    * bronco - standard netrek
    * chaos - wackiness
    * hockey - PASS ME!
    * paradise - more stuff
    * INL - clue play
    * sturgeon - insanity
    * other forks and variants
     
    So please stay and let the good discussion continue. I request we
    create a new thread so that list members who don't want to follow this
    discussion can just ignore/filter the new thread. I will start the new
    thread after this post.
    --
    Zach
    http://www.fidei.org
     
    Allen Tipper <akerasi <at> gmail.com> Oct 11 03:00PM -0400 ^
     
    Zach, thank you. I'm very glad to see that forks and variants are now
    officially on topic.
     
    -Allen Tipper
     
    ---------------------------------
    Insert witty .sig here
     
     
     
     
    Zachary Uram <netrek <at> gmail.com> Oct 11 03:19PM -0400 ^
     
    > Zach, thank you. I'm very glad to see that forks and variants are now
    > officially on topic.
     
    Welcome Allen. I think discussion of variants will end up helping
    classic netrek. Strategies, practices, implementation ideas and
    features that are discovered by thinking outside the box and pursuing
    variants can later be incorporated into bronco clients. And what
    bronco desperately needs is people playing. Player retention is still
    the Holy Grail, but things are so anemic now that if no one is playing
    at all, except for a handful or two of regular veterans, any
    discussion of retention would be purely academic. If a variant takes
    off and succeeds we can easily steer that playerbase toward classic
    netrek. When I started playing around '94 the Golden Age of netrek was
    already in its terminal phase and even then we had no problem
    sustaining multiple concurrent bronco, hockey, chaos and paradise
    games. The strong teamplay aspect, strategic richness and tactical
    shoot 'em up fun is still there in netrek. We just need a new
    generation of players to give netrek a chance. Once they get over the
    initial learning phase and appreciate all three aspects of the game,
    which takes time, a number of them will become diehard players and
    possibly netrek evangelists! In the 90s most online gamers were
    university students, but now we have millions of middle aged gamers,
    even elderly gamers. We shouldn't be trying to appeal to the Call of
    Duty: Black Ops or World of Wacraft crowd. Just focus on making netrek
    easy to play (a web client is a must in my view), easy to configure
    (all of the current clients suffer from UI problems - we need to adopt
    an industry standard HUD display or something that players are
    accustomed to using IMHO), aesthetically and aurally pleasing, and I
    think we need to leverage social media
    (buzz/g+/twitter/facebook/linkedin/etc...) so that new players can
    easily share their new found enthusiasm for the game which will help
    with adoption. Another feature which I think will help to win over
    newbies is a unified, web-accessible stats system with
    medals/achievements functionality and detailed publicly viewable
    stats.
     
    --
    Zach
    http://www.fidei.org
     
    Jared Thirsk <jthirsk <at> shaw.ca> Oct 11 02:51PM -0600 ^
     
    From: Toumal <toumaltheorca-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
    > one of
    > rewrites, otherwise you guys would be playing Empire (or
    > Conquest for that matter)
     
    I'm confused now.  Are you suggesting to make a different game that is loosely based on netrek?
     
    Are you sure your skin is as thick as you think?  You seem to getting flustered for no good reason and it makes you harder to follow.  Relax...we all want to figure out the best approach(es) to moving netrek forward, and we are all grown up enough to deal with differing viewpoints.
     
    > example, can you make new interesting pre-T-mode gameplay without
    > modifying the server? No. Any gameplay change will require server
    > modifications. 
     
    Freedom to experiment with better pre-T modes is a great idea.  It would have helped the discussion with me at least if you shared your 'real reasons' to start with, rather than say "let's rewrite thousands of lines of code and use unit tests and IOP.. it will be good, honest" :)  
     
    Here's some logic.  (Maybe it would help if we stopped speaking english.)
     - Low amount of development effort available => look for biggest bang for buck.
     - Expectation of a new long-term development arc => rewrite everything
     
    I agree with both logical conclusions.  It sounds like you only find the second scenario interesting, so I hope you succeed at it and find others to work with you.
     
     - Biggest bang for buck (for a small development effort) is making the client look modern (like GC) with nice help screens and a smoother interface, I would think.  Instead of server-side tutorials, simply make youtube videos (I think something like it exists already, but I'm sure it could be made more accessible, or embedded in the client).
     
     - Biggest bang for the buck (given a small effort available) is not to rewrite the server to do the exact same thing and then run out of steam.  That, my friend, is by definition exactly zero bang for the buck.  I know you are imagining more, but it's your fault in this discussion for not laying out a nice roadmap of features that you hope for.  
     
    It's still to be seen how much development effort is available.  As it stands now, even you admit it is not enough.   My secret agenda: that you might entice more developers to join you if you talk up all the awesome things you hope to do, given a revamped codebase foundation.
     
    > Doing a cross-platform client should be a no-brainer.
    > It's what made Minecraft a success while nobody even
    > remembers the .net-jailed Infiniminer
     
    Not that I'm against cross-platform, but evidence I find here and on wikipedia suggests fragmentation was the downfall:
    http://www.rockpapershotgun.com/2011/01/20/proto-minecraft-abandoned-due-to-epic-error/
     
    > (Yes there's mono, I know... good luck with that)
     
    Mono+Unity: Windows, OS X, web, iOS, Android, Xbox, Wii, proprietary set top boxes, and soon Linux (not that it matters much), on what's becoming triple-A game engine with a complete pipeline.... I don't think they need any luck ;)
     
    I admit I'm intrigued by Apache Mina.  .NET lacks a lot of nice things in the Java world like all the great libraries under the Apache umbrella.  I have no experience mixing Java with games, but Java could very well be a great choice, especially if you're the ringleader and you are comfortable with it.
     
    Regarding concentrating on the client:
    > You still have multiple clients that look and feel different on every platform, 
    > and a webstart-enabled client, [is something you can only 
    > dream of]
     
    This appears to be an assumption on your part of what a client effort would omit.
     
    Furthermore, having a client look the same on two different OS's is not a benefit
    to the vast majority of users.  "I just rebooted from Windows to Linux and it looks
    slightly different and I'm so confused! Gah! *ragequit*"  
    I can see how a unified cross-platform client would benefit development time, which would in turn promote a higher quality client.  But if improving development time was a goal I'd start by, oh, say, not rewriting the server ;)   (But go for it dude)
     
    > or a client that can spawn its own local
    > server transparently for the user is something you can only
    > dream of.
     
    I'm not sure why this would be hard.
    I haven't set up a server lately, or tried running it on Windows, but I would think it would be relatively low development effort to port it and have some mechanism to start a server with an appropriate config.  But if you want to do a rewrite, just do it and I'm happy for you that it is that much easier.  In my rewrite, I architected it to transparently start a server, as well as support in-client server to skip all netcode, and I'm happy.
     
    (Having players on local servers instead of public ones seems like going in the wrong direction, but I'm sure you have un-expressed reasons why you think it would be a good idea.)
     
    > If you want to concentrate on the client, all you'll get is prettier
    > sprites, maybe better controls and perhaps a nicer UI. 
     
    My sincere concern here is that your efforts translate to a larger playerbase.
     
    Taking the other viewpoint, if you focus on the server, and you get:
     
     - scriptable logic for making pre-T modes
     - scriptable bots
     - people joining local servers instead of public ones
     - more pre-T modes
       - coop T mode (as in 4-8 humans vs bots?)
     
    Maybe I forgot some (I'm omitting 'change planet names without recompile'), but I honestly can't see these things causing a dramatic revival of the netrek playerbase.  Do you??  I think co-op T would help a bit, just like I think pre-T bots have maybe helped a bit.  
    Don't read this as pessimism -- read it as a challenge to be sure and confident that what you will do will have good results.  If I can dissuade you, I'm afraid that 100's of hours of development work will dissuade you and I don't want to see that.
     
    If you do your fancy server rewrite but still have clients that like an air traffic control application from the 80s, I still think players will still be scared to try it en masse.  Java over the years has been known for having awful UI that nobody likes to use so if you have been in a Java world for the last several years maybe you don't get it ;).
     
     - Tutorials
     
    I think tutorials would help a lot, as would simplified training game modes.  To me this is the most compelling user-feature reason for a server rewrite, (but perhaps still an insufficent reason on its own, if I was to do it all myself.)  And I think it would go hand in hand with a client UI that is not intimidating, that holds your hand with tooltips, and that has buttons that appear on-screen for dropping armies, etc., like GC.   Since the client part could be done without a rewrite, I personally would start with it.  Even if Toumal goes and spends a while working on a rewrite, other people could work on these features for a client.
     
    I am a little annoyed (but who cares) that you have seemed to be talking more about developer features than player features.  
    Facetious feature proposal: in addition to the red alert indicator in the client, you have a red alert indicator if someone breaks your CI build, and next to the player list you have a green-red light indicator to show which unit tests are broken, and a new macro for "Please ogg bug #1234".
     
    I'm sure you and I and others could think of more improvements, but I think it would be helpful and inspiring to list them all.  The thought of different features coming to fruition may appeal to different would-be developers and get them on board.
     
    > Sure, the server works, but so do the currently available
    > clients. By that rationale, there should be no change at all.
     
    This statement is not helpful.
     
    > Making nicer explosions or better keybinds in
    > Netrek client XYZ is not going to yield a revival of Netrek.
     
    This is a strawman.  There are prettier clients and I couldn't care less about nicer explosions.  I unfortunately find the prettier netrek clients that have come along harder to look at (partly because they're in early development and have weird zooming.  I think I did try a 3D aspect one that seemed harder to play with but maybe it takes getting used to.  I mostly like GC).  Often in games I wish I could simplify the graphics for a more distilled view.
     
    Galactic Combat has a lot of UI features executed better than I've seen in netrek clients aside from explosions.
     
    > My last suggestion is that you folks decide what you want. The ones
    > who don't want change obviously can keep using their old stuff, the
    > others could move on. 
     
    Potential development streams coming out of these discussions:
     
     1) Toumal's plan of rewrite everything and add new features
         ;-) Need to list potential new features
         ;-) Need a mission statement
         ;-) Need to find enough devs to contribute
     2) Client improvements
     3) Server improvements
     4) Android/iOS app
     
    Thanks Zach for clarifying list topics.  At some point, perhaps after a mission statement is established and an initial team gets on board, I think it might make sense for discussion about a rewrite to be split to a different list.  (Of course, it would be natural anyway to have a dev list.)
     
    It could be a multi-year effort before it successfully recreated netrek (assuming it even tried, Toumal's intentions are unclear to me) and it would detract from those who wanted to work on 2, 3 or 4 above and make for an uncomfortable list atmosphere of mixing old and new.  I may not have time to contribute code right now (since I'm doing my own rewrite) but I would be interested in following and discussing it, and would prefer an email list environment that did not mix two distinct thrusts so I didn't have to worry about annoying people who didn't care about a rewrite effort, or who do not care about it until it is like netrek.  But discussion of both GC and a non-netrek rewrite (until it became a netrek clone) would always be on topic as case studies that relate to potential netrek improvements. 
     
    Jared
     
    Mark Wood <marcus531 <at> yahoo.com> Oct 11 02:37PM -0700 ^
     
    1: Ancient games (like netrek) with minimal pizzazz are reasonable and tolerated on phones and tablets but far less so on desktops ...
     
    2: the current (abysmally sized) playerbase is probably made up of those in two categories : 
    2a: people like me who played netrek starting from ancient times (pre windows 95)
    2b: a few younger generation types who were recruited by old-timers and stayed because of game-mechanics
     
    3: the final few old-timers are nearly all grown-up into daily distractions with jobs and kids etc and not recruiting new players and there is functionally NOTHING else to recruit new players ... I suspect the gen-X recruits don't tend to persuade more recruits into a complex-gameplay-but-without-interesting-graphics games because they know their cohort wants nothing lower than WOW or evercrack, PS3 games, Wii, etc
     
    4: the solution is to make 2 netrek clients ... 
    4a: one for tablets, with gestures and on-screen-buttons
    4b: a different interface paradigm for *keyboarded* smartphones
     
    5: these smartphones and tablets have 
    5a: extra control options (like their gyroscopes)
    5b: touchscreens that operate sufficiently differently than mice that we have to change interface thinking
    5c: potentially odd connectivity
    5d: intermittency of attention, necessity of pausing, etc completely incompatible with a live 16-player game
    5e: total newbies with no tolerance for empty-server issues or caustic commentary in their first hours before addiction sets in
    5f: the very newbies we would love to recruit
     
    6: My suggestion (and eventual intention) is to create a standalone non-server-based phone version of netrek 
    6a: that plays by all the same rules we love, adhering to gameplay feel as much as possible
              (caveats = rapid contextual view switching local/galactic/msg with the other windows shrunken)
    6b: with player-and-7-robots vs 8 robots maybe/later with the option to link to another phone for player+7 vs player+7
    6c: keeping the same major interface elements, specifically including messaging
    6d: and the player controls the robots via messaging commands in text form just like the better netrek bots
    6e: later(maybe) for non-newbies (meaningful rank on a real server (i.e. earned on a PC) ), the mobile-client could allow real-server-play
    6f: but importantly, it has to be a feels-real netrek bot-experience that they play alone, and can pause ... 
    6g: then some % of millions of phone users will try local-only-solo-netrek and some % of them will try the real netrek
     
    Basically, Netrek is functionally dead but the corpse is still quivering ... 
     
    Changing the clothing and decorations on the pre-corpse will not attract newbies, especially with the grouchiness that pushed me away (again)
     
    There is NO meaningful hope of directly attracting the PC (WOW, FPS, etc) / PS3 gamer crowd ... accept this, deal with it and move on
     
    Netrek's only revival hope is to attract the Motorola-droid-1,2,3/LG-Ally/Samsung-Epic/Stratosphere/etc keyboarded-android-users and the various tablet users 
    AND get them addicted to a single-player-game-with-lots-of-quasi-independant-bots and tell them to go to netrek.org for the multiplayer experience.
     
    If anyone wants to put major coding time into netrek's revival, what I've laid out above is very likely to be the only reasonable path.
     
    I would like to think I shall have time to pursue this, but I'm putting out the idea in case someone else wants to do so
         (realistically, I've several other major projects that should come before this labor of love)
         (if I finish my other projects and no-one has done something like this by then, I shall do so)
     
    (and if anyone else is interested, I shall gladly respond privately with my entire list of interface ideas on how to make netrek-on-smartphones still comport with the look-and-feel of the near-dead netrek-on-1990-class-PC-paradigms so smartphone players could seamlessly transition to PC+bronco play as better-than-total-newbies)
     
    -- Sarnac, briefly astro.ufl.edu server-runner, and never-very-good player from 1991-1995 or thereabouts (I've only been accused of being a bot once, on a *very* good day, long ago)
     
     
    ________________________________
    From: Zachary Uram <netrek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
    To: netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
    Sent: Tuesday, October 11, 2011 3:19 PM
    Subject: Re: [netrek-forever] Re: Android app for checking Netrek Servers
     
    > Zach, thank you. I'm very glad to see that forks and variants are now
    > officially on topic.
     
    Welcome Allen. I think discussion of variants will end up helping
    classic netrek. Strategies, practices, implementation ideas and
    features that are discovered by thinking outside the box and pursuing
    variants can later be incorporated into bronco clients. And what
    bronco desperately needs is people playing. Player retention is still
    the Holy Grail, but things are so anemic now that if no one is playing
    at all, except for a handful or two of regular veterans, any
    discussion of retention would be purely academic. If a variant takes
    off and succeeds we can easily steer that playerbase toward classic
    netrek. 
     
    James Cameron <quozl-T/J7+lnXHf4@public.gmane.orgtrek.org> Oct 12 08:39AM +1100 ^
     
    On Tue, Oct 11, 2011 at 06:48:49AM -0700, ahn wrote:
    > suggest you focus on the player-facing client and its usability, look
    > for ways to expose the game to new players, and flatten the learning
    > curve for any that try the game for the first time.
     
    I agree, and this has been my plan now for about five years.
     
    I've made COW on Linux much more usable, by adding a persistent entry
    dialog, playing instructions, display of playing tips, and resilience in
    the face of network disconnection or loss of UDP flow. Also got it
    packaged into Ubuntu, and maintained the code against the continual
    change of the compiler infrastructure.
     
    I've written the new Gytha client, cross-platform, with a full-screen
    dialog sequence, playing instructions, playing tips, and higher
    resolution 2D graphics. It is written in a scripting language, and is
    fairly easy to change.
     
    For teaching the game in a classroom, which I do once or twice a year,
    I've recently added some gradual discoverability scripting, so that the
    teacher can avoid the distraction of weapons during the first few
    minutes of the lesson plan ... allowing the lesson to focus on
    elementary concepts like your position, the position of planets, of
    other players, and how to move your ship.
     
    Flattening the learning curve is important. Among 24 teenagers that I
    taught last week, four of them needed guidance to realise that the
    universe moved around them when they turned on their engines. They
    thought they were stuck in the centre of the screen.
     
    --
    James Cameron
    http://quozl.linux.org.au/
     
    Paul Berker <paul <at> paulberker.com> Oct 11 04:50PM -0500 ^
     
    I am top quoting... forgive me...
    I can't tell you how many times I have been Verbally abused and left playing Netrek... enough that I no longer play.
    or worse when I started to get into the coding and the Two Factions of this group not liking *that other group* going on...
     
    I am not going to name anyone, but some of the Gate Keepers here are strangling this game to death thinking they are saving it.
     
     
     
    On 10/11/2011 4:37 PM, Mark Wood wrote:
     
    Paul Berker <paul <at> paulberker.com> Oct 11 10:25AM -0500 ^
     
    I would kick in my comments on OO
    as bad as the Netrek code may be described, I was able to pick my way
    through it.
    and while OO always sounds so good, it must be better right?
    well try going through someone Else's OO code, I find it much more
    difficult by comparison.
    I think OO makes the original programming easier, but later on for
    someone else much harder.
    Unless someone really creates good documentation... which I never
    usually see.
     
    MaxFerret
     
    Jared Thirsk <jthirsk <at> shaw.ca> Oct 11 12:05PM -0600 ^
     
    From: Paul Berker <paul-Hu6nwV5WzXG+XT7JhA+gdA@public.gmane.org>
    > for someone else much harder.
    > Unless someone really creates good documentation... which I
    > never usually see.
     
    I was trying to get at this in a story in my last big email, but even still, I think if you are starting from scratch, OO is an overall win in promoting encapsulation, extensibility and good architecture.
    When there's no documentation, I would like to think the class structure can help imply and enforce organization and decoupling for future contributions.  In the MS world, tools like Intellisense, live XML docs on demand, auto-generated class diagrams sure make a lot of OO fast to pick up (and I know Java has similar things available.)
     
    It sounds like Andrew could and would have contributed to the netrek codebase if it was better organized, and it helps potential keen best practices type contributors like Toumal not have a panic attack when thinking about working with it.
     
    I was concerned that Toumal might be one to start another programming exercise that didn't have enough man power to actually follow through with contributing to netrek, but he seems set on best practices and content with nothing else, so I say if he wants to start climbing the mountain of rewriting everything, I'll hand him and his as-of-yet unidentified team hiking poles and wish them the best, as it's better than nothing and would become valuable at some point if it did get the needed effort.
     
    Jared
     

--
To post send mail here: netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
More info: http://groups.google.com/group/netrek-forever/
Nota bene: Please be civil and treat list members with respect.

--
To post send mail here: netrek-forever-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
More info: http://groups.google.com/group/netrek-forever/
Nota bene: Please be civil and treat list members with respect.

Gmane