A better put question may be, what blend of graphics and gameplay is needed to get fundings for your game.

I believe that a programmer should not try to be a graphics artist when he is not so, and neither should he pretend to be a storywriter.. And vice versa!

Bjorn Goransson

Unfortunately, for many hobbyists they don't have much choice. :) They're not doing a game that would be funded by anyone and probably don't have the money to hire a professional graphic artist.

---

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

I actually find that both needs to be done almost in paralel, or if you are a lone soldier, then interleaved. Before any gameplay is coded, I need a clear picture of how the screen will look like, how the menus are structured, how the UI is....and this is definitely a graphics thing although maybe they are mock up graphics.

And then from these concept graphics, the coding is done...for gameplay, and others. Soemtimes you'll need more graphics in this process, and then some more coding....and probably on later date, you'll refine those mock up graphics....or add more graphics as more contents are put into the game.

So to me it seems like a game starts with the artistic vision first. You can really have a great gameplay code and all, but if the UI becomes very unwieldy because of the complexity....then what you'll have is a monster of a game, that a user can't play....just because it's hard to play it...or it looks very ugly

redox24:

I think gameplay and graphics are equally important. But even more important is a good storyline.

A very good point but the good storyline doesn't have to be where you expect it to be...

The power of a good storyline at design time is a tremendous help to tie a game together. Too many times you will see games that are a collection of random items and entities thrown in a pot simply because the designer/coder or artist thought "hey, it would be cool to have a [whatever] in the game, lets put one in".

The first thing I do when putting a game design together is to write a short story. I introduce myself to the characters and let them tell me something about themelves. Once I know a bit about them and the world they inhabit. They can tell me the story behind the games motivation, the reason behind the plot, the source of the trouble etc... I will do this for an RPG, FPS or even a scrolling shooter or platform game.

Once I have the foundations behind the game, adding items and gameplay elements becomes a lot more straightforward. If you work on the basis that every item in the game has a reason for being in the game and a cause for it being where it is, you will find yourself avoiding the random "cool" item and instead adding items that belong in the world. (There's no reason an item can't be cool but if it is cool and "belongs" there, it will be even cooler... IMO anyway)

I often take the objects beyond the simple "there's one in the game" by writing excerpts about the items. Their origins, creation, maybe a bit of history. Quite often, being able to imagine to this level of detail will inspire aspects of a game that may have been overlooked or not even considered with other more "bolt it together" type ideas.

As an example, I have a FPS design part completed at the moment. The enemy in the game are extremely non-standard, as a result I had to write quite a bit of background about the weaponry and how it was developed to deal with this enemy. Whist doing so I came up with what I consider a really "cool" weapon. It actually uses a data manipulation technique as it's firepower, but only when it is coupled with a specific item. Without this item, the weapon is no longer a weapon but a functional tool which serves a far more positive purpose in the game world. So I created a logical tool to perform a function in the game environment. I created a simple "effector" item that perfoms another perfectly logical function and then coupled them to generate a highly useful weapon in certain situations. Chances are that without generating the story behind the items, I may not have considered the interraction between the 2. So I ended up with a really cool item that belongs perfectly in the world it was designed for.

A good design can create the whole game in your head. You should be able to sit and read the design and see the game playing out in your mind. You will learn the characters, their abilities, their habits etc... and you will get a good feel of how they will interact with you and others within the game.

Script out set pieces and develop voices in you mind for how the characters speak, it's amazing how the perception of a persons voice can drive an image of how they may look and in turn, how they may function/act.

All of this can be done without writing a single line of code yet you can create numerous elements of gameplay and know how they work before you even start.

So I guess my (other) answer to the question asked "which comes first, gameplay or graphics" I would have to say... design. This might sound very OTT for most people but I find it a tremendous help to giving a game a good foundation to build on.

---

boring stuff moved to my profile...

Bornemix:

I believe that a programmer should not try to be a graphics artist when he is not so, and neither should he pretend to be a storywriter.. And vice versa!

I personally believe that every member of a development team should be striving to be more than the role they perform in. Creative and imaginative programmers are a huge asset to a development team. If they posess no desire to "create a game" but merely to write some code, then all they produce is stale, perfectly formed, highly efficient functions.

I believe that game development is an art and the artists aren't just the ones drawing the graphics. If you can get a team who can work in perfect harmony, where each member has a real desire to develop great games, you can acheive great things.

I taught myself to programme because I knew that just drawing the graphics wasn't truly "developing a game" to me. I started writing game designs as I knew that it would mean much more to create something that started off in my imagination. And I started to write music as a simple sound can inspire and motivate when my mind just doesn't want to think anymore.

I truly believe that had I not learned to be all the things I wasn't supposed to be, I wouldn't have stuck with games for the 20 years I have been doing it. And had I not found a group of programmers who want to "develop games" rather than to simply write code, I wouldn't have stuck with it either.

You don't have to be a programmer who is an artist but it helps so much if you are a programmer with an artistic vision.

---

boring stuff moved to my profile...

Wicky Wuigi:

redox24:

I think gameplay and graphics are equally important. But even more important is a good storyline.

A very good point but the good storyline doesn't have to be where you expect it to be...

The power of a good storyline at design time is a tremendous help to tie a game together. Too many times you will see games that are a collection of random items and entities thrown in a pot simply because the designer/coder or artist thought "hey, it would be cool to have a [whatever] in the game, lets put one in".

The first thing I do when putting a game design together is to write a short story. I introduce myself to the characters and let them tell me something about themelves. Once I know a bit about them and the world they inhabit. They can tell me the story behind the games motivation, the reason behind the plot, the source of the trouble etc... I will do this for an RPG, FPS or even a scrolling shooter or platform game.

Once I have the foundations behind the game, adding items and gameplay elements becomes a lot more straightforward. If you work on the basis that every item in the game has a reason for being in the game and a cause for it being where it is, you will find yourself avoiding the random "cool" item and instead adding items that belong in the world. (There's no reason an item can't be cool but if it is cool and "belongs" there, it will be even cooler... IMO anyway)

I often take the objects beyond the simple "there's one in the game" by writing excerpts about the items. Their origins, creation, maybe a bit of history. Quite often, being able to imagine to this level of detail will inspire aspects of a game that may have been overlooked or not even considered with other more "bolt it together" type ideas.

As an example, I have a FPS design part completed at the moment. The enemy in the game are extremely non-standard, as a result I had to write quite a bit of background about the weaponry and how it was developed to deal with this enemy. Whist doing so I came up with what I consider a really "cool" weapon. It actually uses a data manipulation technique as it's firepower, but only when it is coupled with a specific item. Without this item, the weapon is no longer a weapon but a functional tool which serves a far more positive purpose in the game world. So I created a logical tool to perform a function in the game environment. I created a simple "effector" item that perfoms another perfectly logical function and then coupled them to generate a highly useful weapon in certain situations. Chances are that without generating the story behind the items, I may not have considered the interraction between the 2. So I ended up with a really cool item that belongs perfectly in the world it was designed for.

A good design can create the whole game in your head. You should be able to sit and read the design and see the game playing out in your mind. You will learn the characters, their abilities, their habits etc... and you will get a good feel of how they will interact with you and others within the game.

Script out set pieces and develop voices in you mind for how the characters speak, it's amazing how the perception of a persons voice can drive an image of how they may look and in turn, how they may function/act.

All of this can be done without writing a single line of code yet you can create numerous elements of gameplay and know how they work before you even start.

So I guess my (other) answer to the question asked "which comes first, gameplay or graphics" I would have to say... design. This might sound very OTT for most people but I find it a tremendous help to giving a game a good foundation to build on.

I totally agree. This is what I wanted to express with my worse written post.

Of course I ALWAYS do graphics first.

Which is why I haven't finished a compelling game yet. :)

I'm now working the other way.  Gameplay then graphics and whatever else is required to support that gameplay.

As a consumer, I would much rather have a game that's fun to play then full of bells and whistles.  Bells and whistles get old fast.  Put together that's fun and challenging and I'll buy it! :)

 

As others have said, if you're developing by yourself, the two go hand in hand. For my DBP entry, I hacked everything together as fast as possible to see if the concept would work. There was no scoring, no menus, just the core gameplay concept. Once I felt that it would work, I added some working graphics, being various icons. Back to the code, implementing the front end and menus. Back to gameplay, adding scoring and end-game conditions. My wife noted that the game had potential, but it was too confusing and inconsistent, so I reworked the graphics to be more consistent. Back to code again...

And so on...

So, I guess the conclusion one should make based on this thread, is that excellent graphics and excellent gameplay is mutually exclusive.  :o)

MagWheels:

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.

This approach, like every other one, is a great way to go about working if you are solo.

If you want to have the best of both worlds (as much as you can anyway), create a schedule. Plan some gameplay you want to have done by some future Date. The schedule a task following that to spruce up and make pretty some of the new elements you have added.

Any combination of the above with work just fine. Front load work, back load work, whatever you feel comfortable doing. The biggest thing is to keep making forward progess on one side or the other.

I think it depends. But, in general, Gameplay first with one simple reason; Gameplay does not get outdated as fast as graphics. Gameplay can last like decades if it is great, but a superb graphics will be outdated in a year, or worse, half year. By the time you can focus on graphics, new technology comes out to either replace old technology or make existing technology easier to adapt.

But in other case, if I get a game engine like UE3. I think I will get my hands on graphics right away because I am such a graphics whore. Especially in a big company when showing off graphics to press is really important. You need to work on graphics first to set a standard for artist to work on. And programer on gameplay concurrently. IMO, it will be like three stages. 1) Gameplay Design and Graphics capability prototype. 2) Content creation, (gameplay, model, and textures). 3) Level design and testing. Roughly like that.

I have never worked in the industry, but I think speed is the key here. First graphics fundation and level design tool. Without that, it will take too much time to finish a game in time. And it is better to complete a game in 2 years, just a thought.

As a designer:  Definitely the graphics.

As a fan:  I definitely want the focus to be on gameplay.

---

Love the Casual Games business? Try the free game downloads here

As a solo game developer I find gameplay always gets priority. The time that I have taken out to improve the graphics is when it was required to facilitate the gameplay. I consider the UI not "graphics" but more a function of the gameplay. At the moment my game has a visually basic yet a very functional interface, with the ability to build the interface like you would a windows form. Later down the track I'm going to actually skin those buttons but at the moment I use basic gradient shading. Later I will also add any bells and whistles to animate the interface, but gameplay first!

What to develop first Graphics or GamePlay,

With the little bit of work I have done I tend to work out any major coding aspects first; of course I’m no artist and this may be why I go for code first. My other argument for this is you can lay out the game with temp art or space holder art and use that to attract others to the team, having said that you could just as well go the other way build some solid interesting art work and fake the mechanics to attract a team to help develop the “real” mechanics, either way focus on the strongest skill you have then use that to drawn in others (assuming you are looking for a team).

At lest that is the way I think I would go at it.

---

Death and fire!

Definitly gameplay.  What i will do is I have a series of throwaway models + terrains + textures that i use as a standard set, and i put those in first, then work on gameplay, and when that is done i make the models + terrains + textures to conform to gameplay and add the fancy stuff.

---

--------------------
Dont sweat the petty stuff and dont pet the sweaty stuff.
--------------------

Has to be gameplay for me as I am a completely hopless when it comes to graphics (which I will normall, beg or borrow) while developing.

---

Ant.

I always like to spend a little time thinking through the game play. However. I must say that I often find dabbling in some Graphics (or evening some sample sequenced music) sometimes gives my a spark of gameplay inspiration. What I mean is... Playing around with some models and graphical effects has lead me to discovering some gameplay features.

Here is an interesting one... I have also found that some bugs (...Or as I like to think of them... Emergant features) have become key gameplay items. An example that springs to mind is some collision coding i was working on. I was aiming to have things get pushed out the way (Visually). However, I made a mistake and the things that were meant to get pushed out the way, appeared to get stuck to the thing pushing them (A sort of sticky effect where they were pushed out the way too slowly). I left this "bug" in, I mean "feature", as I felt it helped the gameplay.

 

---

Resplicing some XNA...

http://duckocide.spaces.live.com/

That was amazing, your 100% correct on this. Hands down.

Ty very much, that helped me out alot, and opened up alot of ideas for me to start on.

I tend to use a spiral approach.

1. Get some basic graphics and gameplay coded (ugly/prototype graphics and bare bones gameplay code)
   
2. Add more basic graphics as gameplay advances (still prototype graphics to fill in areas needed, gameplay getting better now)
   
3. Get enough graphics to finish gameplay coding (add more prototype graphics, maybe clean up a few graphics, finish gameplay coding)
   
4. Redo all graphics to finish (redo any ugly graphics)

---

-----------------------------------------------
Jim Welch

Some games really got nonsense graphics but their gameplay can over come this problem so i recommend caring more about gameplay also if your game much graphics you'll need a high performance PC also if you have it will always kill the RAMS and asks for more like COH which even on Core2due ,4GB rams , nvidia 8800GT it still runs slowly so you must balance your game but just do care more about gameplay.

---

Ashour

Gameplay is the single most important thing in a game.

Otherwise you might as well call it a movie.

But programming gameplay first is a physical impossibility.

Without some graphics on the screen, it doesn't matter if you have the best physics system in the world or the greatest AI that has ever been coded.

So you need to make a distinction between design and coding.

Do the gameplay design first. Play around with it on pencil and paper if you must, but get it in your head what you want to achieve.

Work out what graphics handling code you need to be able to implement the gameplay, and design your rendering pipeline around that.

Then start coding with programmer graphics.

When you have the basic structure in place, you can play around skipping between writing graphical effects, kernel code, creating meshes or sprites, as much as you like, it makes no odds which order you do it in.

It does not matter to your physics system that you don't have a skybox in.

Your collision detection code cares not that your shader doesn't handle phong lighting yet.

The example of using cubes for things you don't have models for is exactly right.

A guy I know has another way of describing it.

He says work out what data you need for a given situation first. Then figure out how to display it. I see his point, I have been caught it  before when I suddenly realised I needed to display some data and had no screen resources left. I had to completly rework the display because I forgot about one item.

 

 

---

Information is not knowledge, knowledge is not wisdom, wisdom is not truth, truth is not beauty, beauty is not love, love is not music, music is the best! Wisdom is the domain of the Wis (which is extinct).

I would say it depends on the game being created.  For example, if I do a pong clone I have a basis of knowledge I can go off of and I don't need to write down the rule on scoring because I know them so I can jump into programming the look and functionality.  Although, if I build a new RPG RTS game, all the rules should clearly be defined before anything is built so you don't contradict things in code.

This goes back to the Carmack/Romero, Design powering Tech and vice versa but I lean towards tech powering design though both affecting each other.  I'd type more but class is ending :)

Waruwaru:

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... ;)

Funniest, yet most down right true post I have read here.

I agree whole hartedly...

Besides, work on gameplay first so your game will do what you want, THEN worry about how good you can get your graphics so that you know how high end the pc will need to be.