Editorial JE Sawyer on mod making

[Vault Dweller]

Tags: J.E. Sawyer

<b>JE Sawyer</b> has made an interesting and very long <a href=http://forums.obsidianent.com/index.php?showtopic=8168&hl=>post</a> on mod making on the <a href=http://forums.obsidianent.com/index.php?act=idx>Obsidian forums</a>.
<br>
<br>
<blockquote>Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.
<br>
<br>
It’s not common for projects to be successful in spite of mismanagement. You can certainly develop a game or mod without tight management, but you might as well wish, click your heels together, and hope that things will come together. Management takes time and is neither fun nor glamorous, but it is of vital importance to the success of a team endeavor. I’d like to suggest a process and some general tips on how to organize a mod project. These suggestions aren’t necessarily the best in the world. You may even think they are bad ideas, but they seem to work from my perspective. These suggestions assume that you, the initiator of the mod-making process, are the team leader/producer/god emperor. Don’t get too caught up on titles; only ego-tripping retards really give a damn anyway. If you’re the one coordinating things and getting the ball rolling, this post’s for you.
<br>
<br>
Before I begin with a phase breakdown, I’d like to suggest some general stuff:
<br>
<br>
• Set up a web forum, IRC channel, mailing list, bug database and FTP site for your mod. There are a lot of free web forums. http://www.ezboard.com/ is a decent one. Finding an IRC server to host your random channel isn’t necessarily that difficult, but may take time and require jumping through hoops. However, real-time discussion on a weekly basis is pretty important for team communication, camaraderie, and general cohesion. Mailing lists are a good way to prick the ears of people who may not read the boards every day or who were effectively put on a waiting list to joint the mod team. Just don’t abuse it. http://www.bugzilla.org/ is a pretty damned good open license bug tracking software package. The FTP site may be hard to swing for some people, but it’s really useful for organizing assets. Just give uploading privileges to people, organize the folder structure as you see fit, and it will make things much easier for everyone.
<br>
• Don’t let people (or the entire team) drift. Keep people focused on the tasks at hand. A lot of people who volunteer for a mod just want to do the high-level fun stuff. A lot of the stuff in game development is not fun. However, if you can keep people focused on the milestone tasks (even the un-fun ones), the milestone build should show enough progress to really get people pumped. Un-fun tasks are rewarding when the payoff exceeds the drudgery.
<br>
• If possible, use something like http://www.wikimedia.org for your master documents. Always keep backups of the source files, but it is best if the entire team has access to one version of documents. It helps prevent confusion when changes are made. Of course, always inform your team members when documents have changed, and let them know what has changed and where they can see what has changed.
<br>
<br>
VISION PHASE (team lead)
<br>
<br>
• Establish what you are trying to accomplish with your mod. Are you simply trying to create a set of new levels? Are you going to change the HUD? Are you going to add new weapons? Are you going to add new character models to the game with new animations? Cover breadth and depth. How many new levels? How many new monsters?
<br>
• Justify why anyone should give a **** about what you’re doing. Why is this fun? If you want to make a mod because you personally think it’s fun, despite its narrow appeal, that’s fine. However, it’s easier to get people (including potential team members) excited about what you’re doing when you can quickly and clearly tell them why what you’re doing is going to be fun and exciting.
<br>
• When you have determined what you want to do and why it will be fun, write it down in clear, concise terms for dissemination to people who may want to work on your mod. You really do not want to bring people on board only to have them leave halfway through the project because they misunderstood what the team/you was/were trying to accomplish. Keep everyone focused on your goals from the beginning, and remind yourself of them through the project.
<br>
• Given the scope of your mod, make a rough estimate of how many team members you will need. At this stage, you are guessing, because you will not have a good idea of what is involved with every task. However, you should be able to estimate certain things. E.g., if your goal is to make new levels and use existing tools to modify things, you probably will not touch code and will not need programmers. However, you will need level designers to lay out maps and 2D artists to create textures. Break down your needs into four sub-team disciplines: design, art, programming, and audio.
<br>
• For every discipline you will be staffing, try to find one really good team member. Do not try to staff the entire team immediately. As the project director, you have a good idea of the vision, but you may be abysmal at analyzing the details of implementing that vision. Before you throw 4-8 “artists” at a mod, you need a level-headed, informed analysis of your art needs. Find one good artist first. Find one good programmer if you need one. And hey, if one is all you need, that’s great. If a deluge of people volunteer, thank them for their submission, but tell them that it will be a short while before you fully staff up. Keep in contact with them throughout pre-production so they don’t drift away. PROTIP: You may find people who would like to help you, are super bitchin’, but just don’t have the time. Consider politely asking them for their help in analyzing other applicants, particularly if you don’t know enough about the discipline to separate the wheat from the chaff. Now that you have a core team, it’s time for pre-production.
<br>
<br>
PRE-PRODUCTION (team lead and core team)
<br>
<br>
• Once you have established your core team, disseminate your vision document for analysis. The goal is for the core team to seriously analyze the scope of the project and break it down into realistic lists of tasks. THE ESTABLISHMENT OF A TASK LIST IS OF VITAL IMPORTANCE TO THE SUCCESSFUL MANAGEMENT OF YOUR PROJECT. Remember, for everything you want to accomplish, someone has to make it happen. Things don’t magically get done. Even the smallest tasks should be listed (within reason of course -- just try to be thorough). Accompanying the task lists should be asset lists. An asset is any object (usually an art object, but possibly a table file or other bit of data) that needs to be created for use in the game. E.g.: One of the tasks is the creation of Monster X. Implicit in the creation of Monster X are the creation of Monster X’s data (in code or through an editor), its model, its textures, its skeleton, and its animations. When you schedule these tasks out, you may group them in the task list for simplicity (i.e.: Monster X’s animations), but be sure to actually list all of those assets out in a team-available list somewhere. If you don’t list it, you might as well assume that it is not going to be created.
<br>
• Create master documents for each discipline. These documents will effectively be the blueprints and guides for how your mod is completed. They will be referenced by other members of the core team and by the larger team during the production phase. The master documents should explain how each set of tasks will be completed and should list specifications for assets and processes where needed. If programmers will need a certain compiler or a set of libraries, make that perfectly clear. If the textures for level geometry need to all be power of two sizes, 4-bit, no larger than 512x512, .tga format, and come in under 2 megs on one load, it would be wise to list that out. The organization of these documents can be discussed by the core team, but the format should be decided by the team leader.
<br>
• Organize your task list. Remove redundant entries. Promote communication between team members to recognize dependencies and risks. You may find that some of the core team members condemn an element of the vision as impossible or extremely high risk. If the team comes to a consensus on this, seriously consider revising the vision and scope of the project. Anything that is “risky” is something that should be implemented and tested as early as possible. This is particularly important if it’s an element of game play that could make or break the project. If you have a strange new mechanic or weapon that may drastically alter game play, implement it early and test it. If the whole project rests on that “new thing” and it sucks, there’s no point to continuing forward with the vision as written. Dependencies between tasks (e.g., you need this editor support before you can make this feature work) should be clearly noted for later integration into the schedule. All dependencies should be completed prior to the tasks that need them. I know it seems logical, but you’d be surprised how many people don’t “get it”.
<br>
• Estimate the time required for each task. Yes, every single goddamned task. The smallest unit of time should be about an hour. These don’t have to be hyper-precise estimations, but they should be realistic. If you’re uncertain on a set of tasks, pad them a little. It’s almost always better to estimate a task will take more time than less time. If the task comes in under the estimation, hot damn, you’re momentarily ahead of schedule.
<br>
• Summarize the work-hour totals for each discipline, possibly organized by sub-discipline (animation or modeling, for instance). This will give you a good idea of your staffing needs. If you have 38 hours of programming tasks, one programmer working 5 hours a week for 8 weeks should hit the goal. If you have 180 hours of art tasks, one artist working 3 hours a week isn’t going to be done in the same year as the programmer, so that may throw a wrench in your plans for a three month dev cycle.
<br>
• Keeping dependencies in mind, start to organize the task list into a schedule. Give emphasis to high-risk items and coordinate them towards a pre-production milestone date. Also, if you have a multi-step pipeline/process for getting assets into the game, test them. A convoluted pipeline can spell disaster for a project. This pre-production milestone will serve as a proof of concept and of the team’s capabilities. If you can successfully complete the riskiest elements of the project in a timely fashion, completing the other elements should be easier, even with a larger (more difficult to manage) team. As you schedule these things, get realistic estimations from the team members on how many hours they can put in per week. Really, please, keep in mind that you’re working on a mod, and that people may have real lives and real jobs to attend to. End the implementation phase of your milestone about a work-week ahead of the actual milestone date. Leave the last week for tweaking and bug-fixing. Be firm about this. DO NOT let features get implemented after your one-week cutoff. A stable, playable build should be the goal. Quality, not quantity.
<br>
• If the schedule falls short in one discipline (e.g., it will take two weeks to do everything in pre-production but the animation, which will take eight weeks), either staff up or move the pre-production milestone date to something more realistic. Realize that it will take time to find new team members and get them up to speed, so schedule “their” tasks accordingly; do not schedule a non-existent team member with tasks the day that you realize you’re coming up short.
<br>
• Coordinate the new team members with the core so that the growing group is still all on the same page. Have them read through the master documents and take their feedback, when appropriate.
<br>
• Begin work on the pre-production milestone. Have all team members report daily on their progress. If a team member does not report, assume they accomplished nothing. Track progress realistically. If you see people slipping on dates, discuss the issues with them and try to adapt your schedule appropriately. Do not wait until the end of the milestone to take action. By that time, it’s too late to fix the problem. SLIPPING IN GAME DEVELOPMENT OCCURS BECAUSE PEOPLE DO NOT REALIZE OR DO NOT TAKE ACTION WHEN SCHEDULED TASKS SLIP. If necessary, re-assign tasks from a “slipping” team member to a team member who is ahead of schedule (or willing to do more work), or replace the team member. Mod workers are notorious for being all talk, no action. They will not be penalized for failing to do their volunteer work. Don’t bother trying to lay a guilt trip on them; if they aren’t enthusiastic enough to make time for it, get them off the team. It’s as simple as that.
<br>
• Continually keep the entire team informed (passively in web form and actively in a weekly e-mail update) of the every member’s progress on the milestone. Not only do the go-getters help motivate the other team members (“Hey, we actually did something!”), but the team will be acutely aware if any of their dependencies slip. Don’t just list dates, percentages of completion, and task names. Write up a brief overview of what got done, what didn’t, and what that means, overall.
<br>
• Near the end of the milestone, at a pre-scheduled date, have a team analysis of where the milestone stands and what needs to be done to make it happen “for reals”. Some tasks may not be attainable. Note that and discuss that in the pre-production post-mortem. For everything else, make realistic and appropriate modifications to the schedule. If one animation will be missing, maybe convincing the animator to work a little extra in the last week isn’t unreasonable. Crunch itself isn’t bad. No schedule is perfect. Crunch is bad when it is continuous because there is no realistic, monitored schedule.
<br>
• Create a build with the pre-production milestone assets (code, art, dialogues, etc.). Review it and disseminate it to team members. With them, carry out a post-mortem to analyze what went wrong, what went right, and what that means for the upcoming milestones and tasks. Actively draw opinions out of the team members on what they felt went right and wrong. Some people don’t volunteer opinions, even if they are of vital importance.
<br>
• If your pre-production milestone was not an abysmal failure, move on to production.
<br>
<br>
PRODUCTION (full team)
<br>
<br>
• Re-evaluate the task lists and break them down into milestones, similar to the pre-production milestone. Each milestone should have something to show. For amateur mods, it doesn’t necessarily matter if the milestones are two weeks long, a month long, or three months long. What’s important is that a significant volume of overall work is accomplished that takes the milestone build to a significantly higher level than the previous milestone.
<br>
• Address any risks that arose during pre-production. Change the scope of the project, begin looking for new team members, etc. Schedules and master documents are not carved in stone. They are living documents, and should be treated as such.
<br>
• As new team members come on, bring them up to speed, help them feel like they are part of the community, and work, work, work that schedule. Pay attention to it. Change it. Bring slippage to the attention of team members and act on it quickly.
<br>
• Complete the milestones, dummy. The hard part’s already been taken care of. I don’t care if you want to give the elf blue eyes or grey eyes, or if the rocket launcher should do 50 or 100 points of damage on a direct hit. You and the team can figure that out on your own. But if you don’t have an organized, scheduled approach to your project, it’s unlikely that any of those details are really going to matter.</blockquote>
<br>
Comments?
<br>
<br>
PS. I know it's long, Saint, so my bad. We can cut it if you want to, or, since it's informative and educational, maybe we should move it to content, if Josh doesn't mind?

 

[Diogo Ribeiro]

Damn. Was going to point people out to this article in a few minutes.

I'm not part of the staff, but I second the suggestion of trimming it and move it to the content database, maybe makie this an editorial would be nice. I don't think JE would mind (though its always better to ask).

 

[J.E. Sawyer]

As long as you don't fundamentally change what I wrote, I don't care where it goes; it's "your" site.

 

[Vault Dweller]

Thanks, JE.


RPG Codex is happy to announce a computer game design program. Please forward us $50 and we will mail you detailed instructions on how to make your own game by a renowned designer JE Sawyer.

 

[POOPERSCOOPER]

As long as you don't fundamentally change what I wrote, I don't care where it goes; it's "your" site.

ur still a faggot

<3 romero

 

[Voss]

Make it stop, make it stop.
Not the content, its just a bit overwhelming to walk in on all that.

I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.

About this bit. Sure there are exceptions, but...
generally, a rough equivalency can be work out. Unsound ideas come up a lot an awful lot. And idiocy seems to spread like a plague. Of course, that largely comes down to my General Theory of the Spread of Idiocy:

People being skull-fucked by howler monkeys.
The parts of the brain that aren't physically damaged by some damn monkey's lice ridden cock are liquified by all the damn screeching.

 

[Tiliqua]

People do post-graduate courses in Project Management, but why bother, Josh has condenced a few years study into one insightful post. Anyone who is half serious about a project should read this and use it as a template. Brilliant stuff.

 

[DarkUnderlord]

JE Sawyer has made an interesting and very long post on mod making on the Obsidian forums.

Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.

Edit: <snip>

Comments?

PS. I know it's long, Saint, so my bad. We can cut it if you want to, or, since it's informative and educational, maybe we should move it to content, if Josh doesn't mind?

Comments? Yeah mother-fucker, I'll give you a comment. Learn to do a news grab asshole and link to it, not post the whole fucking thing.

Bitch.

Not sure I agree on the discipline thing, breaking a project up into it sure but the design guys are sometimes programmers or the artists want do some design as well and if you've got a list of "staff" with associated "roles" they should be on both lists and... I prefer the "have team members", "some do this, others do that, some do both" and just manage each task as we reach it with the "who does what" stuff.

Time estimation goes from "should take a week" to "well, I didn't do it this week because my HDD died and I had to buy a new one and next week is my sister's wedding and by the way, I'm taking holidays and won't be around until..."

Don’t bother trying to lay a guilt trip on them; if they aren’t enthusiastic enough to make time for it, get them off the team. It’s as simple as that.

Amen to that. OMG d00d, u didn't do it, u shood feel so ashaymd!!1!

Overall, I think the second most important thing, apart from what's in giant text, highlighted and in capitals is this:

Management takes time.

E-mail lists, updating tasks, keeping track of milestones yadda yadda yadda generally leaves the project manager with no time to actually do any work on other stuff.

That's some good stuff from JE though. I respekt it 'cause JE's made some good mods in his modding career, like Asswind Dale 2.

 

[Surlent]

Quite extensive post for mod making.
IMHO very good what-to-do list for large projects but unnecessary for 2-4 people who just makes few weapons and some more spells.

Btw JE, how are you holding up in Midway ?
Do you lead projects there yourself or design ?
Seen Romero or Tom Hall there ?

 

[Saint_Proverbius]

Romero is JE's bossman.

 

[Vault Dweller]

Comments? Yeah mother-fucker, I'll give you a comment. Learn to do a news grab asshole and link to it, not post the whole fucking thing.

Bitch.

I appreciate your advice, although I'd like to point out that if I needed any, I would have fucking asked. In the future, when you feel that you have something important to say, write it down and patiently wait till I ask for your input.

Bitch.

 

[Major_Blackhart]

DU got slapped. He said bring it, VD brought it, and set it out on the table!

 

[chrisbeddoes]

Hello. My name is Chris.....
I’m not necessarily an expert on the game development process
I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because people wrongly believe that making games is fun when it fact it is a tedius boring job 90 % of the time.


I’d like to suggest a process and some general tips on how to organize a mod project. These suggestions are certainly not the best in the world.

These suggestions assume that you, the initiator of the mod-making process, are the team leader/producer/god emperor. Don’t get too caught up on titles; only ego-tripping retards really give a damn anyway. If you’re the one coordinating things and getting the ball rolling, this post’s for you.

Before I begin with a phase breakdown, I’d like to suggest some general stuff:

a) Make sure that you have a rich daddy / big bank account / won the lottery before starting to make the mod because you will need some means to live.

b) Forget about social life . Get rid of girls, wifes, kids , lovers and other bothersome things that stand in your way of sucess. (mod success that is)

c) If you have lots of monies get a few people and pay them to do work for you. Also pay a fat ugly lawyer and use him to sue them if they do not deliver your work in time with all the bells and whistles that u need.

d) If you do not have lots of monies to hire people then make sure that you use only certified geeks.
Account in slashdot is generally a good sing as well as glasses , muopia and a big belly from too much time spend in front of the pc and too little exercise.

e) Make source that you backup your source files on something other than the cd -rom filled with mp3 from kazaa.Those source files are important !

VISION PHASE (team lead) YEA ! *u r boss u do all work yea !)

• Establish what you are trying to accomplish with your mod.Are you simply try to alienate or frighten your parents that suddently see your social life go to zero ? or are you simply using ur mod as an excuse to get rid of girls in order to improve ur financial situation ? or are u truly a geek ?



• Justify why anyone should give a **** about what you’re doing.
Well nobody will give a damn but you can always get feedback if you include some errors in ur mod .
Just make sure that they are not too severe because then nobody will want to play ur mod.


• When you have determined what you want to do and why it will be fun, write it down in clear, concise terms for dissemination to people who may want to work on your mod.

That way u will know what the other team mempers did not do and all the added work that u have for urshelf because all the other team mermbers are lazy and quite propably have a life.

• Given the scope of your mod, make a rough estimate of how many team members you will need.

But guess what . If the only one that gonna really work on ur mod in u better make small changes .

• For every discipline you will be staffing, try to find one really good team member.
PRO-TIP . Get in front of a mirror while brainstorming this process.(second pro tip-clean the mirror first if itsd dirty)


PRE-PRODUCTION (team lead and core team)

• Once you have established your core team, disseminate your vision document for analysis.

To ur doad and mom. With luck and if they are really rich they will get so frightened by this that they will sent u for expensive vacations elswhere or find a hoo--r to take good care of u in order for u to forget ur project.

• Create master documents for each discipline. These documents will effectively be the blueprints and guides for how your mod is completed.
Just to make sure that u do not forget that in the first 2 months of ur prroject u managed to do .001 % of all tasks.



• Organize your task list. Remove redundant entries. Promote communication between team members to recognize dependencies and risks.
This means basically is that u think u have a great idea tell it to others and u get silence ur idea sucks .
Remove it and do something else.





PRODUCTION (full team)

• Re-evaluate the task lists and break them down into milestones, similar to the pre-production milestone.

Well this basically means that when u actually have done 10 % of the things that u wanted to do ur mod is a sucesss.realise that u will never complet the other 90 % and delete them from u list to do.

Also fix all the game stoping bugs. Fixing all the others bugs is however unnessesarry imparctical is boring and will take infinite time.
But why bother ?
There are a lot of people on forums to test yr mod for free and point ur bugs to u.


Comments?

 

[Diogo Ribeiro]

While I agree to pretty much everything Sawyer mentioned in the article, I feel there's an additional reason as to why many modules for NWN - from unfinished to finished projects - end up being less than good or unfinished. I may be wrong, but I always felt the community promoted quantity over quality.

Anyone can make a module and upload it to NWN Vault, but this makes it so anything, quality wise, is up there; and more often than not, no one cares. The somewhat ease of use of the toolset, coupled with a lack of standards or guidelines for module publishing (at least, there is none that I know of) makes it so the Vault is flooded with modules made by builders who only had a "Hey, I can do that!" or "Me too!" attitudes backing up the project. I think its important to understand that, if you think you can do the same as everyone else, then chances are, someone else has the same line of thought as you, and likely already did the same as everyone else - a forgetable module, played by many but enjoyed by few, now being nothing more than a data entry that's undermining my attempt to quickly access something that's actually good.

 

[POOPERSCOOPER]

Comments? Yeah mother-fucker, I'll give you a comment. Learn to do a news grab asshole and link to it, not post the whole fucking thing.

Bitch.

I appreciate your advice, although I'd like to point out that if I needed any, I would have fucking asked. In the future, when you feel that you have something important to say, write it down and patiently wait till I ask for your input.

Bitch.

You obivously dont care about input, you always post stupid ass long shit and say "OMG SORRY SAINT LOL". How fucking hard can it be to pick out a few lines and have the rest linked?

 

[Vault Dweller]

I usually make a note to Saint after a long post out of respect for a man who runs this show and asked me to keep it short. I also left it up to him to slice it and dice it if he wants to.

As for the input, I do care, but not when it's accompanied by "motherfucker" and such. What and how I post is my business, and it's up to Saint to interfere and/or ask me to step down.

And last, the reason I posted the whole thing is because it was posted on a forum that could be reorganized one day and the article would be lost. I thought that the Codex is a proper place to collect and keep such items. Saint will decide.

 

[J.E. Sawyer]

Romero is JE's bossman.

He hasn't been my boss for a couple of months. He's now the creative director for Midway San Diego instead of the team lead for Gauntlet. David Kunkler is my boss, and he's a cool dude.

That's some good stuff from JE though. I respekt it 'cause JE's made some good mods in his modding career, like Asswind Dale 2.

In turn I respect your post because you've made some good posts in your long history of posting on internet message boards.

 

[Sol Invictus]

It's in the unapproved content thingy right now. Just waiting for Saint's validation. Added blockquotes, bold and so forth.

 

[Vault Dweller]

Thanks, Exitium, looks good.

 

[DarkUnderlord]

Comments? Yeah mother-fucker, I'll give you a comment. Learn to do a news grab asshole and link to it, not post the whole fucking thing.

Bitch.

I appreciate your advice, although I'd like to point out that if I needed any, I would have fucking asked. In the future, when you feel that you have something important to say, write it down and patiently wait till I ask for your input.

Bitch.

Hey dipshit, remember this?

Comments?

Yeah that's right mother-fucker, that's you asking for help and if you'll note, I did write my fucking comment down in the fucking forum where it's supposed to fucking go. Sure you ask Saint for some fucking help but guess what asshole? We're all members of this fucking community and so if I want to give my fucking comment about how much fucking shit you fucking post on the front fucking page, well I fucking will.

Just remember next time that this:

JE Sawyer has made an interesting and very long post on mod making on the Obsidian forums.

Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.

Edit: <snip>

... is too fucking much.

Fucker.

 

[Vault Dweller]

Comments?

Yeah that's right mother-fucker, that's you asking for help

Hey, dumbfuck, learn to read. That's me asking people what they think about the article, as I don't give a fuck what whiny bitches like you think of the way I post news.

and if you'll note, I did write my fucking comment down in the fucking forum where it's supposed to fucking go.

What's with the emotional outburst? Do you have a PMS, bitch?

Sure you ask Saint for some fucking help but guess what asshole?

Are you an idiot? What help did I ask for? I made a note to Saint where I suggested to move the article to the content section as Saint is the one who approves such things, and that was it. Once again, learn to read.

We're all members of this fucking community and so if I want to give my fucking comment about how much fucking shit you fucking post on the front fucking page, well I fucking will.

Be my guest. We allow trolls and idiots to post here after all, so glad you decided to join them. Nice community you've got there, DU.

Just remember next time that this:

JE Sawyer has made an interesting and very long...<snip>

... is too fucking much.

Yes, I'll remember. Wouldn't want you to have another psychotic "episoide"

Fucker.

Bitch

 

[Diogo Ribeiro]

Chill, dumbnuts.

 

[EEVIAC]

Chill, dumbnuts.

This is what happens when there aren't any decent RPG's. First The Beast, then The Rapture, then The Curved Lightsabre...

 

[Vault Dweller]

Maybe we should take RP's advice and chill, DU. So, if you were to say something like "I went over the top when I gave you my advice", I would say something like "Well, come to think about it, the damn post was kinda long". Then we shake hands and the whole thing's like never happened. What do you say?

 

[Diogo Ribeiro]

You gonna let the bitch talk back to you like that, DU? You all pussified or what?



Just kidding I really felt both of you were being a little extreme, but you can do what you like. Vault Dweller's appeal to serenity in his last post gets my vote.