Graphic or Coding? which one comes 1st? (For Indie Lone Ranger)

[zerodevice]

Ok, I'm not sure how many of you guys are Indie Lone Ranger, but this is what i've been wondering everytime I wanted to start making a new game.

I have 50% of Graphic design skill, and another 50% of software programming skill.

I'm sure some of the Indies here are the same as well.

So, what do you normally go for?
Do you draw all the graphics assets you need then start coding?
or do you code with a temporary image holder and replace it later?

[Sharpfish]

Typically the latter for me. There is little point me spending weeks perfecting the perfect art if it could end up being scrapped once the prototype proves the concept flawed or funless.

I will make 'some' early nice graphics to get a feel for the concept, and I never use really rough artwork as I like to have an idea about how it will all blend together but I don't spend hours on it either. Then I code what's needed to get the basics together and adjust/tweak as needed. That goes on for months then finally there comes a time when I can start doing "final" art for the game.

so:

1.Art mockup (with "ok" graphics) to see concept better
2.Prototype with placeholder art (mostly coding phase)
3.Extended Coding (the real meat and veg of the programming that will basically be working towards the final code)
4.Start adding in final art
5.Final coding and art in unison (connected and somewhat circulatory referenced).

[PsySal]

I generally do the two as I go along. I try to make graphics as I need them. Just start out with basic graphics, without much detail but trying to capture the general shape and colour of what you think you'll want. Later you will go back and redo a lot of the graphics but I personally find it really hard to work with "placeholder" graphics.

Try to get a feel for colour, shape, and animation as you work.

[Sybixsus]

Graphics first. I can't work without them because I'm normally doing fairly complex 3d stuff and you just can't write the engine until you know what the media is. No point writing a bunch of stuff for lightmapping only to decide later that your lightmaps aren't coming out as good as you thought and you'd prefer to use normal and specular maps instead. Or writing a nice actor pipeline only to discover that your actors are going to be in a completely different format because the exporter you were using doesn't like the number of bones you've used and then you have to rewrite half of your actor class.

So yeah, graphics first. Which is a real bitch, by the way. I'd much rather work the other way if I could, but it's just not practical with the considerations I mentioned above. I'd waste too much time coding the same things multiple times.

[Dylan Fitterer]

If the gameplay you're building is even just a little bit experimental then the coding needs to come first. You'll likely end up throwing out code and may as well not have to throw out graphics too.

[S2P]

The basics first, if its a 3D game, then the terrains. Buildings next, then cosmetics such as trees to make the game look good, then other objects, and finally the characters / vehicles. Once this is all in place, add the code to make it all work.

[amaranth]

Graphics first for me too. They inspire me to program.

[soniCron]

I think it's critical to begin programming as soon as possible. Until you have something tangible to sink your teeth into, what's the point in creating assets?

That said, I rarely follow my own advice. I usually form the idea in my head over a period of weeks, and once I feel the idea is worth persuing, I start with some preliminary look/feel tests. (Both art and music.) This then serves as inspiration as I'm programming the game.

[JoKa]

Since I have to pay for graphics I can't afford to start too early with a nice look. First I have to be sure the prototype is worthy to invest some money. So I use ready-to-use animations from the MMF-libs and squeeze them into the size I need for testing. Or I draw placeholder gfx within a few seconds. Of course, I don't want to show this selfmade prototype-"artwork" ;)

[Anthony Flack]

Well, I think the advantage to doing both yourself is that you can work on whatever needs doing at any given time. So I will tend to do whatever graphics I need to support the latest bit of code, and whatever code I need to support the latest bit of graphics, and they both go together.

When I started Cletus Clay though, I do remember spending a fair bit of time making basic tools, right at the start. Speed-testing the graphics system and so on. And then right after that I spent a fair bit of time making 80% of the main player animations, just solidly working on that for a month or so. After that, it was a bit of one, a bit of the other.

[electronicStar]

I do both as I go along as I need them, but I noticed that it is difficult to "switch" between one activity and the other,because they involve two different ways of thinking and different brain functions.That's why I tend to procrastinate a lot when I have to stop coding and start creating art. Strangely it is easier when it is the other way around, probably because coding is easier to get into and I don't need to be in a special mood.

[Christian]

I think its a thing you must plan ahead, since you need to test you games to see if the play is fun, you need to start programming first, but you cant start programming before having a plan about what the graphics would look like, what animations they would have, what position and size they will have, how many, etc, in my experience, whenever i worked with unplanned graphics and place holders the overall results on the screen where allways bad in the graphics part, after i had completed the programming and then made better graphics, i often had to tweak the programming also to make the graphics better, that made the gameplay change too and had to be programmed again, so that was not a very efficient way of working.

The best thing to do is to design a game with the graphics in mind before start programming so that you can programm with the visuals in mind too, then you can use placeholders, with the right proportions, positions, animations, and so on, that way you just have to make better graphics after programming is done without having to worry if they are going to fit, you just replace the graphics and thats it.

[negativegeforce]

code first, you don't wanna spend 300 hrs on graphics to end up changing the game somehow and ending up redoing the graphics. Until you nailed down what the final game will be its a waste to make final art. For instance you want pirates in the game, so you make the sprites or models/animations. Then later on you decide to remove them, congratulations on wasted time :D

[GBGames]

I think it sounds like people generally need some graphics to start coding, and I've started to produce the graphics I need first to get a mockup screenshot. That way, I have an idea of what it is my game needs to do to mirror that screenshot.

Originally I would program first, but since I didn't have anything to show for it, I found that making the graphics to fit the code was a pain and sometimes didn't work out. For instance, if I wanted animations to work a certain way, and it turned out to be fundamentally flawed, it is a pain to change the graphics, but it is even worse to change all of the related code.

So while you don't need final graphics, you should probably start with some graphics (and this advice probably extends to things like sound, too) to get a feel for what you are aiming for while coding.

[vjvj]

Definitely code first. I want to make sure the game is fun before I keep moving forward. Only exception to this is when I'm writing tech and need test data.

That said, when I'm bored or need a break I will toss in some better placeholder art for fun :)

[Bad Sector]

I do both at the same time. It also helps me that once i get bored on coding, i just switch to art and vice versa :-).

But i like to do "good art" from the very beginning. It boost my motivation to code when i see that i can work with good art. At the other hand, i have to push myself a bit when i have to work with poor "placeholder" art. This is why even if i probably won't use my art for the final game, i'm trying to learn how to do good art and models (and well, if i learn, i may do some of the art myself and save some money :-P).

[ragdollsoft]

First code.

Than maybe graphics (maybe).

[Sillysoft]

The best case is that your game mechanic itself will be lots of fun. I think coding it with placeholder art to start with is the way to go. Then you can judge the game on its merits during development. hen you're happy with the game design, then it's time to get your art mojo in gear.

[gummikana]

I usually start with a very hazy little sketch and after that I code the deliberately ugly prototype. And only after the ugly prototype is fun enough to play I start working on the graphics.

And I actually have good reason for working on the code first. Raph Koster pointed it out in his blog post 40 ways to be a better (game) designer (http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/).

"Art enhances, multiplies, improves. It does not replace missing fun. If you can get to something fun with minimal presentation, it will get more fun with good presentation."


So I recommend working on the code first and after that start doing graphics.

[zerodevice]

Well, after I've read so many post from you guys.
I think it'll be good to do like this:
1. Start with some simple place holder, but close to what you need.
2. Code the prototype with the place holder.
3. update the images to the final version.
4. do minor twick on the coding to finalize it.

Guess that's how I'm going to do then.

[Christian]

heh :), i guess i would add something:
-1. Design the play fo the game! xD
0. Plan and design the visuals first, what they should be, how the should behave, it only takes you a few hours and it can save you days of code tweaking and graphic manipulation :)

[Nexic]

I kinda do both at the same time. When I finish a piece of code for a certain thing (like a bonus) I'll then make the art for it the next day or something. Obviously this is different when working with an artist. In general it goes code, art, finishing touch code.

I'm nothing close to artistically talented, but I can make the odd few things myself.

[Uhfgood]

It's interesting, I don't even think of placeholder art until some of the gameplay is in a usable form. There is a thing i've noticed though, back in the day. When making a new game they would often work off of a new effect, or a new way of doing code, so it almost always started visual on those old games. Like I think the original gauntlet started with how many sprites you could spawn on the screen, with the hardware. Etc...

I might try in some of my future games to start with the graphics first and then work my gameplay around it. Just to try it out :-)

[Polycount Productions]

Going with coding (http://www.gameproducer.net/2006/01/21/you-dont-need-3d-models-nor-other-game-art-in-the-beginning-of-your-game-project/) first.

[Grey Alien]

code and maybe the odd graphic here and there to keep you interested.

[HairyTroll]

But remember, the key point is to actually *start*.