Jump to content
  • Advertisement
Sign in to follow this  
Sixoul

Getting the art to the rest of the team

This topic is 2079 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm not an artist but I'm working with a club member who's making the art and I'm not sure the best way to go about having him get the art to me. Should I have him make a Dropbox, send through email, etc? I'm not sure of the best way to go about this.

Any help or advice would be much appreciated.

Share this post


Link to post
Share on other sites
Advertisement

I, personally, send weekly/fortnightly updates through email, just using attachments.
If it's more laid back, or something I'm doing with friends, I'll up to Dropbox for large files and send the link through Skype, or just send it through Skype right off the bat.

It's sort of a personal thing and depends on the team dynamic, really. I've had people get me to upload to the team management site instead before, or forums, or a google doc. Whatever fits the team the best.

Share this post


Link to post
Share on other sites

Ideally, you'd want to use a version control system, like Subversion, etc, so that you can always get the latest version of every asset from a central repository (if your HDD fails, then having to re-piece-together the game by going through your email history is never fun), and so you can also easily go back in time to older versions ("hey the game is crashing now, I'll try undoing your changes from 9am today...").

 

In a small, distributed team, this can be a pain to set up though... You need a central server somewhere, and someone needs to back it up and administer it.

Using something like Dropbox is a lot easier in these situations because they take care of the hosting issues. The downside is that you lose fidelity in change management -- every change is automatically 'committed' to the server, without a log message, and regardless of whether it's a WIP or a usable change. Dropbox's versioning / undo / blame abilities are also a lot worse than a real VCS like Subversion, and may not even exist if you're using free Dropbox.

Share this post


Link to post
Share on other sites

If it's just art your sharing, a dropbox of Google Drive will be sufficient. If you're sharing code or working on a project on a program together (like Unity), then you need a version control system. I learned this the hard way. 

 

But again, if it's just art, a well organize cloud drive should be fine. Good luck!

Share this post


Link to post
Share on other sites

Ideally, you'd want to use a version control system, like Subversion, etc, so that you can always get the latest version of every asset from a central repository (if your HDD fails, then having to re-piece-together the game by going through your email history is never fun), and so you can also easily go back in time to older versions ("hey the game is crashing now, I'll try undoing your changes from 9am today...").

 

In a small, distributed team, this can be a pain to set up though... You need a central server somewhere, and someone needs to back it up and administer it.

Using something like Dropbox is a lot easier in these situations because they take care of the hosting issues. The downside is that you lose fidelity in change management -- every change is automatically 'committed' to the server, without a log message, and regardless of whether it's a WIP or a usable change. Dropbox's versioning / undo / blame abilities are also a lot worse than a real VCS like Subversion, and may not even exist if you're using free Dropbox.

 

It's good for coding but I disagree you should set up such system for art. Art is art, it rarely "breaks" and you often have just one person working on one asset be it a texture, model, sound etc.

 

DropBox is easy to use. You upload an identically named file it just replaces the previous one without prompting and keeps the old version as well. Google Drive is also good because it has more storage out-of-the-box, but you need to choose to upload a new revision instead of just choosing the same file.

 

Share the folder, send the link to the team so they can access it. Then you are free to structure the directories and files according to what you have.

 

What I am most concerned about is that you don't seem to give your artists the opportunity to see and test their art in-game and it seems like one-sided process to me. Remember to interact and keep your artists in your game development, they also have many ideas on how you should use their art after they send you it smile.png

Edited by ShadowFlar3

Share this post


Link to post
Share on other sites

 

Ideally, you'd want to use a version control system, like Subversion, etc, so that you can always get the latest version of every asset from a central repository (if your HDD fails, then having to re-piece-together the game by going through your email history is never fun), and so you can also easily go back in time to older versions ("hey the game is crashing now, I'll try undoing your changes from 9am today...").

 

In a small, distributed team, this can be a pain to set up though... You need a central server somewhere, and someone needs to back it up and administer it.

Using something like Dropbox is a lot easier in these situations because they take care of the hosting issues. The downside is that you lose fidelity in change management -- every change is automatically 'committed' to the server, without a log message, and regardless of whether it's a WIP or a usable change. Dropbox's versioning / undo / blame abilities are also a lot worse than a real VCS like Subversion, and may not even exist if you're using free Dropbox.

 

It's good for coding but I disagree you should set up such system for art. Art is art, it rarely "breaks" and you often have just one person working on one asset be it a texture, model, sound etc.

 

I disagree almost to the point of downvoting this, but since you're offering earnest advice, and the topic is somewhat a matter of opinion, I'll just rebut instead.

 

In a simple game, sure, art might not often break things, but there's certainly the potential for breakage and more-complex games run into it not infrequently -- As one example, say a graphics programmer tweaks a shader in such a way that the texture that it used to sample for information no longer contains the correct information. You can't argue that this is a broken code, because the code functions as expected -- the art is simply out of date. Other times, an artist might "check in" some changes to an asset that aren't what the designer wanted -- its a bad idea to simply rely on the hope that the artist has kept a backup of the old version. In larger teams its also not always true that the same artist always works on the same asset -- its unlikely you'll have two different artists working on the same piece at the same time, but many artists might touch the same piece all during development.

 

These kinds of problems are what a version control system handles -- Art should be versioned alongside the code (what if you need to back out some code changes and all your "new" art is incompatible?), sometimes changes need to be undone, people need to be able to collaborate. On top of that, an adequately backed-up version control repository--preferably on a redundant volume (say, mirrored RAID)--offers great piece-of-mind.

 

Now, the one difference, IMHO, between code and art in a version control system is that I believe code assets are best-served with a truly distributed model (typical GIT-like, or mercurial-like workflows), and art assets are better-served by the more-traditional centralized model (check-out/check-in model, more like Subversion). The main reason is the size of the raw art assets, and the fact that you don't need all of the art to do your job in the way that programmers need all the code to do theirs -- for small projects, this probably isn't a practical concern, but still the history of the art repo can become very large -- perhaps too large for someone working remotely over a slow connection.

 

There are workflow advantages to version control too -- You can always afford to be experimental and even recklessly so, safe in the knowledge that you can't break anything beyond repair.

 

If you're a small team, drop-box works for you, and a complete lack of file versioning doesn't scare you, fine. Do what works for you. As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it. I would strongly recommend against even a single artist working without version control, but I can see an argument that it might be unnecessary if you can square yourself with the potential for human error (no or infrequent back-ups) or minor catastrophies (drive failture or an artist who just disappears). Working with two or more coders or two or more artists without version control is just asking for trouble, though, and borders on heresy.

Share this post


Link to post
Share on other sites
As one example, say a graphics programmer tweaks a shader in such a way that the texture that it used to sample for information no longer contains the correct information 

 

That's just bad workflow. Art should not even try to keep up with such tweaking if each tweak results in unusable art file that needs to be redone.

 

the art is simply out of date.

 

Yes, plus the above. How is this relevant to using subversion or not?

 

Other times, an artist might "check in" some changes to an asset that aren't what the designer wanted -- its a bad idea to simply rely on the hope that the artist has kept a backup of the old version.

 

Poor project management again, but of course mistakes can happen when dealing with humans. Anyway like I said Dropbox and Google drive have built-in file history you could use in this case. But in the longer run you just tell your artist to fix the art and use the older version until then. Subversion offers no advantage over this mechanic besides having some arbitrary numbers describing each step.

 

what if you need to back out some code changes and all your "new" art is incompatible

 

See my earlier post and/or above.

 

an adequately backed-up version control repository--preferably on a redundant volume (say, mirrored RAID)

someone working remotely over a slow connection

 

 

I think it's funny you switch back and forth between a serious big scale project and small and poorly arranged setup depending on what suits your point. If you have things like mirrored RAID doing backups you most likely have an adequate internet connection and build your team based on relevant requirements.

 

If you're a small team, drop-box works for you, and a complete lack of file versioning doesn't scare you, fine.

 

As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it.

 

Dropbox/Google Drive don't "completely lack" file versioning... see above...

 

Also the OP situation as I can deduce from what he writes (he is considering email for example) is not an overly huge, serious and complex project. These advice about Subversion are especially overshot in OP's situation, which concerns me the more than arguing about it in a theoretical environment.

 

As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it.

 

 

As a programmer, neither would I. As an artist, however it is a different situation and you have to be sensible about it.

 

While I could agree that some complex model/animation assets might benefit from keeping a history of older files in some form, using subversion for images is just plain absurd. If your pixel is wrong color it doesn't break the workflows of the rest of the dev team and getting all totalitarian strict with things like Subversion is needless. You update the art on a schedule that is not strictly fixed to your code. You can always use placeholders. For things like testing shaders on pixel sampling level (that's not really "art" anymore anyway) the graphics programmer is able to make image files adequate for testing. Like Hodgman said it is "a pain to set up" and documenting versions and changes is just whole lot of useless work. Use it for code but don't expand it to areas that don't need it.

Edited by ShadowFlar3

Share this post


Link to post
Share on other sites


an adequately backed-up version control repository--preferably on a redundant volume (say, mirrored RAID)
someone working remotely over a slow connection

 
I think it's funny you switch back and forth between a serious big scale project and small and poorly arranged setup depending on what suits your point. If you have things like mirrored RAID doing backups you most likely have an adequate internet connection and build your team based on relevant requirements.

Projects come in all shapes and sizes, so do budgets and infrastructure. Private hosted GIT/Subversion accounts are a $10/mo commodity -- I can host either or both for no extra charge through my $9.99/mo webhosting package that I'm already paying for. I fully acknowledge and explicitly say that Dropbox is an option for small teams if they can live without capital-V version control. My argument is that proper version control isn't that much more difficult to grok, and its benefits begin to outweigh the simplicity of something like Dropbox pretty quickly once you have more than one person working on the art assets. No, you don't necessarily need to retain every version of an art file whenever an artist decides to recolor something, but Dropbox will do that by default too.

 

You spend some time knocking how some of the problems are because of workflow, but branches solve those problems and allow everyone to keep working at their own pace. I agree the code and art teams need to coordinate, dropbox doesn't change that, and to the extent possible the code should be robust about art being out-of-date. But that doesn't mean the repository of art-history needs to be sub-standard. I'd rather have the capability and not use it, than to lock myself out of it ahead of time. Things like atomic checkin are really nice, and AFAIK Dropbox can't guarantee atomic checkins of a package of changes, or even package a bunch of files together at all. Branches and tags are also pretty useful. 

 



If you're a small team, drop-box works for you, and a complete lack of file versioning doesn't scare you, fine.
... 
As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it.

 

Dropbox/Google Drive don't "completely lack" file versioning... see above...

 

It keeps old versions around, probably with a date-time stamp of some kind -- you might be able to correlate the two independent systems, but its error-prone. This isn't capital-V Versioning, Dropbox has no notion of what art asset file in its history matches up to what version of your source-code assets.

Share this post


Link to post
Share on other sites

Hi,

 

 

Usually email is good enough, but if the file is gigantic, such as a huge map for your game, then uploading to your website FTP or to something like Sourceforge would be the way to go.  Your team can get at it that way.

 

 

Clinton

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!