• Announcements

    • khawk

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

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


  • Content count

  • Joined

  • Last visited

Community Reputation

238 Neutral

About x4000

  • Rank
  1. This is a question I'm getting asked with increasing regularity: what advice do I have for other indie developers, or aspiring indie developers? Here are some observations I've had from developing, releasing, updating, and promoting AI War. In many cases I'll leave you to draw your own conclusions based on these observations, but at the very least it will provide first-hand data you did not have before. Bear in mind that the landscape has changed dramatically since I originally developed many of these ideas; the rise of the indie was only just starting in 2009, and I randomly happened to be traveling right along with that wave without realizing it. Lucky timing on my part. Most of this advice still stands however, which is why I chose to share it. Not only has the market changed, but my position as an indie developer has, too. AI War has gone on to make over a million dollars in gross sales (and still steadily growing each year), which in 2009 would have made it a clear and unmitigated indie darling. Instead it's what I would call a "cult classic," and there are now tons of such games that you've never heard of. The market has grown substantially, and the Primacy of the Niche cannot be understated for most indies. You still get the standouts like Minecraft or Monaco or Limbo or Journey that larger-than-average audiences have heard of, naturally. But I'd say that the old "indie darling" field of about 1-5 per year has grown to 10-40 per year, and then there is this huge "very profitable niche game" market that likely sees as many as 1,000 games per year at this point (counting mobile). Remember, the mobile "app store" revolution hadn't even begun yet at that point in 2009, and that changed everything for a whole lot of indies, too. It's hard even to quantify the size (in terms of number of games, or total earnings, or average earning for game in any given category) for indie games at this point. Apple and Steam have the lion's share of that data, but even their data is very incomplete. There's no sort of global way to categorize sales rankings at the moment. The One Ultra-Secret Surefire Path to Indie Success I don't think there's any one path to success -- now more than ever. There are indies doing all sorts of crazy things all over the place, and the market actually supports that! It's amazing. There is no better time to be an indie, in terms of the opportunities out there. Most people have at least heard of the indie movement, and there's a huge following of it in general that is hungry for the new and the interesting. And even those who are not interested in the concept of "indie games" for its own sake are often interested in specific genre niches: wargamers, for instance, want good wargames whatever the source. Simulation game fans are hungry for more simulation games, and the AAA studios are not forthcoming. So where do they go? Indies, naturally. The main advice I have is for people to follow their own passions and to find the communities that share those passions. If you're passionate about something, odds are that a lot of other people are too -- the world, and the Internet, is a big place. You may never meet another person in casual real life who shares your passion, but that doesn't mean there aren't hundreds of thousands of people in the world who share your passion. If you can find those people, there's your market. Build something that you delight in and that they will also delight in. Then let them know it exists, in a way that isn't scummy or cloying. Then see if there might be an even wider market, and if you might be able to get on some of the bigger distributors. Or check out something like Kickstarter if you need funding in advance for art or whatever. But have a great prototype before that point, and be prepared for the repercussions of suddenly having lots of backers with very specific expectations that you will likely not be able to fully meet. When something does not yet exist, people form very different ideas of what will come to exist in the future based on what is described. Words are imprecise, and visions shift subtly (or not so subtly) anyhow. You don't need funding to have a great idea. Nor do you need funding to develop something in your off-hours as a hobby. If it's not worth it to a potential indie as a hobby, then probably game development isn't for them; game development is a lot of work, and if they don't love the process then the industry will chew them up pretty hard. There are plenty of examples of games with terrible or mediocre graphics that have gone on to sell really well anyhow because of the strength of their ideas. And with Kickstarter now being a thing, the graphics don't even have to be bad if you can convince enough people that your idea is awesome before you finish making it. It doesn't take a ten million dollar budget to make a game that is attractive -- whether or not you think my games are attractive, that's beside the point. There will always be people who disagree with a given aesthetic, and who are turned off by it. But with the right idea, it doesn't matter. There are innumerable Minecraft videos that start out with the sentiment "The graphics are effing horrible, but check this out!" Personally I think Minecraft has a great aesthetic and is really pleasing to look at, but obviously that's a matter of taste and not everyone agrees. Part of being an indie is accepting that universal appreciation is never coming your way. My other main takeaway remains the same: people are too quick to give up and concede defeat. I said that in August 2009 when I had managed a mere $30,000 or so in sales and was feeling pretty good about that after a very slow start. That was not bad at all for indie developers, and on Impulse (back when it was a bigger force), that was enough to net us the #4 to #2 slot on their top-sellers chart from time to time. This was pre-Steam for us. Then we hit Steam later that year, and it's just been growth ever since. I would never have predicted in 2009 that we'd ever reach a million dollars gross. But through ongoing updates and support and persistence, that's what happened. If I just threw my hands up in the first two weeks after release, when I literally had zero sales, that would have been not just my future career thrown away, but also the careers of everyone who works at Arcen now. The things you learn, eh? My Advice to Indie Developers Make what you want to make. You are your own first audience. If you don't think a game is fun, nobody else will either. If you don't want to play your own game, ask yourself why. Often that will spark ideas on how to fix some underlying problems you didn't even consciously realize you had. Prototype! Almost no game is fun at first, despite sounding great on paper. Prototyping lets you figure out what the sticking points are and address them, rather than just rushing something out the door that has all those original flaws. Make something original! If you're just making a clone of some other game, or a clear homage with some minor twists, expect to fail. Bigger studios will have better production values, and typically more polished execution, than a new indie studio. Where most of the top indies shine is in their creativity, if you think about it. Don't ignore PR and marketing. Those are "bad words" to a lot of people, but they don't have to be. All it means is telling people about your game, and sharing your passion for it. It does not mean spamming or astroturfing or doing other unethical things. But if you don't tell people about what you're doing, you will be ignored. When it comes to the press, often if your pitch for your game does not immediately grab them, it goes in the rubbish bin -- they get too many pitches as it is. So make sure you have a clear, concise, strong explanation for why your game is worth their time. If other review sites are saying awesome things about your game, feel free to mention that to the other outlets along with other news about things you are doing to make your game even better. Aka, "here's our latest post-release patch with all sorts of awesome new stuff for free for players, and also look what site X had to say about us!" Persistence pays off, but keep to the limits of being polite and respectful. The following observations were written back when AI War was publicly available for only a few months but the advice still holds Observation: Getting Started Is Slow I've had a publicly-released game for only around three months now. That might sound like a long time, but if you're an indie developer with no prior connections and no "easy ins," you're still just warming up. I think that a lot of indies think that their game will either live or die in that first month (I know I did), and I'm finding that this is patently untrue. If I had given up after that first month, I would literally have had around 50 sales total. That's still not bad for an indie game -- unfortunately, most sell extremely, extremely, poorly. However, if I had given up after that limited amount of time, or if I had stopped trying to get more publicity for the game, I'd have missed out on month two, which had around 8x as many sales as the first month. And each month since then has had even more sales than the last. So I guess there are a few takeaways from this. First, don't give up too quickly or let yourself get discouraged by early indifference to your product. Secondly, don't quit the day job unless you can afford to go months or more without pay, even after your game is released. Expect to put in some serious time even after your game is out. Observation: Every Indie Game Is Different There is no "common path" for successful indie games. There are perhaps a very few things they all have in common, but generally speaking they all entered the market differently, made a name for themselves in a different niche, and then got noticed by the wider gaming press. Some of them had an easier time of it than others. My Three Major Classes Of Indie Game Or, at least, this is how I think of it. Here they are: 1. Indie Darlings: These sell tens of thousands, or even hundreds of thousands, of copies. You've read about these in gaming magazines and on mainstream gaming sites. Everyone who follows gaming news has heard of the biggest of these, but even the smallest of these have quite a huge footprint. There are very few of these as compared to the other two categories. You know the big boys from this category: World of Goo, Braid, etc. A lot of these are also winners of the various major indie gaming contests, but not all of them are. 1.a. Indies With Publishers: This is a corollary to the indie darlings category, really. Some indie companies actually do form relationships with publishers and this leads to a massive amount more sales and a fair bit more press. Since the indie developer did not receive money up front from the publisher, and since the developer still has full creative control more or less, they are still considered indie, although it is borderline to some people. Examples: Locke's Quest, Supreme Commander. 2. Undiscovered Gems: This is a much larger category of indie games. Basically, these games are not failures, but neither are they remotely near the darling category. Most of these games sell a few hundred to a few thousand copies -- in a few cases maybe a couple of tens of thousands. They might get some spotty mainstream gaming press coverage, but not much (if any). They might have contest wins, but none of the really big ones. They do tend to have some coverage from the various indie-focused websites. Often these games have a really passionate, if small, fanbase. These are quality games, so if they are able to find any publicity at all they will find something of a fanbase, but without serious effort on publicity they will never be very successful (and depending on the game, it might be so niche or hardcore that it never finds a sustainable audience at all). 3. Hobbyist/Nonprofessional: This group is the largest by far, basically comprising anything that a person just slaps together in however much time. Generally there is not much discipline in creating these, nor a great sense of design. Some are really fun and worth playing, most are not. But! Most real game designers start out like this -- I created a large number of games I would consider in this category, although I never publicly released most of them. They were an invaluable learning experience, but if I had expected to make a business out of them that would have been laughable -- selling 100 or even 10 copies would be pretty ambitious and would mostly depend on how many friends you have. Why The Categories Matter Objectively determining what category you fall into out of the above is very important. If you're reading this blog looking for advice, you probably fall in or near the undiscovered gems category. If you're an indie darling, you know it, of course (I'm not, for the record). If you're in the hobbyist category you may not know it. But if you just can't get any sales no matter what you do, then you might have to realize that you are in that category. That's okay! Most of us started there. The realization is important because you need to realize that there is something your game is lacking. You need to either make your game better, or you need to make a new game based on what you now know after having created the first (the code architecture of first-games is often so bad that it's better to just start fresh... I know I did). Similarly, if you are in the undiscovered gems category you are also missing something -- either that "indefinable something extra" that makes the big games really stand out, or else publicity. Or both. Figuring out what you are missing and addressing it is the key to moving up, near as I can tell. So where is AI War right now? We're an undiscovered gem at present, but we're getting a lot more coverage recently, and that's been helping sales trend ever upwards. We've also got a potential publication deal in the works, which could really boost things even more. We'll see. Observation: You Need Distribution Partners To hear 2D Boy (the creators of indie darling World of Goo) tell it, all you need to do is put up a website, make a great game, and people will flock to your site. I have not observed anyone else who has seen this as a workable strategy. For AI War, in our first two weeks of doing exactly that, we had precisely zero sales. It wasn't until we got picked up for Stardock's Impulse platform that things really started kicking off. 2D Boy had an awful lot of publicity before putting up their website. So, instead, my advice is to pursue as many distribution partners as possible. Only the ones that give you a fair royalty rate (most of the time I get 70%), and those which are non-exclusive so that you can cast a wide net, but otherwise just go ahead and keep casting as wide a net as possible. The specific sites you will submit to also vary by genre. But having a website and an ecommerce partner there is also a good idea. Observation: Art Is Not As Important As Indie Developers Think Aspiring indie developers get really hung up on the art in their games. So much so, that many of them never really finish anything substantial. You can't expect an artist to work for you for free -- they're wise to the fact that most of the time the programmer/designer is going to flake out if this is their first project. So do what you can with the art that is freely available out there (there isn't much, but there is some), and otherwise just use placeholder art. If your game is awesome and fun, then you can better attract an artist or you will be better justified in investing in art yourself. Observation: Art Is Really Important It's just not as important as new indie developers think it is. You can't expect to have great art from the start unless you are lucky and know a great artist, or have large stacks of cash just sitting around. But you can still make a fun game that will attract something of an audience. Just be ready to either make a bigger, better, prettier sequel after that, or to upgrade the art on your first game. Depends on how big your first game is, and what the potential market for it is, and how bad your initial art really is. Art clearly matters in moving copies of indie games, but it's not the only deciding factor. You can sell pretty well with fairly poor art, you'll just sell better with better art (all else being equal). Observation: No One Cares About Your Game. Until They Do. Getting that first sale is brutal hard. You need a good demo, good marketing materials, a good sales pitch in general. You have to get someone pretty excited about your game to shell out for something they have never heard of before. If you can get some positive early reviews, that will also really help. Having a distribution partner will also help, if you can get one. You basically need a way to show potential customers that you are for real, that you build something worth paying for, and that they can trust you with their credit card or other personal information (this can be simply offering paypal as an option, or whatever other reputable ecommerce platform). Until you start getting some notice, no one is going to want to notice you. It's a very chicken-and-egg sort of situation. There are too many indie games out there, most in the hobbyist category, and especially if your art is not great people will usually assume that's the category you are in if they have never heard of you and their first contact is from you soliciting them. Eventually you will find some people who will take a chance on your game; if you impress them, then you can move up a few notches in exposure and find more people who will take a chance on it. If no one is impressed after taking a chance on it, then you're probably in the hobbyist category without knowing it. That's not the end of the world -- either make a new, better game and try again, or solicit feedback from your early chance-takers and then improve your offering before you find some more chance-takers. One blown chance is not the end of the line, although you can't afford to blow too many of them with one game. Observation: Publicity Comes In Waves Whether you like it or not, the entire gaming community is unlikely to suddenly sit up and notice your game. There are millions upon millions of gamers out there, and they don't all do anything as a group. When you're starting from scratch, with no reputation or contacts, you basically have to scrounge for anything. Each bit of publicity you gain makes the next just a bit easier. You have a bit better story to tell to potential reviewers (e.g., "Reviewer X loved it and I was wondering if you also want to do a review since you like the same genre."). You will also have players who may be willing to do some publicity of their own, such as talking about the game on other forums, to their friends, etc. I can't stress enough how vital word of mouth is to the startup indie developer. People like seeing positive reviews, but have a mild distrust of that since they don't know if the reviewer's criteria are the same of their own. People also really mistrust anything that the developer says unless the developer has a really sterling reputation (which is why you must never exaggerate or say anything false about your games, incidentally). But people greatly trust the opinions of friends and acquaintances, whether online or off, so personal recommendations like that are the absolutely best sort of publicity you can get if it's on a large enough scale. If you're lucky, persistent, and patient, you'll see your publicity gradually snowballing into bigger and bigger waves of coverage. That's assuming you have a game in the undiscovered gem category or above. Every so often you should send out more press releases or review requests -- the sites won't ever talk about your stuff if they don't even know it exists. Observation: Uniqueness Counts When you are telling people about your game, what do you say? Do you hem and haw and say, "well, it's hard to explain but it's fun?" If so, you're digging your own grave. If you say "it's a clone," you're also shooting yourself in the foot. When people think of indie games, they aren't looking for "like that other game but not quite as good." They're looking for something they've never seen before, that the AAA publishers would never dare give them. If your game is just a clone of some other game, maybe you can find something of an audience, but I wouldn't know anything about that. I can't imagine it would be a sustainable business. It's okay if your game has some similarities to other games -- every game does -- but you also need to offer something genuinely new and startling. Look at all the biggest darlings, and all of the best undiscovered gems, and you'll see this trait with all of them. There is something very defining and unique about each one. Tip: Refine Your Story When you are trying to explain your game to reviewers, to potential customers, and to people you meet on the street, you need to have both an elevator pitch ("AI War is a space-based RTS game with incredible AI and huge unit counts."), and you also need to be able to succinctly explain what is going on with your game at the time. Why is this game exciting? Why should the person take time out of their day to take a closer look at it? This is an evolving process, and takes a lot of work on your part. I highly recommend learning how to write a good query letter, and the best source of information I know about that (although related to book publishing) is literary agent Nathan Bransford's blog. Just so that you can see what I mean, here are some evolving emails I've used over the past few months (with extra personalization as needed for given sites or individuals): A Very Weak Query, Circa early May 2009 Hello, I'm the CEO of Arcen Games, a small indie developer. We're nearing release of our first game, an RTS called AI War. The game has incredible AI and the largest number of units (30,000+ in most games) of any game we know of. It's also cooperative-focused, which is quite unique. Through a Gamasutra article I found your site, and was hoping to get more information about who you are and what sort of opportunities there might be to work together. For screenshots, and more info: http://www.arcengames.com/ Getting a bit better, same week: Indie developer Arcen Games has just made public an advance release of the RTS game AI War: Fleet Command. This is a pretty unique game, with several firsts for the genre. - Cooperative RTS game (1-8 players) with numerous unique ship types. - Challenging AI (some of the best in the genre) in 26 styles, many with unique superweapons. - Insanely high unit counts: 30,000+ ships in most games. - Lengthy campaigns featuring 80+ simultaneous planetary battlefields. - Different Every Time: 16 billion procedural maps, each with specific units. - A focus on deep strategy that you don't get in most RTS games. This is a game created by genre veterans for genre veterans, but that doesn't mean it's inaccessible for players new to RTS games: robust tutorials, a simulated campaign, and a free online mini strategy guide make it easy to get into the game, but hard to master it! The Arcen Games website, with screenshots, videos, a mini strategy guide, and the demo: http://www.arcengames.com/ Thanks! Chris Park CEO, Arcen Games, LLC Much Better, Much Later -- Mid-July Hi there, I'm the developer of AI War: Fleet Command, an indie RTS game for the PC. We're fairly little known so far, but are one of the more popular titles on Stardock's Impulse, and are getting a pretty excellent player community in our forums. The game is a cooperative space-based affair, with some of the best AI in the genre (I did a recent podcast on that on techZing! in addition to a series of articles on the topic at my blog: http://christophermpark.blogspot.com). You can see screenshots and videos of the game, as well as download the demo, from our company website: http://www.arcengames.com/ If you'd like to do a review, please let me know and I'd be happy to provide a license key to unlock the full game from the demo. Additionally, if you're interested in doing an interview about any topic relating to the game, I'm always game for that (the AI has been the biggest point of discussion so far, but some players have been suggesting that it would be interesting to hear more about the decisions behind the unique and effective "AI Progress" mechanic in the game, or other similar game design topics). Best, Chris Park Arcen Games, LLC Beyond The Basics In other, later missives I was also a lot more personalized, mentioned various specific positive reviews, and talked about how this was not a traditional RTS but something of a novel blend of grand strategy, tower defense, RTS, and even with a few TBS influcenes even though it is 100% realtime. I have sent several hundred emails out to various parties about AI War, and my response rate overall has been pretty positive -- maybe 10% aggregate at this stage. These days my response rate is much higher, approach 80-90% because more people have heard whisperings of the game and I have a much better story (having had some really posive reviews from bigger sites), but early on in the response rate was more like 3-5%. This is why you have to submit to so many places! You don't know who will respond, and until you do you need to cast a wide net. If I had just made a good game, and then gotten on a distributor or two, most of the publicity for AI War would never have happened. It's just a fact. Similarly, if I had not had a number of players out there evangelising for the game, a lot of sales would never have happened. Properly promoting, supporting, and updating a post-release game is a fulltime job in itself. Be prepared. You can do a halfway job with it if you are lucky, but if you are not lucky you are once again setting yourself up to fail where you might otherwise have succeeded. In Conclusion If you thought this article was going to be advice about making a good game, then I bet you came away surprised. Making a good game is just the beginning, just as writing a good novel is only the beginning for novelists. If you read much advice for aspiring novelists, almost all of it also applies to indie developers. You need to begin by doing something awesome and startlingly new, and then you need to follow that up with lots of elbow grease, long hours, and promotion efforts (which can often be frustrating and/or distasteful depending on your personality). Anyone who thinks that being an indie developer is easy, or a path to quick money, is sorely mistaken. There is a high chance of failure, the rewards are not great unless you do above-average or better for the market into which you are entering, and it involves a heck of a lot more than just programming/designing a game. You have to be your own marketing department, sales force, PR firm, accountant, and support staff. And you have to do a stellar job at all of those different jobs, or you're only reducing your already poor chances. Granted, making a great game is what counts the most. All the PR in the world won't save a poor game, and will only make people mistrust what you say in the future -- did I mention to never exaggerate about your work? So none of this applies if your game isn't already up to snuff. But what most people fail to realize is just how much work is still involved once you have a great game in hand... and how many chances you have to still fail and languish in obscurity. There isn't a great deal of organized information about this sort of thing out there for indie developers, but you only have to look to book publishing to see where all of this is headed. The steep slope ahead of an aspiring novelist is even taller than the slope in front of the indie developer, but they are very similar slopes all the same. The indie games industry is too new to have much advice around for you to peruse, but if you look at the advice for novelists, you'll have a wealth of mostly-relevant advice. A surprising fact you might not know: most novelists, in fact almost all of them except the bestsellers, aren't making a living out of being a novelist. I kid you not, google it and see. That's pretty sobering. The rewards of indie games development are potentially much greater than the possible rewards you would see for your average aspiring novelist, but you also have a whole team of people to support rather than just a single writer. Most indie game developers aren't making a living at this either, from what I can tell, although the best certainly do. And to be the best, you've got to have the whole package. In the end, "the whole package" can be summarized rather neatly: you have to have a game worth playing, and people have to hear good things about about it and be able to buy it at a price they find fair. That's surprisingly harder than it sounds. You can do it, but you'll go a lot further if you consider the pitfalls and prepare for the post-release work before you actually do release. Indie game development is very much a profession, not a hobby, and it comes with all the rigors you would expect from a profession.
  2. @j-jorge: Ah, ok!  If it's a blitting infrastructure, then absolutely your way (and your proposed second step for improvements) are clearly the best method by far.  Overdraw is such a huge issue with blitting methods, for sure.   Anyhow, glad to hear the hints might be helpful for your new OpenGL methods.  I too started with blitting methods (DirectX7 back in the 2002-2003 era), and moving to the 3D approach was really worthwhile but also challenging at first.  There are still some vertex optimizations that I'd like to do but don't know how to do in an efficient way.  I need to sit down with it more at some point, but I'd been focused on the low-hanging fruit of the textures and such prior to that.
  3. What sort of rendering pipeline are you actually using?  Is this using older-style blitting?  If so, then I think your approach is ideal, although the blitting methods themselves are not very hardware accelerated and thus possibly not the best if you're going to have lots of transparency and other elements.   You might consider doing some more specific profiling to see exactly what is causing your FPS drops.  What this article concerns is pixel fill rate on the GPU, and certainly that is something that is a limiting factor.  But it's really mainly a limiter on older GPUs at the scale of the graphics you're using here, whereas there are some much tigher bottlenecks even on very new GPUs.   The constraints I'm speaking of are material swaps (where textures and such are sent repeatedly to the GPU back and forth during one frame) and the number of "draw calls" in many engines, which mostly just means how many vertex sets are sent.   For myself and my own work, I've focused on reducing material swaps in the main, and then to a lesser extent focused on reducing pixel fill rate and draw calls.   The main thing with reducing material swaps is sorting the draws per layer in the scene, by material, and then not switching materials between draw calls if the new material is the same as the last.   For reducing draw calls, my main approach has been to omit compeltely obscured sprites, as you have here.  But also to combine smaller sprites that share a texture into one larger sprite if they are contiguous, which seems the opposite of what you are doing here.  It seems like your approach will lead to a lower pixel fill rate requirement, in other words, but to a larger number of draw calls.  I am not sure this is a good tradeoff, but you'd have to profile it in your specific engine in order to really see.   There are some other indies I know with vastly more sophisticated techniques than what I'm using.  They are using geometry combination methods that reduce the draw calls even for non-contiguous usages of a given texture, and I believe even across draw depths.  And through the use of sprite dictionaries for way more things than I tend to use them for, they're also achiveing vastly fewer texture swaps, too.   I'm really impressed with what they are doing, but like you I think that optimization should only be taken so far, since there are always downsides.  In my case I feel like those sprite dictionaries and so forth slow development to an unhelpful degree when there are lots of sprites (one of my games has north of 5000 individual sprite frames), so there's always a tradeoff there.   Doing the sub bounding boxes that you were suggesting as the next step would certainly be possible, but I think you will get diminishing returns from that compared to what you have already done.  And, as I think you somewhat implied, I think the work for that next step of the sub bounding boxes will be a lot more than the work that it took to get you to this point.   Anyway -- very good article, and I like the way you were visualizing the pixel fill repetition.  Very clever!  I would suggest texture sorting for material swap reduction, and then geometry combination for draw call reduction, as the next avenues for getting your fps higher, though.   Cheers!
  4. Thanks, Promit -- that's what I needed to know!
  5. Okay, this might be hugely elementary to some of you, I don't know, but I have been scouring the internet and can't figure it out. My problem is simple to describe: I have a sprite image (2D texture) that I am rendering using the Sprite class in SlimDX. I can use the diffuse color to change the color of these sprites, and in general that works fine, but in some cases I really need to just do a hue shift without affecting saturation or luminosity (which diffusion destroys). Is there a way to basically take a hue value from a System.Drawing.Color (or SlimDX.Color4) object, and then somehow apply that hue shift to the sprite? I'd love it if there was something as hardware-friendly as setting the diffusion, of course, but I really can't find anything. I presume this might involve shaders, but I am concerned about overhead if I use a pixel shader, and I need to be able to choose the hue at runtime, not design time. One possible solution would be to use GDI/System.Drawing to make multiple copies of my texture, each with the hue properly shifted, but then that increases my texture count and makes this something I have to use even more sparingly. And I can't really find a good method for doing a hue adjustment in GDI any more than I can in SlimDX (though I put less time into the GDI side of things, because I like that method less for a variety of reasons). I'm basically looking for the most efficient way possible to do a hue shift at runtime in SlimDX or at least through SlimDX. If it involves pre-converting some images at runtime startup that is livable if it will save framerate, but that will make this a lot less functional for me for future projects and uses. I was really surprised to basically find almost no information on any approach that might work, though -- maybe I'm just not searching with the right keywords, I don't know. Thanks in advance for your help!
  6. Okay, just for reference in case anyone else runs into this. Promit and I carried on this conversation some by email, and he figured out that this was an error code that actually CAN come back from that method if the buffer is filled by too much data, which is what I was doing. Strange that only one user ever had a problem with this, but evidently something about his machine was causing the limitation that no one else had. As a solution, I wound up converting an MDX Directsound streaming solution over to SlimDX. I've posted the code and notes here, as well as links to the original article my work is based on: http://christophermpark.blogspot.com/2009/06/how-to-stream-ogg-file-using.html Hope that helps, if anyone else is running into this at some point.
  7. I successfully used the force feedback effects in MDX, but never this particular GetParameters method that I recall. I can't believe something like this was lurking under the hood the whole time. I mean, what a potential timebomb if I had happened to use that particular method.
  8. Hi, thanks for the response -- I'll try adding software mixing as an option, and see if that changes anything for the user. If not, I'll escalate to MS -- do you happen to know the best place to reach them for Dsound issues? Thanks for the response! Chris
  9. I hope this is not another user machine error, but I wanted to run it by you guys and see if you have any ideas on what this might be. I've quizzed the user in depth, he has reinstalled SlimDX (March 2009 SP1), DirectX 9.0c, etc, and he seems to have all of the .NET Framework versions installed and up to date. All his dxdiag results look okay to me, too, but I'm no expert. Here's a thread with more information straight from the user: http://rpgcodex.net/phpBB/viewtopic.php?t=33102&postdays=0&postorder=asc&start=21 The issue is that whenever the code calls the Play method on SecondarySoundBuffer, the following exception is thrown: SlimDX.DirectSound.DirectSoundException: E_OUTOFMEMORY: Ran out of memory (-2147024882) at SlimDX.Result.Throw[T](Object dataKey, Object dataValue) at SlimDX.Result.Record[T](Int32 hr, Boolean failed, Object dataKey, Object dataValue) at SlimDX.DirectSound.SoundBuffer.Play(Int32 priority, PlayFlags flags) This same code is working fine for dozens of other users, many who are on the same OS and machine as this user, so clearly something must be out of whack with his underlying stuff. But after he's reinstalled basically everything relevant, I can't imagine what it is -- I don't know if this is something in SlimDX that is failing, or if it is lower level, down to something messed up in the user's DirectX installation. Any thoughts? Thanks in advance for any help you can offer!
  10. I recently finished programming the first game for my indie games development company, and I'm really pleased with the end result. However, that doesn't mean that there were not a LOT of headaches during development and design, especially in the earlier months. Most of the headaches, from a design perspective, really revolved around the fact that the game is set in space. I was completely accustomed to terrestrial RTS games, and figured I could just apply what I knew from there to a space setting -- I was mistaken. Fortunately I use an iterative prototyping process, so these issues were able to be figured out in a series of prototypes, and the final product I think is actually more unique just because we ran into these challenges and had to think up new solutions. I've written two articles about the various challenges we ran into, and what our solutions were. Feel free to use those ideas in your own games, if you are so inclined: Designing Games In A Vacuum, Part 1: Terrain & Positionality Designing Games In A Vacuum, Part 2: Units, Walls, and Caps
  11. My small indie comany, Arcen Games, has now released our first game, AI War: Fleet Command. It has a number of unique features: - Cooperative RTS game (1-8 players) with numerous unique ship types. - Challenging AI (some of the best in the genre) in 26 styles, many with unique superweapons. - Insanely high unit counts: 30,000+ ships in most games. - Lengthy campaigns featuring 80+ simultaneous planetary battlefields. - Different Every Time: 16 billion procedural maps, each with specific units. - A focus on deep strategy that you don't get in most RTS games. This is a game created by genre veterans for genre veterans, but that doesn't mean it's inaccessible for players new to RTS games: robust tutorials, a simulated campaign, and a free online mini strategy guide make it easy to get into the game, but hard to master it! The Arcen Games website, with screenshots, videos, a mini strategy guide, and the demo: http://www.arcengames.com/ [Edited by - x4000 on May 12, 2009 2:20:32 PM]
  12. Hmm, I've finally got a new version that I'm doing a build of the installer with, and this file path didn't work (with or without the environment variable). I've even tried to go to that path manually on my machine (I am windows XP 32bit), and that wasn't there. Interestingly, I did find the SlimDX.dll file in the direct C:\windows\assembly\ folder, but my installer tool can't detect it -- nor can I pull up that file with that url in explorer (it says file not found when I do that, even though I can clearly see the file in that folder in explorer itself). My conclusion is that there is some sort of special hook in explorer that is displaying the GAC in a manner counter to how the files are actually stored. Do you know anything about this, or how to get around it?
  13. Mike, thanks for opening the issue!
  14. Note: On the DirectSound side, if I take out the memory stream (and thus the conversion from that to an array), that save a lot of memory. Of course, then I'm wasting memory because I've got one static array that I use for prebuffering (before creating a secondary Buffer). That array needs to be 50MB in order to handle the largest uncompressed ogg files I'm likely to have. At the very least, it's way easier on the garbage collector, so that's something -- but I'd still prefer something more like what XAudio2 is doing, just without the performance tanking.
  15. Hi, I'm using SlimDX for my current project, but in the past I've always used DirectShow for music. I've been unhappy with a lot of things about DirectShow, but it was very low latency on playback and very light on memory. In SlimDX, I've put together two solutions, one based on DirectSound and the other based on XAudio2. I have a way of loading ogg files as a stream (using another component), and that works fine and is plenty fast. However, the issue with DirectSound is that I have to load the entirety of the compressed stream into a memory stream, then convert that into a byte array, then pass that into a secondary buffer. This creates a really huge amount of wasted memory, on the order of 60-70 MB for a one or two minute music file (2MB as compressed ogg). It would be really nice if I could just somehow plug my stream into DirectSound in SlimDX, then set how much prebuffering I want it to do. I don't see anything like that in the SlimDX DirectSound classes, though... On the XAudio2 side, the streaming is of course very straightforward, and memory usage is vastly better. It seems like a very efficient solution overall. However, the big problem that I have is latency with this one. In the game, of course sometimes the CPU is very busy, and whenever there is a particularly long game cycle (where the video hitches slightly) the audio also hitches. This is completely unacceptable, especially since it does not hitch at all with DirectSound. I'm running this on a quad core, to boot -- there's plenty of CPU power available, just not on the primary thread at those instants. In DirectSound you can set the priority of the DirectSound processing, but in XAudio2 you don't seem to be able to. In XAudio2 you can set what processor it should run on, but that seems to have no effect. The XAudio2 hitching might also be an IO contention issue, I'm not sure. If that was the case, then I need to be able to set how much prebuffering gets done in XAudio2. From some of the MSDN docs it sounds like that should be possible, but I see no such settings in the SlimDX implementation. I guess all that is handled internally to your library? Any chances of us getting access to it? A solution to the issues with either approach would make me happy, I'm not picky. I basically just need the quality/performance that I'm getting with Directsound, with the memory efficiency / streaming of XAudio2. If there is no solution available, then I guess I'll just have to live with the memory wasted by the DirectSound approach. Any help is much appreciated!