Mutator Week is a simple idea. Every other week is a Mutator Week, and a theme will be mailed out on the Friday night. From this time, everyone is given one week (seven days) to write a simple mutator and commit it to subversion. The following week is for everyone to download the mutators and give feedback on the designs and technical application of the design, as well as review the source code in order to make corrections, bug fixes and updates.
It's not mandatory to produce a mutator every week, as obviously sometimes people get busy and have to deal with real life and what-not, but I'm sure everyone else would appreciate you sticking around to help!
The mutator should be small, sweet and simple. There's no need to produce the ultimate epic mutator that does everything including make you breakfast - that's not the aim of the game. Whether you're making rockets bounce, creating a new power up or changing player movement, it's a little change with some relation to the theme. So how does this all work? Well, you have a theme, and you've come up with an idea. You start writing your code, but hold on! How do I do this or that?
The most important aspect of Mutator Week is that you help each other out. The forums are here not only to discuss what you're doing, but also to ask each other questions and more importantly, to answer them. By helping each other out as much as possible, you'll help each other learn, and that's what you're all here to do. Noone obviously has the time to sit down and teach everyone everything, and noone can be expected to even know all the answers, but collaborative minds can work well if all working towards a common goal.
To keep things competitive, we'll be running a little bit of a competition during the whole thing, where we'll all get to vote on which mutators are the coolest, which are the best written or the most novel idea. We'll be keeping track of these and awarding a few points here and there, and we'll see who comes out on top in a few weeks time (There'll even be a little prize). We'll also award a few bonus points to the people who are really helping others out of course, it's only fair.
When a week is finished, we can package the working ones up and offer them up for download for the general public too, of course, before moving on to our next topic. If you didn't finish a mutator, or there's a small bug, don't worry, we can always fix it up some other time and put it in a future mutator pack too.
Guidlines for Writing Code
Formatting is everything. You may have your own particular style, but in this case, you've been vetoed - the project will have all code written the Epic way - all those other little bits and pieces you sometimes like to rearrange. This organisation helps others read your code, and thus helps you improve it, as well as preventing potential annoying errors from occuring!
- Parenthesis (squiggly brackets) always on their own lines.
- DefaultProperties defined clearly at the bottom.
- Tab out and indent your code to make it easy to read.
- Always fully-qualify class names - this means means 'packagename.classname', not just 'classname'.
When creating classes, always prefix your class names with your unique two letter code - this prevents other people from creating classes of the same name and thus colliding with yours. Remember that each week everyone will be working on putting their classes in the same package file. Two other rules - never create subclasses of the pawn and playercontrollers - that is for the realms of game modes and can often break other mutators!
- Name your classes properly - MI_Mutator_ClassType (My Initials, My Mutator Name, My Class Name).
- Never create new pawns or player controllers.
- KISS - keep it simple, stupid! You've got 7 days to write code, you don't need an epic configuration script of death, just a neat little feature.
- It's all about experimental gameplay and cool code!
Keeping Score
Points are awarded for the two voted 'best overall' (3), 'most innovative' (2) and 'best implementation' (2). Points are additionally given every week for people voted 'very helpful' (1). Points are tallied, and scores are kept. Bonus points may be awarded for outstanding contribution to the project if we feel they should be. At the end of every eight weeks (or four mutator weeks). We'll be awarding the winner a small prize for their efforts, and assitance in keeping the project rolling (you won't be able to win the prize twice in a row)!
What Else?
Have any questions or additions to this guideline? Ask away, and add to the thread, and the main topic will be updated.