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.

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 ]

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

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.

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?

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?

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.

Hi,

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.

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?

Quality Control is YOUR responsibility. You are the leader.

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.

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.