September 5, 2013 11:15 PM | John Polson
"To decide how much detail art should get is a very personal thing for the artist."
[Last month's Screenshot Daily looked at larger game projects. This week, I'm going to look at how developers tackle art in games made in tight schedules. Today we chat about how a developer works with an artist, namely BNeutral (Francisco Marin) about his browser-based, 'fantastic summer blockbusterventure' Timespunkers made in 72 hours for Ludum Dare 27.]
BNeutral: I think we are in a bit of a special position regarding art creation. This is a bit of what I gather as the coder and working with Shwig for about a year now. For whatever reason, he hasn't focused his art training in making the most beautifully detailed, realistic artwork like most artists do (although he does very decently in that area), but instead he has focused in doing "limited palette" aliased paintings very quickly. As such he can churn out sprites of decent quality at an alarming rate. You can see this style of his in most of the game backgrounds and title easily.
This may sound a bit boastful, but he did stream how he made most of the art in a single day. You can see the recordings here if you're interested; they are the ones from August 24.
How do you dictate how much time the art gets?
To decide how much detail art should get is a very personal thing for the artist. Obviously you want to make things small and with few colors to save a lot of time, but ultimately the artist should see how long it takes them to make a background or a sprite, and calculate how much time it will take them to make the others, and see if they have to "degrade the quality" to make the deadline.
I told Shwig to focus on the sprites and not to worry too much about the backgrounds, as the players tend to pay them less attention, but he really likes painting backgrounds. They also did blend in with the sprites a bit, but any "code side solution" like dimming the backgrounds made me feel bad about "degrading his art". What I think took him the most time was the boss knights sprite.
And what about the programming?
What I did to code the game quickly was use a decent library (Flixel) in a high level language (ActionScript3). So I only had to worry about implementing the game itself, not worry about low level details, physics, collisions, or spend time getting simple engine functionality. I'm a bit of a seasoned programmer, so I don't struggle much with code.
If I had to give advice to someone it would be to have them learn how to digest the autogenerated library docs quickly. Most often I don't know much about a library and code with the docs open. It's probably better to be familiar with the library, but using the docs is way faster than following any sort of tutorial (although you may have to look up some bits depending on how the library does things).
I was supposed to also help the art with "programming effects" like particle explosions, particles for snow in the snowy area, and such, which are easy to implement and require minimal art. This however was a bad call, as Shwig was finished with the art quickly, and I didn't even get to implement all the game features by the third day, while he was drawing break rooms with yetis being silly. It would have probably been better to let him do it.
Also I never got to add much "juice" to the game. Some parts that were supposed to have screen shakes and rocks flying are missing them. Damage flashes and score pop ups were implemented in the last minutes.
What are you most proud of?
I'm not really too proud about much of Timespunkers; the only really lovely thing is the art. The "best of gameplay" is probably the bosses, but most people found them too hard! We really rushed into deciding what kind of game to make. I generally try to make games that are interesting and unique in gameplay, but since this was my first time jamming with Shwig, I tried to settle on anything quickly, mostly because I suggested participating in LD to Shwig after he told me he needed some portfolio game pieces. He has even been talking about continuing the game later, and I would really change a lot of things. I'd probably add more interesting controls and powers for the character, drop or at least extend the whole 10 seconds thing, ditch the fixed camera, reduce difficulty, and only have boss stages.
How was working remotely under the time constraint?
Well we have been working remotely for... more than a year now I think; we have never met in person, as we don't even live in the same country. We generally make some decisions via Steam chat (or IRC with the rest of the group for other projects, but he isn't too fond of it), make a few lists of "things that need to be done" and then share files via Dropbox as we progress in our respective tasks.
If I was to say I learned anything about remote projects, it's that you need people that have self-motivation and will get stuff done in a reasonable time without you pestering them. A lot of "internet projects" (and well, the original project in which I met Shwig) tend to gather a lot of people who "want to help" but can't or won't really do anything useful for the project other than brainstorming, or won't "work" unless you annoy them continuously, or aren't really that interested in the whole thing.
Also it's of utmost importance for any such project to iterate on the game fast. If you can't produce a working prototype of the main game mechanic in the first week or two, I would advise reconsidering the whole endeavor. Game jams make this quite obvious, but for longer projects it can be a hurdle.
Any lessons you've taken away?
Well, having more people (of the capable kind) in the group makes making the game way easier, as does having an extra day. Up until now I had mostly participated solo in the 48 hour compo and while the quality of my 3D art is decent, I'm terrible at drawing or painting. And I only make 2D games. So not only did I generally end with weird looking games, but making the art stopped me from adding features. I generally didn't even manage to have music or sound.
This time I had all those "problems" solved, but sharing the game design space made me make a game I'm not too fond of. Also art and music weren't totally solved, I had to make a few edits to the materials given to me so that they were usable in the game. Which is probably my fault for not explaining this to them before the competition. Most notably I lost a lot of time aligning spritesheets, and just managed to explain to Shwig how to export a proper sheet some days ago.
Any nice projects catch your eye?
Probe Team: A game with very simple assets but a great style
Hungry Knight: Simple yet charming