[Vegastrike-devel] Re: Helping with Development

[Daniel H. <dan...@mi...>]

Brian wrote:

>Message body follows:
>
>I am interested in helping with the Vega Strike development,
>and would like to be added as a developer to the Vega Strike.
>  
>
What we've been doing is having people checkout anonymously and work on
it there---and when they're ready to commit their first patch, then we
add the user as a developer, and then the user can commit with cvs
-db...@cv...:/cvsroot/vegastrike commit

overriding their anonymous checkout. If you need a repository for
intermediate changes while you're working on your first bit of code that
can be arranged.

>I like the basic game, but found the configuration program
>to be very lacking.
>  
>
agreed

>Since I do not like the "setup" program, I would like to
>rewrite it.
>Because the change is considerable, I would like to place
>the code in CVS in a seperate top level directory.  The
>program will be a drop-in replacement to the current vssetup.
>  
>
that may work--- there have been a large number of requests for an
in-game configuration utility--but that is apt to be a larger
effort--and perhaps a separate program is good enough.  One of our
priorities is to keep our configuration utilities cross platform---which
limits which GUIs we choose.  Preferably a console version would be
available to mac users without Xwindow (99% of them don't have it)

>What I would like to see:
>Hardware specific settings take into account the system it
>is running on:
>The list of resolutions be changed to 
>[Windowed]
>[Current]
>[ 1024x768 ]
>[ ... ]
>Where the list of resolutions are pulled from the system it
>is currently running on.  During game load, if the
>resolution selected is not available, then it should fall
>back to current resolution.
>
>Joystick configuration should also take into account the
>joystick installed, and it should be easy for non-developers
>to create new joystick profiles (not just the mapping of
>what does what, but also a top level description of the
>buttons and axes and the numerical mapping to physical device).
>For instance, I have a Saitek X45 joystick, and the axis
>mapping of the joystick required making my own configuration
>file (and I still don't have it perfect).  I'm sure a lot of
>users would have just given up in frustration.
>  
>
agreed--the configuration program should be able to look these things
up--but the user should be able to override such settings

>I would like to see the settings split into group, such as
>Game Play, Graphics/Sound, Input, etc.  Most commercial
>games do this.
>I would like to see more control types used, instead of just
>combo boxes (check boxes for on/off items, radio-list boxes
>for some of the commands).  By grouping options and only
>showing one group at a time, screen real-estate would be
>increased.
>  
>
yes--- the actual XML should be able to be edited--individually or in
groups as saved in vegastrike.config

>Just like the current system, an extensible interface for
>the options so
>that new options could be added without recompiling the
>setup program.
>
>Once the setup program is enhanced, I would like to assist
>with filling in the missing descriptions for many of the
>trade goods, ships, and ship upgrades.  This could also be
>worked on while I wait on feedback on various stages of the
>setup program upgrade.
>  
>
you'd probably be working with jackS for that portion of the devleopment

>I would also like to see some design documentation.  It took
>me a while to figure out why the development tree is built
>the way it is.  It works, but it sure would have taken me
>less time if I could have reviewed a design document that
>covered the dependencies and where they could be gotten (I
>had never used GLUT, and freeGLUT, which I had, was not
>acceptable for this program).  This should help out new
>developers that want to contribute to the project, and also
>old hands that need to deal with an area they do not work
>with regularly.  Things to cover:
>  Software Dependencies
>  
>
any actual releases don't have software dependencies as everything is
statically built...

>  Subsystem breakdown, including what file does what, and
>primary developer for each subsystem.
>  Build system description.
>  
>
would be useful

>There are many more ideas, but I think that is a good start.
>
>--
>This message has been sent to you, a registered SourceForge.net user,
>by another site user, through the SourceForge.net site.  This message
>has been delivered to your SourceForge.net mail alias.  You may reply
>to this message using the "Reply" feature of your email client, or
>using the messaging facility of SourceForge.net at:
>https://sourceforge.net/sendmessage.php?touser=1319466
>
>  
>