• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
GeorgeCH

What comes first, artwork or code?

16 posts in this topic

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.

1

Share this post


Link to post
Share on other sites

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 ]

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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

2

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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. 

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0