13 replies to this topic

[glhf]

I guess it might be best for professional studios but for indy then I think its not a bad idea to do art first or at least not delay it more than needed because if you for whatever reason stop working on the game (can happen in indy right) then you can at least sell some of your art that you made in various shops on the web.

[Hodgman]

Who recommends that?
In a professional studio, you've got a whole bunch of full-time artists and programmers. If you're only making one game at a time, and you do the art last, then you'd be paying your art team to sit around doing nothing...

For a 1 man team, you don't have to worry about the above, of course.

Edited by Hodgman, 22 November 2012 - 12:39 AM.

[glhf]

Who recommends that?
In a professional studio, you've got a whole bunch of full-time artists and programmers. If you're only making one game at a time, and you do the art last, then you'd be paying your art team to sit around doing nothing...

yes i also think the same, i dont really know how the studios work maybe they use artists on other projects until its time but i still dont think that sounds very efficient.
i think people who have said this for indy is if its for example just one guy working on the game... and he dont need to hire an artist before the game is more playable or if he will make everything himself then i guess he gets an illusion that the game gets done more quickly.

i dunno..

[Lauris Kaplinski]

Unless you are professional modeler and your art is reasonably generic I doubt that you will sell much. Prepackaged game content market is not as big as people may think.
Usually the best suggestion is - focus on what you are best at first. If you are programmer, start with programming + placeholders. If you are modeler start with modeling + some quick prototyping in Unity or some other similar tool.
Once you have reached to certain stage and are confident that your idea works, it will be the time to think how to organize other aspects of game development.

[Bacterius]

Well obviously if you are the one doing the art, things are different, but the majority of developers cannot produce good artwork (we do "programmer art" instead, i.e. 16x16 sprites that look like a six year old child just discovered MS Paint), and it's better to use that as a placeholder first than to go hunt for/purchase artwork for your game first, because:
- a functional game with crappy art constitutes more satisfactory and tangible progress (to the developer) than a nonfunctional game with beautiful art
- the sprites you choose at first will probably be heavily redesigned throughout the game as you polish the gameplay

It's the same reason why people don't decide on a definitive game name before even starting it - you go with a codename used to refer to "the project", and the actual decision of what to call the release comes in the final stages (and you may even end up actually using the original name - it sometimes is the case, but not always)

Edited by Bacterius, 22 November 2012 - 12:57 AM.

[Kyall]

Greyboxing is a rapid iteration and cost saving exercise. The artists do produce the grey boxes, they are usually modelled, they're just not textured or very detailed. If you imagine a game level that's something like an office; with greyboxing instead of having desk, chairs, paintings on the walls etc, you'll just have walls, floor, and cubes in place of all the furniture. There's not much modelling to do but the artists can still model things faster than other people can (experience with modelling tools) so they would do the modelling, and what this gives you is a good mock up of what a level could be.

Producing actual assets, with textures, and high detail, is expensive in both time and money, this is why there are usually twice as many artists than programmers on a team. And the worst part is that given that expense, once you have the assets, you are stuck with them. Because there's never a good enough justification for throwing a level that has been fully detailed out, even when the setting ceases to work in the story and the layout ceases to be compatible with the mechanics.

So it's pretty useful for small and large teams; because you can build your assets and levels fast, essentially build large swathes of the game so you can iterate, without having to commit to anything, and without wasted hours down the road trying to make old assets fit a new setting or set of mechanics.

[azonicrider]

For 2d (platformer) games, I just use squares as placeholders. The green square is the hero, blue squares are enemies, red squares are terrain.

I wouldn't consider using placeholders as recommended, but eh it all depends on what path you wanna take for developing your game.

[jbadams]

Have you ever seen someone who wants to learn to program games but "can't get started" because they don't have any art? Those are the people that benefit most from the advice to use simple place-holders and replace it later, and they can get themselves completely stuck with thoughts like "I can't start coding the main character, because I don't have a sprite for him", or "how can I make a Pong clone without a paddle and ball sprite?"

In all likelihood their earliest efforts will be buggy and incomplete -- or at least not their best potential work -- whether they have good art or not, and if they're approaching things sensibly they're developing the projects as a learning experience rather than aiming to sell them anyway. The lack of art is an artificial barrier that prevents them from proceeding with their learning, when in reality all they need is some simple shapes to see that their code is working correctly.

[MaxieQ]

Game making is, it seems to me, a team effort. You can't really, except for the simplest games, do it alone. And coders (look at me!) often make terrible artists because we're more concerned with optimisation than artistic vision. We'd dump the colours if we though we could shave off a microsecond on a tight loop.

[Bacterius]

Game making is, it seems to me, a team effort. You can't really, except for the simplest games, do it alone. And coders (look at me!) often make terrible artists because we're more concerned with optimisation than artistic vision. We'd dump the colours if we though we could shave off a microsecond on a tight loop.

Interesting vision. Myself I care a lot about art and graphical appearance, but I simply cannot produce any myself. I definitely wouldn't sacrifice an artistic aspect of the game clawing for a couple extra frames per second. I mean, performance is important, but at some point you just need to accept that doing computational work takes time.

Edited by Bacterius, 25 November 2012 - 06:05 PM.

[MaxieQ]

Game making is, it seems to me, a team effort. You can't really, except for the simplest games, do it alone. And coders (look at me!) often make terrible artists because we're more concerned with optimisation than artistic vision. We'd dump the colours if we though we could shave off a microsecond on a tight loop.

Interesting vision. Myself I care a lot about art and graphical appearance, but I simply cannot produce any myself. I definitely wouldn't sacrifice an artistic aspect of the game clawing for a couple extra frames per second. I mean, performance is important, but at some point you just need to accept that doing computational work takes time.

Art is a complex profession in and of itself. You need to know a lot to produce something decent.

I just don't think that it is reasonable, or should be expected, that a game maker should possess both the coder and art skill sets.

I think of making games as more like making movies than writing books or playing music. You need both a director and an editor, and it's rare that the roles are rolled into one person because the skillsets are so diverse. I think that's the case in game making too.

[SimonForsman]

I guess it might be best for professional studios but for indy then I think its not a bad idea to do art first or at least not delay it more than needed because if you for whatever reason stop working on the game (can happen in indy right) then you can at least sell some of your art that you made in various shops on the web.

For hobbyists the main reason to wait with recruiting anything really is that skilled <insert whatever you want here> simply do not join an unpaid project unless they can see real progress on it. (If you try to recruit for a project that isn't well underway allready you won't attract the talent you need/want, people who do not know you will judge your project by its progress, not its promises).

Start with what you are good at.

Edited by SimonForsman, 25 November 2012 - 07:24 PM.

[TheChubu]

Just don't make 80 different kind of crates to clutter your scenes and everything will be fine

[riuthamus]

Hm... me and my coders have this argument all the time. Being an artist "primarily" the issue is that when we make something for the game we make it for the state the game is in. If some code changes that effects your design, lighting, shaders, size limitations, and thousands of other possible things must be in place before the real art can sit comfortably within your creation. Im not saying wait till the very end of development but I am saying it would be best for the team to have something solid for the artist to work from.

I envision the code to be the bones and muscle of the game. They give it movement and mechanical function. The art is the skin and hair, the clothes, the superficial things that help you make it all look worth something. Without one the other is doomed to fail but you must have a sturdy mold to work from before you can even begin to create solid art.