Making, Selling, and Thinking Indie Games. draft 1
Miscellaneous Forums/General Discussion/Making, Selling, and Thinking Indie Games. draft 1
| ||
| This is really long. And is a first draft. This is not -just- for blitz, so I wanted to get feedback. Tell me I am wrong, tell me I am great. Tell me I spelled something wrong or screwed up basic grammar. Tell me what I should include. Tell me what I shouldn't. Tell me to STFU. All your input is welcome. Even the insulting stuff. Also!.. Important. There is no citation here. If you made, know who made any of these things and think they wouldn't wanna be included in this essay. Tell me. I'll find another example. Making, Selling, and Thinking Indie Games. Indie games are indie. Seems pretty straightforward, no? It is surprising how most indie games try to follow the same sort of rules as the big guys follow. The same rules that don't really work for them either. In this essay you will learn what seems to actually make games sell, how people find games, and what it should be alright to cut and still have a fantastic and well-done game. What are the big companies really doing? When you look at the big-boys you see several things. First, you see that they try to push their graphics as hard as they can. They go on and on about them on their boxes and in ads, and they put forth a lot of cash on them in the first place. Secondly, you see that they focus on one or two major gameplay hooks to try to grab the box-reader. “With gravity gun” or “Over 500 skills!” Things that might sound a little interesting or impressive. Lastly, you see that it all works for them. Or does it? What we miss when we look at the box, is the chain of events that brought people to the store in the first place. While a large number of people do just walk into the store and buy whatever game looks cool, most of them are children or adults buying games as gifts. Relatively few people wander into the store and drop a small fortune on a brand new game without some kind of forethought. There are several major kinds of game buyers; First-dayers, Heard-from-a-frienders, Read-in-a-reviewers, Follow-the-hypers, Bargin-hunters, and I'll-buy-anythingers. First-dayers are the kinds of people that buy games the day they come out, they are into the culture of video games and they are the ones waiting in line to buy the next game in a series. They aren't, however, followers of hype in most cases. Their purchase might overlap with something that is hyped, but they will not buy it just cause others are excited about it. They buy it cause THEY are excited about it. Heard-from-a-frienders and Read-in-a-reviewers and any other 'like' kind of buyers are the ones who do research before they buy a game. They know that games in a series can end up being terrible, and will always wait to see if it is good. In addition, they will be open to games that are normally outside their sphere of exposure should someone they trust really sell the game on them. Follow-the-hypers buy whatever is totally hot. They will be happy to drop 60 bucks on the next big thing, simply because it is the next big thing. Be it 'Doom 3', or 'Quake 4', they are out there scooping up these games like they are candy. Gloating that they got their hands on it, and about how amazing it looks and feels. Next up is the Bargin-hunters, they wait for things to cool off. Could be representatives of any of the other types of buyers, but they rarely buy a full price title. They enjoy getting a great game for a great price. “Startcraft Battle Chest for $10, I'll buy that!” I'll-buy-anythingers aren't those who will really buy anything, they buy anything in their sphere of exposure. Like the stereotypical RPG nerd buying any and all RPGs that come out. Like the sports gamer buying every version of 'Madden', or the wrestling fan who buys all the games. These gamers just buy games that interest them in the store, and they don't even care that the game sucks when they get it home. They are happy with their copy of '50 cent: Bullet Proof' and you can't convince them it was the worst game to come out on the PS2. “Pokemon Black? Yes, please.” What's this all mean? Most people don't buy the game cause the box has pretty graphics, they don't buy it cause it has this that or the other gameplay mechanic listed on the box. They buy the game cause they read about it, heard about it, buy all the like games, buy anything that has those characters/assets in it, or because they think their friend/child might like it. Only a few people buy it cause they were sold on it through the box. The big companies are out there generating hype, making sure the game has the right characters or settings, and making sure it looks good, because there are a lot of people that buy games cause they look good. They are sending copies of the games to reviewers, because a lot of their buyers come from good reviews. They are out there letting people play the game, cause a lot of people buy the game if someone says they played it and liked it. So what am I doing wrong? Indie game designers seem to focus on all the wrong things. The new and fun ideas tend to get ruined with bad design choices and there are loads of lame clones and examples of established gameplay models with new twists. In short, it isn't any different than the big boys. They spend a lot of time and effort on fancy graphical touches and other things that are secondary to gameplay. They do this, because they are told that they need these things by portals and their peers. Is all that true? Yes and no. If you really want to sell your game on a portal, which is like a store that has some minor review abilities and even some user feedback, that is fine. But remember, it isn't the box that sells the game. A good outlet is going to promote your game, at least to the people shopping at that portal, perhaps outside it. But they are again, just showing off the box. You might get reviewed by an indie reviewer with little or no mainstream credit. You might even sell a few copies. But you really aren't reaching your full potential as an indie designer. Unfortunately, it is already too late for that game. Is there a better way? Let us take a look at the types of game buyers, and how they present themselves online. First-dayers, and in most cases Bargin-hunters don't really apply. Sure, you can argue that someone paying $10 for your indie game is bargin-hunting, but they aren't. A bargin is when you are getting something for less than it is worth to you. Paying $10 for a basic 'bejewled' clone is not a bargin. Most people will find your game when a friend tells them how fun it is, or when a reviewer they trust tells them. Surprisingly, they don't care at all how the game looks. Don't believe me? One word. 'Snood.' Want another example? 'Drug Wars.' I can go on. These gamers aren't out to be wowed graphically, and lets face it, you really can't get close to what the big boys can make. Follow-the-hypers exist online too. They play Habbo Hotel, and Furcadia. They tend to be younger, and they don't have a lot of money, but given the chance, they will drop $125 to put dragon wings on their cat-person. Don't under-estimate these people, they can make your game a success. One of the biggest groups online are the I'll-buy-anythingers. Funny, indie developers seem to fall into this category a lot, many will by anything just because it is indie. You find people that will buy all the puzzle games they can get their hands one. Or the misunderstood market of 'free' games, where people pay by clicking on ads and paying other people. Want to make a platformer? Make it fantasy themed and you'll find a lot more people are willing to buy it. What can we learn from these buyers? That they aren't stuck on the traditional 'I pay you once, I own game.' model. The hardest part of getting an indie game to sell is getting people to play it, then buy it. Most people don't like demos. They are a waste of time and serve more to tease you than to be fun. People only use them when they are already considering buying the game. Unless, like 'Snood', the demo is fun. In which case it can get passed all over and become more like shareware and still generate some money. At the same time, most people won't buy the full version, cause they already get the milk for free. (I'm ignoring the sneaky things that Snood does additionally.) How can we maximize our potential? Start with the payment structure. Ad driven browser games? Mini MMO that lets you buy things for your characters or otherwise play for free? Something that works for you. Payment shouldn't be an after-thought. There should be a way to play the game, preferably in it's entirety, that works into your hand. For example, 'Furcadia' is free to play, but if you want new things, you have to pay them for it. Few people are willing to pay a lot, but the ones that are, might drop over $500 in the long run. You could release the first chapter of your game for free, the entire thing. Then charge for all the later chapters. If people are hooked already, they will keep paying for more. Make sure your game doesn't suck. Obviously, graphics are the only way to make some 'bejewled' clone stand out. The alternative is adding in new gameplay mechanics. This might work out for a really simple game, and it might sell well. Still, is it a 'bejewled' clone. Be really creative, it is said all the time “Ideas are a dime a dozen.” So pay the dime for the bundle and actually use one. It seems like the indie games that get finished are all clones, bad ideas, or otherwise lame. If the game sucks, few will by it, if the game is fun, many will. You know what a fun game is, step back and just play your game. Use stand-in graphics, make it look terrible. If the game itself isn't a blast, you can't expect it to do swimmingly. Keep in mind your payment scheme. A great idea is to offer lots of content and a complete game, but offer bonus content and extra aspects to the game through payment. Don't focus on the box-cover saleability of your game. Yeah, on a portal it will mean sales. But the big bucks aren't on the portals. The game doesn't have to look good to be fun, so don't focus on that. At the same time, don't add in new things just because they will look good on the website. Just Don't. Put the extra effort into the gameplay. Create more meaningful content. If you have the time and money, it can't hurt to have good graphics, but it is far more important to be a good game first. Market properly. Your game is done, but people can't buy it unless they know about it. Marketing don't just mean getting people to the site, although it could mean that if the site will absolutely get people to give it a try. It means getting people to play the game. It could mean burning discs and handing them out on the street near a game store. It could mean posting 'fake' stolen versions on warez sites. It could mean anything that gets the game into the hands of people to get them to play it. If the game is fun. They will tell their friends. It is as simple as that. Leaking a few 'beta' versions that lack a lot of the later content can be more effective than any demo. You are indie, so you have to be indie. You can't play everything straight. Obviously you can't break the law, but none of these things do. You have to think like other indie art forms. Indie films screen their movies for free anywhere they can. Indie music does a lot of the same. Viral marketing and word-of-mouth is all indies have to go on. Even a portal is a form of word-of-mouth. Don't get caught up in being professional. Feeling grass-roots and down-to-earth is what makes indie appealing to people. If you can get the fans involved in making the game, that is even better. This is another of the things that 'Furcadia' does. You can use the user to make most if not all of your content. Few indie games do this, it is being pioneered by the big guys, which is completely backwards. The best example of this I can give is 'Naked War.' Unique payment plan that allows you to play the entire game for free, oodles of word-of-mouth, a real indie spirit, great gameplay, and on top of it all nice-looking graphics. 'Naked War' is indie in the way that things should be indie. It has a grass-roots feel. It is all about community growth and user input. This is what indie games should be. It is too bad that most aren't. |
| ||
| I guess my first question ( without having read anything beyond your introduction ) would be "Who is the author and why should their thoughts mean anything to me?". I would expect the article to tell me this pretty early on, because everyone has opinions, and can write an article. I want to know if the opinions are just for a little entertainment or if I should pay attention. As I said, I haven't read it, so I have no idea if you cover it or not, but if you don't, you probably should. |
| ||
| You have a typo! Search the page for "startcraft" and you will find it. Nice article! Really helpful :) |
| ||
| Thanks Gabriel. It wouldn't be a bad idea to talk about myself. Tho.. haha.. I bet it would make it LESS important.. hehe. Thanks Picklesworth. I was actually expecting to get a lot of bad feedback... Just.. cause.. you know.. That's all I get here. |
| ||
| The new and fun ideas tend to get ruined with bad design choices and there are loads of lame clones and examples of established gameplay models with new twists. I couldn't agree more. And it's because when you have 1 person writing/coding the game solo, he's just assumes his ideas are great and goes with it. He doesn't ask for feedback and if he does he takes the criticism personal and doesn't make any changes anyhow. That's a huge drawback to indie games made/designed by the solo coder. Two heads are better than one...no doubt. EDIT: It seems like the indie games that get finished are all clones, bad ideas, or otherwise lame. YES!! You're reading my mind! And the ones that get finished are clones because...no one takes the time to come up with original game ideas! Sometimes reinventing the wheel is a good thing... I have the ability to create a clone of successful puzzle game very easily. But I'd rather come up with something original. Even if it means never releasing a game ever in my life. |
| ||
| I'll agree with you there. But it isn't always just that. Sometimes what is easy to code, I mean, like 10 lines of thoughtless nothing, really should be replaced with 1,000 lines of really hard code. The only reason to bother is to make the game better. That reason isn't always enough to expend that much energy. You might say to yourself. "I know it would be better if these sprites lit-up or outlined when you hovered over them... but it isn't so bad." meanwhile.. someone playing the game might say. "WTF am I supposed to do!" Small things can kill games. Which is why we should all really be trading design documents. Some of us should be writing them, cause we really think these things out. And others should be making the game from it. Cause their ideas aren't that good and they lack the focus or attention to detail to really get it 100% right. After all. What does it cost to give someone credit. I'd gladly give away a game idea for a name in the credits as the 'lead designer' That's a big deal, and can mean big things. The guy who made he game can keep all the profits. 5-10 of those will get me a really nice job. I'm going on the record saying I would do this for anyone here. And this one is free. My name is William Brall. Just drop me a note saying you made it so I can put it on my resume. www.dampes8n.com/novellachronicles-designdoc.doc |
| ||
| Not a bad article, although I've got a few qualms with parts of it. Don't focus on the box-cover saleability of your game. Yeah, on a portal it will mean sales. But the big bucks aren't on the portals. The game doesn't have to look good to be fun, so don't focus on that. At the same time, don't add in new things just because they will look good on the website. Just Don't. Put the extra effort into the gameplay. Create more meaningful content. If you have the time and money, it can't hurt to have good graphics, but it is far more important to be a good game first. Market properly. Your game is done, but people can't buy it unless they know about it. Marketing don't just mean getting people to the site, although it could mean that if the site will absolutely get people to give it a try. It means getting people to play the game. It could mean burning discs and handing them out on the street near a game store. It could mean posting 'fake' stolen versions on warez sites. It could mean anything that gets the game into the hands of people to get them to play it. If the game is fun. They will tell their friends. It is as simple as that. Leaking a few 'beta' versions that lack a lot of the later content can be more effective than any demo. You are indie, so you have to be indie. You can't play everything straight. Obviously you can't break the law, but none of these things do. First you say, don't worry about the "box-cover saleability," which in the case of indie-games comes down to screen-shots and unique selling points that can be posted on the portal page, but then you say you've got to do whatever you can to get the game into players hands. While I agree with the latter point, I kind of disagree with some of your suggested solutions. Posting your own leaked copy of the game isn't actually going to get people to download it, unless it looked interesting in the first place. Even putting games on a disc and handing them out to people won't work in a lot of cases. I don't know about you but whenever I'd get a free Demo CD with some magazine, I didn't install all the demos and try them out - only those that I had read about beforehand or those that were already highly hyped. The rest I just don't have the time to bother with. And regarding your statement "most of the big money isn't on the portals," well, as far as I know that's just patently not true. I think that's the equivalent of saying that "most of the AAA titles aren't sold in stores but are sold through direct download" or something. While it is true you can make *HUGE* sums of cash venturing in a new direction -- Furcadia sounds like it's doing well, and I just know "Adventure Quest" and "Dragon Fable" must be making a killing, their page rankings are ridiculously high for an "indie-game" and their design leads to little overhead costs (no multiplayer servers, for one)). So while I agree that venturing out into new territories can be highly profitable, there are obviously no guarantees there. And it's just not possible or even desireable for every game to be adapted to fit into some different pricing model, IMO. The #'s tend to show that the casual market is dominated by older women, and I think the numbers would also show that most of them just want a game that is fun and cheap that they can pick up and play. While there is a market out there that'll play a game that is free but offers the option to purchase special abilties, items, whatever (or often-times as it is, more or less "requires" said purchases if you really want to be effective or see the whole game), there is also a large market that would be turned off by such a pay scheme. Anyhow, I'm not an authority on the matter by any means. If you want much more and much better feedback, I'd post this over at the IndieGamer forums - (http://forums.indiegamer.com/index.php?). There are a couple of guys over there that live quite well off of their indie games revenue, and there is a big divide between those who are portal supporters and those who think portals are the devil. Anyhow, there are just a lot of guys over there with finished games and a lot of real-world experience and they'll give you the best feedback. Prior to that though, here's a few nit-picky things bargin should be spelled "bargain" also, this line Marketing don't just mean getting people to the site, should read, "Marketing doesn't..." Despite my feedback I thought it was a good article and tend to agree with most of the points (I'd love to see fewer clones and such), yet, I think you are sort of taking a naive idealistic look at things. It's just one of those things that's fairly easy to say, but when you're going to put in 60-80 hours for the next 6, 12, or 18 months, it's a lot harder to ascribe to and take such a big gamble by going with a new and innovative game/game-mechanic. And even the best of ideas still might not translate to fun - capturing fun is an elusive beast - and that's why people are so content to do a spinoff of a formula that is already known to be "fun" (at least to their target market.) |
| ||
| It's a nice article, but what's the point? I mean, I hate to be blunt, but you're not saying anything new or profound. It just comes across as a mix between idealism, bitterness, and simplistic "common knowledge". Also, by writing There are several major kinds of game buyers; First-dayers, Heard-from-a-frienders, Read-in-a-reviewers, Follow-the-hypers, Bargin-hunters, and I'll-buy-anythingers. you are potentially alienating and offending almost every section of the marketplace, and you come across as somewhat jaded and condescending. Your potentential user base may well consist of fan boys, lemmings, skinflints, and people who possess no critical faculties, but it's generally a good idea to leave this as an unspoken truth. I have problems accepting advice from someone who doesn't understand this. Also your prose style is somewhat clunky. For example When you look at the big-boys you see several things. First, you see that they try to push their graphics as hard as they can. They go on and on about them on their boxes and in ads, and they put forth a lot of cash on them in the first place. Secondly, you see that they focus on one or two major gameplay hooks to try to grab the box-reader. “With gravity gun” or “Over 500 skills!” Things that might sound a little interesting or impressive. seems to be more message board casual than journalistic article. |
| ||
| It is a first draft. Don't forget that. Points taken. I had planned to re-name the types of buyers. Got any replacement names in mind? SOS I hear you, this is more an inspiration kind of thing. I hope to inspire more indies to take the chance. Making a clone might be 'safe' but it also has no realistic high potential. It is kind of like the difference between putting your money in the bank at 2-4%, a mutual fund that averages more like 10% and playing the stock-market which has crazy-high potential. The safe bet isn't really the right choice for most people, but neither is the risky one. The right bet is the mutual fund, which is still a gamble, but which isn't a particularly crazy gamble. You can argue till you are blue in the face that a tetris clone can make you a fortune, the odds of this are so slim that it isn't worth even considering. At the same time, something really off the wall, experimental and costly isn't a great bet either. But doing "some" of what I laid out in the article is better than doing none of it. If you are going to make a tetris clone, at least add some new features. Give it something to set it apart. And find a new way to make money off it. Perhaps the idea is to build a really slick and smooth flash version, one that is really smart and not clunky like 99% of all the flash tetris-clones I've played. Then make your money off ads. Advertise in a new way. Also. I will agree about magazine demo-discs. But I wasn't talking about that. I was talking about walking up to people and telling them about the game, saying you made it, and giving them a demo or 'beta' version. I like the 'beta' thing cause it seems more interactive to regular people. They feel like they might be able to help out somehow. Alternatively. You could risk minor law-breakage and leave copies of the disc in places for people to find... For example. Label them in sharpie with "Top Secret. Pre-Beta -name of game- disc." Or something like that. Walk into bestbuy and install it on all the PCs, then load it up and leave. Or do the same in other places that have internet access on their in-store PCs. (One of the ways I am promoting www.omgwtflmao.com is by loading it onto the machines in apple-stores, radio-shack and other places and then leaving.) These things are 'limited' in their initial scope, but build a base of fans that don't feel like they were advertised to. They feel like the found it. They feel ownership in that. This is what viral-marketing is all about. |
| ||
| Well, if I were you, I'd cut out everything from (roughly) "There are several major kinds of game buyers..." to "... “Pokemon Black? Yes, please.”", and replace the next paragraph with something like: "Few people are influenced by box art. They make purchasing choices based upon the reputation of a product (for example, they might make decisions based on the advice of friends or on the recommendation of a reviewer), because it is a part of a trusted brand (for example, if the product is a sequel to a favourite game, features familiar characters, was created by a respected designer, or released by a favoured publisher), or because it is familiar (for example, in terms of genre or gameplay mechanics.)" However, bear in mind that if you are going to make sweeping generalisations then you need to provide evidence to support them - evidence and references help seperate facts from opinions. I hope this helps. |
| ||
| Good point raised by Gabriel - why should I read your article, unless you can summarise your actual experience and background of developing, releasing, marketing and actually selling games? Have you actually got this experience, and can you back it up? |
| ||
| Have you made and sold games yourself DampeS8N? |
| ||
| Those who can, do. Those who can't, teach. |
| ||
| It was a genuine question BTW. I wasn't insinuating anything. |
| ||
| Noddy land. I would simply discourage everybody from wanting to make games. Would? I mean I do. But if you're already there then I wish you all the luck. ..and you can't write an article like that and expect it to be of any real use to anybody unless you've been there and done it. It's worthless otherwise, except as a work of fiction or bare-faced plagiarism. Having said that, it was just about worth the read if only for the subjective viewpoint. |
| ||
| I thought it was a fairly good article and had some interesting perspectives about types of buyers and their mindset that I didn't know about already, so in that sense your article is successful. I agree with the idea of initially providing a large bulk of your product for free. You can always supply extra content later at a price. I think this reflects also a more spiritual mindset where you are more open to sharing, have more interest in including the audience in the product, and show that you give the user something to empower them and inspire them to be creative themselves. I think this is the approach I will take with my future products - releasing the basic platform and toolset free and then developing content later which would have a fee attached, on the same grounds as the user who could just as easily create content and sell it. I don't think it particularly helps to set yourself up as someone that others must become a `follower` of, although some people are surely intent on idol worship. I think overall I would design my business model and approach to a product based on what is correct spiritually, rather than what someone has devised based on making profits or being popular or whatever. |
| ||
| How can someone write an article on something they have no experience of? Genuine question. First rule of writing: write about what you know. |
| ||
| I think overall I would design my business model and approach to a product based on what is correct spiritually, rather than what someone has devised based on making profits or being popular or whatever. Recipe for disaster. |
| ||
| Recipe for disaster. I don't know if I'd go that far...but even spiritual people need to eat. |
| ||
| No they don't. Everything they need is provided by their deity. |
| ||
| No they don't. Everything they need is provided by their deity. What, so they don't eat the food that their chosen deity provides? How rude! Seriously though, I agree with the points made about 1) making clear your own background to help the reader understand where you are coming from, and 2) what value are you adding to the subject matter, if you don't have any/much experience of the subject in hand? I don't disagree that such an article would be very useful, but maybe it should be written by pooling knowledge around here, rather than writing "off the top of your head", as could be implied from what you've said so far... |
| ||
| What, so they don't eat the food that their chosen deity provides? How rude! How about interrupting Him with prayer every Sunday! On his day off! That's just inconsiderate.Seriously tho' I think people would do just as well reading some of the more traditional books on marketing (like Geoffrey Moores Crossing the Chasm and it's follow ups or Michael Treacy and Fred Wiersemas The Discipline of Market Leaders). No offense to the original poster, although he does seem to make a few statements that collide with conventional wisdom. I mean if marketing where a democracy, sure I'd vote for DampeS8Ns version as well. |
| ||
| Gotta say my thoughts were the same as Gabriel's and John's but I didn't wanna post that in case you thought I was "in competition" or something having written a few articles about Indie gaming myself. As of yet I haven't read it either, sorry. Might do later...Anyway it's good to write stuff, hope you enjoyed it and didn't get too cynical (that's so been done before ;-)) |
| ||
| It is mostly about applying viral marketing, indie film and music marketing techniques and the 'attitude' of 'indie' to indie games. Some people seemed to enjoy it. But the people not reading it right off the bat are the people I want to. I do have substantial expirence in the fields I described above. So I can list that information too. I like JustLuke's idea to take out the whole 'kinds of buyers' section and replace it with something shorter. Unless someone else objects? In which case I can go with my first plan and change their names. I don't know if John Pickford is gonna come back to see my response to his question or not. If so. No, but like I said above, it is more about how to sell the game, make a game that is indie, and be indie. Which is exactly what you've done with Naked War. When I got to the end of the article I looked over the Naked War site to gather information about it. I noticed an article that I went back and read. Do you mind if I use it has a reference? It also talks about a lot of the same things I do, and you are a hell of a lot more credible than me, likey from all standpoints, certainly from games. Lastly. You have to understand the difference between who is buying what exists, and who is willing to buy what could exist. I'm told a lot that the casual games market sells mostly to lower-middle age women. Did you ever stop to think why? It should be anything but. They aren't the people who are online the most. They aren't the people who go out to a store and buy a brand new game off the shelf. Personally. I think it can only be explained by the rest of the game buyers rushing out to buy AAA games. Pay more for more quality. And why is that? Cause indie games doesn't mean the same as indie music. Indie music means there isn't some big producer hanging over them telling them what to put in their music, how to sound, even writting music for them. It doesn't all sound the same, cause they have the freedom to be different. Indie music is about talking to their fans, it is about getting feedback and playing small shows. That is what indie should be about. And that is what we THINK indie games are about. But they aren't. They are about clones, bad graphics, cut corners and shallow simplistic game play. Something only a complete novice to games would buy cause it is cheap and looks cute. Who are complete novices to games? Oh.. Middle aged women. It is a symptom of the disease, not the target market. Indie music doesn't just cater to one kind of person. It caters to every kind of person. The only people that don't listen to any indie music are those who only listen to music casually. Think about how ass-backwards indie games are. Where causal music listeners are the ones who listen to label music on the radio only. Like when they drive. Or in a club. Or maybe they buy an album once a year. And everyone else is perfectly willing to listen to an indie band to see if they are cool or not. Meanwhile. No one will even look at indie games, unless they are casual gamers and just want something that isn't fun to play for more than an hour. Same with Indie films. Indie films are doing better and better at the Oscars, in theaters and on DVD. Sometimes they come out in the wrong order. You'll see the DVD, it'll sell really really well and they will release it in the theaters. There was a day when 'direct to video' was exclusively bad. Indie games is supposed to be like this: Deal with topics you can't normally touch. Be a little or a lot grass roots. Have flexible payment methods, or new ways to make money. Experiment with gameplay. Be new, fresh and different. We want so hard to be both indie and AAA. I think it betrays both. The problem is that any musician can get some tracks cut, not any designer can finish a game. In that regard it is more like indie film. But indie games aren't even like that. Indie films get help from all over, they can raise small sums of money from hundreds of people. They might have many novice hands on set to do minor things. Indie game designers don't do this. They tackle it all on thier own. Hmm.. There is something else I should add in, perhaps. A section about teamwork. |
| ||
| The casual game market is mostly women aged 40-60 who like travel, pets, and gardening. You can lump indie developers into 2 categories. The talkers and the doers. If you're considered a talker and you write an article about how to make a game, then the doers are gonna get offended and say "how dare you!?". While there is some value to that response, it's a tad egotistical. Especially on these forums where everyone is generally in the same boat, rowing to the same successful game paradise. It's the talkers you have to watch out for though. Anything super cool, groundbreaking, and exciting will come from that crowd. =P |
| ||
| Add in a section about why most people never finish their games. Due to laziness, lack of focus, lack of determination, and most important of all, the fact that maybe making games isn't your forte. If you never get a game finished, and you're looking for your special talent that you'll use to create a successful future, then maybe game programming isn't it. You should move on and keep looking for what you can put your heart and soul into. |
| ||
| I'm told a lot that the casual games market sells mostly to lower-middle age women. Did you ever stop to think why? It should be anything but. They aren't the people who are online the most. They aren't the people who go out to a store and buy a brand new game off the shelf. it's more upper middle age, or maybe middle middle age. Anyway yes I have thought about it. These are the people that like off-line games like crosswords, wordsearch, jigsaw puzzles, sudoku etc who have money and who don't pirate games and who don't want to play violent games. They are well off, have computers and like playing buying and playing games. They won't buy some Indie developer's amazing shooter or physics inspired thing that all the coders think are cool, they'll buy a well polished addictive puzzle game perhaps with a cliche theme.Really there's a problem with definitions. Indie may mean people making freeware shooters, or retro-remakes, or weird experimental games or casual games that are invariably clones. Guess which sort sells the most? Should that be your only critera for makeing a game? Of course not - it depends on who you are and WHY you are making a game. Are you making it for fun as a hobby? If so, great do what you feel like - do it for art. Are you making a game for a job? Yes, aha, well try to combine your art with sensible market research and business sense so that you can continue in your job for many years. Pretty obvious really... |
| ||
| Hmm, I don't want this to come off sounding mean but (imho), there is sooo much wrong with your article I don't even know where to start. Also, a point to make about the Naked War creators - they have made like TONS of games over the last 20 years or so, so I suspect they know a little bit more about game design than your "average" indie developer... |
| ||
| And they were very successful doing exactly what I described here. Or at least most of it. Lets see. Atypical payment structure that offers free play to those who want to try the game out - check. New, or at least re-thought gameplay - check. listening to fans and having a grass-roots feel - check. |
| ||
| A snippet from an article by Nick Tipping (of MoonPod Games - who've just released their second game, Mr Robot) posted on the TIGSource Forums: There are a lot of people who want to be indie developers, and have been trying to finish their first game for years. That doesn't stop them posting on forums. Within a few months of releasing our first game, most of what I had thought to be true turned out to be complete bollocks. If I'd have been posting before we had a game out, I'd have been talking a lot of rubbish. |
| ||
| Grey, what's wrong with the article? Is it because he doesn't have a game on a portal atm? |
| ||
| Grey, what's wrong with the article? Is it because he doesn't have a game on a portal atm? No, just some stuff like this:"But remember, it isn't the box that sells the game." "Paying $10 for a basic 'bejewled' clone is not a bargin." (depends who you are) "Want to make a platformer? Make it fantasy themed and you'll find a lot more people are willing to buy it." "Most people don't like demos." "Obviously, graphics are the only way to make some 'bejewled' clone stand out." "It seems like the indie games that get finished are all clones, bad ideas, or otherwise lame" "But the big bucks aren't on the portals." (... this one is hilarious.) "The game doesn't have to look good to be fun, so don't focus on that" (again, depends on who is buying.) "It could mean burning discs and handing them out on the street near a game store." Sorry, I'm not going into why - it would take too long. Like I said it's just my opinion so you know think what you like :-) It's good that DampeS8N is thinking about stuff and writing and I don't want to discourage him. |
| ||
| I think he's taking a more chivalrous approach. Sadly, sometimes it IS the box that sells the game. Then you get home, install it and want to return it but can't. Hasn't happened to me personally though. I do a LOT of research on a game before I put down my cash. Personally I've never bought an indie game...because I just haven't found one good enough. /shrug I would say most indie games are someone trying to cash in on a popular game. There is some truth to that. My current game is a sort of match type game. Most games are clonish in nature. There are very few original ideas coming in these days. Video game ideas are showing their age. There's only so many ways you can skin a cat. Plus it's more profitable to make a game in the likeness of an already successful game. |
| ||
| There are a lot of people who want to be indie developers, and have been trying to finish their first game for years. That doesn't stop them posting on forums. Within a few months of releasing our first game, most of what I had thought to be true turned out to be complete bollocks. If I'd have been posting before we had a game out, I'd have been talking a lot of rubbish. Exactly why I rarely post about the game I'm working on. Sort of a "hex" thing. If I talk about it too much, it'll never get finished. Heck. I might not even need the benefit of a hex to make that true. Damp: I enjoyed the article, but I sort of sit in the same thought as everyone else. You seem to have a solid idea of what to do to be successful. If you haven't done it yourself, it just seems like a research paper more than anything else. A research paper isn't necessarily void of credibility, but you need to be honest with your audience and let them know. That means siting your sources to maintain your credibility. |
| ||
| Grey talks like everything I said is 100% untrue. Yet if it weren't for the things I said that are true, his games wouldn't sell at all. Grey makes games that have a new twist on the format. And ones that are really good. They aren't half-assed and they aren't particularlly good looking either. I mean.. He proves my point with his own games. Take out the themes, the better take on the match-3 and the really fine movements, and his games wouldn't make 1/4 of what they do make. |
| ||
| Don't worry RocketGnome. It is just a first draft. I will cite my sources and I'm considering heavily talking about my background as well. No worries. The main reason I haven't done it myself, is because I'm not a very good coder.. I'm a fine conceptualist. I'm a visionary. I'd make a really good tester too. What I don't make is a good coder. And I don't make a very 'aesthetic' artist. I can however do really nice pixel art. Since most indie designers are very solo in their game-making, I don't find a lot of partners. I can say that I have never, in over 100 projects, quit. I can't say any of them have been completed. The ones I started myself, which were few, the other team members crapped out on. And the same is true of the ones I didn't start. The only one that seems like it might get done is Apocalypse Online.. but I can't see it be successful as planned. Nor did I have much more to do with it than some level design via height-maps and some music that might not end up being used... cause Nils has his heart set on getting the band "Apocalyptica" to do music or let him use what they already have. I don't quit. I'm a very competent level designer, and I am able to visualize how gameplay will work in my head.. I'm a savant like that. I don't have a clue how to prove that last bit. I can just 'see' how the completed game will look and work. I can feel the controls in my hands and see the gameplay... It is absolutely mind-melting that no one will even give me the chance to just sit down with them as they are thinking up their game idea. By that, I mean someone capable of getting a game finished. My ideas aren't all grand. If you read the Novella Chronicles design document you'd see. They are doable. I actually lean conservative on real projects. It is frustrating that you have to be able to finish a game all on your own to get any kind of respect. It is a critical detriment. It is a lot like wanting your new CEO to be able to lift 70 lb boxes because that is what the people on the floor have to be able to do. Being able to code has nothing to do with being able to see the flaws in a design, or being a good visionary... Hell.. Look at Carmack. Then look at Miyamoto. |
| ||
| Grey obviously has more experience than I in the casual/indie games realm. But I thought I'd comment on the items he had problems with to assist Damp in gathering other points of view. "But remember, it isn't the box that sells the game." Probably sells the first one though. "Paying $10 for a basic 'bejewled' clone is not a bargin." (depends who you are) Yeah. But this whole article is opinion based, so it might be as valid as the rest of it. I personally side with Damp here, as I lost interest in the original Bejeweled (much less any clone of it) within about 15 minutes of play. $5 wouldn't be a bargin to me. "Want to make a platformer? Make it fantasy themed and you'll find a lot more people are willing to buy it." I think the key to platformers or any other game that falls out of the more formulaic realms (such as match-3, first person shooters, etc) is IP. In a platformer, a main character has to have some personality to set itself apart. Fantasy theme wouldn't be enough in my opinon. "Most people don't like demos." I personally don't like the breadcrumb crap that's left behind when I un-install demos. I prefer a crippled demo that lets me play the first level or so without a time limit. "Obviously, graphics are the only way to make some 'bejewled' clone stand out." There's some validity to this. Why would I pay for the same game unless there's at least one element that makes it more appealing. For Bejeweled, I'd say the best that can be done to that game and retain it's clone status is to improve the multimedia aspects of it. "It seems like the indie games that get finished are all clones, bad ideas, or otherwise lame" It appears that there is a confusion between indie games and casual games. Since most casual games are self-funded, I guess that makes them indie in that regard. I think the distinction is that casual games take less risk because they are made for the intent of sale. Indies may sink or swim on their own merits and are more of a labor of love than what the market expects. "But the big bucks aren't on the portals." (... this one is hilarious.) For the casual games developer, it obviously is where a lot of the money is made. Portals (from my understanding) are also not too terribly inclined to do something terribly risky. Therefore, an edgy "indie" title might hold no interest to them or be promoted prominently enough to get the types of sales a casual title would. "The game doesn't have to look good to be fun, so don't focus on that" (again, depends on who is buying.) A pretty, but crappy game is still a crappy game. I understand a lot of casual developers sell a crap title if it's candy-coated crap, but that doesn't make it fun because it's visually appealing. Take "buying" out of the equation and his point becomes incredibly valid. A fun game can have it's graphical element cleaned up later and still be fun. Harder for the opposite to happen. "It could mean burning discs and handing them out on the street near a game store." I'm pretty sure I'd never do anything with some home-made disk that someone handed to me off the street other than see how far it could fly or how many pieces it would shatter into against a nearby building. |
| ||
| the fantasy thing is taken out of context. I was saying, you'll capture the fantasy-game-players which is a very big chunk of the market. the same exact game with say.... Random cartoon guy A, running through typical grasslands B... wouldn't do as well. With the same graphical levels. |
| ||
| I guess we sort of agree then. Though I'm not sure if a fantasy game player would buy a platformer just because it starred a barbarian and a dragon. Unless it's Bert the Barbarian... great grandfather of Cletus.... (as I said.. personality... IP... etc) |
| ||
| Well.. you'd be surprised. What I mean is that the choice of theme will effect the number of people buying it. There are people that just buy anything fantasy. They read fantasy novels, play DnD, and live breathe and die fantasy. Another, illegal to do, example would be to make a pokemon themed game... I mean.. Look at that god-awful pokemon racing game on the DS.. |
| ||
| I was going to stay out of this, as I'm yet to complete a game myself, but this little gem caught my eye: It is frustrating that you have to be able to finish a game all on your own to get any kind of respect. It is a critical detriment. Ahem. I've been reading many books on the whole game making scene, from both an Indie point of view and a professional point of view (and my mastercard has the scars to prove it). The one thing the game industry is overflowing with is "visionaries" and "dreamers", who are all wanting to be a game designer. Now, there's nothing wrong with wanting to be a game designer, but you need to have some sort of track record. Let's suppose I've got this game idea. It not any old idea, it's the which will sell millions. It will, really. Now, let's suppose I go up to (say) Grey Alien (I'm picking on him because he has actually sold some things. Plus, I don't know him) and tell him of my idea, and how I want to get lots of respect because I've got an idea. Not any old idea, the idea, the one which will sell millions. My betting is that he would ask to see my track record, and when I produce a blank sheet of paper, he would tell me to go away. Why? Because ideas are actually worth bumpkis. He probably has far more ideas than he can possibly accomplish in a single lifetime. There's people walking around who are so visionary, with amazing ideas popping out of them every few seconds it's probably not safe for them to drive. It's the action of taking an idea and making something physical of it that earns you respect. From what I've read, the gfx can be substandard (or purhcased), the music can be pretty naff (or purchased) but the fact you've actually taken the time to build your idea into a product earns you respect. Also, some ideas are great on paper, but decidedly not great in reality. It takes experience to know the difference, and you can only get experience one way. Have a look over these forums, or over on the Dark Basic forums, for all the announcements of a new game that amount to little more than a few screenshots of some basic 3D object on some default media, with a program which does little more than load and display these items. Then watch how many actually follow through to a finished product. There are some truely stunning projects that never seem to get finished, then there are some very crap one that never much get started. Paris Hilton might get instant celebrity status because she's Paris Hilton, but the real world doesn't work like that. We have to earn our place. Talking the talk when you can't walk the walk is a sure-fire way of ensuring that anything new or insightful you might have to say is ignored. And, for what it's worth, I found Indie Game Development Survival Guide and Designing 3D Games That Sell! to be very valuable resources. Now I'll go back to hiding under my rock... |
| ||
| you missed the point. Your ability to program a game is not a marker for your ability to design one. There wouldn't be a job 'visionary' or even a 'lead designer' or 'director' if what you said was really true. Think of it this way... Some directors can act.. most can't. They can't do set design, or make up. Hell.. They might not even be able to do camera work. They direct. That is what they are good at. Suggesting that the only way to get enough respect to be able to direct a movie is by being an actor, would be met with ridicule. Why is it not in regards to games? In regards to being a lead designer. I have academic expirence. I was the lead designer for 2 5 week mod classes.. It may not mean much.... which is unfortunate. One of those mods was an RPG conversion of Warcraft 3. Which we made it through about 50% of the first 90% of the process. (the last 10% can be called the second 90%) Let me repeat that. I inspired a team of 7 people, with skill ranging from incompetent to novice, to convert warcraft 3 into a turnbased RPG. Complete with random battles, some of the menu, all of the story (but you can't really get to it all) and some of the worst level design I've ever seen... In 5 weeks... really 4, since the first and last few days were toss-a-way. www.dampes8n.com/FON_V_1-11.zip is what we ended up with... getting it to work right might take some doing, but it should kinda-work if you load up chapter 1 and walk around.. you'll get into some battles. |
| ||
| you missed the point. Your ability to program a game is not a marker for your ability to design one. I disagree strongly. Game design is an iterative process. You can't know whether something is fun or not until you make it and try it. At least, no normal person can. You say you're a savant in this area, but there's no evidence to support it. You THINK that what you come up with will make a good game, but it's never been tested. Right now, there's no real way to make a game without coding one, unless you can hire people to code it for you. Learn to code well enough to prototype, or mod an existing game, and get creating. Otherwise you'll spend your entire life talking about being able to do something instead of actually doing it. Also, Since most indie designers are very solo in their game-making, I don't find a lot of partners. I can say that I have never, in over 100 projects, quit. I can't say any of them have been completed. The ones I started myself, which were few, the other team members crapped out on. And the same is true of the ones I didn't start. That's a weak excuse. You don't think it's your fault because you justify your own actions and place the blame on the other team members, but that doesn't mean it wasn't your fault. Some people sit around and make up excuses and other people stand up, clench their teeth and don't give up when the going gets tough. I battle daily trying not to be in the first camp. So should you. Anyway, what I'm saying is, close this window NOW, start working on something and finish it. No excuses. |
| ||
| Well, I agree with the opinion that a designer need not have coding experience or what not to be a good designer, and that a great coder may be poor at game design. The problem is this though - even *if* you are a great designer - if you've got no track record you're basically trying to sell a boat to someone in the desert. Why? Well, because even *if* you had a great design, if you were pitching it to a poor designer, they'd be unable to see the greatness of your design, and if you were pitching it to a good designer who could see the greatness in your design...well, they've undoubtedly got their own good designs to go off and implement (or pitch to others)...and they either have equal (i.e. none) or more experience than you yourself will. It's just one of those things where you have to pay your dues. |
| ||
| No, a designer doesn't need to have coding experience, but they do need to be able to create their vision and revise it. If they pay someone else to implement it, that's fine. Good point about not being able to see the value in someone elses design - rumour has it that Will Wright had to fight management to be able to develop and release Sim City and The Sims. |
| ||
| Grey talks like everything I said is 100% untrue. Just to clarify, yes there are some valid points in your article, sorry I didn't mention them. He probably has far more ideas than he can possibly accomplish in a single lifetime Lol, yep that's true, but it's probably also true of most peopl on this forum too! :-)So how do people become game designers without programming? Maybe by working in a big tema as an assistant designer or something? Then eventually moving up to the role of designer. Or, putting your money where your mouth is, and hiring a programmer, artist and musician (as others have said) to make your design into reality. Or, in the Indie scene, design and program your own game from scratch, hiring in artists/musicians and even marketeers/publishers as appropriate. |
| ||
| Another option is to using something GameMaker or Multimedia Fusion which, with a bit of effort, will let you program some decent games. Nothing too fancy , and if the scope gets too large it might be harder to make the game in MMF than a "real" programming language, but small casual games or concept prototypes could easily be made. You could then use those as a means of leverage when you are trying to encourage others to work under you. |
| ||
| He probably has far more ideas than he can possibly accomplish in a single lifetime i think thats called 'ambition',and IMO,its what makes people ultimately successful,no? |
| ||
| Of course, then there's a related problem of having a single idea that is so big there'd be no way to implement it in a lifetime. :P I tend to suffer from these visions of grandeur and it's so painful to cull a design down to a realistic size. |
| ||
| I wonder how receptive a AAA design team would be to having an unpaid assistant visionary/lead designer intern? I always hear people moan about how hard it is to find really good lead designers. That would certainly fast-track the process. Look at me hijack my own thread. |
| ||
| He probably has far more ideas than he can possibly accomplish in a single lifetime Hmm I would say that many people have ideas but do nothing. Ambition is the drive to actually make them happen. Then success comes from picking yourself up when the ideas flop in reality and trying again. i think thats called 'ambition',and IMO,its what makes people ultimately successful,no? |
| ||
| I wonder how receptive a AAA design team would be to having an unpaid assistant visionary/lead designer intern? That's a joke right? You don't walk into a lead designer position with no experience. It's perfectly possible to start as a tester and work up (not even that difficult - plenty of people take that route). It's hard to find good lead designers because very few people can really design games. I mean design a game from scratch - not suggest '[popular game] but better' - which would probably describe 90% of the design docs I've seen. At the risk of repeating what others have said, only finished work counts. Only finished work means anything or proves anything. Abandoned projects are meaningless. If you want to make games then make games. You will not get others to do it for you. |
| ||
| Obviously, graphics are the only way to make some 'bejewled' clone stand out. Anyone who thinks that is true needs to go get the PuzzleQuest Demo right away.More importantly anyone who thinks that, has no business designing video games. |
| ||
| yep that was my point. Also Cradle of Rome which has an interesting metagame. |
| ||
| Obviously, graphics are the only way to make some 'bejewled' clone stand out. Metal Gear Solid:Sons of liberty had outstanding graphics for its time,sadly,the only thing that stood out was that it was a pile of cack! IMO |
| ||
| To be fair, Metal Gear Stupid isn't exactly a match 3 game. |
| ||
| To be fair, Metal Gear Stupid isn't exactly a match 3 game. quite correct,but it is a great example that great graphics dont entirely mean a great game. id play a bejeweled clone anyday over that piece of monkey ass |
| ||
| Well I don't think his point was that flashier graphics necessarily gave a better game, just the the match 3 game was a concept that could not be expanded in other directions. Which is obviously incorrect. |
| ||
| You have to pick through all the self-proclaimed indie game Gods to find the posts with real value. I'd say most don't have the experience to back their informational posts. |
| ||
| Well I don't think his point was that flashier graphics necessarily gave a better game, just the the match 3 game was a concept that could not be expanded in other directions. oh,okay, I must of missed the context of the thread a little :-] You have to pick through all the self-proclaimed indie game Gods to find the posts with real value. I'd say most don't have the experience to back their informational posts. sadly, I have never released anything on portals and what not, but I have played a few in my time (lol,who hasnt). i'd be most intrigued whos made what,and possible which language they used. |
| ||
| There are a lot of good games based on the match-3 concept. Hell.. match-3 is based on tic-tac-toe. When I say 'bejewled clone' I litterally mean a clone. Not like Grey's games which take the gameplay in a new direction. I mean. Big wall of 'things' which when you swap them they make matches of 3, disappear, and then the ones on top fall into place. End. Or MIGHT have some minor tweaks.. Like more or less items, or simple powerups. But not a complete change in gameplay direction like Grey's games. |
| ||
| well I don't think my games are that big a gameplay change. I just added in lots of powerups, different shaped grids and tiles on the backgrounds that need to be removed. That's pretty much it but it does make it a lot more fun than plain bejewelled. |
| ||
| yeah. Which is the opperative requirement. You didn't just rip it off entirely. You also have holiday themes that grab a different audiance than just average bejewled. |
| ||
| Hey your web comic site made me laugh :-) |
| ||
| Hey your web comic site made me laugh :-) So you're the one! |
| ||
| Which comic was it that made you laugh? LineOf7s It has gotten A LOT better. A LOT!. And some of the new ones are gonna be even better. |
| ||
| LineOf7s It has gotten A LOT better. A LOT!. And some of the new ones are gonna be even better. I checked it immediately before I posted, because up until now I considered Grey Alien to be somewhat sensible. Let's just assume I'm not your target audience. PS: Just kidding GA. :o) |
| ||
| Humor is a very subjective thing. Some people think Bob Hope was hilarious. Others think Eddie Izzard is. Lot of people watched Friends, Will and Grace, Aqua Teen Hunger Force, Tim and Eric Awsome Show Good Job, South Park, and Two and a Half Men... How many people do you think like all of these shows... I sure don't. |
| ||
| What about talking about what not to do on game websites. I decided against a few otherwise-nice-looking indie games because their websites have things like the following: - "Particeles! lotsssss of particeles and explodies ;-)" Crap grammar, crap spelling, and what the hell is that at the end? If your game has a sweet particle engine, show that in the screenshots. Nothing reeks of unproffesional coding more than bad websites like that. |
| ||
| haha it might be worth a mention. |
| ||
| I was thinking about this on my drive to work. I think you need to narrow down the scope of your article, and instead of offering advice and what basically amounts to encouraging people to embrace "indie ideals" take your article in the direction of offering creative ideas for different payment schemes for indie games. You yourself said you are more the creative/visionary type, so I think this would be a much better route. Besides, if you're article is simply offering ideas and suggestions, you don't need "credentials" per se for the article to have worth. I think the key thing is to offer suggestions like you did above, utilizing real world examples - i.e. the wings in furcadia, dragon amulets in DragonFable, etc - but also create unique pay-schemes for the indie games that don't traditionally employ such methods. Come up with and elaborate on some unique pay scheme for a Match-3 or a Betty's Beer Bar type game. You aren't going to convince the cloners to stop cloning with one simple article - or, more likely, with any article - so why waste your breath trying? Instead, just offer ideas and those who are willing to take a bit of a risk and innovate will see them and perhaps try them. |
| ||
| Besides, if you're article is simply offering ideas and suggestions, you don't need "credentials" per se for the article to have worth. Whilst this is true, credibility still plays a part. Suppose there are two people in a room, both with "ideas" on how to sell software. One of those people is Bill Gates, the other is me. To whom are you going to listen to? @DampeS8N, This whole thing on game design has been nagging me, because I've hit a brick wall in the development of my own game idea. I've got some very basic technology running, I've got some high level stuff worked out, I've got some low level stuff worked out... and I've stalled completly. Again. Here goes another project, it's just going to fizzle away like all the others. Only this time, I pulled out one of the many books I have on game design (Game Design: Theory and Practice) and started to read it over breakfast. I found a discussion on game design documents. Now, I thought I had a game design document, all 3 pages of it in Word. This book was talking about a thirty page document being somewhat light-on. So, I've taken a bit of time today at work and started to expand my design document. I've fired up Microsoft Project and started to lay out what I need to do in there, with some rough time frames. All of a sudden, the development road map seems to be coming together. Not taking the time to do a proper design document has been my problem all along (and it also means my wife has been right all along, damn her ;) ). Now, my personal litle epiphany might be old new to the other guys here, but for me, the revelation that I've been screwing up at the most basic level is both welcome and annoying. But it also pinpointed what has been bugging me about this whole "I want to be a game designer" thing. If you can't code, fine. Codeing isn't everyone's cup of tea. But if you want to be taken seriously as a game designer, design a game. Not the typical team request that gets stomped on within 10 seconds ("I've got a great game idea that I need a programmer and an artist for. It's like Quake 4 but better, with a neat twist that involves time travel and glo-sticks"), but a full-on design document with detailed gameplay breakdowns, art asset requirements, codeing schedules, development timelines, the whole enchilada. Alternatively, if you've got a novel payment scheme worked out, give us the details. Show us the research that your idea is better than everything else out there. Prove it. Your original article was an opinion piece, and as an opinion piece it was ok, I guess. Some of your opinions as advice seemed a bit odd, but hey, they are your opinions. If you're going to redo your article, and you don't have experience, have research. Link everything back to source articles and other research, so I can see that you've done the hard work of bringing all of this together, and are thus worth listening to. Lead me by the hand to your conclusion, and I will listen. |
| ||
| Did you read my design document? What about this one. www.dampes8n.com/gamedoc.doc (This was for class, and was a couple years ago... so some of it is laughable.) Also. I wasn't saying this is a work of genius.. just that at over 30 pages there is still a ton missing. I really should make a full design document for one of my really genius ideas.. Complete with drawings and the full 9s... But who would read a 250+ page document? |
| ||
| Did you read my design document? What about this one. I'm really not the person to critique a game design document, as I'm learning it myself. However, since I've opened my big mouth I better follow through. First of all, where is your development schedule? How are jobs to be broken up? What technology do you intend to use? How many people do you think you need? Nearly all objects on the battle field should be destroyable. This is a major strategic component of the battles. One of the things the book I referenced above mentions is to be wary of "pie in the sky" technology without detailing how it works. Fully destructable scenery is, to my understanding, very much a holy grail. The way you describe it, the game is fully 3D, so you're going to need some cool physics in there. Yet, you don't mention the physics technology you want to use. This game will be made for the Playstation 3 as Sony has established themselves firmly as the number 1 seller of video game systems in the current market. The game may also be ported to the Xbox 360 and the Revolution. Given the sales of the PS3, compared to (say) the X-Box, don't you think that this is a risky strategy? Also, what is the cost of PS3 dev tools? The X Box dev tools are free - and Microsoft has in place a distribution platform for Indie games.Honestly, the design document reads to me like a draft, with lots of details to be added. How about some screen mock-ups? I'm having difficulty visualising what the screen would look like (I'm an FPSer rather than a RPGer). The non-linear design of the battles, customization of the player-characters, and amazing storyline are designed to keep the player interested throughout the gaming experience, and to keep the player always wanting more. If you're going to make a statement like this, back it up in the document, otherwise it comes across as just another detail that's going to be worked out later. I personally didn't find the 2 page storyline all that amazing (in fact, it all seemed somewhat linear). You again get the chance to fly around freely and do side quests, of which, there are now more to act in. Where are the side quests listed? What do you accomplish in them? Does successful completion (or otherwise) affect the outcome of the game? Can I just ignore them?I don't want to come across as dumping on you. I know it seems like it, and I also know you've done a damn sight more work on this design document that I have on mine. But it's not complete. It's like 25% complete, with all the hard boring work ahead. |
| ||
| it was also made on a 1 week schedule for a class... didn't you read all the stuff I said above? didn't you notice the wii was called 'revolution' in the doc? Also.. A lot of the missing elements were toms fault.. haha.. I can dump on him, it is his fault. I'll comment on the destructable objects. This is a tactical square-based game. The objects are just assets. No fancy physics required. No different than a barrel in doom. We made this back when they had JUST announced the 360 was going to be called 360. That's how old this thing is. We got an A... ALSO.. This is NOT an indie game design document. It was assumed we were making a preliminary design document for a game of our own design given whatever assets we might need. He didn't want us to bother with a lot of extras. Just nail the core down... We did about 50 times more work than we were supposed to... Our prof was Mark Baldwin.. if you don't know who he is.. well.. "The Perfect General" and "Empire" |
| ||
| The X Box dev tools are free - and Microsoft has in place a distribution platform for Indie games. No they aren't and no they don't. |
| ||
| No they aren't and no they don't. quite right,its about $99 per year for a creators club license. as i see it,XNA is still currently beta,we'll probably end up with a XNA framework thing for free,which we'll have to hook up with c# ourselves,but i can imagine any 'pro' version of xna will cost roughly the same as any other standard 'Studio' products |
| ||
| quite right,its about $99 per year for a creators club license. And it doesn't quite qualify as a distribution platform so much as a way to share your source code and media with other developers. |
| ||
| As a matter of interest, I'm working with a well known game designer at BFG right now. The design doc is only 9 pages long, but a) it's for a casual game not some epic FPS AAA shop-title and b) lots of the fine-detail is worked out on-the-fly with me asking loads of questions. I also get to suggest things which is nice. Basically making games is an iterative process, you try stuff out, it doesn't work, you try something else and you continue until it's right. |
| ||
| It was assumed we were making a preliminary design document for a game of our own design given whatever assets we might need. That explains it then, because I skimmed over it while trying to put myself in the position of a prospective coder and it struck me that the document was actually a bunch of useful background stuff that would allow YOU to really start designing the game. Which is to say there's not a great deal of meat in there for the coder -- like the specific mechanics of combat, AI specs or even the basic structure that you envisage will be used for characters and the like. Which is why, I think, you really need to be able to code a little bit to design, even if it's just to prototype and balance various elements in a text console. To my eyes it looked like a good foundation for the design, though -- not knocking that. It's just that for a BattleRPG I would kinda expect the designer to have detailed the battle engine. Your ability to program a game is not a marker for your ability to design one. It's a fairly good marker for you not being wildly unrealistic about what can be achieved in the available time, though. I was listening to some radio pranks the other day where the station DJ pretended to be the answering machine, and even when he was answering directly back to the caller some of them didn't twig that it wasn't a machine. Not everyone has a mature and current understanding of where technology is and what it can do, and I bet a fair few people who fall into that category fancy themselves as game designers. I'm sympathetic to those who require some familiarity with computers from those who want to dictate what others will do with computers for a living. There wouldn't be a job 'visionary' or even a 'lead designer' or 'director' if what you said was really true. Is there anyone with that title who didn't either code his/her way there or happen to have a parent who was a personal friend of Hiroshi Yamauchi? |
| ||
| Is there anyone with that title who didn't either code his/her way there or happen to have a parent who was a personal friend of Hiroshi Yamauchi? I was under the impression that Miyamoto was already working for nintendo as an artist when they droped the radar scope electronics into his lap and said "Make a game that uses this." He had no programming background. I would argue that having a programming background might even serve to cloud your ability to clearly see your vision. You forget that nothing is impossible and will side-step 'minor' improvements that would take forever to code. Granted. There is a difference between a big team of 300 and 2 guys. A great designer should understand that. Last night I decided to step up and prove myself with a design. It is a puzzle game, very very loosely based on a rubik's cube, tetris, and a matching-game. Sound confused by that description? I won't go into it more just yet. But when It is done, I'll gladly let Grey have the design, he can just slap my name on it somewhere as something relating to design or concept. Notice how I'm not even considering the fact that he might not wanna do it. This game is utter genius. If you are too too curious, I can detail it to you in an e-mail grey. |
| ||
| And it doesn't quite qualify as a distribution platform so much as a way to share your source code and media with other developers. yep,commerical xbox distribution at this time is a no-no, unless you share your code/media,to other developers only. though develop it for the pc,and you can distribute it however you like,a msdn geezer told me that himself,well,on the forum,as that was one of my first questions when i tried it. |
| ||
| I would argue that having a programming background might even serve to cloud your ability to clearly see your vision. You forget that nothing is impossible and will side-step 'minor' improvements that would take forever to code. You seem to have convinced yourself that not bothering to learn about the technology you plan to employ is somehow the opposite of being lazy. Bit if a stretch, that. :) |
| ||
| knowing how to make a bitmap rotate, or how to re-order a list of items in code or not, has no bearing on your ability to apply those actions. If you think that knowing the ins and outs of hash-tables will somehow help you to design a videogame, you are sadly mistaken. Ideally, a game should be designed by the people who will play it. One day, that will be the case. (Ala holodeck) Today, it is best to be able to step back and see the game from the point of view of someone who is playing it. What they will think is fun. That, is far far more important than knowing how to code it. That is the programmers job. Figureing out how to apply realistic physics to a ball that has just been struck by a bat in 2D. Knowing what it should play like, and how to make it work are 2 different things. The programmer might think to use a vector line for the bat to calculate the angle the ball was struck at. The designer need only know the ball will fly in the right direction. Knowing how it got there might help him compromise his ideas later on, but that is all it will enable him to do. Still... Knowing that it uses a vector line, is all he needs to know. He doesn't need to know how to code that. Indeed, trying to keep things like that in mind will take his attention away from the big picture. Which is what the player is going to see. The player will never see your elegant solution. They will just feel how the game plays. What feels right, and what doesn't. |
| ||
| Very kind offer thanks DampeS8N but I'm busy until June at the moment. By all means hit me with the idea though. Email address is in my profile. |
| ||
| Is there anyone with that title who didn't either code his/her way there or happen to have a parent who was a personal friend of Hiroshi Yamauchi? Neither Daniel Irish (Relic) or Chris Avellone (Interplay, now Obsidian) ever worked as a programmer (and would probably resent the implication that they did). Just to name two that immediately spring to mind as having designed/produced some of the most critically acclaimed games ever. |
| ||
| Ideally, a game should be designed by the people who will play it. Did you ever see that car Homer Simpson designed? |
| ||
| That is a perfect example of the difference between play and utility. Children make up games to play with thier friends all the time. Imagine if they could simply ask for whatever gameplay elements they want in the game... like I said, ALA holodeck. Homer enjoyed that car. It might not be successful as a car, but it is what he wanted. If it were a car in cyber-space and the world was a game. It would have perfectly suited what he wanted. I sent you an e-mail Grey. I left out a lot of the details on the gameplay. I've thought it all out and how to do it. But it really needs a proper visual aid and a good description. Which I didn't wanna bother with since all you really care about is the idea itself. |
| ||
| The major concern with your approach, for me, is that you're very neatly compartmentalising design away from reproach or criticism. The game ends up sucking? It's the coder's fault for not achieving the vision. Game not finished on schedule? It's the publisher's fault for not hiring enough staff to generate the content that the vision demands. Reviews terrible? Well that's not the game I had in my head that ended up onscreen so don't blame me. And so on... I don't see, from what you've said, how you envisage the design ever being analysed on a cost/performance basis. It just sort of sits on this holy mantel, away from mere concerns such as practicality of implementation and market viability. That might superficially sound like putting the design first as you auteur excellence, but what it really does is cordon design off to a point where it's in danger of drifting into irrelevance. I'm sure you can recall what happened the last time someone declared design as law! While I'm rambling, I should also express surprise that you don't appear to want to make the procedural mechanics of the game your domain. It costs a lot of money to persuade someone to program your ideas rather than their own, so those ideas may as well be fully formed and exact. Otherwise I fear you run the risk of paying someone to program their take on your overview. The most detailed design document you can have, ultimately, is the source code, remember. I've been quite negative there and taken some of your ideas to their logical worst case, but it's food for thought I hope. Ideally, a game should be designed by the people who will play it. Yes I've said before that I'm a little bit surprised that the current gen of consoles don't ship with middleware as their dev tools. I'm surprised you still need to code; but you DO, and even if you didn't you'd still need to script. A game, fundamentally and no matter how you dress it up, is most accurately communicated as a set of mathematical and logical processes. You can't escape that. |
| ||
| Neither Daniel Irish (Relic) or Chris Avellone (Interplay, now Obsidian) ever worked as a programmer (and would probably resent the implication that they did). Just to name two that immediately spring to mind as having designed/produced some of the most critically acclaimed games ever. Cheers Flamey, that's interesting. I bet they had a pretty good grasp on the tech, though. And that's what I'm really disputing -- the idea that wilful ignorance is somehow beneficial. |
| ||
| The major concern with your approach, for me, is that you're very neatly compartmentalising design away from reproach or criticism. The game ends up sucking? It's the coder's fault for not achieving the vision. Game not finished on schedule? It's the publisher's fault for not hiring enough staff to generate the content that the vision demands. Reviews terrible? Well that's not the game I had in my head that ended up onscreen so don't blame me. And so on... This is true. But only in the role of 'visionary' as a director or a lead designer, Those are all your fault. You should have pushed them harder, you should have been the one making it happen. That assumes the idea wasn't bad to begin with. But I am a firm believer that you can make anything happen. Miyamoto is a testiment to that. I don't see, from what you've said, how you envisage the design ever being analysed on a cost/performance basis. It just sort of sits on this holy mantel, away from mere concerns such as practicality of implementation and market viability. That might superficially sound like putting the design first as you auteur excellence, but what it really does is cordon design off to a point where it's in danger of drifting into irrelevance. I'm sure you can recall what happened the last time someone declared design as law! On the contrary. These are all factors that go into makeing a good design. If it can't be made, or no one would ever buy it. You failed. The design is bad. I'm not surprised that we don't have really good noob-tools for making fun games. It is romantic to suggest that the optimal designer for a game is the person who will be playing it. But no one wants to explore that in reality. Game designers enjoy being creative. They also want to impress their own values and ideals on others. You can't learn something from a game you created yourself. At least, beyond self-reflection and technical skill. You can learn something from playing a game like... Final Fantasy 6. Or Harvest Moon. Or even obvious games like Where in the world is carmen sandiego. There is little interest in designing a really robust snap-together gameplay system with procedural content generation and random-but-not-really-random events and boards. The gameplay should be designed by who is playing it. That doesn't mean the content should be. You can never be surprised without that aspect, and therefore, you will always be bored playing your own game. Unless it is a game like a puzzle game, or with a lot of emergent situations. You need something like the holodeck. It doesn't have to be holograms, it can be on a screen. It doesn't have to be voice activated. It can use a paragraph, or even snap-together details. But it has to be able to surprise the player. So it needs some kind of bank of ideas. This is why these kinds of things don't exist. No one wants to make them, they are more advanced than current technology permits and they would be very very hard to balance. I did have an idea tho. You could have a bank of potential ideas and mechanics. An online listing of 'random' generated games based on those, and a rating system and variation system that enables the game itself to fine-tune it's own gameplay using the players as a measure. |
| ||
| If you think that knowing the ins and outs of hash-tables will somehow help you to design a videogame, you are sadly mistaken That's rubbish. Really. Understanding coding is a *massive* help. It may not be totally essential but to dismiss this altogether is folly. |
| ||
| I'm not dismissing the importance of a basic to moderate understand of coding principals. But being an expert coder versus knowing how it works isn't going to make the game's design any better. Period. I'm not saying it is useless to know how to code a video game. I'm saying that it doesn't make the game's design better. And if you are focused so heavily on some fancy graphical wizzardry that you forget to do something seemingly minor like working out a proper control-scheme, you've short-changed your own game. Also. You'll be less likely to, say, change from a keyboard controled system to a mouse controled one. If the gameplay should seem like it really would be better that way. After all.. making THAT code change is no small step in most cases. |
| ||
| I've worked two designers and I'm not sure how much coding skills they have (maybe a little but not tons). What I would say is that I've been asked a quite a few times to code something and the logical details haven't been thought out properly so I've ended up saying "hey this won't work" and having to explain why etc. (also same with particles, some kinda vague description and I'm left to experiment) As a programmer, it would've been easier if someone had worked out that detail and said "Do A, B and C and it leads to D E and F etc). Would have saved a lot of time and effort (and emails) on my part (but been more on the designer's). In fact I actually felt like the Micro designer in that I worked out all the details while the actual designer was the Macro designer (just the ideas man, if you see what I mean.) I feel that if I moved into the role of producer that I'd be able to direct programmers with a real understanding of what I'm asking them to do and also I'd have already worked out the logic/pitfalls first. |
| ||
| DampeS8N, email me that idea if you will. I'd like to have a stab at programming it. It could be a great opportunity for both of us and who knows, it might develop into a game company. I'm a decent programmer, I know you're good at art and are creative. (I've been known to be creative too). Consider me as filling out a programmer job application to you. Pure 50% split, I'm not greedy. Shoot me an email. |
| ||
| wait... for the puzzle idea? |
| ||
| I've never worked for a games dev company, but I can imagine the scene where a self-proclaimed 'game designer' walks into the office, with no real development experience. As a grunt, or cog in the machine, I would seriously doubt their ability to turn an idea into a coherent product, unless they had credentials and could 'walk the walk' as well as 'talk the talk'. My own opinion of a real games designer is someone who has worked on the really nitty gritty stuff, and actually been through the process of games release several times. I'd also expect they haven't become jaded and cynical about the games industry, and can think freely outside the constraints of their knowledge, but without the 'pie in the sky' mentality. I would expect them to be able to guess actual sales figures for different design models (e.g. 2D vs 3D). Most importantly if working with a team, they must have a sound, comprehensible vision that others can really get behind and believe in - whether it's completely original or not doesn't matter. |
| ||
| Chroma. If Grey passes on the idea, I'll gladly work on it with you. Or another one entirely. :) |
| ||
| Pure 50% split How you gonna pay the artists and musician and sfx engineer? ;-) Hey if you are giving away 50% JUST for game design you might wanna get him to do the "producing" i.e. publishing/marketing as well. |
| ||
| 50% of profits, he does the artwork, I do the programming. We find some low cost/free tracks on the web. No need to over-complicate things. Making games isn't a lost arcane secret that only a few know how to do. :p |
| ||
| Anyone who thinks that is true needs to go get the PuzzleQuest Demo right away. More importantly anyone who thinks that, has no business designing video games. Holy crap. A bejeweled-like game that I actually enjoyed. Thanks for the link Flameduck! To be fair, this game was obviously funded beyond the scope of the average "indie" devleoper (if that matters in the context of this forum). They have an ESRB rating at the front of it. I can't imagine that's something you get for free... |
| ||
| The more ambitious your design the more you need the coding experience to keep it in check. That's been a huge factor in my own design - is this feasible...can I implement this in some manner and keep memory in check...will implementing this require more info to be sent to the user which equals higher bandwidth costs...and if so, is it worth it? And then there is the ever present question: How long will this take to implement and do the pro's outweigh the costs both in money and time? And even if you answer yes to that, you have to prioritize all of your ideas. It gets harder when all those ideas are inter-related and depend on each other being present for maximum effect - how can you cut an idea out while minimizing the negative effects that'll have on your other ideas. |
| ||
| I'm saying that it doesn't make the game's design better I'm saying it does, massively. |
| ||
| No more than having. Say. Advanced painting knowledge. Or Advanced cooking knowledge. Give me one example where knowing what can be done isn't enough, where knowing how to do it is enough. Obviously we are making the assumption that you aren't the one coding the game. I mean. Obviously if you are coding the game having coding knowledge will make the difference between success and failure. That is independant of the design. |
| ||
| Did you read my post about working with designers that don't know programming? Basically it makes life harder and if I just tried to program it as they suggested, it would be bugged. Advanced knowledge of programming isn't essential (although it would help) but a medium level understanding of programming (and logic and maths) would definitely help. |
| ||
| No more than having. Say. Advanced painting knowledge. Or Advanced cooking knowledge. Rubbish. If you are suggesting concepts and don't have a good idea how they will be implemented or what's even possible then you are at an extreme disadvantage. At the simplest level programmers WILL tell you something you ask for is impossible. Being able to explain how something is possible, and better still being able to show them will work wonders. But more fundamental than that, if you don't understand how games work under the hood then you aren't going to be good at designing them. You may be able to drive a car without being competent mechanic but you sure as hell won't be designing one. |
| ||
| Think of it like architecture. Let's say you want to design your own house. You have a good grasp of aesthetics and so feel that you can do this yourself. And sure, I've no doubt you could turn up some nice looking blue-prints, but then the questions arise. "Will this design support this floor with only 1 beam?" "How will I get the plumbing from point A to B to C?" etc, etc. You may have designed the most beautiful house on paper, but will it stand? The big problem about not being able to answer these questions is that you won't be able to answer the one question that rules them all, "How much is this going to cost?" In this example the cost would be money, but in a game design for an indie coder, or a group working for free with promise of royalties, the cost is going to be in time. We've all got a budget, both monetary and in regards to time. You *need* to be able to get a decent estimate of how much time (and money) a project will cost, and you can only do that with some underlying knowledge of coding, art creation, etc. That knowledge will help shape a design *every step of the way.* |
| ||
| Did you read my post about working with designers that don't know programming? Didn't read it. But that's your opinion based off your 1 game experience from Oz. Hardly enough experience to base a whole article on if you ask me. If the programmer doesn't communicate with the designer and let him know what can and can't be done then it's his own fault. Technically, a designer isn't required to know squat about programming. I think sometimes being the designer and programmer can be a bad thing. Unless you're a control freak, then it's ok. :p |
| ||
| To echo the points made by John, and others above, you cannot expect to produce an achievable design document without either: a) having a decent knowledge of game development yourself, or b) working very closely with people who do have that knowledge from the start. If you don't, you risk having a design document that is a wish-list, is un-realistic, is un-achievable, will prove to be flawed, will result in project failure, or incurs exorbitants costs. It's back to that argument about a design document simply saying "It'll have deformable scenery too", without any understanding of what that adds in gameplay terms, or the implications in technical terms. It's that understanding of the cost / benefit equation; where to make sacrifices in your vision (e.g. drop deformable scenery), and where to make quick wins (e.g. support for more input devices). Okay, so I don't have a brilliant track record in game development, but I *do* have a very good track record in IT projects, and to some extent it's the same principle. The best visionaries are those that have grown into the role. (They're also those that will acknowledge their weaknesses and get input early on in the areas they don't know). |
| ||
| If the programmer doesn't communicate with the designer and let him know what can and can't be done then it's his own fault. It's both of their faults. Communication is a two way thing. The designer has a responsibility to make sure the programmer understands, and is able to implement the design. You do not just fire off a design and wait for it to be completed, expecting the programmer to raise issues. (I'll admit this can depend on the people involved, but it pays never to assume). Technically, a designer isn't required to know squat about programming. I think sometimes being the designer and programmer can be a bad thing. Unless you're a control freak, then it's ok. :p All projects need clearly defined roles, and in general it's best to separate them. Projects need a "visionary", a project manager and "do-ers", and in general, these need to be separate people. Too many project managers think they can be both the visionary and manage the project (and some insist on do-ing too). It rarely works because very few people can do both. Obviously it's different with small teams, but if you can make those distinctions, it helps bigtime. |
| ||
| I agree with Mark Tiffany. The relationship I have had in my contracts is: Me - Programmer Employeer - Designer Others - Artists, Musicians. The designer will say "This is what I want to do" and present me with a basic document with some mock up drawings of what he sees in his head. Then he says "what do you think". I look at the material, come up with some basic mental images of code structure and time. I offer pro's and con's of different elements of gameplay (not the gameplay mechanic, but more how this will be implimented and the many different ways it can be implimented with pros and cons for each). I then find the really hard areas and warn him that these will take more time to impliment, then find the really easy stuff and say these you can expect in the prototype. He then comes back with "what are your requirements for media". And I answer with the solution he chose from the list of options I gave him. Then I start the prototype (basic version with simple gameplay mechanic, and no interface really, the interface should usually be the last to develop unless its an RTS or something). I put together some basic game objects, with simple keystroke commands to make it do what he wants it to do. We go back and forth on tweaking the prototype till he sees what he wants to see. From there we make more decisions. When I say 'we' I mean I present the issues I had to over come in the prototype, and some possible solutions I come up with. He tells me what he wants to keep, and what he wants to dump. Any new features he came up with go into the prototype for testing at that time. From then on, the design is usually set in stone (with the exception of dumping more features to expidite development, but that's at his call, not mine). As for design, he is the designer. I have never been able to work freely myself, I have always needed someone calling the shots (not that I am incapable of design, it's just that I am a perfectionist, and get caught up on futile details in code that I shouldn't). I offer suggestions from time to time like "I think this looks better than that" or "this guy looks a little cheesy in my opinion" but I leave it at that. I dont push the issue as it is his vision, and I am the guy bringing it to life. Does my current employeer have coding experience? I think a bit, enough to give a decent pong game anyhow (I dont think he would take offense to that comment either). Does he need coding experience? Not really. He relies on me telling him what can and can't be done. He relies on my opinion of time required for each feature, for that is how he determines cost, not only cost of me, but cost of artists (to get the required bone structure I need to work with, or the required music format) as well. What makes my guy different from other guys with ideas? Well for one, my guy already works in the industry as an entry level designer for another company. Does it pay him well? I dont know, he would say it's enough to pay the bills and fund his hobbies (that being designing his own games). And lastly, he is able to pay for the work he wants done. Most designers want to do the sweat-equity thing, which usually never turns out in the end. when a guy has something invested (more than just his time and thoughts) it becomes important to him to see it through to completion. I did ask at one point why he choose me over others he has interviewed (after all, I dont claim to be the be-all-end-all of programmers like flameduck does ;-P ). His response was "you can created completed games most indies dont see it all the way through, and most pros can't because they never had to". Which sort of brought an aww to my jaw. I just assumed most in the industry do the project from start to finish. He said that most of the AAA industry coders only work on a small part (say the rendering pipeline, or physics), they would never be able to do it all (physics, input, sound, rendering, or even HUD/GUI) to see a project from start to finish. That's my 2 cents any how. The relation ship works well (well until late I should say, where I switched jobs and had to tell him that I don't have enough time to dedicate to what we used to do). He keeps asking if I can spare some time for some simple casual, but I can't promise anything (as I would hate to commit, and not be able to deliver). He keeps offering the money, which is a good motivation, but I can't in good honesty commit yet (4 months at my new job) |
| ||
| Didn't read it. But that's your opinion based off your 1 game experience from Oz. Hardly enough experience to base a whole article on if you ask me. If the programmer doesn't communicate with the designer and let him know what can and can't be done then it's his own fault. Sigh, I said two game designers. Plus for 10 years I did bespoke business software for clients who were the "designers" who knew squat. So yeah of COURSE I had to communicate with them and let them know what is and isn't possible and then OFFER a viable alternative/solution - I wouldn't have been very professional otherwise... What's this about a "whole article" btw? I haven't written a whole article about game designers not knowing how to program...I just mean my post further up in the thread. |
| ||
| You can know what is and isn't possible without being about to code it yourself. To take the design a car metaphor. Yes. People who design cars can't build them. They can't machine the parts, most can't assemble them, and some don't even have working hands and feet to be able to drive them. (I knew one such person.) You DON'T need to know everything down to the smallest detail. A lot of architecture at the highest level is done by artists, who then hand the designs off to their team who figure out how to make it stand. Then with the space left inside they do more designing. They have architectural expirence, and most know what can and can't be done, but when you are talking about a giant building, you can't keep all of that in your head. No one can. Suggesting you can't be a good designer without knowing code is as rediculous as saying you can't be a good designer without being a galler artist, a comicbook artist, a musician, a composer, an actor, and be rich. Since people with all these skills are likely to be needed for the project on some level. It is like saying you can't be a composer unless you can play all the instruments you are composing for. You need to know their range, what goes into playing, what can and can't be done. But you don't have to be able to play it to know those things. |
| ||
| Your problem is defining knowledge of code as 'can and can't be done' - but anyone that's been coding for any length of time will tell you that software development is in fact a series of interlinking tradeoffs. Not understanding those tradeoffs, in this real world with limited budgets, schedules and system specs will end in disaster. It is impossible to 'know about' programming without significant programming experience. No two ways about it. Sure, if you're talking about a finctional machine that will read the game from your head and then play it in front of you, you don't need to know the implementation details. But that's the machine doing the gameplay design, not you, because what you've got in your head is a cloudy glimpse of what the game could kind of be. |
| ||
actually. What I have in my head for the game me and chroma are making, looks exactly like Only with smoother motion and some other additional things. They are just as clear in my head as this is. Sure, it doesn't look all that great like that. But I don't really care about looks when I design gameplay. Looks can come later. The hardest and most time-consuming bit is trying to articulate what I see in my head. I can litterally play the game in my mind. albeit, sans some of the complexity as I can't remember the location of 49 tiles on a grid. I can replace them all with 2 colors and move the reds around, which is one way to play the game. Another is to move the colors into 'piles'. A 3rd way is to try to stratify the colors into layers and clear them bottoms up. I'm sure there are more ways. People keep comparing it to chuzzle.. Aside from the tiles looping around to the other side, and you needing to match them by color. I don't see any likeness. The gameplay is completely different. Seeing as you get to pick when to clear the tiles, and you aren't restricted to how many moves you can make before you clear them.. in chuzzle you can't move unless it makes a match. It is far more like "The Same Game" only with the ability to move and an 'endless' stream of new tiles. Chroma doesn't get to decide how the game will play, just how it will work. Which is what he says he wants. So far, he has done a bang-up job. I'm majorly impressed. |
| ||
| Ahh well. I'm done with this brick wall (ouch!) Good luck DampeS8N. |
| ||
| Right, well, be sure to check in in 6 months and tell us how it went. |
| ||
| My thoughts exactly. |
| ||
| can't knock down a brick wall with eggs. Try throwing something stronger at it. Like detailed examples. |
| ||
| DampeS8N, for what my opinion is worth, I think you should keep up with your designs but spend some of your spare time, if not learning how to code, then at the minimum downloading Clickteam's "Multimedia Fusion 2" and playing with it. It's got a 30 day free trial. What is it? It's a "game maker" program that requires no real coding. It doesn't even require scripting, per se. You can easily drag and drop objects/sprites around a "frame" (basically a level, or what will be seen on screen) and then go to the event editor and set up an event like "When ball_Sprite collides with left edge of screen -> Play Sound "Doink.wav" + Make ball_sprite bounce." I remember years ago, using the predecessor to MMF, a program called "Click and Create" (and before that - "Klik and Play") and me and my friend made a simple game where you each controlled a strange creature (using some of the animated sprites that came with the program). When player one pressed attack, lightning bolts would come down from the top of the screen in a diagonal motion . Player 2's attack was a wider but slower moving projectile that shot in the direction he was facing. Whenever a players attack object hit the other player, it would subtract their health until one was dead. It was simple, sure, but it was actually kind of fun. The best part was - it literally only took about 30-45 minutes to make. I had some experience with the program, sure, but it doesn't take more than a month or so to get enough experience where you can whip out simple games or concept prototypes with ease. Seriously, check it out. www.clickteam.com |
| ||
| Before I bother with it. I've used some other 'like' programs. Does this suffer from very laggy and jittery response times? Since there is no way to go in and tweak the code, you can't really fine-tune gameplay, so it I would rather it be 'too fast' and have some kind of wait command, than be too slow and hard to control. If it is capable of being smooth, and can handle larger projects. I'll give it a go. As for coding. I'm not a terrible coder. I can put together a web-page in PHP, up to just about any complexity. I can get something to 'work'. I haven't ever been able to wrap my brain around getting things to work 'properly'. Not to mention that I absolutely hate doing it. |
| ||
| can't knock down a brick wall with eggs. Try throwing something stronger at it. Like detailed examples. If you're going to dismiss the advice of several experienced developers then really, that's your choice. Believe it or not the advice was well intentioned - we are trying to help. I don't think the onus is on us to convince you. Go ahead and make your games. Prove us wrong. |
| ||
| Before I bother with it. I've used some other 'like' programs. Does this suffer from very laggy and jittery response times? Since there is no way to go in and tweak the code, you can't really fine-tune gameplay, so it I would rather it be 'too fast' and have some kind of wait command, than be too slow and hard to control. If it is capable of being smooth, and can handle larger projects. I'll give it a go. It works well. It's internally frame rate limited, I believe. It also has an option to run at a constant speed independent of the end users computer specs. In this case it just drops frames if necessary. But it runs decent on any semi-modern machine. Of course, if you coded the same thing in C++ it would be a lot faster but would also take exponentially more time. As far as larger projects? Well, it can be used for casual games (Cactus Bruce was made in the original MMF I believe. MMF 2 has hardware alpha + rotation, so a lot more eye candy is possible.) Other games that have been made with it are "I'm Ok" (http://67.15.42.30/ImOK/). Be warned, that game is...disturbing. A game that you should definitely check out (and I should as well, for some reason I've never gotten around to playing it, but it's hailed as one of the best games to be made with MMF (actually, I think it was made with Click and Create but..)) is Eternal Daughter, a side scroller rpg. http://www.megagames.com/news/html/freegames/eternaldaughter.shtml  It's a great program as long as you aren't trying to make a really advanced and/or huge game in it. You could, with some serious effort, make something equal to FF6 or so, I'd say. |
| ||
| Be warned, that game is...disturbing. No it's awesome! I'd totally forgotten about Jack Thompson's foray into the videogame designer business. I guess this proves without a doubt that not only do you not have to be a programmer nor know anything at all about videogames, to design a good videogame. In fact all you have to be is an obnoxious ambulance chaser on a power trip with an axe to grind. |
| ||
| If you're going to dismiss the advice of several experienced developers then really, that's your choice. Believe it or not the advice was well intentioned - we are trying to help. I don't think the onus is on us to convince you. Go ahead and make your games. Prove us wrong. Ditto. Personally, I think this is one the best, most useful threads / discussions that's been had on this forum. Let's not demean that with banter. I think there are a hell of a lot of useful opinions / ideas that people can take from this, and ultimately it is up to the individual whose advice to listen to, or not. There is no "one true path", no matter what some people would have you believe. We should get together to discuss this stuff more often! |
| ||
| actually. What I have in my head for the game me and chroma are making, looks exactly like [piccy] To be fair, looking at that and contrasting it with the RPG outline you posted, it really emphasises the relevance of what SculptureOfSoul said a little way up, which was: 'The more ambitious your design the more you need the coding experience to keep it in check.' So sure, I can see how you might get by designing a tile-slider this way when something more complex would demand more technically savvy details (like an AI spec). Nevertheless, what you posted also shows at just how simplistic a level coding skills become useful... The hardest and most time-consuming bit is trying to articulate what I see in my head. I can litterally play the game in my mind. albeit, sans some of the complexity as I can't remember the location of 49 tiles on a grid. I can replace them all with 2 colors and move the reds around, which is one way to play the game. Another is to move the colors into 'piles'. In other words, you've got a vague idea of how the game might play but you won't know for sure whether it works or not until somebody programs it for you. In contrast, if you could knock up a prototype (just blipping the values around an array without the animation, say) then you'd already have worked out the best number of separate colours to make it nicely challenging, an appropriate algorithm for seeding the playfield, the optimal speed at which to ramp up the difficulty etc and when you delivered the spec to your coder it would be a credibly complete design (rather than a bit of a stab in the dark). In other words, you can't actually do the bulk of the design without a coder -- to me that would be a predicament to extricate myself from, not a benefit to be embraced. I hope (and expect) that it will work out for you, but I feel pretty confident that you could expediate the design process by being able to rustle up and experiment with your own ideas independently. Multimedia Fusion 2 I really like MMF2. It's overpriced and, last time I checked, not really up to the job of delivering the quality required for a commercial game (no double buffering / torn graphics) but it's still charming and surprisingly powerful. It also forces you to describe your game as a working set of rules so is probably more useful for prototype development than fledgling designer-written code or potentially flawed pseudo-code. |
| ||
| At the risk of sounding contrary I think genuine original puzzle games are much harder to design than pretty much any other type of game. There's nothing to hide behind, if your gameplay doesn't work then you're knackered. With something like an RPG you can 'design' one by simply coming up with a story and using existing game mechanics. A large portion of so-called game design documents are like this - just a scenario\storline attached to an existing game mechanic. More like an idea for a mod really. |
| ||
| In contrast, if you could knock up a prototype.... Actually this is a good point. According to Fred Brooks, every team makes a throw-away prototype. Whether they intend to or not. In my experience that's pretty much on the money.And what John just said is really spot on. Which makes one wonder how he came up with both Wetrix AND Sticky Balls. He must be a genius! |
| ||
| In other words, you can't actually do the bulk of the design without a coder -- to me that would be a predicament to extricate myself from, not a benefit to be embraced. I hope (and expect) that it will work out for you, but I feel pretty confident that you could expediate the design process by being able to rustle up and experiment with your own ideas independently. Give this man a medal. When Dampe 'plays' the game in his head all of those details are being glossed over so of course it feels good. |
| ||
| At the risk of sounding contrary I think genuine original puzzle games are much harder to design than pretty much any other type of game Yeah and I'd add to that that even clones of puzzle games are hard to code, sure the design has already been done in the "original", but you don't have the design doc and you have to figure out in detail all the gameplay mechanics + add in new ones and check it doesn't crash or have unexpected anomalies. Simple example: make a match-3 then allow the user to make moves DURING as cascade = complex possible outcomes/bugs. |
| ||
| I agree, it's very difficult coming up with an original puzzle game idea these days. |
| ||
| I agree with Mark Tiffany. This thread will be very helpful to lots of people for various reasons. I also agree with JP about RPGs. It annoys me to no end that people just slot in a story and blah blah into the same old battle-structure. I wouldn't do that, and if Tom didn't have his heart set on doing the battle system I wouldn't have let it happen in our DD. My own RPG ideas are new. I tend to try to get rid of the old standbys as much as possible without upsetting the balance. I designed an item-only system a while ago. No levels, just equiping items. I had another which had about 50 character classes, all of which were completely unique, or at least less-common (in the case of time mages and librarians) It was going to be a tactical RPG, hexagonal with low numbers. The battles would have a time-line and a lot of mages were capable of using that timeline. The Psychic, for example, can peer into the future and tell what the AI has in store given current situations, with a higher and higher degree of being wrong the more turns you look ahead. The Time mage could roll back time for his party, restoring their HP and where they were standing, while not effecting the enemy. Or doing the opposite and pushing the enemy forward, repeating the last turns actions on them. The Librarian was able to predict enemy skills and spells, since they were somewhat random what skills the enemies would have in their pool. obviously, this RPG is way too big for any small indie team to build. So it isn't really viable for me unless I one-day end up as part of a big team. |
| ||
| The Psychic, for example, can peer into the future and tell what the AI has in store given current situations, with a higher and higher degree of being wrong the more turns you look ahead. I rest my case. |
| ||
| I rest my case. lol, common Michael, you could code that with your eyes closed ;-) |
| ||
| :) I make the impossible possible ftw! |
| ||
| I wasn't writting a design document. I don't see how you rest your case? If I was. I would have detailed how. Namely. It assumes the player makes no moves, which is how it gets more and more wrong the farther you look ahead. If the player has already locked in other characters, it processes their actions and stores them to enact between rounds. If they haven't locked in their moves, it assumes no motion on their part. The AI then 'plays' the next round like it would should the game be playing the next round. It holds the outcome and repeats for however many rounds. Along the way, it stores random values for random happenings, so should the same random calls be made when the player actually gets that far into the battle, it can repeat with that random value, making the actual future and the guessed future more consistant. When it reaches the target time-frame it 'ghosts' the new location of the enemy, and shows ghosted values over all the characters (PC and Enemy) for their new values. Also showing ghosted versions of the status effect values. Thusly, showing what the future might hold. Best if used to look forward in the future by 1 or 2 turns when you have a PC and an enemy who are likely to continue attacking eachother in the comming battles. In this instance, it will correctly predict the next movement of the enemy. Say, the enemy is going to step back and heal himself, the player can chose to use that information to his advantage. It might, show that the enemy plans to unleash the strongest attack skill in the game, in which case inflicting 'silence' or something else that will interrupt the skill might be the best course of action. As might be retreat. I DON'T just say things without investigating how one would do these things. Do you want me to detail what kind of AI it is? That isn't important here, seeing as it can store the values of, and use before-hand, almost any 'kind' of AI. If you were saying it isn't possible... that's silly. OOOoorr... Were you saying a 'psychic' was done in another RPG? Which? I've played a LOT of RPGs... |
| ||
| For squirts and giggles I'll also detail -some- of the AI. The enemies have a 'general' AI that moves them all, they don't act on their own. First, it calculates out all of the enemies possible moves, in the order of there action, which is based on speed. It assumes the almost-best-case scenario, so it assumes that all attacks will hit and deal max (but not critical) DMG. It looks for the 'best' option depending on what state it is in. States include, but aren't limited to: Normal, where it just attempts to deal DMG to the player, but conserves special skill power and MP, something in the order of a 10% chance of special skills. Enraged, where it attacks to deal the most DMG picking the most powerful attacks no matter how wasteful it is, Cripple, which favors status effects. Magic Happy, which favors magic attack. Scared, which it defaults to if all or most of its units are heavily damaged, this is a run-away state. Heal up, which it goes to if a unit is heavily damaged, this only effects units with healing spells. Last ditch, is the state after Scared, in which the AI goes into an Entraged like mode that favors healing spells for mages with them, also healing items yada yada. These states are determined through a set of ifs, basic state-based AI. I'm not going to go into how it picks where to attack, but understand, I did think through that as well. It is a very long-winded topic. (to check the future, it just 'asks' the AI and then doesn't impliment it to the player, grabs the values and re-runs however many times and then uses the data to build the future-projection.) |
| ||
| Yeah, "reading the future" wouldn't be that hard once you've got the AI system in place. The hardest part (by no means impossible though, obviously) would be devising the algorithms to determine the AI's next move in the first place. It's like chess but...more moves and more strategies available. Of course, developing a really smart AI isn't always a good thing anyways. Players like a challenge but don't like being beat - at least not on a regular basis. |
| ||
| exactly.. the hard part with chess is picking the best moves ahead of time.. This AI doesn't think in 'advance' it does the best move RIGHT NOW! which is as simple as making all the moves in the data and then picking the one that worked out the best for it.. haha... even THAT might be 'too' good. It could be a random pick between the top 2-5 options.. That is something that needs to be tweaked in testing. |
| ||
| gosh, after 3 days of reading this thread, I'm finally to the end. Good read, though. Starting with the original complaints about the article, it does appear that you are stereotyping the ways people go about buying video games. And, I would seriously not rule out the effects of a demo. I myself am quite happy to download a demo to try a game out. It gives me the best opportunity to try a game out. I don't go by the hype that's on the page, or user reviews, or even the screenshots on the game's page. I want to try the game out myself, and see if I actually like it. Demoing a game isn't the only consideration I'll give for a game. If someone I know says a game is good, and I know they've played it, I'll want to learn more about the game... but them liking it doesn't mean I'd buy a game straight out, I'd want to learn more about it. But then, this is coming from a guy that rarely buys games (or any toys for that matter). But anyway, the point is that everyone buys differently, and weights the information they have on the games differently. |
| ||
| I didn't say DON'T have a demo. But to also consider people who won't play one. There are people that are different, but the nature of humanity dictates that many are the same. Groupings, especially ones you can target, can be helpful. Thanks a bunch for your input tho. |
| ||
| oh man. Reading the future! Free tip: NEVER use random numbers in AI. |
| ||
| Namely. It assumes the player makes no moves, which is how it gets more and more wrong the farther you look ahead. Seeing as making no moves is the one thing that the player definitely isn't going to do, what it does is start off completely wrong and stay that way. I'll give you this, as a spell to determine whether a character was going to be attacked and killed next round, it could be quite interesting -- but that's surely the limit of its scope. I think it would be hilarious if seeing if any enemy was due to deliver a killing blow cost the casting character his move, so unless there was a comrade to step in and help, a character could only predict his own demise just before it happened! |
| ||
| Well, it would be useful to see what the (likely) actions are say 2 or 3 rounds from the current round for all of the enemies that are next to player units (which will presumably either attack an adjacent player or heal themselves or something to that effect.) If you knew you werent' going to move some of your units for a few rounds, having insight into the nearby enemies attacks could be quite helpful. Otherwise, it could be structured differently to allow you to actually move your characters each round that you see into the future, and then see how the computer would respond to that move. So basically, it would store the state of the current battle so it could restore it after the spell, and then let you actually play out a round or two or whatever, and then move back to the current state. To offset any random numbers used to introduce chance into the algorithms, you'd have to store/restore the random seed as well when the spell is cast. |
| ||
| For squirts and giggles I'll also detail -some- of the AI. Wow. That's terrible AI. First of all it assumes way too much, and the assumption it makes are largely going to be wrong. Sounds a lot like a poorly implemented expert system, with little to no expert knowledge (everything it assumes). I can't see how this would be challenging at all. Free tip: NEVER use random numbers in AI. Yup. It's an important aspect of game design that the choice the player makes has somewhat predictable consequences. The more you add randomness into the equation, the less predictable it becomes, and the more it becomes a game of chance, rather than a game of skill. The chess approach (playing through all possible moves to find the best one) is only applicable for chess games. For proper games you'll need a much more heuristic approach. |
| ||
| I agree about the random numbers thing - it's just laziness when coding AI in the hope that it may do something interesting but usually results in it performing terribly. |
| ||
| [pseudo] Random numbers can be a powerful tool but they are extremely easy to misuse. Generally it's simpler to keep them well away from any gameplay code. I tend to use them only for cosmetic stuff. If you ever find yourself using random numbers to make a decision you'll generally find it weakens the gameplay. It's always better to work out some proper logic for that decision. And if it becomes predictable then so much the better - gamers love figuring stuff out. |
| ||
| And if it becomes predictable then so much the better - gamers love figuring stuff out. good point,ive never thought about it like that before Note to self:Use proper logic thanks john |
| ||
| it only uses random numbers when 2 things are even. Or in the chance that the AI is still too good picking the best move for the round. Not for picking attacks at random. Example. If the Enemy has 2 characters, both attack mages. The best move might be for one to attack with ice, and the other with fire. Which one should do which? This is a case where it being random isn't bad. But keeping track of that random value is key to makeing the same 'choice' when the future actually happens. Also. Randomly picking between the top 2-3 best case options will add variety, unpredictability, and weaken the AI. I said I would only do that if it was still too strong. If It is too strong, that's terrible, adding some slight randomness expressly to weaken the AI, is acceptable. I love how you all instantly assumed my Finite State Machine AI was a Final Fantasy 2 random-action-monster AI. Even tho I only mentioned Random in a few key locations. Maybe it was from the future bit that you assumed the AI used randomness? You all do realize that things like "Will he hit me in the next round." and "how much dmg will it deal." are acceptable questions to ask? Can you tell me another way to do hits and misses and picking how much damage it'll deal between the min and max damage values I told you about in the AI? Those are random numbers, which have to be stored so you can repeat them. You are just looking for holes in my design.. You won't find any. Not looking where there are none. If you asked me about the storyline for this game, then you'd find holes, I only detailed a small part of it. An outline. |
| ||
| Example. If the Enemy has 2 characters, both attack mages. The best move might be for one to attack with ice, and the other with fire. Which one should do which? The problem is that you don't understand that the problem you're trying to solve, cannot be solved in polynomial time. Look up some classic problems of this type (like the traveling salesman problem).Anyway, even in your specific case there would be at least two better way to chose which mage should do which attack. Depending on the overall strategy for defeating your opponent, maybe one mage has more powerful fire spells, or maybe one has more mana. There are literally hundreds of factors that could be a defining tie breaker, all of which are more suitable than random. Also. Randomly picking between the top 2-3 best case options will add variety, unpredictability, and weaken the AI. You will not be able to find one (never mind 2 or 3) best case options for your AI in a reasonable time (like say 2 days). That's the problem with exponential time complexity. As the number of options increases linearly (like from 4 to 5) the time to find them increases exponentially (like from 16 to 32) Now imagine testing 1 option takes 1 ms, testing only 17 options (to figure out which is best) will take you a day and a half. Besides which you won't need to weaken an AI like this - it's too easy to exploit. Can you tell me another way to do hits and misses and picking how much damage it'll deal between the min and max damage values I told you about in the AI? Erm hello? You said that the AI assumes that it will always hit and always do max damage. Doesn't seem very random to me. The greatest flaw of this assumption of course is that the AI will thus never be able to actually kill a player, except by pure chance. You are just looking for holes in my design.. You won't find any. Actually I think we've pretty much shot down every aspect of your design. You just refuse to listen. Which I suppose you're entitled to. I only detailed a small part of it. An outline. So not so much different from the design really. |
| ||
| "Anyway, even in your specific case there would be at least two better way to chose which mage should do which attack. Depending on the overall strategy for defeating your opponent, maybe one mage has more powerful fire spells, or maybe one has more mana. There are literally hundreds of factors that could be a defining tie breaker, all of which are more suitable than random." Come on.. I was talking about the limited situation where they AREN'T. First move, Identicle mages! "Erm hello? You said that the AI assumes that it will always hit and always do max damage. Doesn't seem very random to me. The greatest flaw of this assumption of course is that the AI will thus never be able to actually kill a player, except by pure chance." I wasn't talking about the AI in that. But. The AI assumes that their attacks will hit and that they will do the higher end of their damage to determine what the best action will be... Which is exactly what players do. The exception being spells with a low hit chance. It might mean instant death, but it only hits once in a blue moon. In this case, the player weighs that more lightly. In mine, the AI will only not pick that spell when it doesn't have the MP or it is in normal mode. "So not so much different from the design really. " Fine.. Whatever. I wasn't copy and pasting the entire 50+ page design document. Believe what you want. |
| ||
| Lets be perfectly clear. Here are the 2 mages. Mage 1 spells - fire, ice. Mp - 56/56 HP - 125/125. Equipment - basic staff, leather armor. Mage 2 spells - fire, ice. Mp - 56/56 HP - 125/125. Equipment - basic staff, leather armor. They sit on a grid like this: Mage 1 is 1 and Mage 2 is 2, the player is P.... O is an empty square. OOOOOO OO1O2O OOOOOO OOOPOO OOOPOO in this situation, everything is even. One of the Ps is weak against fire, the other weak to Ice. Tell me, other than random or always going with fire first, which mage should use fire and which should use ice. I don't want fire to always go first, cause that means when the mage has an even option, it'll always use fire first. Lets make it more simple. There is one mage with both spells, and an enemy that is weak against lightning, fire and ice will deal the same damage. They cost the same to cast. Again.. you either always use fire, always use Ice, or randomly pick one... Or swap back and forth with requires keeping track of what was last.. which is kind of a waste of mem. (I simplified the grid, equipment, and stats. They do not represent the actual game, just a basic obvious example) I'm curious... If both spells cost the same, what difference would it have made who had more mana? Is there some rule in magic that says whomever has more mana gets to cast fire? I think not. |
| ||
| I wasn't copy and pasting the entire 50+ page design document. 50 pages? You expect a programmer to read 50 pages worth of design document? Ever? Seriously. Listen to what people are saying - try working with a programmer first. Unless it's Playboy, no programmer is going to read a 50 page document. Ever. Tell me, other than random or always going with fire first, which mage should use fire and which should use ice. The one with the best line-of-sight? Even if line of sight has no effect on the outcome it would be more natural that the mage with the best shot at the fire vulnerable player, took the fire shot. I don't want fire to always go first, cause that means when the mage has an even option, it'll always use fire first. Of course realistically how often is that going to happen? If the AI is often faced with "race" situations where a whole array of options ultimately have the same outcome, that is an indication of a serious design flaw. If fire and ice are likely to always be "equally worthless", why have two in the first place? There is one mage with both spells, and an enemy that is weak against lightning, fire and ice will deal the same damage. Again, if fire and ice are predominantly identical (that is, that a noticeable difference doesn't occur very often) we are talking about a design flaw. It should not be a programmers task to solve design flaws by arbitrary numbers. It is the designers job to create a design where fire and ice are fundamentally different, and always offer interesting choices. That's why many games for example have Fire damage give additional burn damage over time, and Ice damage slow down the character. Because then it makes a tactical difference between choosing one or the other. An enjoyable game does not present you with a series of choices that are ultimately identical. If both spells cost the same, what difference would it have made who had more mana? It might not. I'm just saying that any good strategy would take that into account - particularly when your AI revolves around trying to second guess the players moves, rather than just picking off the weakest, with everything you've got. Is there some rule in magic that says whomever has more mana gets to cast fire? I don't know. It's your make believe world. Could be an interesting game mechanic. |
| ||
| "The one with the best line-of-sight? Even if line of sight has no effect on the outcome it would be more natural that the mage with the best shot at the fire vulnerable player, took the fire shot." Both have the same, only from the opposite direction, line of sight. I used an example where fire and Ice would both be neutral, specificly. "It might not. I'm just saying that any good strategy would take that into account - particularly when your AI revolves around trying to second guess the players moves, rather than just picking off the weakest, with everything you've got." Who said anything about second guessing players moves? Also. the line about not reading a 50 page design document is laughable. 50 pages is nothing for a design doc. I heard the one for Oblivion was over 1000. |
| ||
| I heard the one for Oblivion was over 1000. Did you also hear how many people actually read it? |
| ||
| People read the parts that were important to their job. The programmers read about the programming related things, the artists, read about the art. The level designers about the level design and so on and so on. Few people read the whole thing, but that should be expected. Why would the programmers read the story? Other than if it interested them.. (Most of the doc was the story outline.. I hate to see the story bible for that game...) |
| ||
| Well, in my experience, the only people who care about design documents are designers. Most people need a more pragmatic approach to development. Most developers I know subscribe to the OHIO principle, which means that they need to make decisions now about what to do. Anything that covers more information than can be quickly evaluated, is simply discarded in the name of efficiency. |
| ||
| Are these AAA developers? Cause everything I've ever read, seen, or been taught says that Design Documents, Story Bibles, Art Bibles and the like are the core control devices of game design. |
| ||
| Are these AAA developers? Depends on what you mean by AAA developers. Is Total Overdose an AAA game? How about any game in the Hitman series? are the core control devices of game design. I didn't say it wasn't. I said only designers read them with any degree of certainty and/or enthusiasm. |
| ||
| been taught There's one thing being taught how to do something, another to learn how to do it. While I have zero experience of large-scale game development, I do have experience of complex software projects. While project control documentation like this is often useful, it is *always* a mistake to assume they are the be-all and end-all. I will *never* use any one methodology / approach to a project RUP / PRINCE2 / JFDI. I'm not saying such processes are inherently wrong, but you do what is needed where necessary and where appropriate. Don't just follow a process by rote because that's what you were taught. I cannot stand people that believe that because they've been taught how to do something in a class (C, VB, management, system design, whatever) that they know best. A lot of people coming out of the education system think this, but until you get real world experience, and realise the flaws of any one rigid approach, you're not worth diddly-squat. You need to be flexible or you'll end up wasting time. That sounds a bit personal - it's not intended to be directed just at you, more a comment on the "what I've been taught comment". |
| ||
| Mark has a valid point. It's one thing to know that tools exist and how to use them. It's another entirely to know when to apply them, and more particularly when not to. Despite all the methodologies Mark mentioned, the most common one is still code & fix. |
| ||
| Bollocks. I didn't say design documents were the end all and be all of game design. I said that people who work at a company that uses these, read them. Otherwise, they are not doing their job. Plain and simple. They may not read the entire document, but joe-nobody at the bottom of the process wouldn't have a clue what his 2D item objects were for without reading the design document. If he didn't read the art treatment sections, If he didn't read the sections that talk about what these items are (lets use the rupee item from any zelda game as an example) he wouldn't stand a chance at making them look right. And if he asks "Hey, boss, what am I supposed to make drawings of?" That boss will say, "Look in the design document, I'm busy critiqueing these character designs and telling the artist who drew them what need's work." The lead programmer can choose to impliment whatever system they think is best, so it might mean that the underlings don't have to read THE design document. However, I'm willing to bet most do, and I'm also willing to bet that 90% of the information provided to them comes from the design document verbatim. Like any company, there will be people who aren't doing what they should be. Those people are poor employees. They obviously don't care about the project they are working on enough to know what it is all about, so why would you expect them to do a good job at what they are being asked to do? |
| ||
| I'd read a 50 page doc if it was my job to code the game. I've read much longer and more boring docs about business software systems... |
| ||
| In 20+ years I don't think I've witnessed anyone actually read a design doc. They are just so much wasted paper for the most part. With a few small exceptions where I've prepared small, tightly focused mini-documents everything is generally done orally. I don't even write them any more unless it's a freelance contract - but even those tend to be shorted concept docs largely dominated by Ste's artwork. And if he asks "Hey, boss, what am I supposed to make drawings of?" That boss will say, "Look in the design document, I'm busy critiqueing these character designs and telling the artist who drew them what need's work." Nah, the boss will just tell him. I love your ideal view of this but it's not something I recognise. Good game design is iterative. Nobody is in a position to write a proper design doc until the game is finished - when there's no point. |
| ||
| yes agreed game design is definitely iterative. The initial doc is a guide and many details need to be worked out, scrapped and redone (often many times) as the development progresses. |
| ||
| JP. How many of the games in that 20+ years had more than 100 people working on it? We actually went over all this in a design class at UAT. We had big huge discussions about design documents and what they are good for. The conclusion was that as the number of people working on a game (and the focus of the school is obviously on the AAA industry, not indie or even small scale games) goes up, the design document becomes more and more essential. Mark Baldwin, the prof, didn't ever work from design documents on his games, however, when he does side-work now-a-days, he always uses them. They are the best way to know everything about a game which you have very little to do with. When he was doing the AI on Metal Fatigue, it was really a toss who was looking at the Design Docs or not. But today, with numbers of people working on a project in the hundreds, the design document is crucial. There are even jobs becoming available in some of the bigger development 'mills' that focus ONLY on document upkeep. People who's job is only to keep track of changes and update the design documents. Additionally. Design Documents are the perfect storage medium for game ideas. You can't ever forget them. This is the primary reason I use them. I can write any game ideas I have, get them down, and then completely forget them. Move on to the next idea. In a small team, they don't do much more than serve as a way to keep track of the initial idea... then again. A small team doesn't need a giant design doc. If your design doc needs to be 150 pages to get all the information down, then that is the best way to keep it down. No team of 2-3 people is going to be making, or I should say finishing a game that big. But if they stand any chance of being able to do it, the design doc is what will enable it. Even if only one person is reading it, that one person knows what is going on, and what will need to happen. Er also. JP, I hope you haven't taken offence at any of this. Someone said this thread is great, because of all the divergent ideas and the freedom of the arguments. At the same time, I don't want to insult people I have lots of respect for. What you do, and have done in the past, are great. I'm not saying otherwise. If memory serves me correctly, you (or your brother) were responsible for some of one of my favorite NES games. Solar Jetman. I don't remember if it was code or art. I think art. |
| ||
| >We actually went over all this in a design class at UAT. We had big huge discussions about design documents and what they are good for. Well if that's the case then my actual experience must be wrong. |
| ||
| We did design docs on my games course but i never liked them. Lecturer said nothing should be in the game thats not in the doc but I thought thats silly, what if an idea clearly isnt working, or one idea spawns another. |
| ||
| I've had loads of ideas that sound great on paper but just don't work when implemented. I've never done a design doc - I just usually start out with a basic idea and let things evolve from there. Some of my better ideas, visual effects etc. have come from plain experimentation. Is it even possible to have a cast iron design doc from the start and stick rigidly to it through to project completion? |
| ||
| Well I just tried out MCF: Ravenhearst and I can see why the MCF games are so successful. It's a really great game and it gets you enthralled in it, then the 1 hour demo time runs out. The object find part of the game is a bit tedious but apparently most people find it fun. If you can make a game that people get into and the 1 hour time runs out and people are like WTF!...I wanna keep going! Then you're in like Flynn! |
| ||
| Like i said, John, If you left the AAA industry more than 5 years ago, or if you never worked on something with a ton of people working on it, you might have missed it entirely. Your expirence can't be wrong. But neither can Mark's. You can both be right, assuming you have been with different teams at different times. |
| ||
| Whatever. |
| ||
| Dampes8N, I admire your conviction and idealism, but you're beginning to seem a bit stubborn. Just saying. |
| ||
| EDIT: Double post. |
| ||
| Who should I trust more. John Pickford someone who has worked on several true classics, or Mark Baldwin a man with some game of the years under his belt. It isn't an easy choice, so I am inclined to believe them both. I'm not so idealistic as to think that all game companies function the same. Nor would I not work with someone who isn't using a design document. Sometimes the game is simple enough for it not to need one. That animated gif I posted before shows all the major gameplay elements of the puzzle game me and chroma are now working on, and we aren't using a design document. It would get in the way more than help. but at the same time, I can't imagine working on a huge project with over 100 people, without some kind of control documentation. Be it a design document, or something else that is in a different format but has all the same information. At a certain point, a Design Document would have to get way too big. I see a lot of games being designed through a wiki. Is that really any different when you get down to the intention? |
| ||
| With a few small exceptions where I've prepared small, tightly focused mini-documents everything is generally done orally. Amen! Right now myself and Damp are just shooting a ton of emails back and forth. With this particular game concept there's really no need for a design doc. There's no story at all (think Mindsweeper) so it's purely game mechanics, rewards, etc etc. Oh and eventually some polish (turtle wax?) I have a bum right ankle and no commitments whatsoever. This might actually get finished... |
| ||
| It better >.> hehehe |
| ||
| How many of the games in that 20+ years had more than 100 people working on it? I think you'll find that even today, the number of games produced by more than 100 people is less than 1%. If you won't take my word for it (or Johns word for it) industry veteran Daniel Irish (Mobygames Bio), claims the average team size is between 20-60 people. (Game Producers Handbook, you can get it of Amazon, I suggest you read it). We actually went over all this in a design class at UAT. We had big huge discussions about design documents and what they are good for. They are good for keeping a project focused, and preventing scope creep / feature creep. The conclusion was that as the number of people working on a game (and the focus of the school is obviously on the AAA industry, not indie or even small scale games) goes up, the design document becomes more and more essential. Well the conclusion was wrong. As the number of people go up, design documents become less important, and DUR's become more important. The ideal configuration for productivity is autonomous groups of between 4 and 8 people. So if you have a larger project, you break it down into tasks that are solvable within your timebox (usually 14 days), by the team that's taken on the task.You then use some sort of process management tools (you can use Gantt charts and Microsoft Project, or you can use SCRUM and divide your work into Sprint, Release and Backlogs, or you can use XP, TQM, or whatever other process management tools take your fancy. You can even mix and match between them). There are even jobs becoming available in some of the bigger development 'mills' that focus ONLY on document upkeep. Yes. Why do you think these jobs are available? To paraphrase Fred Brooks: "It is more cost effective to have good programmers develop and mediocre programmers document". Congratulations, you just landed a job that involves keeping 1000's of pages of information up to date, so you can tell the programmers what they need to know when they ask, so they don't have to spend their valuable time sifting through hundreds of pages of irrelevant drivel. Additionally. Design Documents are the perfect storage medium for game ideas. Actually that would be Treatments. The Design Documents main purpose is to prevent feature creep and thus it's a really poor choice for keeping track of game ideas. Who should I trust more. John Pickford someone who has worked on several true classics, or Mark Baldwin a man with some game of the years under his belt. Like I said, those who can, do. Those who can't, teach. In any case Mark Baldwin is not credited with Metal Fatigue on his Mobygames Bio, he might want to rectify that if he did indeed work on the game. From what I can see tho' he was mainly involved with Empire and Worms sequels. As for who you should trust more, I don't think anyone really cares - should you land a job as a designer, you'll learn soon enough how many people bother to read design documents. We can talk again then. I see a lot of games being designed through a wiki. Is that really any different when you get down to the intention? Yes. Although it greatly depends on how concise the designers are. |