I've been working on my game since the Release 1.0 came out earlier this year and so far have been focused primarily on the gameplay.  Just recently (last week) I started adding "polish" to various areas of my game.  I'm getting a little worried that my game does not have enough graphics bells and whistles at this point (bloom effects, etc.)

I'm curious to know how the rest of you are approaching your XNA game dev projects.  Are you focusing on graphics (eye-candy) first, gameplay first, or a mix of the two, or maybe even some other order of events?

---

--
Fuel N' Spark Games
Makers of RocketBall and Exisled

GAMEPLAY!  ;)

Of course, everyone will say Gameplay over Graphics :P But in any case, I'll have to go with everyone else and say Gameplay first, proceeded by awesome graphics.

Another vote for gameplay here. You can get away with great gameplay and crappy graphics. You won't get away with the other...

If you don't finish your project, a game without good graphics is an ugly game.  But if you start with graphics first and not finish, you have a nice slide show... ;)

---

Visit my blog at http://waru360.codesan.com/

DOAX2 anyone? While not a terrible game, it's selling point is obviously the pleasing polygons, not so much the gameplay ;)

I've never played that game, but I've been hearing evil things about it :|

I feel the need to play devil's advocate here and say graphics.  I start out with really basic made in paint/blender graphics and then work on gameplay.  Cause you don't need a dazzling level if the mechanics are whack.  On the other hand you can't have killer gameplay if you don't having something to show you visually that the code is performing up to snuff.

Even Gears of War sandboxed levels on the fly to test the mechanics before actually fleshing them out to their finished states.

I do agree that killer graphics can always come later, that's what the artist is there to do.

RinusMaximus:

Another vote for gameplay here. You can get away with great gameplay and crappy graphics. You won't get away with the other...

QFT!

---

Jim Perry
Here's what I'm up to.

I'll take a slightly different approach here and say, "focus on whatever strengths your team has first".  And here's what I mean by that.  If you're a lone coder ... then chances are that you'll definitely want to focus on gameplay first while using some janky programmer art. 

However, if you're lucky enough to be working with a team (or at least you and an Artist), then you should focus on first delivering one solid piece of the game.  That means menus, awesome art, 1 good level (or whatever for your gametype), and solid gameplay *in that level*.  The idea here is that you get one bitesized snapshot of what your game could/should be, and tweak from there.

If you're curious about this methodology, check out http://agilegamedevelopment.com/

---

---

Joel Martinez
Blog: http://codecube.net
Play Videos on an XNA Texture: Scurvy Media

When considering this question, you have to ask yourself, of all the games you own, are you willing to pick up and play an older one, whose graphics are dated?  If the answer is yes (and for 99% of us it will be) the reason is because of the gameplay.  So, keeping that in mind, gameplay comes first.  If you go to extremes and make a game that's 100% graphics then it's not fun to play, but 100% gameplay is, even if it leaves you wishing it looked a little better.

I'm a team of one and now that I have some basic gameplay in place, I'm bouncing back and forth between gameplay and graphics. Mostly I'm doing this to give myself a break from one task by focusing on the other. I'm no artist, so I find the graphics quite challenging. If I left all of the graphics until the end, it would feel like a huge, discouraging task.

yeah, ultimately everyone kind of works their own way.  When you're by yourself, really, whatever feels right is the way to go.  The challenge comes when you try to assemble a team ... now one must deal with a number of differing worker types.  Actually, Vic from the FlatRedBall engine (XNA version coming soon!) posted a pretty good article on how to successfully lead an independent game team:
http://www.flatredball.com/frb/docs/index.php?title=Tips_for_Completing_an_Independent_Project

---

---

Joel Martinez
Blog: http://codecube.net
Play Videos on an XNA Texture: Scurvy Media

I will have agree with MagWheels. I'm also doing a game by my self and I find that it's more productive to bounce around both, I usually do a week of gameplay a week of content. That way I can get a greater perspective of the whole game and mix the gameplay and graphics in an better way. I believe that if you are working on a problem for more than 1 hour you should do something else and go back to it latter, that makes me gain time and don't be all stressed out about a stupid error.

The approach I've taken is this:

It all started with a game idea.  I visualized in my head what I wanted this game to look like and how I wanted it to play.  Then, I took inventory of my current skill set and evaluated what skills I would need to acquire to reach my final goal.  The biggest hurdle I had was building 3D models and then drawing them in the game.  So, I decided to tackle this first.  I did this by basically building a simple model from scratch and successfully importing into a test game.  Then I would build on those skills until I could successfully do what I wanted.

But the graphics component is just one of many I've applied this process to.  I have about 10 or 20 test programs for different things the final game will need to do.

With that said, I understand this is the typical gameplay vs. graphics argument, which to me is quite silly.  In the best of games both gameplay and graphics are top notch and complement each other well.

So, rather than do one or the other, I do them both at the same time.  Most painting artist will tell you the most absolute worse thing one can do while painting is focusing in on one small area.  Usually, they do a rough sketch of the "Big Picture" and then fill in the blanks.

So, in the end, I vote for neither gameplay or graphics.  I vote for "Build an awesome polished game and don't release it till it is awesome and polished".

"A delayed game is eventually good; a bad game is bad forever"
- Shigeru Miyamoto

Good Luck on your game.  I hope it turns out well.

- Matt D

Gameplay. Always.

Though most of these posts have been gameplay vs. graphics that wasn't the question. The question was in what order if any the game is made. Gameplay has to be implemented second then art third, there really is no other way.

The first thing you do is design the game. In a perfect world the design will be perfect and chisled into stone. At which point gameplay code simply becomes content and all content can be made at the same time. Last time I checked we didn't live in a perfect world.

How can you make UI and menus for a game that doesn't exist? How can you make creatures and such that don't exist? Sure you can go back and forth. For example implement the weapons then have the art for them made. In the end it will take longer and cost more. The starter gun is just a little too powerful so we're gonna change it to a sling shot. Oops a sling shot doesn't look like a gun! Gotta through away the newbie gun art and make a sling shot. This happens over and over again as the gameplay is iterated upon.

Now in my world the newbie gun would be a cube. Maybe I'd go all out and make it a blue cube so I know it's the newbie one. It is just as powerful as the one with art so I'll change it to the newbie slingshot. I think the newbie sling shot will be a blue cube!

At some point the art is going to be made and changing things will occur this cost but you want to try to push that off until the last possible moment. Level based games are a little easier as once a level is completed it rarely changes much.

I've been making games for over 20 years as such my designs are just about perfect ( at least in my mind and just about only there ). As such sometimes I get a little cocky. For the current game I ordered all the Boss Creatures before Bosses ( or even creatures or levels) were implemented. I wanted one boss version of each creature type. Boss art can be such a great thing to show off. The game has 12 creature types so I ordered 12 Bosses. The game only has 9 levels and each level now only has one boss so I have too many boss arts! Wow even MY designs aren't perfect. ;) Not to mention the wasted stone tablet.

Aside from that mishap the rest is going well. The archer you control is a fisherman from an older game. You fight deadly cubes trying to pickup four treasure cylinders to unlock the level exit. At some point the creature cubes will be animated enemies and already one of the treasure cyclinders is now a fancy crown. The crown looks prettier but the game plays the same as it did with the cylinder.

Even ignoring the cost, it is hard to know what art to make without the gameplay. Artists ( whether or not it is also you or a seperate person ) need to know what the model will do to make it. Right now my archer is still a recycled fisherman. A bow and arrow is kinda slow to shoot and more than a little tricky to aim. I might change it to a crossbow. If I do the quiver on his back would be very different. Also his fingers would need to animate seperately. It's also starting to feel more like he'll be a teen rather than an adult as planned. As a matter of fact he may even come in a female version in the end.

About the only thing a game that you can pretty much not worry about changing is the sky. Even then if you go all fancy with dynamic clouds and such you better be #^%#& sure that there will be a sky.

Too many games today have things in them just because the art was already made but they serve now purpose to the gameplay or worse something doesn't look at all like it should. That can all be avoided by making the game play before the art.

 

gameplay is definitely first.  No matter how pretty the game is, if it sucks, no one will play it.  Take ff7 for instance.. not that pretty of graphics, but i know millions of people out there still play it

---

Zero Industries....site coming...eventually...

I would have to say gameplay first.  Graphics can always come at a later date (or even better if you have an artist who can develop some amazing graphics on the side).  I always start out with simple graphics to get a feel for how the game works and plays, and then update them.

Like other posts here, if you have really amazing graphics but terrible gameplay, noone is going to play it for long.  There are numerous games I can count that fall under this category.

While I also think gameplay is more important, graphics can't be an embarrasment.   If you're not making a multi-million dollar game I don't think there's need to worry about absolutely cutting edge but, at least for what I'm writing, I hope I can make my graphics so it doesn't drag the rest of the game down.  If the best I could come up with was 15 year old graphics I probably wouldn't bother.

When I'm considering getting an indie game, I first find out what I can about the gameplay of course; but then I want to see a few screenshots.  If it looks too dated I still won't get it even if the gameplay looks ok.  So for my personal buying a game has to pass the test in both gameplay and graphics before I get it.

The whole reason I'm here pounding out a game using XNA is because it allows me to make cool graphics a bit easier then before.   I also went out and got XSI|Foundation along with other tools and am in the process of learning them.  I'll probably be purchasing some models from Turbo Squid or elsewhere and probably try to get a professional artist I know to contribute.

While the thrust of my games is on unique gameplay you can't get elsewhere, I do want my graphics to add to the game and not detract from it.

I am working alone, but I think this would apply either way.  There is a lot more than just Art vs. Gameplay.

• You have to come up with the gameplay
• Hopefully you've got some inspiration from somewhere.
• You have to know how to make the art
• Maybe you don't have a professional artist in your group.
• You have to know how to USE the art
• A beutifully skeletal animated model isn't as cool if it just sits there or isn't properly shaded.
• You have to make the game 'guts' or engine if you are really cool
• This isn't gameplay this is the stuff that makes the whole thing work
• Even more stuff

I think like someone said before, the first thing you do is Design.  You will think about gameplay and graphics during design.  You will brainstorm, scrap ideas altogether and pull your hair out.  Eventually you have to start working though.  The way I did it was to start with little test projects to see if I understood separate blocks of technology enough.  After I felt satisfied, I started a 'real' project and moved the relevant bits inside to get a starting point.  I then expanded and refactored a lot from there.  I'm at a point now where I am somewhat stuck between art/technology/gameplay.  I know kinda how I want the game to work.  I know kind what I want it to look like.  The biggest hurdle I think is still: how the hell do I make it play like X and look like Y?

I still think graphics take a back seat.  I can make models and put bones in them to manipulate in code and then get a real artist to make it look decent and just reuse my skeleton.  I think the most important thing to come up with is a stepped plan.  You can't start out writing a multiplayer supershaded Gears of Warcraft.  But you can start small and make it much bigger.

---

-Wil Burton

Well, in the long run you need gameplay over graphics...

Though, with the way that the making of games is set up, I would say make your graphics as good as you can first.  Maker sure your textures are good and then make sure they fit your models.  After that I would work on animations and getting your basic commands to work correctly.

After all that is out of the way is when I would start on actual storyline and gameplay.  It gets all the rest out of the way and lets you focus 100% on the core of the game, since all of the graphics and character stuff is done.

I think a lot depends on your mentality. I am by profession an artist/designer/programmer in that order. It means that my ideas are driven on a visual level which kind of dictates my creative process.

I find it very hard to draw "rough" art that does a job as opposed to finished art that looks right though. So the minute any part of my code requires an art asset, it has to be the right asset for the situation. The problem comes when you've spent 9 hours drawing graphics and have quite honestly seen enough pixels for one day, only to get home and realise that the next stage in your game requires artwork. Which is probably why I end up writing more tools at home than games.

Programmers are generally happy using boxes or circles to represent artwork, would they be as happy to use rough, unfinished functions or classes in the same way, or would their code have to be "right" from the start?

---

boring stuff moved to my profile...

Well, the obvious answer is gameplay, but that doesn't necessarily mean programming.

Especially in a team situation, the gameplay needs to be available to everyone and understood by everyone.  That means that everything should be written down somewhere.  If your character attacks with a hammer, and that hammer should flatten enemies, that should be noted.  Concept sketches are nice here too, but not usually necessary (unless your idea just can't be explained with words).

Once the game design document (what I described above) has been fleshed out, how you proceed is really up to your team.  There are many approaches to creating software products - games in particular.  While graphics vs. game code is one of them, there is also top-down vs bottom-up to decide on.

I personally believe that if you have the design document fleshed out enough, everyone should be able to work in parallel.  That means your programmers will use simple represtations of things while they are programming (see: programmer art) while your artists work on actual game art.  If you've set things up right beforehand, and you have a good version-management system, your artists can actually update the in-game art without touching a bit of code.

Now, for a one-man show, I think you need to concentrate on gameplay.  You'll of course need some simple graphics, but a game won't stand on graphics alone.

Of course, if you're just making things for practice, then play your weaknesses.  If you're horrible at collision detection code, then create your own collision detection and response system.  If you need to work on shader code, then build a post-processing framework.  If you just wish you could model, then go for it!

---

http://www.kyleschouviller.com

Another vote for gameplay here.  Simply put, like many others have said, a great looking game with no game itself isn't a very good game.  I believe the most appeal for games initially comes from eye pleasing graphics but the addiction factor comes from how creative you can be with the gameplay.   That being said, if you are working on a game solo or with a small, no to low-budget team, you will not have time to make an amazing looking game that is also fun...you will never finish.  Besides all the time it takes to make great looking models, animations, and textures, graphics also comes in your ability to optimize your rendering and write good shaders.   These things take a tremendous amount of time and that alone will prevent you from working on the game itself.   Eye pleasers should be added after you have done considerable work on the game itself (i.e. people want to play it) and you want to invest some extra time making it look better.

I'm on my first experience doing a game, so my opinion might worth little. I vote for gameplay, but I add a comment...

I really like when the universe presented by a game is consistent, and every single piece of the world makes you recognize its origin and say "yes, that an artifact of those freaking aliens" or "a human weapon I can use!". Having everything put in its place, so that you believe the big picture, makes the game be a better one. This I call great universe design.
Imho this creation of the universe of the game is still not graphics vs gameplay; it's the beginning of the whole process in which concept art, mockups and story boards are great tools. Once the universe is created you can then focus on gameplay and graphics.

I personally think that starting writing the gameplay without having considered the universe of the game is loosing an opportunity. Which one? Simply the opportunity to combine gamplay actions with a meaning. Depending on how much the universe differs from the real world, simple actions might require little or much time to be defined. And once an whole set is there, you can start refine it toward the emotional goal you want achieve, which is usually fun.

I believe that this makes the difference between "yet another clone" and "wow this is cool". Fancy graphics full of eye candies might be hard if you work alone, but a