Developing
Don't ask, just do. Follow the issues, add issues, enjoy and thank you for your interest.
As you will note, everything is lumped in together, data and all, mostly for easy running and playing. However for devs, this is not ideal. For those devs, if you haven't already installed git, you should probably learn.
Needless to say, to prevent a lot of running around, I am going to provide the information here:
The experimental branch is the unstable version, it's not guaranteed to work or even compile and it's where much testing is done.
- Software - Full Article
- Coding Style - Full Article
- Commenting and Documenting - Full Article
- Identify the problem and propose a solution.
- Clone/pull/fetch Experimental/Master depending on your needs (the source code that you are working from)
- Create and check out a new branch.
- Implement your solution.
- Ensure code meets style needs (Many beautifiers out there that will do this for you).
- Push to own branch.
- Test/Compile
- Confirm that all "Debugging code" have been removed (Avoid the use of Macros, if they have to be used, comment)
- Submit pull request.
- Code will be reviewed/tested for compilation, style and basic testing.
- If approved code will be merged with the experimental branch.
This isn't an exact science there will obviously be exceptions, this is an open source project after all. These are really expectations rather than "rules". Hopefully following this development flow will help us catch more bugs/errors and prevent broken code from being merged.
Pro Tip You don't necessarily need to copy the compiled binary to the bin/ each time, just create a symbolic link to skip that step - loki1950
Essential to getting it right the first time.
This is the absolute minimum testing level for any contribution to the Vegastrike-taose project. Don't leave it to chance.
- Cmake Level Run cmake, this will yield any basic errors, missing files and such like.
- make level Run make, this will yield any compilation errors and warnings.
- Game Initialization run ./vegastrike, this will run through a series of checks to get the game started.
This is recommended to make sure the game plays as expected.
- Game Run Actually go into the game.
- Play Test 1 Play for 15 minutes
- Play Test 2 Play for 30 minutes
- Play Test 3 Play for 60 minutes
While not essential, logging in your testing hours is a good routine for developing. Developing is great and all but sometimes our "fixes" may introduce other bugs, which is why the Recommended Test Level includes Testing Time. This allows us to weed out other bugs and potentially fix others. Finally it may also inspire us regarding what would make the game even better. Use the following bullet points as guidance for what to include.
- Version Tested (grab the commit number preferably)
- How long you played for (in hours, so half an hour is 0.5, fifteen minutes is 0.25).
- What problems you found or felt.
- Anything else you feel would be useful.
File these in an issue with the Log: Testing Hours label.
Gathering new and updating existing artwork is a priority for this fork and any contributors will be welcomed. In order to make it easier for you we will attempt to counter some of the most common barriers to developing in Vegastrike.
Preferred Software
While not the most sophisticated software in the world, it is free and open source inline with Vega Strike guidance. Other software such as Adobe's Photoshop or Autodesk's Maya or Nvidia's Compression tools may often provide a better solution but unfortunately cannot be supported as a preferred developing software for this project, but this does not restrict you from using it so long as you have the appropriate licence.
.image, .texture, .cube; Vega Strike makes use of the proprietary .dds format (in apparent contravention of Open Source design objectives). The best way to access these files freely and quickly is by making use of GIMP's gimp-dds plugin. These files are exported as .dds, but are renamed to .image, .texture or .cube later on. Though there are some special conditions.
.image, is usually reserved for sprites and, HUD interfaces and so on. These often have translucent or sometimes completely transparent parts but the gimp-dds plugin doesn't do a good job of saving these files. An excellent job of opening and editing them however. The best advice is to export them as .png files (preferably flattened as .dds doesn't like layers).
Once exported they can then be converted through nvcompress, better known as the Nividia Texture Tools (yes, another proprietary software) though can be obtained as libnvtt-bin on linux distributions, which are under an MIT licence. 'nvcompress' takes three arguments. The compression (which will depend highly on how much transparency you need or want). The input file. The output file, which of course can be given it's final name such as .image.
Many of the sprites appear to only work successfully with BC3 or lower.
It is unfortunately, not possibly to interact with some of these materials without making use of proprietary software. While they do not necessarily require being paid for, it is an unfortunate side effect of not being observant of licences and the standard will need to be converted to something more Open Source friendly.
Such as: KTX
Older Developers should assist and induct newbie developers slowly. If they're work doesn't compile, that's their problem, if it doesn't compile or introduces bugs, then the commits can be returned, but if it does compile and doesn't introduce bugs but it doesn't meet our standards through one way or another, the older developer should take care of those matters and give an extremely friendly pointer to how we usually do things. (Extreme care must be taken).
Over time, newbie developers will get used to how things are done, be less prone to repeating their mistakes, ask questions, propose better ways of doing things. It is important for us to have good solid reasoning for the things we do and how we do them and it is extremely important to be newbie friendly.