Luminous Forts Developer Document Welcome to the Team (Do not be afraid to edit this file, add points or anything. I would be glad if you made changes, I don't mind it at all. Thanks) Development must be taken very seriously. This mod is not a joke or a little get together group. If you do not work, then you get kicked out, it's as simple as that. Also as the mod gains more steam, entry into the mod will be far stricter, especially for people outside of the Sourceforts community. The most important dev team members are the devoted and motivated ones that churn out content. Ideas are easy to come by, but making the ideas real is the really hard part. We'll take a democratic approach to ideas and accept very much from player testing as long as those giving the ideas adhere to and remember the mod's philosophy. Philosophy Game Play and Game Design Luminous Forts is going to be Sourceforts 1.9.5 and much more. We are not just building a mod to be Sourceforts 1.9.5, but to continue on to be Sourceforts 2.0. This being said many things will be done to make sure the mod will last, if and when the hands that recieve it from us continue to work on and develop the mod. This mod follows FicWill's philosophy that Sourceforts is not Capture the Flag with blocks, but blocks with Capture the Flag. The old Sourceforts team looked to many different ideas and was looking to make a lot more game modes that weren't just Capture the Flag. Luminous Forts should strive for this. For example all the game really needs is an objective to get one team attacking the other teams base, there could be a switch behind it that ends the game or opens a door or a trigger to score more points, etc. There are countless ideas, some good and some bad that could be done with the idea forts and opposing teams. Team hierarchy and responsibility Due to our lack of man power many group members are required to take on a multitude of tasks. (ie. Programmer has to manage, take game design ideas, etc.) A manager's role is not to boss people around and to tell them how to do their work, but to motivate, encourage and help them with their work. Modellers: Striving to get away from the Half Life 2 universe requires that we redo many of the in game models. Modellers dictate the artist style and direction of atmosphere in the mod. Programmers: As we lack a Project Manager, the programmers and modellers should deal with game design and looking through ideas of the mod. It's really hard to find good programmers and it's even harder for those programmers to be dedicated, so looking for another programmer is basically out of the question for now. The programmer must be able to create decent code and not inhibit progress. Mappers: (Not sure about this field) However one thing about mapping is that we require creative and new maps to fit the new game modes, so making and building from layouts is a must. Also, prototyping maps is a real plus. Artists: (Not sure about this field) Development Cycle Release Dates Communications Usually the bottleneck of the development is communications. Communicating takes a huge amount of time and usually is the downfall of most mods (this mod may be no different.) However, there are a few things you can do to make modding a little more easy and enjoyable. Cutting out distractions is essential when you're working. Do not give bug reports or feature requests to a programmer, unless they ask you about something. Put bug reports and feature requests on Trac or if you prefer Bugzilla for the first. If you have a huge idea you can even email it (yes, I said email). You can also use the Wiki on Trac for lengthy ideas too. We will have development discussions mostly geared to game design for 10 - 30 minutes once a week, this time has yet to be determined. Meow is going to get us forums. Creating a mod that will last One of the main goals of Luminous Forts is to produce a mod that will last and age on to many releases. To do this requires a lot, but some of the things we can do to make this easier is: No poisonous group members. Does not matter how good they are, if they're annoying/hurting other people in the group then they're out. They can take their work with them. This goes without saying, but no trolling others making fun of them, etc. Especially if they've asked for it to stop. Code will be slowed down to put a further emphasis on quality. Documentation will also be created for the code. Tips for Good and Quick Work d Authors: Revisions 1 Hekar Khani