Jump to content

  • Log In with Google      Sign In   
  • Create Account

What comes first, artwork or code?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 GeorgeCH   Members   -  Reputation: 137

Like
1Likes
Like

Posted 29 March 2014 - 10:27 AM

Dear all,

 

We are in the process of writing up the GDD for our first mobile game, with neither of us having experience in the software development industry (I've managed IT projects before, but they were mostly code-driven and did not feature a graphics component). We are going to outsource the artwork and the development, most likely to two different parties to save costs.

 

My question is - what comes first, the code or the artwork?

 

Based on my research, it seems the first time after the GDD would be to ask the programmers to produce the code for the game using placeholder art - e.g., square boxes instead of real graphics.

 

Then the next step is to send this over to the artist and ask him/her to create the artwork to fit the placeholders.

 

Once the artwork is ready, it goes back to the developers who fit it to replace the placeholder graphics.

 

Does this sequence sound about right? Note that I know I'm leaving out the QA part.



Sponsor:

#2 Tom Sloper   Moderators   -  Reputation: 10159

Like
7Likes
Like

Posted 29 March 2014 - 10:58 AM

Ask your programmers when they will need art. Then have your artists deliver it by that date. Never keep your programmers waiting for assets.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#3 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 29 March 2014 - 12:09 PM

Imo you could do it both ways, #1 craft graphics well suitable for your prototype mechanics and game ideas #2 code mechanics for the assets [more axperience as to this things is not present in my case ]



#4 Icebone1000   Members   -  Reputation: 1148

Like
2Likes
Like

Posted 29 March 2014 - 12:13 PM

Generally you will have concept artists assisting the designers to visualize the game early on, with sketches, mockups, etc.



#5 frob   Moderators   -  Reputation: 22731

Like
7Likes
Like

Posted 29 March 2014 - 12:30 PM

Both get refined during the process. As Tom referenced, it is typically much easier for artists to provide simple objects than it is for programmers to make something and add it to the workflow. It is usually best for artists to provide the resources to programmers in advance of them needing the resources.

 

Understanding the workflow is important. Often the dependencies switch back and forth. You need simple models early but they need full rigs (or whatever you are using for slotting or parenting relationships) very early. The models can be refined over time, but they need to be mostly complete before animations can proceed. Programmers need a way to move between animations (often using graph-based tools with animation info tied to nodes) and block animations are enough to work from initially, they'll need enough model and enough code to avoid clipping issues.

 

 

There is no fixed "A, then B, then C".  It is a flow unique to the tools and project. Often during pre-production while refining the design there is enough information for modelers and programmers to begin work while coordinating with design to refine the design from boring words into potentially fun prototype.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#6 GeorgeCH   Members   -  Reputation: 137

Like
0Likes
Like

Posted 30 March 2014 - 07:45 AM

Thanks! Since we will be outsourcing to different people, we can afford to have the developers waiting, in the sense that I expect they will be charging an hourly rate - so even if they don't have assets to work with, that wouldn't cost us money, only time (and we aren't working towards a strict launch window of any kind).

 

One other question - where are some places where I could start looking for budget estimates on the art? E.g., a place where I can run a quick price check showing a sample of what I want and getting an estimate on that - without any commitment to pay?



#7 Tom Sloper   Moderators   -  Reputation: 10159

Like
0Likes
Like

Posted 30 March 2014 - 11:35 AM

where I could start looking for budget estimates on the art? E.g., a place where I can run a quick price check showing a sample of what I want and getting an estimate on that - without any commitment to pay?


Ask your artists.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#8 Ravyne   GDNet+   -  Reputation: 8155

Like
2Likes
Like

Posted 30 March 2014 - 03:52 PM

Games especially never really fit into the waterfall-style development model that was fairly common in the earlier days of software development. It's always been a fairly asynchronous operation -- There's the game vision, and from that comes the technical vision and the artistic vision that are largely independent but still require constant communication between those sides of the studio. A good example is that the technical staff needs to inform the art and level design staff how many objects, polygons, lights they expect the engine to be able to handle. Of course, the art staff gets to have input on what the engine becomes -- at some point they have to reach an agreement about how the technical vision supports the artistic vision, so that they both work together to achieve the grand vision of the game.

 

There's very little A->B->C to it, its more about everyone sharing in the same vision, knowing what it takes to get there and what everyone's expectations are, and then working every day to get closer to the ideal. At the same time, even the best-laid plans end up not panning out -- maybe its just not realistic to draw 1000 monsters, or maybe fighting 1000 monsters at a time just isn't fun -- as a result, plans change and the team adapts. If that team is communicating all along, its not such a big deal to get the fleet all turned in the new direction. If those teams are working in their own bubble, with vague plans to rendezvous some distant point down the road according to a strict plan, or if some have been left with nothing to do while others work, only to discover their miscalculation, its a huge, demoralizing deal.

 

This is why a lot of game studios were early adopters of more agile, fluid, and perhaps unorthodox working styles (even if not adopting formal Agile methods).

 

I say get both sides of the team working as soon as possible, with whatever code and assets are available, as they become so. I recall reading long ago that Valve's level designers early in Half-Life 2 were often working with rough geometry that had no texture or real materials applied. A simple per-pixel lighting model was applied to flat-orange geometry; which was plenty to start working out level design and even play-testing it. code, art, and design were all able to start working without burdening or bottle necking each other, and in the end they converged on what was the game of the year. I don't know what their daily working details were like, but at least at a high-level, they seem to exemplify a lot of good ideas.



#9 3Ddreamer   Crossbones+   -  Reputation: 3169

Like
2Likes
Like

Posted 31 March 2014 - 12:03 AM

Hi,

 

smile.png

 

Dear all,

 

We are in the process of writing up the GDD for our first mobile game, with neither of us having experience in the software development industry (I've managed IT projects before, but they were mostly code-driven and did not feature a graphics component). We are going to outsource the artwork and the development, most likely to two different parties to save costs.

 

That is ideal for a game developer to have team members in somewhat of a competition for future services.  It is also good to spread the risk to two or more parties instead of let the full weight of risk fall on one person's shoulders. So far, you are strategically positioned.

 

My question is - what comes first, the code or the artwork?

 

Most of the successful and profitable games are developed along a course similar to this:

 

1) Game Concept

 

In the largest game development companies, this can take a team weeks or months (as time permits while they work on other projects). The game concept is usually scripted in printed documents, market analysis is done to establish market appeal, and early outline for game functionality is constructed. Last part of this stage is a cost analysis and estimate to be approved by the game development leadership.

 

2) Game Design

 

The AAA game development method is to have a professional game designer work with one or more concept and design art specialists to communicate the design in art form.  The game design is illustrated visually with colored pensil art, digital art, cartoon illustration with captions, or other preferred art medium or combination of them. Sometimes 2D and 3D artists to be used in actual game art asset creation are used for the preliminary game design illustration.  It is common for many changes to be made in this stage as project managers and/ or game designer brainstorm with the game developer leadership and the art team to improve game design.  This can even lead to revision of game concept if a "brilliant idea" is conceived.   Often final approval for the project depends on the impact of this stage in the imagination of the leadership.

 

3) Organization

 

Though a highly anticipated game concept (such as version 2 of a game series) might see dedicated organization begin almost immediately, a new game concept will require approval of game concept and game design before substantial resources are invested in the project. This means that the full team will not be assembled until approval by the head of company.  The effect is that programmers, artists, techical support personnel, and testers become fully engaged once game development is launched in earnest.  

 

4) Proof of Concept

 

This is a demo game.  It must show that the company can both create the functionality and supply the art content.  Investors who know anything about the industry should demand a Proof of Concept version of the game before investing more money. Who starts first, coders or artists, may depend on who you believe needs the most time to complete a stage of the development or version of the game.

 

5) Game Development

 

The real construction of the game begins. Programmers and artists will scramble in a mad frenzy to not be the team caught trailing the other. Neither team wants to be the one responsible for delaying the reaching of project milestones.  IT personnel will be expected to meet software management, source control, version control, and documentation objectives.

 

Conclusion

Game concept, game design, game design art, and IT issues are the priliminary stages before programming and art teams can make full speed progress. Investors will not be happy to provide capitol for a project until they approve of the game concept and design, which takes game design art to communicate these to the investors. 

 

For these reasons, one can make a case that ART should come first. The 2D and 3D artists often have the skills to supply the game design art to satisfy the investors.  Art is closely tied to game design.

 

 

Based on my research, it seems the first time after the GDD would be to ask the programmers to produce the code for the game using placeholder art - e.g., square boxes instead of real graphics.

 

Very skilled programmers do not need to know anything about the game concept and design. It is the responsibility of leadership to know game concept and design, then tell the programmers what game functionality is needed.

 

If done correctly, the game designer will make the end user game functionality by using the tools made available by the coders. This is why the programmers do not need to know a single thing about the game concept and design.  They only need to know the features to be made available to the game designer.  The game designer will manage the artists and request new functionality in the tools from the programmers.  Sometimes the game designer knows and does NO coding, though high level coding of game functionality is desired and preferred.

 

NOTE:  Game Developer is the person or company which is ultimately responsible for the creation of a game.  Game Developer does NOT mean programmer or designer, though Indy game developers fill all of these roles.

 

Then the next step is to send this over to the artist and ask him/her to create the artwork to fit the placeholders.

 

This is a matter of personal preferrence and convenience.  Actually, the artists can create all of the art before a single line of coding is written and the opposite is also true.

 

In your case, you should test having programmers and artists working simultaneously, then YOU import the completed artwork into your game. If you do it this way then only YOU need to know what the game concept and game design is, plus maximum efficiency and shortest time for development is possible.  Synergy depends on YOU and not them.

 

Once the artwork is ready, it goes back to the developers who fit it to replace the placeholder graphics.

 

"Developer" is a single person or a single organization responsible for the creation of the game. The roles of the developer vary greatly from company to company, doing everything as in the Indy Developer, or only handling leadership responsibilities, or having some role in the actual creation.

 

Does this sequence sound about right? Note that I know I'm leaving out the QA part.

 

 

If you have strong strategic thinking and leadership skills, then the programmers and the artists do not need to know anything about the game concept and design.  What proportion of skills and roles are used by the team members is partly a matter of necessity but mostly a matter of your preference.

 

It is ideal to have all team members working independently of one another but dependent on YOUR guidance. This way none of them are waiting on one another but only waiting on leadership upon completing elements of the game. This is BY FAR the most cost effective way of running a game development company. cool.png

 

Imagine at the other extreme if all of your team members are depending on one another for everything and spend many hours discussing things among themselves instead of making things. ph34r.png  Does that sound profitable to you? ohmy.png

 

Quality Control is YOUR responsibility. You are the leader.


Edited by 3Ddreamer, 31 March 2014 - 12:23 AM.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#10 frob   Moderators   -  Reputation: 22731

Like
4Likes
Like

Posted 31 March 2014 - 12:51 AM

Wow. Taking it section at a time.

 

If you have strong strategic thinking and leadership skills, then the programmers and the artists do not need to know anything about the game concept and design.

 

No. You don't wait until the contract is signed before telling "Oh yeah, this really isn't a FPS, it is a kind of turn based/RTS hybrid." 

 

You need buy-in and feedback from everybody. You might write your pie-in-the-sky GDD thinking it will take three months for five developers to build, only to hear back from your development team that you are looking at 15 people for 12 months. If you design in the dark you will probably be surprised what you see when daylight shines on it.

 

You cannot lead effectively without knowledge, and you get knowledge by active communication and constant feedback.

 

 

 

What proportion of skills and roles are used by the team members is partly a matter of necessity but mostly a matter of your preference.

 

 

Only partially so. If you write an art-heavy design you will need more artists. If you right a code-heavy design you will need more programmers.

 

You have some ability to guide it through your decisions, but if you make up an art-heavy design and then hire insufficient artists, the results will be unsatisfying.

 

 

It is ideal to have all team members working independently of one another but dependent on YOUR guidance. This way none of them are waiting on one another but only waiting on leadership upon completing elements of the game.

 

Yes you need to remove the blocks. That is part of the job of a producer and the project manager.
 
Removing the blocks does not mean "working independently but dependent on YOUR guidance".  That is called "micromanagement", and it is a bad thing. It means the manager is blocking everything. 
 
Over the years my experience is that interdependence is far better than independence. When studios follow the (absolute garbage) advice that chain of command must be followed, it goes like this:  Artist asks the art lead. Art lead asks the project manager to cross divisions. Project manager asks the programming lead. Programming lead asks the programmer.  Programmer provides an answer to programming lead. Programming lead relays it to the project manager, who passes it to the art lead. Art lead tells artists. The process takes three days...
 
... by which time the artist hunted down the programmer, they had a five-minute discussion and the pair found an even better solution than either would have found on their own.
 
Your goal as a producer or project manager are to enable people to do their jobs. Finding good ways to manage means removing barriers, not micromanaging their tasks.

 

 

This is BY FAR the most cost effective way of running a game development company.

 

Citation needed.

 

 

 

Imagine at the other extreme if all of your team members are depending on one another for everything and spend many hours discussing things among themselves instead of making things.   Does that sound profitable to you?

 

I have seen too many counterexamples to even know which one to cite.

 

 

For every game object before starting work we involve the designer, the programmer who will own the feature, the modeler who will own it, the animator who will own it, the sound engineer who will own it, and the QA lead and at least one tester. For important objects we also include the feature's producer(s) and potentially additional developers. The designer discusses the design with every one of them before the final design is approved, often with each group getting clarification or more information back to help build a solid design. Then we have a meeting where all the disciples get together, read the design, and either accept it along with its schedule or suggest significant refinements and send it back to the drawing board. 

 

Often these are scheduled in 4-hour blocks as a chunk of the project moves forward.

 

Some of those objects are simple and can be reviewed and accepted in a matter of minutes. Some of those objects are complex, requiring an hour or more for everyone to agree. It is usually obvious how long the design will take, but sometimes there are surprises where a seemingly simple object makes everyone object to unexpected complexity, or a seemingly complex object can be reduced into very simple parts by the individual disciplines.

 

That kind of open communication allows bad to become good and good to become better.  

 

We can be halfway through the meeting and suddenly the QA lead asks "Have you thought about such-and-such? If they activate A and B at the same time, will this break the game?." And suddenly everybody stops and realizes there is a fatal flaw.

 

Or the audio tech speaks up "I might have counted that wrong, but when I multiply those together it looks like you are asking for about 300 unique voice events. Is that correct?" And suddenly the designer realizes the requirement needs to be removed.

 

The programmer might realize "What if we tied this in to such-and-such system? We could gain these features and also reduce the cost, but it needs more art", followed by the artist "I can probably reuse the existing such-and-such asset if we did that, we can reuse the rig and probably half of the animations", etc. A short conversation follows with some very minor design adjustments. The end result is a 50% reduction in development cost and an even better game object.

 

You want to avoid a situation like Congress, with 535 competing ideas, but it would be foolish not to get input and buy-in from every discipline before starting. These people are your team and your most valuable resource, they are not your enemies.

 

Quality Control is YOUR responsibility. You are the leader.

 

It is everyone's responsibility. Done well everybody is accountable for their own work, and diffusion of responsibility does not apply.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#11 3Ddreamer   Crossbones+   -  Reputation: 3169

Like
1Likes
Like

Posted 31 March 2014 - 01:22 AM

Wow!

 

 

Hey frob, please re-read my post because I gave plenty of exception and I feel that you took everything out of context. I don't have time to hit all the issues now, but I will cover one thing that makes everything that I said both happen in the real world "by preference" and is eventually available to every game developer.

 

The collection of software available to the leader of a game development company makes nearly everything practical, but only if the leader has the skills to use those software.

 

 

Taken in context, everything that I wrote is available and actually being done in the industry.


Edited by 3Ddreamer, 31 March 2014 - 01:23 AM.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#12 GeorgeCH   Members   -  Reputation: 137

Like
2Likes
Like

Posted 01 April 2014 - 05:58 AM

Dear all - thank you ever so much for the thorough and detail discussion of the different project methodologies, and the pros and the cons of each. I confess, I am pleasantly surprised by how active and to-the-point this community is!

 

Thanks a lot,

George



#13 gamearx   Members   -  Reputation: 105

Like
0Likes
Like

Posted 05 May 2014 - 11:57 AM

Personally I had a big pain in ass by balancing between these two apects in development of our games. First thing you should have is a concept, then it goes to design document and specification. Then go sketches, to determine how the things will look like. Believe me, if you don't have sketches approved before you start the development - you're screwed. Like I did. 

On early stage programmers can work without any art. Code don't require it. And when the code is done, they will need art to setup the game. 

So in your plan take it into account, that the art should be done before programmer will finish his coding part. Because there will be gaps that you can't fill out during the process. 

 

Balance is art. You'll never learn it until you do couple of games with a team.


Edited by gamearx, 05 May 2014 - 11:57 AM.


#14 John Farrell   Members   -  Reputation: 110

Like
0Likes
Like

Posted 13 May 2014 - 11:34 PM

Well, what comes first is the artwork - It's because without the art work you can't move forward with the code. You can say artwork is the idea in which you will be going to write down the code for. 


John Farrell

Technical Consultant

Rapidsoft Technologies Pvt. Ltd.

Website: http://www.rapidsofttechnologies.com/


#15 Orymus3   Crossbones+   -  Reputation: 10630

Like
0Likes
Like

Posted 14 May 2014 - 06:31 AM


Well, what comes first is the artwork - It's because without the art work you can't move forward with the code. You can say artwork is the idea in which you will be going to write down the code for. 

 

Careful there. Starting with art could be a problem if you end up with all of the art produced but that it doesn't fit the programmer's expectations (asset sizes for example).

You need both teams to start and get them talking. This is why, oftentimes, its best to do in-house to minimize communication issues. By outsourcing to both (independent) parties, you are successfully cutting down costs, but make it that much more important to keep them synched, which will require (a lot of your) time.



#16 3Ddreamer   Crossbones+   -  Reputation: 3169

Like
1Likes
Like

Posted 14 May 2014 - 05:44 PM

In the development of many AAA popular game titles, the artists went to work first in creating concept art, sometimes in illustrated scene by scene fashion.  If it is done very well, then some of those artworks can be used for attracting more investors and for advertising the game once it is done. The more experienced the game development organization, then generally the more feasible it becomes to have a choice in whether to commit to some art assets first or to begin coding.  Both could begin literally on the same day, as well. A highly skilled single person Indy developer could likely start with a 3D model or start with assembling some game source code libraries with a bit of coding.

 

If the first 3D model is exported from the 3D software in one of the standard model file formats according what the game engine will use, then this likely is no problem. One could begin to create a game that is very art asset driven from the start. To get a "map" or "level"  rendered by the game engine would be an early priority so all art and coding can build in relation to it. 

 

However, if already existing code libraries are to be used, then it could be preferable to tie these libraries together as a game framework upon which art assets would later be imported. Next, further coding would be needed to make game functionality and gameplay features. It is not unusual for placeholder art to be used until all fundamental game source code is ready.

 

Some game development companies have been blasted by gamers for using almost the same game engine, game functionality, and similar game concept in consecutive releases from the company. Here is a case where a company feels desperate for improved development cost to sales ratio.  In this case perhaps all the basic coding is done and used as placeholder while the company puts new art assets in to the framework and will later add coding as needed.

 

In my opinion, most beginners to game development should start with coding first and add art assets later.  An exception might be the highly skilled 3D artists who needs to build on a level that he or she has made.

 

My conclusion is that what is made first (art or coding) depends on factors such as personal preference, skill set, available existing framework, and business pressures.


Edited by 3Ddreamer, 14 May 2014 - 05:49 PM.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#17 Acharis   Crossbones+   -  Reputation: 3986

Like
1Likes
Like

Posted 24 May 2014 - 03:09 AM

We are going to outsource the artwork and the development, most likely to two different parties to save costs.
I know I'm wasting my breath here, but waht you are trying to do is a suicide. Code and art are two critical components you need to have at least one as your core competence, it's a disaster otherwise.

 


Based on my research, it seems the first time after the GDD would be to ask the programmers to produce the code for the game using placeholder art - e.g., square boxes instead of real graphics.

Then the next step is to send this over to the artist and ask him/her to create the artwork to fit the placeholders.

Once the artwork is ready, it goes back to the developers who fit it to replace the placeholder graphics.
Nope, that's now how it's done. Coders will not "fit" any real placeholders (unless you can deal with wrong colourts conversion, inferior rescaling, etc) and artist can not be "sent over" the placeholders (also, you need concept art to show the artists).

 

BTW, placedholders can't be "empty boxes", it still needs some ugly art (forunatelly, coders draw them on their own in most cases). For example you can't code an animation without an actual picture of a human (with fifferent poses if we talk about 2D).

 

My advice would be ordering a finished game (corde+art+sound) and only do the marketing/publishing.


Europe1300.eu - Historical Realistic Medieval Sim (RELEASED!)

PocketSpaceEmpire - turn based 4X with no micromanagement FB





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS