Slash'EM is the game it is today because many people have helped to develop it. Some in large ways and others in small ways. Both kinds of contributions are vital to the life of a game like Slash'EM. This page aims to tell you how to contribute in small ways and provides some pointers for those who would like to make a larger contribution.
You may find it helpful to read the description of how Slash'EM is developed.
It is a sad fact that the dev-team do not have as much time to play Slash'EM as they would like. It is therefore very important that when we consider whether a proposed change to Slash'EM is beneficial or harmful to the game we hear the views of players as well as programmers.
Please consider joining the slashem-devel mailing list and partaking in discussions. Your opinions and your votes can help to make Slash'EM a better game.
Another thing that the dev-team don't spend enough time doing is testing. This is especially important during the alpha phase of development when we need people to test the game who aren't going to be upset that they've just lost a really promising game due to some stupid bug. We would also value input during beta-testing since we have found that many people don't bother to report bugs assuming that we must already know about the problem. In truth, if a bug is not listed in the bug tracker, we almost certainly don't know about it.
If you are planning to test Slash'EM under UNIX then it will help if you can configure the game to work without any privileges. We don't normally recommend this type of configuration because it provides no defence against cheating on a multi-user system but it has the great advantage that UNIX will generate core files on segmentation violations and the like.
If you do find a bug then we would be very grateful if you could include the following pieces of information in the bug report:
We often find that we have bugs logged which have been there for a long time. It is very helpful to have confirmation that the bug is still present in a recent version and even better to get clues to what circumstances might trigger the problem.
If you would like to fix a bug in Slash'EM then please choose one of the unassigned bugs from the bugtracker and drop a line to the slashem-devel mailing list to ask a member of the dev-team to assign the bug to you. If the bug is something that you have found which hasn't yet been reported then please submit a bug report via the bugtracker first.
Once the bug has been assigned to you, you can be confident that no one else will be working on it. The first step to fixing a bug is to get the source for Slash'EM. You can use the latest source tarball. Even better is to use CVS to get a copy of the latest source.
Once you think you have fixed the problem, create a diff against the Slash'EM source that you were working from. Ideally, this should be in unified diff format taken from the top of the Slash'EM directory tree. For example, you might work as follows:
% mkdir cvs % cd cvs % cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/slashem \ > co slashem
Then after making any necessary changes to the files in the slashem directory, building the game and testing it, you can create a patch as follows:
% cd cvs/slashem % cvs -z3 -Q diff -u > ../patch.diff
You should review the patch to ensure that all the changes you made are included and the make sure that no other changes have been included (eg., debugging output). Once you are happy with your patch send it to the slashem-devel mailing list for review.
We recognise that, having submitted your patch, you will be very eager to hear back from the dev-team. We do try and review patches submitted to slashem-devel in a timely fashion, but please bear with us if it takes longer than you might hope. Sadly we cannot always give as much time to Slash'EM as we might like to. Your understanding is appreciated.
Once your patch has been reviewed, it will either be returned to you for further work if that seems appropriate or committed to the CVS repository by a member of the dev-team. The dev-team member will also create an entry in readme.txt listing the bug as fixed and giving you credit for your work. It is easier if you don't include this change in your patch since it is likely to introduce conflicts which need to be resolved manually. You can now sit back and bask in the glory of having make your first contribution to Slash'EM.
If you have an idea for a new feature for Slash'EM (or an improvement for an old one) and you are prepared to implement it then you can propose it on the slashem-devel mailing list. This isn't the only way that new features get added to Slash'EM, you can also simply write and publish a patch. If it proves popular, we may decide to include it (or a modified version of it) in the next version. If you have a great idea, but aren't able to implement it, then please submit a feature request instead. The slashem-devel mailing list is not the place to propose that other people implement your idea, however good it is. Of course, if you have already found somebody who is prepared to do the implementation, then that's quite a different matter.
You might like to base your proposal on the following model:
If you decide you'd like to propose more than one change then you will need to consider whether to make one proposal or several. Ideally they should be several proposals if they are independent of each other and one if they need to be considered as a whole. With several proposals it's worth spacing them out a bit so that we don't get confused.
Send your proposal to the slashem-devel mailing list and wait. Chances are that you won't get any replies (which hopefully means that no-one objects). Allow a couple of weeks just in case and then submit the patch to the patch tracker.
When writing your patch, it would be very helpful if you could follow the Slash'EM coding conventions.
There are also a number of jobs that you will need to join the dev-team to do. These include the following:
The Slash'EM dev-team is not some elite group which is particularly difficult to join but we do ask volunteers to prove themselves before they join. In our view, this will delay a serious applicant only very slightly while avoiding the problems of accepting people onto the dev-team who then don't actually do anything, or perhaps worse, allow their enthusiasm to overtake their abilities.
If you would like to join the dev-team, please take the time to demonstrate your ability to do the task you would like to take responsibility for and your commitment to Slash'EM by helping from outside the dev-team until you have some sort of track record. As a guide, this might take a couple of months, or longer if you have less free time available to give. Note: We are only too aware of the difficulties of combining Slash'EM with a busy life. Please do not feel that there is any requirement to invest a certain amount of each week or even of each month. Many of us are only able to give a small amount of time too!