I know there are issues with groups of people working with a single set of code, but I think there's moreso when it comes to texturing; at least, the issue shows more. With code, you don't see it as you're using it. The different ways people code can work together and you won't know the difference, putting a group of artists in a timed challenge, and telling them to get so much done... There's going to be a big gap in styles. With time, they could work slower, match things up better, but it's timed, and that privilege is lost.
I'm glad to see that we're getting our questions answered and issues acknowledged, but with so little time before the challenge starts, all this talk is basically moot. Yeah, some changes can be made, a few fixes done, but the big issues that would change the criteria of the challenge completely aren't as flexible, I'd think.
There are definite gaps in programming styles as well. And not just using camelCase vs lowercase vs - you get the idea.
Our ideas can conflict.
Programmers can say were gonna add a new ore that manipulates time:
One might think: Lets make the world tick change to make the sun move backwards really fast
One might think: Lets add a new dimension that is filled with ruin and midevil warfare
In a similar way to how you can solve math problems in different ways, you can also program to do a certain thing in very different ways.
I could throw a bunch of examples down, but it might not make sense if you can't read java.
There are definite gaps in programming styles as well. And not just using camelCase vs lowercase vs - you get the idea.
Our ideas can conflict.
Programmers can say were gonna add a new ore that manipulates time:
One might think: Lets make the world tick change to make the sun move backwards really fast
One might think: Lets add a new dimension that is filled with ruin and midevil warfare
In a similar way to how you can solve math problems in different ways, you can also program to do a certain thing in very different ways.
I could throw a bunch of examples down, but it might not make sense if you can't read java.
But unlike textures, you can have various people write different class files their own way that all interconnect with each other and work just fine, thats why Object Oriented Programming exists in the first place. Sure, they may have 12 different ideas on how to get the answer 42, but it doesn't matter as long as that person writing that .class file can make it output the answer 42. The other people's coding style doesn't really matter, as long as everyone is aware of what everyone else is doing. If you have different ideas on what "42" is in the first place, thats an entirely different problem. Once you all agree 42 is just a number, and not the answer to the meaning of life, the universe and everything, and then press on.
Textures on the other hand, people with drastically different drawing styles will clash. For example, if myself, Steelfeathers, Syclone, corner_g and Alvoria (etc) got together to make a pack I can pretty much guarantee even though all of us are good artists, the output will look like garbage. Our styles are fundamentally different and just don't work together.
This doesn't apply to programming; even if you have drastically different coding styles, as long as you're all sticking to one area (.class/set of .classes) of code and as long as yours outputs what it should be outputting to the other parts it doesn't matter if you decoded your output was 42 because you got it by adding 2 numbers, subtracting one from another, squaring it, or just setting it. All that matters is the other class files receive "42" from that class file and it'll work like a champ.
I know I'm horribly oversimplifying the entire programming process, I'm just trying to make a point that artists just don't work together the same way programmers can.
I'm just trying to make a point that artists just don't work together the same way programmers can.
I agree with almost all of what you said. However, the use of an absolute in this sentence bothers me. Obviously teams of artists are capable of working together, or else big games with 50+ people on the art team would not look as nice as they do.
I think there are challenges for both coders AND artists when working in teams, although those challenges are fundamentally different. So let's not devolve into "who has it harder", please.
Just a quick note to say that I've updated the Rules page for ModJam to specifically state that partial packs will be accepted if they follow a "theme" (ie, Trees and Flora, NPCs, The Nether, ...). I'm working on some more prizes as well.
Hopefully this change makes it more interesting for resource pack makers this time around, realizing we are right up to the deadline here
Next time around I promise some more "support" (for lack of a better word) in the resource pack competition!
I agree with almost all of what you said. However, the use of an absolute in this sentence bothers me. Obviously teams of artists are capable of working together, or else big games with 50+ people on the art team would not look as nice as they do.
I think there are challenges for both coders AND artists when working in teams, although those challenges are fundamentally different. So let's not devolve into "who has it harder", please.
Eh, sorry. I didn't mean to make it sound so absolute.
I should probably rephrased that to "I know I'm horribly oversimplifying the entire programming process, I'm just trying to make a point that artists usually do not work together the same way programmers can. Although they can in certain situations they can, like in large scale development teams"
Although even that isn't quite the same, I get what you're saying though and I agree with you. I also didn't mean to make our job sound harder, I actually think they're about the same. It is actually possible for artists to work together, although like you said they really don't function the same way. Usually with game development you have concept artists, texture artists, 3d modellers (if its a 3d game), character artists, etc. But these guys have months just to perfect all their styles to come together with a single style they can all agree on and all have the ability to output, then focus on their specific areas.
I guess the MC equivalent would be something like one person makes the blocks, one makes the sprites/items, one makes the GUI and one makes the mobs. So it may be possible with an extremely well organized and highly skilled team to make a single texture pack that looks good together, but it's still not the same as how programmers do it. For example, your pixel art and my cartoony art don't look good next to each other, but if this was programming, it wouldn't matter as long as yours is doing it's job and mine is doing it's.
So while it is possible for artists to work in teams, i just feel it's just unrealistic in a situation like this with people from various skill levels and various styles to come together in such a short amount of time. I think the reason it works with serious dev teams is they're all highly skills (most of them more so than everyone here) and they have plenty of time to just sit down and hammer out an art style they are all capable of doing, and agree with, plus additional time to gain the talent at actually designing it.
While I don't know how large art teams work, I imagine that there's a minimum of a few months where their output is basically zero because they're all trying to figure out how to have an output in the first place, but that's just an assumption.
Our ideas can conflict.
Programmers can say were gonna add a new ore that manipulates time:
One might think: Lets make the world tick change to make the sun move backwards really fast
One might think: Lets add a new dimension that is filled with ruin and midevil warfare
In a similar way to how you can solve math problems in different ways, you can also program to do a certain thing in very different ways.
I could throw a bunch of examples down, but it might not make sense if you can't read java.
Twitter: @iPixeliMC
But unlike textures, you can have various people write different class files their own way that all interconnect with each other and work just fine, thats why Object Oriented Programming exists in the first place. Sure, they may have 12 different ideas on how to get the answer 42, but it doesn't matter as long as that person writing that .class file can make it output the answer 42. The other people's coding style doesn't really matter, as long as everyone is aware of what everyone else is doing. If you have different ideas on what "42" is in the first place, thats an entirely different problem. Once you all agree 42 is just a number, and not the answer to the meaning of life, the universe and everything, and then press on.
Textures on the other hand, people with drastically different drawing styles will clash. For example, if myself, Steelfeathers, Syclone, corner_g and Alvoria (etc) got together to make a pack I can pretty much guarantee even though all of us are good artists, the output will look like garbage. Our styles are fundamentally different and just don't work together.
This doesn't apply to programming; even if you have drastically different coding styles, as long as you're all sticking to one area (.class/set of .classes) of code and as long as yours outputs what it should be outputting to the other parts it doesn't matter if you decoded your output was 42 because you got it by adding 2 numbers, subtracting one from another, squaring it, or just setting it. All that matters is the other class files receive "42" from that class file and it'll work like a champ.
I know I'm horribly oversimplifying the entire programming process, I'm just trying to make a point that artists just don't work together the same way programmers can.
I agree with almost all of what you said. However, the use of an absolute in this sentence bothers me. Obviously teams of artists are capable of working together, or else big games with 50+ people on the art team would not look as nice as they do.
I think there are challenges for both coders AND artists when working in teams, although those challenges are fundamentally different. So let's not devolve into "who has it harder", please.
Hopefully this change makes it more interesting for resource pack makers this time around, realizing we are right up to the deadline here
Next time around I promise some more "support" (for lack of a better word) in the resource pack competition!
Eh, sorry. I didn't mean to make it sound so absolute.
I should probably rephrased that to "I know I'm horribly oversimplifying the entire programming process, I'm just trying to make a point that artists usually do not work together the same way programmers can. Although they can in certain situations they can, like in large scale development teams"
Although even that isn't quite the same, I get what you're saying though and I agree with you. I also didn't mean to make our job sound harder, I actually think they're about the same. It is actually possible for artists to work together, although like you said they really don't function the same way. Usually with game development you have concept artists, texture artists, 3d modellers (if its a 3d game), character artists, etc. But these guys have months just to perfect all their styles to come together with a single style they can all agree on and all have the ability to output, then focus on their specific areas.
I guess the MC equivalent would be something like one person makes the blocks, one makes the sprites/items, one makes the GUI and one makes the mobs. So it may be possible with an extremely well organized and highly skilled team to make a single texture pack that looks good together, but it's still not the same as how programmers do it. For example, your pixel art and my cartoony art don't look good next to each other, but if this was programming, it wouldn't matter as long as yours is doing it's job and mine is doing it's.
So while it is possible for artists to work in teams, i just feel it's just unrealistic in a situation like this with people from various skill levels and various styles to come together in such a short amount of time. I think the reason it works with serious dev teams is they're all highly skills (most of them more so than everyone here) and they have plenty of time to just sit down and hammer out an art style they are all capable of doing, and agree with, plus additional time to gain the talent at actually designing it.
While I don't know how large art teams work, I imagine that there's a minimum of a few months where their output is basically zero because they're all trying to figure out how to have an output in the first place, but that's just an assumption.