Before posting in this forum

[ironbelly]

In replying to yet another 'join my awesome team' thread, giving them the same response I've given countless others I'd figure I'd create a thread with some helpful instructions for people coming here for the first time posting up their recruitment thread.

***
First and Foremost: If this is your first Foray into game development it is highly recommended that you spend a couple days(as in 10-15 hours) googling around what actually goes into making a game. There's a reason why a lot of these indie projects take 5-8 years to make from the start of the concepting phase to actually releasing. There's also a good reason by 98% of them will never release. I know you think you're the exception but honestly go through and learn exactly what goes into making a game, you should be able to outline all of the 'foreseeable' work involved before anyone starts doing anything.
***

Now, if you've actually done that, and I honestly applaud you if you have, and are ready to post your recruitment thread, please read the following and make sure your thread touches on all of the points below:


First off, have you read this: http://forums.epicgames.com/threads/...rum-Guidelines ? I'd say than 50% of you don't so why don't you break from the norm and give it a quick read. In particular the first two points:

1. Please be clear whether are looking for someone to join your team or you are looking for a team to join.
2. If you are looking for recruits, please explain your game in detail and post concept art if available. Be very clear whether you are looking for an employee (for pay) or for a hobbyist. Use the thread prefixes when posting. You will see a dropdown next to the thread title.

But the one thing that is missing from that post and something that is equally as importing as describing 'What' you are making is 'Who' the heck are you and why should anyone give their incredibly precious time to your project? The 3rd point in that list above should be:



3. Please provide a small but detailed bio of yourself and what makes you fit to lead a project. What relative experience do you have that qualifies you to lead this project that you are proposing?

Hundreds if not thousands of artists, modelers, programmers, audio engineers and writers spend enormous amounts of life every year working on projects that go no where because they were started by folks who had no business starting a team in the first place. Do the world a favor and don't be one of those people, don't waste the precious time of others before you really know what goes into one of these projects in the first place. To compliment point #3 it would also be hugely re-assuring to potential team members if you could also detail how prepared you are and what kind of infrastructure you have in place to manage your team. Being up front and answering the following questions in your post goes a long way to showing that you are ready to start and lead this project

• Do you have a GDD completed? Or at the very least a comprehensive Concept Document?
• Do you have a style guide/Art Bible completed
• Do you have a Business plan completed?

Let me take a moment here to re-iterate some good points made by others about the above mentioned documents. The documents in themselves aren't of the utmost importance here, although they certainly do have their value and they aren't meant to be bibles that need to be 100% fleshed out before you begin prototyping. At the end of the day if someone were to hand you a completed GDD it wouldn't be worth the paper it was printed on. The reason you create these documents is not to have a GDD in itself, it's to go through the vast amount of Q&A, research and deep contemplation required to complete a GDD. To put it philisophically it's about the journey, not about the destination. It's so that you can deepen your understanding of your product to the point that you can foresee upcoming challenges in production in relation to the big picture, that you can properly plan and pace out the gameplay without having to spend months going one direction just to do an about face, and in the context of this thread it tells potential recruits that you are damn serious about what you are doing. That you have and are prepared to put in serious time, energy and thought into yuor product which at the end of the day ensures a much greater chance that you're project will be successful and that their time will not be wasted. Because a good GDD, a good BP is a LOT of work, hundreds and hundreds of hours of on going work but even then it's just the tip of the iceberg for what it takes to make an actual game, and if you're not prepared to sit down for that then the picture your painting for your recruits is that you're probably not going to be able to stomach the 1000's of hours that will be required of you to get the game to launch.

• Do you have NDA's and Royalty Share agreements in place(if applicable)? Have they been approved by a lawyer?
• How are you managing your team? Forums, CMS, PMS, etc ?
• How often and through what means do you conduct team meetings?
• How many members do you currently have and what do they do?
• How large of a team are you aiming for?
• How long of a development cycle are you predicting?
• How much work has been done so far? How far along are you?

You have to consider your recruitment thread as an interview of sorts, of yourself and so you should treat it as such. You need to show the community and potential recruits why, out of all of the amazing projects that they should contribute their valuable spare time to yours and just as importantly to you.

This post isn't just meant to save the rest of us the time of asking all of these questions in the future it's also to help you make the most out of this forum and your post here. You will notice gigantic improvements in how many responses you get from you thread if you at least make an effort with some of what I've mentioned here. That being said this surely isn't a complete list and I'd love to hear from the rest of the community as to what else is missing from most of these new recruitment threads these days.

In the end I hope this helps and i honestly hope your project defies the odds and becomes a run away hit.. The better you do as an indie game dev the better we all do so go out, kick some ass and draw more attention to this amazing community and the amazing tech that Epic has given us to play with. This truly is the greatest time to be doing what we do!

**ATTN ALL MMORPG/MMOFPS/MMORTS Developers**

If you have come here wanting to make the next greatest mmofpsrtsrpg sandbox game that is better than anything the world has seen yet and makes SW:TOR look like crap read, this thread: http://forums.epicgames.com/threads/...lding-a-Studio as it best sums up the best course of action for you

[fragfest2012]

good guide, albeit maybe taking inspiration from mine (please don't bash me for that, I think it is at least relatively accurate, and, if it isn't, by all means say so), and mine is in the works of being reinvented anyways. Plus yours deals more with putting up a recruitment thread, whereas mine is geared towards helping people start a team, but whatever, your thread is top notch anyways.

[juguefre]

[LIST][*]Do you have a GDD completed?[*]Do you have a style guide/Art Bible completed

what if someone "cough" "cough" doesn't have those 2 "cough" "cough"....

[fragfest2012]

Then they are usually unsure of where they want to go with their project.

[juguefre]

Then they are usually unsure of where they want to go with their project.

how can you know that? what if there is a clear path to follow and somehow the GDD and the concept art are not necesary ..... is possible, there are no rules to be honest.

[TheAgent]

I'm working with a team of 3 and a GDD is very important. It sets the limit and prevents scope creep. I worked by myself and I know a GDD is important. Even if there is no GDD a To Do List/Gameplay Wants etc is always important in replace of a GDD. You cant just put everything you have in a game with nothing to remind you of what is next.Or what the original plan was in the first place.

Overall GDD's are good!

Are they needed? Maybe not.

Is something needed to keep you on track and on pace. Yes!

Is it similar to the GDD. Yes!

Good post ironbelly, this should be stickied.

[juguefre]

Is it similar to the GDD. Yes!

well maybe it is similar, to me looks like a short story with lots of tasks and things to do............

[ironbelly]

what if someone "cough" "cough" doesn't have those 2 "cough" "cough"....

Then the end of the world is coming sooner for you than the rest of us Ha! j/k , it just means that this hypothetical person has a new item at the top of their priority list. In all fairness there will always be a point in any project when a GDD won't exist, unfortunately they don't pop into existence alongside every great conjured game idea, so they have to start somewhere. Even if it's 1/2 way through a project and you dont' have one yet then now's the time because it's going to save you a massive amount of rework down the road.

GDD's are evolving organic documents and I've recorded enough articles at industrybroadcast that deals with them to know that they are no longer the arcaic tombs that got written once and then never touched again. This is why we have them in wiki format so that they can be as collaborative as the rest of the project. At the end of the day they server 2 major purposes in my mind.. First they force you to ask a lot of questions and do a lot of research that you normally wouldn't do. It's the same as writing your Business Plan. It forces you to know your product inside and out and makes you realize that until you've written your GDD or your BP you actually know very little about what it is that you are making. Secondly, it gives you the ability to no frame the individual components of your project into a much clearer broad overview of everything. From this altitude things can start to look a lot differently.

All of this just leads to more experimentation in the mind and on paper and less experimentation and rework in the studio(be it IRL or virtual) and at the end of the day it's a hell of a lot cheaper to do this stuff in the pre-planning / pre-production than in development

[fragfest2012]

Ironbelly and Agent stated my thoughts better than I did, I wonder why...oh yea, they are really good devs and are probably two of the top 20 at least people in this forum.

[ironbelly]

Or maybe we just have more time on our hands?

[fragfest2012]

Or maybe we just have more time on our hands?

Actually that is a really good point.

[rM//AndY]

what if someone "cough" "cough" doesn't have those 2 "cough" "cough"....

Hello,

I'd just like to quickly chime in with my own personal thoughts on this subject. As much as I respect everyone else's opinions on the matter, I don't believe it's as black and white. I actually disagree with quite a few points in this thread (and some of you will probably disagree with me too), but I'll talk about one specifically:

Having a completed GDD before the start of dev almost guarantees failure (or turns out to have been an utter waste of time). You're basically setting in stone the entire fate of a project without having done any kind of prototyping or testing to actually validate your design decisions (and, in my opinion, updating a GDD as you progress defeats its purpose).

Indies (and most AAAs these days) have been moving away from the waterfall model and adopting methodologies like Scrum and Lean which work well with a prototype-based approach, allowing the dev team to remain flexible as they design and implement features and assets iteratively. It makes a lot more sense to write your vision in a 1-2 page Concept Doc (example) and plan/implement the rest progressively based on feedback gathered from prototyping various ideas.

UE3 (and Kismet in particular) is actually perfect for this approach. As Epic's Lee Perry so expertly explained during his talk at MIGS this year (link), prototype-based design shaped the GoW series. Epic's game designers prototyped their ideas in Kismet and either left them in (obviously fleshing them out and porting most of them to code) or tossed them out based on the reaction/feedback they'd received from the rest of the team.

[You'll obviously need to adapt the above to serve your specific needs; don't just follow it to the letter.]


In short, newcomers shouldn't be encouraged to spend that much time on quasi-useless paperwork; instead, spend time on actually building a fun game (and no amount of paperwork makes a team/leader "ready" or "qualified" to build a game anyway).

I completely agree that recruitment threads should contain more than just two lines (ideally you'd post the entire Concept Doc I mentioned above), and that the team's/team members' track records are very important too. In the end, there's always going to be some amount of risk in joining any team and, in my opinion, it's up to the applicant to ask the right questions during the interview process, gauge the overall preparedness of the people already involved, and decide for him/herself.

[TheAgent]

Or maybe we just have more time on our hands?

This ^....

[ironbelly]

This is going to turn into a massive discussion about the merits of running a remotely distributed UDK team with a lean/kanban approach and I'll move my retort to the general discussion thread instead of derailing this one. Bottom line is what you say sounds good in theory but it falls flat on it's face in practice and I'll show you why

http://forums.epicgames.com/threads/873619-Management-Methodologies-for-distributed-indie-teams?p=29812835#post29812835

The real point here is that you are 100% correct in where you are coming from because I've gone down both roads before.. I've gone down the completely agile road with a project that failed because the agile system in place, ironically enough, wasnt' agile enough to keep up with the unpredictability of the nature of remote indie teams. And i've also gone down the structured very serious waterfall approach where the project got completely tied up in the documents and nothing got done. We had the best god damn documents on the planet though, which I now use as templates for everything I do, but the project never got off the ground.

The point I'm making with the GDD here, in context to amateur developers who have either only a few, or no projects under their belt is that the GDD is a critical exercise for them that forces them to learn their project inside and out infinitely better than they would have otherwise, but it also forces them to learn a lot more about the process of game development and what's going to go into making their project. At the end of the day the GDD does have value, especially when you are working with people spread all over the globe who at time don't even have the same mother tongue(a lot easier to read english than hear it), but the real point I am making here is that it isn't about the destination, it's about the journey with this. After creating my first 200 hour, 45 page business plan that had been reviewed by VC's, investment accountants and attorneys, I realized that before I started it I knew absolutely nothing about the business of making games and I shown the importance of these exercises because before I made that BP I thought I knew a hell of a lot about the business of making games The same goes with a good comprehensive GDD, for a first time developer going through one will truly open their eyes to what's involved with realizing their dreams and maybe, just maybe they won't be so blind going into it in the first place.

Hello,

I'd just like to quickly chime in with my own personal thoughts on this subject. As much as I respect everyone else's opinions on the matter, I don't believe it's as black and white. I actually disagree with quite a few points in this thread (and some of you will probably disagree with me too), but I'll talk about one specifically:

Having a completed GDD before the start of dev almost guarantees failure (or turns out to have been an utter waste of time). You're basically setting in stone the entire fate of a project without having done any kind of prototyping or testing to actually validate your design decisions (and, in my opinion, updating a GDD as you progress defeats its purpose).

Indies (and most AAAs these days) have been moving away from the waterfall model and adopting methodologies like Scrum and Lean which work well with a prototype-based approach, allowing the dev team to remain flexible as they design and implement features and assets iteratively. It makes a lot more sense to write your vision in a 1-2 page Concept Doc (example) and plan/implement the rest progressively based on feedback gathered from prototyping various ideas.

UE3 (and Kismet in particular) is actually perfect for this approach. As Epic's Lee Perry so expertly explained during his talk at MIGS this year (link), prototype-based design shaped the GoW series. Epic's game designers prototyped their ideas in Kismet and either left them in (obviously fleshing them out and porting most of them to code) or tossed them out based on the reaction/feedback they'd received from the rest of the team.

[You'll obviously need to adapt the above to serve your specific needs; don't just follow it to the letter.]


In short, newcomers shouldn't be encouraged to spend that much time on quasi-useless paperwork; instead, spend time on actually building a fun game (and no amount of paperwork makes a team/leader "ready" or "qualified" to build a game anyway).

I completely agree that recruitment threads should contain more than just two lines (ideally you'd post the entire Concept Doc I mentioned above), and that the team's/team members' track records are very important too. In the end, there's always going to be some amount of risk in joining any team and, in my opinion, it's up to the applicant to ask the right questions during the interview process, gauge the overall preparedness of the people already involved, and decide for him/herself.

[fragfest2012]

Where is your retort, I want to read it badly...

And @ rM//andY:
I agree to a point. I think the leader should have a good couple pages that detail the idea in gameplay, art and story/design, which is very similar to your concept document. But, I think the couple page GDD, should be updated and added to regularly in the development process based on feature testing. That being said, there is only so much time you can devote to testing because this is an indie project, and it has to sell at some point, plus your team will get tired of testing at some point and they need to be with you. Overall, having a short concept document that addresses story, gameplay, and art is essential to start, and then experimenting is good to help narrow and kink out good features that you want to keep. And, that concept document doesn't necessarily have to be a word document, it could be in the form of like a mindmap, a spreadsheet, etc; it just has to clearly organize your thoughts and game ideas.

Anyways, that is my opinion, and having a full-size GDD is not necessarily a bad idea, except I wouldn't go over like 20 pages cause that is tiring, and the GDD can still be changed in development which is the important part.

[fragfest2012]

It looks good, although I think it would have been better to be in this forum, imo.

[rM//AndY]

This is going to turn into a massive discussion about the merits of running a remotely distributed UDK team with a lean/kanban approach and I'll move my retort to the general discussion thread instead of derailing this one. Bottom line is what you say sounds good in theory but it falls flat on it's face in practice and I'll show you why [...]

Hi Ryan,

I'll read through the other thread soon, but I just wanted to mention that what I've described is an approach that we've been using for years (and one of the main reasons why Overwatch was such a success). There's obviously more to it than the small paragraph I wrote, but it can definitely work, even for decentralized teams. As you've mentioned though, it takes more than just know-how and a set process to make a project succeed.

As for the rest of what you wrote, I don't disagree but... if they need to go through that process, then they're simply not ready to be forming their own team, let alone post on these forums. At that point, I'd recommend either joining an existing team or starting up/working on a mod first (which will also help to build that track record you mentioned).


Millan,

There is definitely a certain level of documentation that needs to be kept/updated during a project. We keep track of 2 main areas:
- User stories (features broken down to their simplest components) and use cases,
- Details regarding custom actors and nodes (Kismet).

That's pretty much it. Features/gameplay ideas each have their own individual threads for discussions/reference, and our Task/Bug Tracker brings all the information together: CLICK CLICK CLICK

Anything more than that will be information that either changes frequently (and is a waste of time to keep up-to-date) or will barely ever need to be referenced.

As for your comments on testing, I wholeheartedly disagree... but I think I've hijacked Ryan's thread enough for one day. :)

[fragfest2012]

Well, I guess your method probably works better for you. What I do is I have a ~15 pg GDD which I change from time to time to reflect changes in ideas, etc and then we are starting to prototype, and, as soon as our character is done we can move beyond initial experimentation which we already did (well, it was mostly me, before I had a real team). So that method works for us, and I think the reason it does is because my game is story-centric, so we have to really lay all that out clearly and it takes more space on paper.

Anyways, both of our methods work, but I think they work better for different types of games.

[Alienated Phreak]

I LOVE this guys! Its one thing to know how to make a game, but knowing how to develop it is a whole other concept.

But I have a few questions if you guys would be so nice as to answer them:

I'm really finding nowhere to turn to on this subject, right now I know that I need a GDD, TDD, and a few bibles or something.

Does anyone know of some bible templates?

And what's a BP?

[noyobean]

A BP is a business plan. It's the GDD of a business.

[Alienated Phreak]

Thank you

[ironbelly]

Bible templates are hard to find.. Gamedev.net is a good start.. Search for Art Bible or Style guide. I had to go to an ex-art director for tips on mine.

Basically what we do is we start by having a discussion with our art director about the direction for the visual style.. He then goes out and grabs as many real world examples to demonstrate shapes, materials, lighting and color. After that does up some quick illustrations of the areas of the level itself to demonstrate this. and then it all gets put into a guide..

Each level has it's own style guide and the purpose of them are to establish: the atmosphere and the mood and then give you a good idea for how this place was built. IE: What kind of materials were used? How is it lit? Are things clean or dirty? What archetectural style is he pulling inspiration from.

For the most part it's 90% images/illustrations and 10% descriptions


At the end of the day you need to be clear what you want the player to feel as he goes through the level and then it's the art director to tell you how you are going to accomplish that visually.

[fragfest2012]

I would say, unless you are aiming for a commercial product and have a sizeable budget now to realize it, that a BP isn't really necessary until you get closer to the finish-line, so to speak. I would recommend a GDD that just lays out ideas, which doesn't ahve to be long, a couple pages will suffice as long as it lays out the gameplay and such well, but a few more helps if the story behind your game is important. Not sure about the TDD, I don't have one, but hey, maybe you would want one, I have just never used or written one before.

[KenD]

Nice work on this Ironbelly. I have a GDD and working towards getting the AB done. Not planning on a BP as yet. This should be stickied

[fragfest2012]

I agree it should be stickied.

[Lexluthor1]

This is a great thread ironbelly..

I thought I'd bump it because I've just spent a couple of hours reading through some of the threads made by people in this section ,"Got Skills? Looking for Talent?" and I must say, its the funniest of all the forums! Why serious level designers and modellers even bother reading half this nonsense on here is beyond me!

Who in their right mind and from any serious games developer, would advertise for team mates on here ? Its all kids who have no idea about managing or running a team of developers..The posts might look good, but you only need a basic understanding of English to make your proposal seem interesting! I read the threads purely for the fun of it, and I can tell you, I laughed a lot ...It should have the prefix of Comedy,Got Skills? Looking for Talent? ...........

Seriously though, are some of these threads just people having a laugh or are they genuinely serious ?

One thread made me laugh so much that I have damaged ribs now......The one where the guy ,(Gentleman something or other) wanted a level designed for £100 ...Clueless to say the least....If I were employed to make a level over the description he gave, (COD) I'd want around £15000.00 to £20000.00 per level...

[fragfest2012]

I gotta agree lex, not only is this thread amazing, but there are a lot of posts here that are, well...nonsense. They are run by people who don't know what they are doing, and sometimes they don't even put more than like ten minutes into making the post. When I started mine, I put more time in, and now I have a decent-sized team and we can do some cool stuff, but I started out with little experience in guiding people. I made up for that with a very good knowledge of UDK and each of the roles in making a good UDK-powered game. So I was able to learn through experience, and would now say I am a decent leader, but still not an amazing leader.

[Lexluthor1]

I gotta agree lex, not only is this thread amazing, but there are a lot of posts here that are, well...nonsense. They are run by people who don't know what they are doing, and sometimes they don't even put more than like ten minutes into making the post. When I started mine, I put more time in, and now I have a decent-sized team and we can do some cool stuff, but I started out with little experience in guiding people. I made up for that with a very good knowledge of UDK and each of the roles in making a good UDK-powered game. So I was able to learn through experience, and would now say I am a decent leader, but still not an amazing leader.

Well I've never joined a team or do I have any intention of joining one but each to their own...

I'm fortunate enough to be able to design my levels,model my assets and package my games commercially, entirely on my own...
In some ways, people are under the illusion that they have a great chance of getting their game or concept out there by joining a "Team" , I personally think it would be a hindrance for someone new to game development..

I'm working on a project soon with two other guys but luckily, we all have our own companies and wouldn't call ourselves a "Team" , more of a collaboration!

[fragfest2012]

Well, I simply meant, I had to learn a bit on the fly, and I wish I would have joined one or two more teams first, but hey, it is working out for me so far. And I by no means expect a ton of people to play my game, and, with some practice in Uscript and a working copy of 3ds max, I could make an entire game myself as well.

[ironbelly]

Absolutely.. Obviously people need to get their skills to a certain level before they can join some of the more serious teams out there but I can say for nearly every member of our team that the experience of working with so many other talented people drives them to push their abilities further than they would have on their own. Coupled with the fact that they have a sounding board of 30-40 people who are invested in what they are doing means that as a whole this group of people becomes far more powerful than simply the sum of all of their parts.

The nature of the project determines the necessity, or lack there of, of a team, I'd say. Which is probably a good argument for new UDK dev's not to join a team because if you need a team you are probably biting off more than you can chew But if you want to focus soley on 3D modeling, or animation then you're going to need others to fill in the missing pieces. This thread, nor this forum, is aimed at the latter there as it sets it's sights on the new 'team leads' that have big ideas and little experience in which case take Millan's advice and join a couple teams to see what you're getting yourself into before wasting the time of others and write up your GDD, BP, LDD, and all that in your off hours. You'll emerge far better prepared in the end.

[Lexluthor1]

Absolutely.. Obviously people need to get their skills to a certain level before they can join some of the more serious teams out there but I can say for nearly every member of our team that the experience of working with so many other talented people drives them to push their abilities further than they would have on their own. Coupled with the fact that they have a sounding board of 30-40 people who are invested in what they are doing means that as a whole this group of people becomes far more powerful than simply the sum of all of their parts.

The nature of the project determines the necessity, or lack there of, of a team, I'd say. Which is probably a good argument for new UDK dev's not to join a team because if you need a team you are probably biting off more than you can chew But if you want to focus soley on 3D modeling, or animation then you're going to need others to fill in the missing pieces. This thread, nor this forum, is aimed at the latter there as it sets it's sights on the new 'team leads' that have big ideas and little experience in which case take Millan's advice and join a couple teams to see what you're getting yourself into before wasting the time of others and write up your GDD, BP, LDD, and all that in your off hours. You'll emerge far better prepared in the end.

Perfectly explained and I totally agree

[fragfest2012]

Yay, I love it when people like what I say!

[ironbelly]

It's easy to love when it makes sense Which is just my way of bumping this thread as it seems 1/2 dozen or so folks in the past week could have used it before posting their recruitment threads

[fragfest2012]

It's easy to love when it makes sense Which is just my way of bumping this thread as it seems 1/2 dozen or so folks in the past week could have used it before posting their recruitment threads

I know right!

[Black_Stormy]

Good to see that there is some people on the forums with a clue. Personally I quite enjoy reading all the naive threads and putting in my own two cents. Ever gone to interlopers? Those guys destroy posts like the ones made here. I know I'd be better off offering them some sound advice but there's just so many of them it's near impossible to weed out the ones with any actual promise, and softly flaming them is just easier.

The general rule of thumb for me is that before asking for help or making a recruitment effort, have the game to a point where you would be wasting your time trying to develop it further by yourself. Have the game pretty much half finished. I'm an artist so I'm not going to be asking for a coder to help on my project until pretty much all the art assets are complete.

As far as the design doc debate goes, I think DDs are more for yourself than for pitching the idea. For instance I never realised how hard it would be to untie the mouse movement from camera rotation and activate the cursor in game until I did a quick concept doc for the player controls. The documents' primary uses (for me, on a one man team) is to gauge how much time your game will actually take.

[Lexluthor1]

It's easy to love when it makes sense Which is just my way of bumping this thread as it seems 1/2 dozen or so folks in the past week could have used it before posting their recruitment threads

Do what I do ironbelly and tell them they have as much chance as meeting god with their idiotic ideas...

I've only ever read about two good ideas in 8 months

[rM//AndY]

What worries me is just how unwelcoming and (at times) unprofessional our community is coming across. We're not only effectively scaring off amateurs, but even veteran developers might think twice about recruiting or joining existing projects through these forums.

I'm not trying to offend anyone or start any kind of argument; this is just my own personal opinion based on what I've seen in the short time I've been here.

[silent_bob]

What worries me is just how unwelcoming and (at times) unprofessional our community is coming across. We're not only effectively scaring off amateurs, but even veteran developers might think twice about recruiting or joining existing projects through these forums.

I'm not trying to offend anyone or start any kind of argument; this is just my own personal opinion based on what I've seen in the short time I've been here.

True that, unfortunately ...

[theflamingskunk]

What worries me is just how unwelcoming and (at times) unprofessional our community is coming across. We're not only effectively scaring off amateurs, but even veteran developers might think twice about recruiting or joining existing projects through these forums.

I'm not trying to offend anyone or start any kind of argument; this is just my own personal opinion based on what I've seen in the short time I've been here.

Strongly Agree.

Although the problem of oversized ego's is something that I have observed to be very common in the Community. Especially when an amateur thinks they are a badass professional and proceed to non-constructively criticize every beginner thread. Its even come to the point that they are starting threads to mock some of Begginer threads.

I am also not trying to start an argument, I just believe that some people need to just chill out and not act like a condescending asshole.

[fragfest2012]

What worries me is just how unwelcoming and (at times) unprofessional our community is coming across. We're not only effectively scaring off amateurs, but even veteran developers might think twice about recruiting or joining existing projects through these forums.

I'm not trying to offend anyone or start any kind of argument; this is just my own personal opinion based on what I've seen in the short time I've been here.

Got to agree with you here, there are some people (not pointing fingers) that are too condescending or harshly critical. I try not to be, but I know even I can fall to it every now and then, which is why I sometimes refrain from posting and let others like ironbelly do it for me (lol). But there are some good, experienced devs here who know what they are talking about (ironbelly, you, and others) and I sometimes like to back them up. Anyways, gotta thank ironbelly for this thread, wish it got stickied.