How *not* to make it as an Indie...

**wazoo** · 09-08-2005 11:41 AM

After several false starts in trying to get something accomplished as an Indie, I think I'm finally on my way..*cross fingers*

I thought I'd post some thoughts for others who might be starting out but are having a difficult time getting started.

1 - It honestly doesn't matter what platform or language you use. Everyone here gets VERY focused on what version of DirectX you should use, or what language you should/shouldn't use. Why you should/shouldn't use OpenGL/blitz/torque/SDL/etc...

Bottom line: Who cares? The top priority should be finishing the game (especially if this is your first).

2 - See 1. It's so important you should read it 2x

3 - Sometimes knowing TOO much about everything can slow your progress. I envy those who only know how to use Blitz3D for example. My problem is that I'm fairly knowledgeable about a lot of the tech....which causes me several delays similar to those Ogre units from Warcraft2:

"*This* way" "-No *that* way!"

Pick a language, pick a platform and just go for it. Ignore the constant "noise" around the pro's and con's of each. Once you get serious and actually finish some games THEN I think you can make more of those "business focused" decisions based on what you want to make and how you're trying to reach.

These are just my 2 cents, but I'm just so happy to be back Indie-style.

**Nexic** · 09-08-2005 01:28 PM

To be honest I would disagree with you to some extent, choosing a good platform is important. However of the ones that are good, you shouldn't really spend too loong thinking about them. Just stay away from DirectX 8+, anything that refuses to be wrapped (gamemaker for example), or anything that is too slow (DarkBasic).

Also you should try not to use up too big a budget for your first title, as there is a good chance you won't make it back. Instead try something low budget to get experience. Then once you know what you can realistically expect you can remake the game with higher production quality, or go for something else. But getting a couple of games out will teach you exactly what you can expect.

Another way to fail is to make games that clearly aren't popular, like I do!

**KNau** · 09-08-2005 05:18 PM

Another way to fail is to make games that clearly aren't popular, like I do!

I second that one! Although I can counter your Dark Basic argument since my first and financially most successful game was done in DB. But I understand your point and I would never go back to it

From my own experience I will add that you should also develop games that interest you; the old "from the heart vs. chasing the money" argument. If you are making a game that you love then you are more likely to do it well and more likely to succeed. The net is littered with shoddy, half-assed puzzle games designed to cash in on the milf market. You don't have to go that way to make good money, in fact the growing body of evidence shows it's a sure recipe for failure.

My first game was made because it's something I thought would be fun to play and it has done the best. I followed it with 2 crappy puzzle games that bombed horribly. I followed those with a generic puzzle game that I was fun (a mix of the two strategies) and achieved mixed results, still mostly bad.

Whenever I get around to making another game it's going to be something that I want to do for fun because it's in having fun and showing off that you will produce your best work.

**Ska Software** · 09-08-2005 05:28 PM

Originally Posted by wazoo

Everyone here gets VERY focused on what version of DirectX you should use, or what language you should/shouldn't use.

You should use VB6/.NET and DirectX 7/8/9.

**SquareDanceSteve** · 09-08-2005 07:23 PM

I agree, personaly I like vb.net 2003 with managed directx9

**Omega** · 09-08-2005 09:40 PM

I thought vb.net was a no no for games? Plus isn't it decompilable?

**wazoo** · 09-08-2005 10:29 PM

Originally Posted by Nexic

To be honest I would disagree with you to some extent, choosing a good platform is important. However of the ones that are good, you shouldn't really spend too loong thinking about them. Just stay away from DirectX 8+, anything that refuses to be wrapped (gamemaker for example), or anything that is too slow (DarkBasic).

Also you should try not to use up too big a budget for your first title, as there is a good chance you won't make it back. Instead try something low budget to get experience. Then once you know what you can realistically expect you can remake the game with higher production quality, or go for something else. But getting a couple of games out will teach you exactly what you can expect.

Another way to fail is to make games that clearly aren't popular, like I do!

Yup those are good points

I thought your game was DX8+...so you're saying even 8.1 is a bad idea?

**wazoo** · 09-08-2005 10:32 PM

Originally Posted by Omega

I thought vb.net was a no no for games? Plus isn't it decompilable?

??

Not that I've ever heard.

I guess it depends on your overall "plan" as well. Using .NET may not pay off so much right now, but it will probably eventually be the standard...

*shrug*

Like I say, pick the language/platform you love to work with and something will happen.

**SquareDanceSteve** · 09-08-2005 10:37 PM

there are a number of tools designed to protect managed code.

Really does it matter if anyone decompiles our code?

**Nexic** · 09-09-2005 12:37 AM

Wazoo, one of my older games, Arch Wing required DX 9 and had pathetic sales. All my other games need DX 7. But as XP comes with 8 you could probably get away with it

**Sharpfish** · 09-09-2005 12:43 AM

Can't agree with the "steer clear of DX8+" comment, as there are a number of games requiring that on many portals and in some top tens. Also it depends what features of D3D you are using (i.e fixed function = more compatible, programmable pipeline = limiting your audience to those with decent graphics cards).

<edit> - DX9 is a different matter - though it is a "better api" (improved internally over DX8) it is far less common. Xp comes with DX8 and is a massive portion of potential target audience...). So unless you need specific features from a high DX version go with as LOW as you can while still being able to get on with the development. I think being completely oblivious to the impact of the api you use is pushing the "just get on with it" thing a bit too far. If you do this, chances are you will be back to retro-grade it before long to quieten all the complaints of "won't run - won't buy" from potential customers. </edit>

I personally would not use .net/managed (or java) because I myself have not been able to run things on different (modern/updated systems) due to lack of runtimes - runtimes that even *I* can not be motivated to install - but if it eases your development pain then go for it. I am now using straight C++ and DX8 with OGL1.2 fallback (with software fallback for 2D games). Trying to get any lower than that at the stage I am at would be pointless as I could spend the next 3 years going round in circles "adjusting" to best practices and never actually releasing anything

The other choices such as B3D, BlitzMax, PTK, SDL etc are all valid and proven as usuable, you will not go wrong using any of them, but each has it's strengths and weaknesses.

I can agree that once I stopped worrying about what the best aproach was I got straight back into things and concentrated on the GAME(S) and not the technology.

**Nexic** · 09-09-2005 12:47 AM

Well as I mentioned, DX 8 is actually probably okay, but DX 9 is a big no no, I can't think of any RA top tens that required that. Or infact, any games that made it onto RA.

**princec** · 09-09-2005 12:56 AM

Originally Posted by SquareDanceSteve

there are a number of tools designed to protect managed code.

Really does it matter if anyone decompiles our code?

I don't think so... I gave away the source to Ultratron shortly after release and it hasn't made a blind bit of difference.

Cas

**Robert Cummings** · 09-09-2005 01:45 AM

Yeah, I don't see how the source could make a difference, it's pretty ultratron specific.

I think most source is specific, which is why I don't really subscribe to overuse of OO techniques. You can spend hours getting perfect re-usable code only to never use it.

What really counts is your input, network and graphics routines etc... not the game source.

Regarding the topic author's comments:

I think you're right. Just bloody finish it. You can port it with ease after. Porting my game took a DAY and it's thousands upon thousands of lines of code. Very little really changes, only the syntax.

So get that game done.

**wazoo** · 09-09-2005 05:44 AM

Originally Posted by Robert Cummings

So get that game done.

In the immortal words of Hulk Hogan, "Amen brother."

**ERoberts** · 09-09-2005 06:35 AM

vb.net is only good for corporate devs (in-house development with a controlle deployment platform), which is what it was designed for. It is not suitable for mass-distributed software, and might never be. Which is a shame, as it is an incredibly productive environment.

VB6 is a better fit. Almost as productive, and you can get it to run on almost anything

**James C. Smith** · 09-09-2005 07:03 AM

There is no black and white. There is no one thing you should or shouldnâ€™t do. They all just influence the outcome in their own way. But no one thing is going to kill itâ€¦.unless you donâ€™t finish your game.

I think there are a lot of â€œtoolsâ€ that I would not recommend for the development of mess market software. I donâ€™t care if you are making an indie game, a casual game, a retail game, a shareware screen saver, an FTP client, or a word processor. If you want a lot of people to be able to run your software, it is best to avoid .NET and DirectX 9.

However, I completely agree with wazoo that none of that really matters compared to getting something finished. If you are short on time (working part time), resources (not many people helping you), and experience (havenâ€™t shipped a game before) then you need to use whatever tools will make your life easier and help you stay focused on the task at hand.

Go ahead and use VB.NET with managed Direct X 9.0c if that is what it takes to help you get your first game done. It will limit how many people can run your software, but not finishing it would limit that much more severely. Trying to code to Direct X 3 in C++ (or some other example of the opposite end of the spectrum) may allow your software to run on more machines, but it could take you a lot longer. Maybe you will still finish the game, but you wonâ€™t have time to include all the extra bells and whistles that make it really fun. Choose tools that allow you to maximize the amount of time you spend making the game FUN to play (and maybe even fun to make).

Obviously it is nice if you can find some middle ground. If Direct X 8 opens up your potential target market by 20%, and it only takes you 10% longer to code than Direct X9, then maybe making that one compromise is worthwhile. But it still may not be worth while if making an indie game is your hobby and Direct X 8 is causing you to be frustrated rater than having fun and being creative.

**Christian** · 09-09-2005 08:01 AM

I would like to remark something allready said:

make games you really *REALLY* like to see done, a game you are PASSIONATE about

Something is having the drive to finish a game, another thing is to want to finish a game, another thing is no make a game you are interested in, and another completelly different thing is to make a game you are PASSIONATE about.

I made various games in the past, but i recenlty discovered that trying to get a game that you are passionate about is the BEST way to complete it and enjoy all the development proccess. You dont need to design a game exclusively to yourself, you still can design a game that sells and still be passionate about it.

**ggambett** · 09-09-2005 08:06 AM

I've recently written a Direct3D renderer for my 2D engine. I aimed for Direct3D 7.0. I've heard many times that its syntax was horrible and whatnot, but I found it quite trivial to do what I needed. Essentially alpha-blended, color-tinted, hardware-accelerated, bilinear-textured rotated quads. What am I supposed to be missing for not using D3D8? I admit it may be way better to do 3D, but for a 2D engine what's the point?

**mDEV** · 09-09-2005 08:19 AM

Originally Posted by Nexic

Well as I mentioned, DX 8 is actually probably okay, but DX 9 is a big no no, I can't think of any RA top tens that required that. Or infact, any games that made it onto RA.

Is it really making that much difference? Can you name a good game that failed to sell because its using DX 9?

**Robert Cummings** · 09-09-2005 08:41 AM

You don't ask a question like "failed to sell because it's DX9"

You ask a question like "Can my audiance even PLAY it?" The answer is on these forums if you search. It's a FACT for online sales, that DX9 is hurting sales. Retail is a completely different market, as retail CD roms have DX9 on them.

**wazoo** · 09-09-2005 08:59 AM

Guys excellent responses and sage advice for all.

@Robert: Great points about DX9 and online sales. I'd have to reread the license agreement, but are online projects allowed to distribute DX along with it? (ie. just like in a retail CD)? Of course it adds size to the total download package...

@James: Great summary on making the best choice for a DX version..(ie. sacrificing x to get y)

@mDev: I can't name one, because I can't think of many indie projects (off hand) who've released one. AFAIK, there was the dude who did that 3D Pool game using DX9. IIRC he started with the DX9 Appwizard and went from there. He did make comments about regretting that version of DX, but at least he finished the game and was selling a few copies.

Who knows? By now he might've regressed the codebase to DX8.1..

Naturally there's always better choices/tools to use for your games...or I should say there's "more marketable" technologies than others but at the end of the day, it's still great just to have that game finished.

While you're doing some marketing, etc. you can worry about any DX version regression, or optimizing this and that.

**Black Hydra** · 09-09-2005 01:52 PM

My theory for how things are going to go for myself:

1) Begin making game.

2) Work hard on game while absorbing as much information as possible about all aspects of the business.

3) Release game sometime later.

4) Realize you know far, far less than you once thought and start working to learn more again.

The problem for unproven indies is that as much anecdotal evidence (and some statistical) evidence you can gather to help form your information base, secondhand experience is worth very little without a specific context attatched to it. Its like thinking you can drive a car well because you have heard a lot from good drivers and know how an internal combustion engine works.

The more you learn, the more you realize you don't know!

**Uhfgood** · 09-09-2005 09:56 PM

Here's the thing. If it's not finished, you don't know whether or not it was the right choice for selling. You can't sell something that's not done. At least there's someone somewhere that probably made a sale with DX9 and whatever else you said not to do, and it's probably one more sale than you ever did or will do. (Note: i'm talking to a potential developer, chances are alot of you already finished and sold a number of games)...

But think about this : 1 more than 0 is twice as much ;-)

(No points for trying to prove this mathematically).

**wazoo** · 09-09-2005 10:39 PM

Originally Posted by Uhfgood

Here's the thing. If it's not finished, you don't know whether or not it was the right choice for selling. You can't sell something that's not done. At least there's someone somewhere that probably made a sale with DX9 and whatever else you said not to do, and it's probably one more sale than you ever did or will do. (Note: i'm talking to a potential developer, chances are alot of you already finished and sold a number of games)...

But think about this : 1 more than 0 is twice as much ;-)

(No points for trying to prove this mathematically).

Couldn't agree more. That goes back to my first post that launched this thread.

If you're already in the biz and have a few under your belt, then you know already what'll work and what won't.

Like Nike says, just do it. You can sort out a marketing plan later and/or learn from the project for your next one..

Plus if you start with DX9 now, then maybe by the time you finish your project it'll be the new "casual standard"...*grin*

**Chris Evans** · 09-10-2005 02:05 AM

Originally Posted by Nexic

Also you should try not to use up too big a budget for your first title, as there is a good chance you won't make it back. Instead try something low budget to get experience.

This is good advice.

I had a great time making my initial Pow Pow game, but I probably spent too much in hindsight considering it was our first game. I hired top-notch voice talent to do the voice acting, I contracted a fairly expensive artist to do the 3D boss models, and had over 8-10 custom music tracks plus all the other regular setup costs with starting a business.

So in some ways I wish I waited until after my 2nd or 3rd game to do a big budget (relatively speaking) game. However in other ways, I'm glad I did a somewhat ambitious game as my first title. Since I now have a lot more experience than I would have gotten if I just did 2-3 small puzzle games. I now know I have the stamina and perseverance to do 12+ month projects.

Though for other starting Indies unless you already have a lot of experience I also recommend holding on to your big budget game until after your 2nd or 3rd release. Get used to the process of doing a game from start to finish before you dump huge amounts of money on it. No matter how many anecdotal stories or case studios you hear/read, it's always an eye opening experience once you go through it yourself.

**Nexic** · 09-10-2005 04:32 AM

Is it really making that much difference? Can you name a good game that failed to sell because its using DX 9?

Arch Wing

Well, thats probably not the only reason, its certainly not a brilliant game. Sometimes I give this game away for free as a newsletter sign up incentive and everytime I do I get large numbers of customers (50% maybe) who can't get it to run.

**Black Hydra** · 09-10-2005 06:45 AM

I think another point that is good is to be flexible with your projects. This is something that is hard for many indies to do, but it is one of the few advantages you do hold.

I remember reading from Daniel Cook that one of his first big projects he wrote a several hundred page design document and their team followed it religiously. Another team was working on a game aswell but took an approach that was very flexible. The other team made Unreal Tournament and Dan made a game that was a big flop.

So you have to be able to scrap things that aren't working and make changes.

A week or so ago, my game was a full 3D space game (similar controls to Void War) after much thought (and some feedback

) I made the decision that the game would be far more playable if I made it a 360 degree top-down shooter instead. So this is a pretty big set-back in terms of development (although 3D to 2Dish isn't nearly as hard as the other way around) but you have to recognize that something isn't working and change it regardless of how much work it was to do in the first place.

**wazoo** · 09-10-2005 09:05 AM

Originally Posted by Chris Evans

This is good advice.

Though for other starting Indies unless you already have a lot of experience I also recommend holding on to your big budget game until after your 2nd or 3rd release. Get used to the process of doing a game from start to finish before you dump huge amounts of money on it. No matter how many anecdotal stories or case studios you hear/read, it's always an eye opening experience once you go through it yourself.

This is excellent advice and I go with that 100%!!!

Although I've got some really awesome titles, I know enough that I want to work out the "kinks" in the system first by making two or three much smaller games. By doing this, I get the first experience of running around making hosting decisions, contract negotiations with the portals and what-have-you.

Then by the time I do get my bigger budgeted stuff out there, I can maximize it's impact.

At least that's how I look at it..

Thread: How not to make it as an Indie...

Thread Tools

Display