What you can do to help CWE development!

[Branan]

It's really time we made a more public TODO list, so that anybody can see what needs to be done. Code issues have always been available on the Github issue tracker, but there are non-code things that can be done as well.

Please don't post code feature requests here - use one of the existing threads or the bug tracker. If you have suggestions for other ways the community can get involved, you're welcome to use this thread. If they seem reasonable, I'll add them to the master list.

In the same vein: It's better to discuss code issues on the tracker. Discussion of other community tasks is welcome here.

Code
Some of the code issues will have existing H-uru devs assigned to them. That usually just means "This is the person that knows that bit of code well enough to do it". They probably haven't actually started on it yet, but they're a good person to ask for info on how to get started if that issue interests you. This list of issues is also not exhaustive - these are the sort of "junior jobs". There are some major rewrites to do, if you're interested in a challenge.

• Remove a spurious assert in plDXPipeline
• Use LZMA instead of ZLIB for network compression
• Move the python glue to C
• Get more plasma apps building in CMake

Content

• "Unit test" ages that test specific features. Sound, physics, and graphics are all on the table for major rewrites, so having simple ages that we can use to confirm behavior of individual features would be awesome.

Other

• If you have technical writing experience, the README and wiki articles related to CWE could probably stand to be given a good rewrite.
• Recruiting is always awesome. If you know a developer who might be interested in working on CWE, you should totally point them in our direction (or at least the direction of this thread)
• You might have noticed we don't have a donation button anywhere on the GoW or H-uru pages. That does not mean we don't appreciate money, just that we keep avoiding the issue of how to handle a pool of money and split up donations. If you feel you really want to give monetary support, it would be welcomed. The best thing to do is to contact Hoikas about helping to foot some of the GoW's bills - they aren't all that high, but he is a college student. Every little bit helps. Alternatively, if there's a H-uru dev that's implemented a feature you think is totally rad, you can try to get in touch with them directly. If you want to create a "bounty" for a specific bugfix or feature, you should contact a guild councilor or one of the H-uru leads and we'll figure out the best way to handle it.

[Paradox]

Content

• "Unit test" ages that test specific features. Sound, physics, and graphics are all on the table for major rewrites, so having simple ages that we can use to confirm behavior of individual features would be awesome.

If you're a developer, and you're familiar with C++ and want to get to know the Plasma codebase, writing unit tests is an incredibly good exercise that is also highly useful to the project overall.

We know that the engine works in MSVC, but now there are people starting to compile it under minGW, g++ on Linux, XCode on Mac, etc. There is also the challenge of 32-bit vs 64-bit code. Unit tests gives these developers an easy way to check that the code still works as intended when they are adding new features or porting it to a new platform.

I also wanted to say that if anyone is interested in developing, or just in watching development, you should jump in the #writers IRC channel on irc.justirc.net.

[Jojon]

Ok, so ages much like the footstep test or sprite gallery ages, where various parameters for things like friction/elasticity/volume/hearing range/blend modes and strengths/etc, can be compared; mostly for legacy compatibility, but also for wide user range consistency with new features, then?

What Paradox wrote, sounds more like a "simulated" test bed, though, where outputs are compared directly, numerically -- coder work, rather than the impression-reliant builder/tester/golden-ear..? I guess in the end, one still have to have to have a bit of the latter, to confirm the results from the former...

Hmm, bounties... What to prioritise... Would any of the devs like to suggest some important ground-work they'd prefer to see done before anything else, but would be easier to slog through, where there some extra incentive? :7

[Paradox]

What Paradox wrote, sounds more like a "simulated" test bed, though, where outputs are compared directly, numerically -- coder work, rather than the impression-reliant builder/tester/golden-ear..? I guess in the end, one still have to have to have a bit of the latter, to confirm the results from the former...

That's right, I was talking about a bunch of tests that use known inputs to specific functions and check that we get the correct known output. These tests could be run automatically every time someone makes a change, to ensure that the core engine functionality hasn't been broken by a change.

However, numeric/data-based tests are in no way going to be able to check for things like visual, physical, and audible results. Those test Ages, and a group of people willing to load them up and run through them, are also important.

[Branan]

I specifically didn't put unit tests on the code list because they're not really a fun way to get involved. They will help a new dev learn the codebase, but they're rather tedious. I wanted to list things that would be more interesting, but are still things someone new to the CWE code could do - though some might require other skills.

I listed age-unit-tests mostly because I wanted to list something that artists could do to help the developers. Test ages for various features are definitely something we're going to need in the reasonably-near future.

[Deledrius]

A relatively bite-sized coding project for a new contributor might be to solve the widescreen issue still open.

[Karkadann]

"Unit test" ages that test specific features. Sound, physics, and graphics are all on the table for major rewrites, so having simple ages that we can use to confirm behavior of individual features would be awesome.

Anything specific you had in mind, sound, physics, and graphics is kinda general I may be able to help out here if I had something more to work with.