• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Tobl

Members
  • Content count

    51
  • Joined

  • Last visited

Community Reputation

364 Neutral

About Tobl

  • Rank
    Member
  1. Hello, It is possible to go completely without targeting aid, but if you want to do that, it should be a clear design decision, not just because you couldn't get it to work. Since we can assume that a race which develops space-fighters could also program some basic auto-targeting systems, you're already tuning it down. It'd valid to say you want your player to go Skywalker all the way and do the entire targeting by hand, but, as I said, that should be because you want to, not because you have to. If you don't want to do that, I'd go with the 3d crosshair since that is what was understood faster (according to your tests) and even if it's unprecise, a beam is already way more specific than the entire screen as target area. I can think of two ways to improve it's usefulness in targeting. A: actually draw the beam (a thin and subtle style would suffice) and have it simulate the behaviour of a light beam: generally, it goes to infinity (or the edge of your screen), but if it hits something, the beam gets interrupted, clearly showing what you're aiming at. B: take advantage of the "3d" in 3d crosshair. Keep the two crosshair as main indicators, but add smaller crosshairs in the distance for the closest enemy to your aim-beam / all enemies closer than x to the aim-beam. The math I'm talking about would be (since I'm not sure it was clear what I meant and your post looks like you'll be able to visualize this): 1. get your aim's vector 2. calculate distance of the enemies to that vector 3. get closest enemy / all enemies closer than x to the vector 4. for each enemy, calculate the nearest point that lies on the vector 5. add a small crosshair at that point Considering what you've written so far, this shouldn't be too hard for you to implement. Hopefully this helps you out a little, bw, Tobl
  2. Hello, I would also recommend using GIMP (opensource and free) for most situations: - if you just want to try it out and see how it works, use GIMP, it's free and you don't pay much for software you probably won't ever use for real work. - if you want to communicate with your colleague, GIMP should also be fine. There might be tools missing in one of the two products (yes, there also is awesome stuff that can only be found in GIMP) or they're in another location, but the important parts of how you work and what is possible/easy are the same. - if you want to become autonomous and do all your textures by yourself, GIMP might also be a good choice. It's just as hard/easy to learn as Photoshop, I really can't think of anything you can't do with GIMP that you'd need for creating textures and, the big advantage, it's free for commercial use. However, if you want to work really closely together with your colleague, with both of you editing the same project file, you pretty much have to use Photoshop. GIMP has an importer for psds, and it work's fine for most parts, but there are some flaws (text layers for example) that will make professional work pretty much impossible when working with two different programs and the risks of breaking layers or such when exporting back to psd are too high. Of course it would be just fine if your colleague would use GIMP as well, but he's most likely not going to switch, so yeah, this would be the case where you actually have to buy/rent and learn Photoshop. bw, Tobl
  3. Hello, This is originally a design-method, but maybe a moodboard would also be helpful. Basically, you take a stroll 'round google images, picasa, flickr, dA etc. and put together a A3-sheet (or 2-3 screens worth of content) full of images that convey the feeling you want your game to have. When searching for the images, it's important that you focus on the mood, not the content. It's okay if it happens to be the same setting as your game, but it doesn't have to; don't hesitate to include something with a completely different setting if it manages to invoke the feelings you desire for your game. If your moodboard is somewhat good, the artist will be able pick up that mood way better than he would be able to from the average description and at the same time, he'll get some first impressions what kinds of shapes, styles and colorpalettes could be used to create that mood. @All Names Taken: I hope this will be helpful to you. @Everyone else: Do you think this is a good method for this situation? As I said before, I only know this as a method in the early stages of (mostly product-)design, but I don't see why it shouldn't work in art as well. bw, Tobl
  4. [quote name='omegaweapon2' timestamp='1353119863' post='5001682'] I'm thinking the story should be its strong draw. The hero starts as a zero and got recognized for the battles he/she fought and choices he/she made and important items that was bought. [/quote] Maybe doing so would unlock new characters. Why would a king bother about some newbie rat-slayer? But when that rat-slayer has grown in strength and sets out to kill that terrible monster that had the town in fear for decades, the king's support would be available. bw, Tobl
  5. Hello, I've never played 4x before, so maybe I'm not the best judge, but I think the limited comm-speed could work very well. One or more point(s) of reference could be controlled directly by the player, whereas everything else would run on AI and take only orders from the player. The question would be, where the point(s) of reference should be located. I'd like to see you taking your officer-system a step further and have the player control just the one "in charge". It wouldn't be gameover if that person dies since the player would just gain control of the one that comes next in rank (maybe he can even make the character resign to change the person he's controlling. However, the information that a new guy is in charge would also be limited to the speed of light, making this distinctly different from controlling everyone at once). If you wanted to have another ship/planet as the point of reference, you'd have to move the character there. The general idea here is that you change the player's role from "controlling the system" to "controlling the most powerful one in the system", which is a definitely weaker role and provides another kind of challenge to the player. Also, if you decide the to implement the comm-speed in any somewhat important way, I would suggest having a (toggleable) representation of where the data is on the map (only the ones sent by him, he can't know there's data on the way in his direction). This will make planning easier for the player, and explains exactly why his commands are not instantaneous, thus greatly reducing the "feels like its just there 'cause I wanted to do something about communication". bw, Tobl PS: If the above was just the description of an existing game, please point me to it, I'd really like to try this out.
  6. Hello, Some guys a semester below me at my university just finished this for a little sideproject [url="http://ig.hfg-gmuend.de/Members/sandra_krauss/meine-projekte/kinect-projekt-starry-sky"]Starry Sky[/url] The fog is basically just a continuous stream of circles, coloured according to a certain scheme, getting larger and more transparent with time until they disappear. If you're really interested in implementation, I could get you their email-adresses, but for now, maybe it's just good for a little inspiration. bw, Tobl
  7. Hello, [quote name='PyrZern' timestamp='1352313094' post='4998518'] I believe this is when you should jump on Photoshop and make some Mock-Up Screenshots. [/quote] Before / instead of starting up this gigantomanium: Grab a piece of paper and a pencil and make a few mockups. I wouldn't believe it myself, but I've been studying interaction design for some time now and there simply is no better tool to get your ideas out for the first time than pencil and paper (and maybe a ruler). "But I can't draw." - Even better! It means you won't loose yourself in unnecessary details. If you still feel the need to "improve" your work digitally, either scan it in and adjust values / contrast in Photoshop / Gimp or, if you wanna do anything more, use a tool that actually fits the task. It's called [i]Photo[/i]shop, it's meant for [i]Photo[/i]manipulation, and for almost any other task, it is not a good solution. If you wanna stay with Adobe-products, Fireworks, Illustrator or even InDesign are better suited to create mockups with. If you look outside Adobe there are many tools specifically designed for this task, several of them even online and offering a free trial (don't have a favorite here, so not going to post an example). And, to not give the wrong impression that any of them would be the best way to do a mockup in this early stage: they're not, paper is. It's what the pros use, it's what education recommends and it's what experience tells us. Hope you found this little pro-paper-rant helpful and maybe even enjoyed it a little (at least I enjoyed writing it), bw, Tobl
  8. Hello, [quote name='All Names Taken' timestamp='1352251049' post='4998287'] Movement = EDSF as apposed to WSAD was wondering if this would be very confusing for players? [/quote] Yes, it would. Players have been trained to work with WASD. Whenever they start up your game and have to position their hand on the keyboard, they will end up wondering why they're running backwards instead of to the right. Even worse, if they spend enough time with your game to learn the EDSF (which is highly unlikely, given this big dissatisfier), they will start misplacing their hand in other games, meaning you have broken not only your, but also other games. Sorry, but in interface design, if you don't have a really good reason to do something in a new way, it's not called being innovative, it's called breaking user habits. [quote name='All Names Taken' timestamp='1352251049' post='4998287'] Crouch = Ctrl Run = Shift + Direction [/quote] First reason why we use WASD: For the majority of hands these two modifiers (esp. Ctrl) and the ESDF-controls are too far apart and therefore too hard to reach. [quote name='All Names Taken' timestamp='1352251049' post='4998287'] Block/Guard = G [/quote] This does work, but it's not the best solution. I assume you wanted to use "G is for Guard". However, the upper left and even more the upper right corner (R in ESDF) of the directional controls are easier/more ergonomic to reach and don't break the flow of player movement as much. A seldom-used alternative is using the Alt-Key. The thumb is the most versatile of our digits, still, it's usually only used to operate the spacebar. Using the alt-key minimizes collision of movement-inputs and block-inputs. Of course, jumping and blocking won't be possible at the same time, however, at least I wouldn't know of many combat-systems where that would be a prominent or realistic feature. This approach on the other hands has two conditions: 1. You pretty much have to use WASD for movement or they won't align nicely. 2. You / your programmer will likely have to write a routine to catch the alt-key since most languages can't handle that natively. [quote name='All Names Taken' timestamp='1352251049' post='4998287'] Interact = A [/quote] That seems to be pretty much the only reason for using ESDF. Again, I'm guessing "A is for Action"? There are many other great keys around (from now on using WASD): As I already mentioned the Q and E are very easy to reach. Since interact doesn't have to work as fast as combat, you could also use F if you've put block somewhere else. Speaking of block: if the player can sheath his weapons, you could also use modus-sensitive block/interact or secondary/interact assignments. However, make sure to use that with a defensive combat-skill to avoid accidentaly hitting objects/npcs and so that the player is able to attack quickly without having to manually unsheath his weapon. [quote name='All Names Taken' timestamp='1352251049' post='4998287'] hotkeys z, x, c, v, b. hotkeys 1-0 ,and . (< >) as a way to cycle through hotkey setups ? key possibly acting as a 'context' on off feature that pops up the most appropriate hotkey bar hotkeys in the form of W and R [/quote] Those are far too many hotkeys. Hotkeys are supposed to be used to quickly perform usual but non-trivial tasks from muscle-memory. Given your list, you have 15-17 hotkeys (depends on if you include W and R) times x because you offer several setups. Memorizing that many assignments will take the player longer than beating your game, and that is for traditional memory. Memorizing them by muscle-memory is actually impossible since muscle memory cannot recognize different modi, even less so when they can only be choosen relatively but not absolutely. What's even more, most of these hotkeys aren't even quickly accessible. Sure, the letters are super-easy to reach and the left half of the numbers are also acceptable. But the higher numbers? nope. And to change the setup the player actually has to move his hand over the entire length of the keyboard. In terms of shortterm-memory, the human mind is capable of storing 7 +-2 chunks of information. Even though your case of memorization is long-term, the model is still a good approximation of how much will work. So even if you're sure that a large number of hotkeys will be needed for your game and you also want to keep the separate hotkeys for inventory and abilities, limit yourself to using z, x, c, v for one of the hotkey-sets and 1-4 for the other, maybe adding b and 5 if you really think it's necessary. This will give you a total of 8-10 hotkeys, enough for the frequent tasks and still something that the player will be able to learn. Hope this was helpful, bw, Tobl
  9. Hello, jbadams has made a great overview, if in doubt, go with that one. [quote name='jbadams' timestamp='1352122496' post='4997563'] Although this often shares some amount of overlap with the RPG genre, the major difference is that an adventure game will usually contain minimal (if any) combat. [/quote] The only part of jbadams' post I have a (small) problem with. I'd say that the fact that adventures prefer riddles over combat is more of a symptom than a defining characteristic for them. The main difference imho would be, that in an adventure, the story is the most important feature, whereas in an rpg the protagonist is. Of course there are rpgs with astonishing storys out there, but even in those cases, the most important part for the gameplay experience is the character and how the player connects with him (no matter if the protagonist is a fully developed personality or a blank slate for the player to insert himself into). Also, since we've already got such a great topic on game genres going, there's another pair of genres that I've always struggled with keeping apart: adventures and roguelikes. It'd be really nice if someone could tell me the difference between those two. bw, Tobl
  10. Hello, First of all: What age is your target group? That is very important, since kids could mean 2yo as well as 12 and they're easily as different as a 10 and a 40. [b]Do you think this is a good and encouraging prize?[/b] Simply put: no. Considering my premise about age: maybe for very young children, but I wouldn't use it for primary school or older. Why is that? I see two main problems with this approach: 1) From the child's perspective: They simply aren't interested in seeing a picture. They can get much greater stimulus from watching tv or playing other games without having to work for it. Also, there is no connection between the task they have to complete and the prize they get. Adults have been trained to accept "I have to push buttons on this keyboard in order to eat" (and even in this case there is a connection even though it's artificial), however, kids haven't and don't feel much motivation if the connection isn't clear. Try "you can watch tv after helping with the dishes", no matter how you phrase it, a kid will always see two separate items: the nasty "doing the dishes" and the nice "watch tv". 2) From an educaters perspective: Even if the kid is motivated by just a picture: In your scenario, the child learns that they should learn because they will get a "happy-maker" in return. Actually, a person doesn't aquire such a thing simply by learning stuff. The reason we want kids to learn is that they will be able to do stuff they wouldn't be able to do without that knowledge. In order to to have a solid motivation for learning that cannot easily be broken by outside factors (such as the aforementioned greater sources of fun), a child should understand the connection of learning and being able to do stuff and have that as it's motivation. What could be done instead? I know this may sound like a step back and maybe it is, but bear with me for a moment: First, instead of awarding them with a inherently worthless picture, try awarding them with a point-system. Children either have already learned or are in the process of learning a common system in which a simple number can carry a value (-> money). Of course those points shouldn't come out of nowhere, so instead of giving them a fictional currency (gold-bits, fantasia-dollars) or abbreviated exp. (which is just a random assortment of letters), give them "learning points" or experience (written in full length), which are a representation of the knowledge that they are accumulating in their heads. Now they have a way of measuring how much they have learned (of course their knowledge and points differ greatly, but it's close enough if they can see that both are growing). Now for the second step: Have them understand that their points and therefore their knowledge actually is worth something. The best solution here is, of course, to implement the application of points directly into the game. However, I don't know your game and therefore cannot tell if or how that is possible. But even if that is not possible in your game, you can still utilize the fantasy, more specifically the empathy of the children. You already have a representation of the childs knowledge, why not also have a representation of the child itself? Let them make a character in the beginning. Then, as they gather more and more points, they can buy abilities for their character. Have the child choose between different abilities and also show them such that are slightly out of reach. They don't have to be able to use them ingame, it's simply enough for them to be able to say "Hey, my character is able to identify eadible mushrooms and in two or three days he'll finally be able to speak orcish" (yes, terribly cliched fantasy-setting, but feel free to do something better ^^). Because it identifies himself with the character and choose the abilities himself, it will understand that by learning it will actually be able to become who it want's to be. At least in my opinion, that should be a better motivation than looking at a picture. [b]Can you think of a nice way/effect to reveal the parts of picture ?[/b] I'm not going to answer this right now, because it is totally out of place to begin with. If you're asking whether your general concept is good, don't ask about most specific implementations in the next sentence. If you have thought about my, and hopefully also other's, replies to the first question and still want to use images, ask again and I'll try to come up with something. Also, make sure to watch [url="http://extra-credits.net/episodes/gamifying-education/"]EC's episode on gamifying education[/url]. The methods may not be directly applicable to an educative game, but try to understand the underlying reasons why stuff is being done that way and why it's assumed to work. Those reasons most certainly are applicable. bw, Tobl
  11. Hello, [quote name='Abrahman McGuyenski' timestamp='1352047385' post='4997211'] Hi everyone, I hope I'm posting this topic in the proper section. [/quote] Unfortunately not, this belongs in "Your Announcements". bw, Tobl
  12. Hello, In my opinion, this all depends on where you draw the line between art and design, so I'm going to start with that question [b]Do you see any difference between design and art?[/b] While there are many ways to separate these two, I do so according to the motivation that led to the creation of the design/art. Design is being done because of a need from outside the creator, whereas art is being done because of a wish from inside the creator. A little more controversial example to demonstrate: If someone paints a painting in order to have something he can sell so that he has something to eat, even though the buyer intends to hang it on his wall as "art" it actually is design, because the creation was triggered by the need to eat that came from outside of the creator. [b]Would you consider a game interface an art? Why yes/not? If yes, can you show/tell any examples?[/b] Generally speaking: No, since it's clearly being created because of the need to have interaction between the player and the game. However, games themselves are much more likely to fall under my definition of art (not all of them of course), so if you take an artistic game like [url="http://www.ludomancy.com/games/today.php"]Today I die[/url] where game and interface are pretty much the same, yes, you might argue that the interface is art. [b]Do you have any background in arts – university/hobby…?[/b] In arts? No. But I am studying interaction design (design of user interfaces and, to a lesser degree, user experiences). [b]Can you imagine a sole game interface hanging/running as a video in a gallery at some point in the future?[/b] No. Just as a still image cannot convey an artistic movie, a video following a predefined course cannot convey the interactive nature of an artistic interface. I could, however, imagine hand-on-exhibits, on a small scale of course. [b]To what extend do you think is game interface an integral part of a game?[/b] I know not many will agree with me on that, but theoretically speaking are the interface and input about as important for the player-to-game channel as visual style and aesthetics are for the game-to-player channel. Actually they're quite similar; both are mainly noticed as dissatisfiers (you notice the unbelievably ugly character design of a sidekick or the impossibly counterintuitive button-layout), but if done exceptionally well they may define the entire atmosphere and experience of the game. Yes, I know, interfaces are kinda lacking on "exceptionally well"-part, but I do believe it is possible or else nobody would have ever bothered with the Wii and all the other stuff that came after that. [b]Do you consider a game art an art?[/b] Given my definition of art and design, that depends on the individual case. I'd say both can be found in current game art. --- [b]If you work as a user interface designer/game designer/artist, could you also please answer some of these questions:[/b] I'm just a university student, but I'll do these as well if you don't mind. [b]Where do you work? (company name or just industry is fine enough)[/b] Hochschule für Gestaltung Schwäbisch Gmünd ("University of design" Schwäbisch Gmünd), in Germany [b]What is your process? (do you think it is closer to a designer or an artist)[/b] I'm definitely a designer. The process we use most often is a semi-standardised model consisting of research - concept - design - prototyping - evaluation and many iterations back and forth between the different stages. [b]Have you ever been mistaken for an artist if you are a designer (or vice versa)?[/b] Fortunately not, but I'm pretty sure I'll be in the future. Other common misconceptions we have to deal with are that every designer does fashion or marketing. [b]Have you ever considered you could express yourself with user interface? How did it go? Can you show/tell me?[/b] Most of the time we deal with design assignments. I did try to insert personal preferences in there before, but those experiments have shown that that's not an advisable approach. If the problem comes from outside the designer, the solution should be based out there as well. However, I have at least one private project of which I chose the goal myself and that is certainly an expression of my own desires, even though it still covers an (admittedly not all that common) need. Hope I could help you with your paper, bw, Tobl
  13. Hello, Could you [i]please [/i]keep it down? I've seen you advertising this tool on three dedicated threads, all of which were bumped today. Additionaly, you've posted it in no less than three of the pinned threads of which only one is dealing with software (the other two being about tutorials and assets). @JTippetts: Of course this is your decision to make, but is this really considered neither spam nor crossposting? I would have thought at least one of them would have taken effect by now. bw, Tobl
  14. Hello again, @nsmadsen: wow, my arguments surely got ripped apart ^^. But after all, that's exactly why I was so eager and at the same time so hesitant to post them (eager to hear other's opinions, hesitant to misinform others since I don't speak from experience). I can see many of your points, other's I'd still disagree with and very few we've simply got our wires crossed, but we've both made our points, so I won't go on about that and instead simply say thank you for helping me understand the people that like ndas a little better. bw, Tobl
  15. Hello, @ Bakuda: I'm sorry for taking this a little offtopic.[s] I will move this to a new topic if the discussion should grow any further, but please bear with me for the moment.[/s] I will start with the less radical part of how NDAs hardly give you any advantage: - First of all, nobody forces you to make all your content public. Just say "hey, I'm making this <short description> game, contact me if you're interested", you don't need an nda to do that. - Of course the nda is mainly about that person then revealing all of the content. Fortunately, our brains are quite capable of evaluating whom we can trust. If the other one is someone trustworthy, you can simply ask them to please not reveal anything and they most likely won't. If on the other hand the other one is someone out to screw you, they will do so with or without an nda, there's always a way. - The above is even more true considering that an nda is nothing but a piece of paper with a little bit of ink applied if you're not willing or able to enforce it. If someone actually breaks the nda, it will cost time, energy and money to actually hold them accountable for that. Even if you are willing to move time and energy from the gamedevelopment to the courtroom, being an indie-team, you most likely won't have the funding to pay a lawyer. - "But what if someone steals my idea?". That is certainly the most-asked question in this context. And even though it's been said countless times, let's repeat once again: ideas are cheap. They're a dime a dozen and anyone working in gamedevelopment has more ideas in their head than they'll ever be able to produce. What makes a good game is the execution, not the initial idea. The only reason someone in indie would prefer to steal your idea instead of working together or making one of his own, is that they don't have any. But if that is the case, they'll hardly be capable of making that idea into a game any better or faster than you. - The other main reason for NDAs is marketing. The trick with mystery-marketing however is that, while no one knows what the answer is, everyone knows that there is a 'mystery' (in this case, the content). The big industry can pull that off pretty easily, they can just push content into the media until everybody is sure to have heard about that at some point. Indie teams on the other hand do not have the budget for that and mainly rely on word of mouth advertisement, and it's just really hard to get people to say "I've seen this cool upcoming game. I've never heard of the guys who make it and I don't really know what it's about, but you should definitely check it out." Maybe there are examples where it worked and it would be great to hear of them, but most of the time, indie-gaming is still too small and at least I wouldn't know of any cases where that really worked on a large scale. Now for the real deal, why is it actually bad for development: - Methods and standards have evolved in game design and continue to do so, but in it's core, it is a creative process. And like any creative process, it relies heavily on the dynamic within the team and the motivation of the individual members (even if money keeps them working, motivation is what produces quality). NDAs damage these dynamics by introducing yourself with two basic premises: Even though you might make a 180°-turn from outside the team to inside, the very first connection between the team members on which anything else is built will be distrust. Secondly, even before the new guy is joining, you define an unhealthy hierarchy: You are the boss and you alone decide the rules under which one might work with you. While I certainly don't say there shouldn't be any hierarchy at all, the role of the team leader should be a supporting one, not the bad boss that want's to control everything. - While there might not be many that are higly opposed against ndas in indie-teams, the simple fact that they have to make quite an effort to only view the most basic content of the game and thus even consider joining the project is a huge inconvenience for many people when looking for a team. The result is that quite a few of them simply won't and stick with a project that tell's them what they're up to from the beginning instead, resulting in fewer that are even contacting you. Those that do contact you are then likely to contact the other teams with ndas as well, resulting in them having lot's of options which project to join. All in all, it will result in you having a much harder time finding members than you would have had otherwise. - As Katz already said, this will also take away the exchange with other developers and the community. While many might do well enough without input from other developers, a quick glance at the gamedesign forum shows that most of the people that ask for advice there get tons of ideas they wouldn't have ever thought about on their own. Even more important might be that this doesn't apply to design-questions only, but also to tech-questions. So especially if someone on the team is inexperienced or trying out something new, they won't be able to ask "I'm trying to <do this>, how do I accomplish that?", making work much harder for them and lowering the quality of the product. - Finally, a game idea evolves and changes heavily during production. While it's always good to have a design document, an nda requires you to have a very detailed one so that as many of your ideas as possible are covered by the nda, and then reinforces the notion that those ideas are "worth protecting". This leads to a very static design process, where many deferring roads remain unexplored and lots of potential goes unused. TL;DR: Lot's of reasons why one person believes that NDAs are bad for indie teams. [s]If you think this topic is worth further discussion, please send me a pm and I'll port what we have now to a new topic in order to avoid spamming this thread.[/s] bw, Tobl