Simplify
by Charlie Malbaurn · 02/11/2007 (2:30 pm) · 4 comments
Well, it's been a while since I posted anything and even then it's probably been a real long time since I posted anything worth while.
Today, I wanted to kind of talk about my problems. Most of these problems are shared by a lot of different people.
Anyway, as a software developer, I've almost always been a VB programmer. I know a lot of people have this and that to say about VB but the fact is it's made my life pretty damn comfortable. I've picked up c# because I've become accustomed to C syntax working with JavaScript and also because it affords me the same kind of visual layout VB does.
The problem that I face as a would be game developer is that with VB I've always been able to throw controls on a form, get the design the way I want it and then go from there. It's the classic Top Down design. Most of the time I take it as far as doing documentation before design to work out everything that I want to do on paper. Sure the designs changes --and the docs change after all is said and done-- but it's always made me really fast at what I do.
Back to the problem at hand; I have the artistic ability of a carrot. I either make an awful attempt at graphics and get depressed and give up or I spend so much time with the graphical elements that it still ends up fug and I get so off track that I totally loose interest.
The second problem is that the more people you bring in --especially in a product that will probably pay little to no money up front-the more they may want to change X and Y and then god only knows what the product is going to be like. I know that's being selfish but what's the point of indie development if you're not making what you wanted to in the first place?
So what I decided to do is this: Design the game knowing the my graphics are ass, hopefully make it as solidly enjoyable as possible and then hope beyond all hope that someone will like it enough (or at least see exactly what I'm trying to accomplish) to help with assets and not try to change it too much. I realize input is important but I've also learned over the years that it's not so easy to explain what you are trying to do. The bosses say 'well let's do this' and you fold and do it and then they say, 'You know, you should have done this' and your like 'um yeah, that's what I was saying to begin with'
I also figure that if you can make a game that holds up play wise, but doesn't look so hot, you may be able to solidify how great your game could possibly be and you may have a better chance of getting the assistance you need. After all, it would show artists that you're serious and that you probably know what you're doing. Or you may realize that it's awful.
At least that's what I hope; the former not the later. I guess we will see...
Let me know what you think.
-Charlie
Edit:
Sorry, forgot the obligatory image
Today, I wanted to kind of talk about my problems. Most of these problems are shared by a lot of different people.
Anyway, as a software developer, I've almost always been a VB programmer. I know a lot of people have this and that to say about VB but the fact is it's made my life pretty damn comfortable. I've picked up c# because I've become accustomed to C syntax working with JavaScript and also because it affords me the same kind of visual layout VB does.
The problem that I face as a would be game developer is that with VB I've always been able to throw controls on a form, get the design the way I want it and then go from there. It's the classic Top Down design. Most of the time I take it as far as doing documentation before design to work out everything that I want to do on paper. Sure the designs changes --and the docs change after all is said and done-- but it's always made me really fast at what I do.
Back to the problem at hand; I have the artistic ability of a carrot. I either make an awful attempt at graphics and get depressed and give up or I spend so much time with the graphical elements that it still ends up fug and I get so off track that I totally loose interest.
The second problem is that the more people you bring in --especially in a product that will probably pay little to no money up front-the more they may want to change X and Y and then god only knows what the product is going to be like. I know that's being selfish but what's the point of indie development if you're not making what you wanted to in the first place?
So what I decided to do is this: Design the game knowing the my graphics are ass, hopefully make it as solidly enjoyable as possible and then hope beyond all hope that someone will like it enough (or at least see exactly what I'm trying to accomplish) to help with assets and not try to change it too much. I realize input is important but I've also learned over the years that it's not so easy to explain what you are trying to do. The bosses say 'well let's do this' and you fold and do it and then they say, 'You know, you should have done this' and your like 'um yeah, that's what I was saying to begin with'
I also figure that if you can make a game that holds up play wise, but doesn't look so hot, you may be able to solidify how great your game could possibly be and you may have a better chance of getting the assistance you need. After all, it would show artists that you're serious and that you probably know what you're doing. Or you may realize that it's awful.
At least that's what I hope; the former not the later. I guess we will see...
Let me know what you think.
-Charlie
Edit:
Sorry, forgot the obligatory image
About the author
#2
The whole "screw it, I know its gonna look like ass" comment made me crack up laughing ... I've said that a number of times, but my major down fall is the lack of enjoyment when it comes down to the nitty gritty code ... I have tons of fun writing the cool stuff, or experimenting with an idea and going "Oh shit, that worked!" ... but when it comes down to the boring tedious code that really isn't all that much fun to write, but you have to write it either way ... thats where I flop and go "Ok ... next up!" ...
I wish you the best of luck with your venture, and hope you keep us informed on your progress -- always make me feel better knowing that other people are struggling through it, and making it ... gives me a sense of hope that eventually, when I'm old and grey ... I may be able to do the same ... :)
02/11/2007 (5:37 pm)
I agree, your approach seems plausible, and I believe is the approach most of the more serious indie developers go on ... I myself, am a hobby coder ... and I'm slowly trying to work my way into the Indie Game Development industry ... as I have a full-time job as a coder for enterprise applications, I tend to keep my hobby code "fun" ... when I get to the boring parts, I usually give up and jump onto the next project ... something I've been struggling with working on for quite some time now ... The whole "screw it, I know its gonna look like ass" comment made me crack up laughing ... I've said that a number of times, but my major down fall is the lack of enjoyment when it comes down to the nitty gritty code ... I have tons of fun writing the cool stuff, or experimenting with an idea and going "Oh shit, that worked!" ... but when it comes down to the boring tedious code that really isn't all that much fun to write, but you have to write it either way ... thats where I flop and go "Ok ... next up!" ...
I wish you the best of luck with your venture, and hope you keep us informed on your progress -- always make me feel better knowing that other people are struggling through it, and making it ... gives me a sense of hope that eventually, when I'm old and grey ... I may be able to do the same ... :)
#3
02/11/2007 (11:50 pm)
Placeholder art is actually THE way to go, in my opinion. Stuff will change. A lot. Which means, if you have had "final" art ealy on, it`ll not be so "final" anymore and artist will have to tweak it. Over and over again. Plus, as an artist, its always been easier for me to work on top of already existing placeholder art, because, well, you can easily test the look of things and see it all in motion and context.
#4
Anyway, my point is that the processes are similar. You work with other disciplines, their work impacts your work, the execution of the project evolves to stay on target to meet the original concept.
All of that is made easier by sticking to a given method, prefereably one that you know well. In your case, that's working in a VB-type flow with placeholder art. Go for it! You know that workflow, leverage it to your advantage and worry about the polish when your concept is working the way it's meant to. Or more importantly the working the way that makes you happy!
02/12/2007 (6:22 am)
I have to agree with Nauris. Before I got into video game art I was a production architect, meaning that I specialized in doing the working drawings for someone else's design. That process has been defined and refined over decades if not centuries of practice and is all about doing things in passes - or in video game jargon, iteration. Refinement, tweaking, second pass. Whatever you want to call it.Anyway, my point is that the processes are similar. You work with other disciplines, their work impacts your work, the execution of the project evolves to stay on target to meet the original concept.
All of that is made easier by sticking to a given method, prefereably one that you know well. In your case, that's working in a VB-type flow with placeholder art. Go for it! You know that workflow, leverage it to your advantage and worry about the polish when your concept is working the way it's meant to. Or more importantly the working the way that makes you happy!
Torque Owner Sam Redfern
I think your approach sounds good. Write the game using placeholder art and if it's got good gameplay/design then you *will* hook up with interested artist types.