Archive for January, 2011

So this weekend was the Global Game Jam. The jist of it is that game developers all around the world meet up in their respective cities and divide into teams. They’re given a theme (this year’s was “Extinction”) and all the teams have 48 hours to develop a game based on that theme. I’ve done some super short game dev competitions back in my hobby days and they’re always fun because you’re forced to focus on game design and getting to work, no slacking off or slowing down. It’s pretty incredible how much you can get done in a weekend when you’re motivated.

This wolf guy is from the game I was working on. The idea was that you have Beefalo (buffalo that look like giant slabs of meat) and they’d act with swarming behavior, heading toward and away from things on the map, and you have to herd them off the cliffs around the edge of the map by laying down objects that they have to go around, or that attract or scare them. The wolf was an object that would scare them away. Unfortunately we ran into a lot of problems on the programming side (one programmer had to work his normal job for part of the weekend, and we tried doing the game in HTML5 which turned out to be way more complicated than expected) so the end result is more of a little tech demo…but I think the idea itself has potential.

I got to get a lot of animation workflow practice in. I’ve got a pretty solid flow going, and I’ll record my desktop as I animate sometime. I’m always trying to find the fastest way to animate haha My laptop held up awesomely, I put it through quite the workout and it was totally worth the price.

It was interesting working side-by-side with programmers again. We had 2 artists and 2 programmers, and the programmers were doing their thing while the artists were doing theirs and then at the end we just combine everything. I haven’t worked like that in a while since now I’m working on the art ahead of the programming, so it was cool to go back to the old method for a weekend.

Sleeping on the floor and not showering were rough, and it turned out the University’s food courts were closed for the majority of the weekend, so I ended up pretty much living off a tub of gingerbread cookies haha Sunday night I downed a bunch of healthy food, showered, and slept for like 20 hours. I think next year I’ll bring food and an air-mattress…and like, a can of febreeze haha

The Jam itself was pretty cool, if you’re a game developer anywhere in the world, you should consider attending next year. Everyone was friendly and I got to meet some people who’s games or names I recognize. I was recognized as Tsugumo which was fun haha Met a couple guys from Pixelation. I’ll definately be attending the GGJ next year and down the road when I have employees going on, I’ll figure out a way to encourage everyone to attend it. I think short projects like that teach you good things about working efficiently and avoiding feature-creep.

I’ll post some ninja game related stuff next update. It’s the end of the month so it’s time to go over my financials and see if I’m screwed or not so far haha

- Quickdraw

So my workflow right now involves drawing and animating the art in Flash, then saving the frames out as .PNG files and reducing and trimming them in Photoshop. I’m using Flash because I’m predicting that the next devices that come out (iPad 2, iPhone 5, etc.) will increase their screen resolution just like the last generation did with the retina screens, so Flash’s vector art scales up to any size nicely compared to bitmaps.

As an artist though, I like drawing and animating in Photoshop more…I’m used to the layout and I like the tools in it. Drawing with vectors in Flash, I use the Brush tool because I can free-hand my art which is faster than drawing it point by point and messing with bezier curves…but the trade-off is that the lines come out less accurate. I may draw a squiggle shape, like the profile outline of a face, but it won’t come out exactly like I draw…there’ll be little smoothed curves and such as the math guesses “close” to what I want.

That’s a big part of the reason the art is super sketchy, it’s hard to GET clean perfect line-art in Flash quickly, so I’m adapting to that.

The other catch is that while Flash has a lot of great tweening options (you set two keyframes and it figures out what to do with the shape’s position, scale, rotation, etc. in-between those frames), it also pumps out a TON of frames. It’s pretty easy to spot a game where the art was animated in Flash because there’s lots of extremely extremely smooth animations.

Visually, that’s not a bad thing…60 frames for a running animation looks way smoother and nicer than a 6 frame run animation. But when you’re making a game where you have limited space and memory, that 60 frames adds up FAST and next thing you know your game is huge or running slow on low-end systems.

This is my ninja’s Idle animation. I export the original Flash animation, which is 12 frames (starting from standing, to breathing full out, and back to standing), and then I go through and look at them and see “okay, which frames are necessary for the animation? I need the first frame for sure, that’s what other animations are based off. And I need the middle frame, where he’s in the down-most frame of his breathing…but now which of the frames between the two can I get rid of and still have the effect stay the same? Well Frame 2 is VERY similar to Frame 1, since the momentum of his breathing is at it’s slowest at that point…so I can probably zap Frame 2. Maybe even Frame 3. Frame 4 is halfway between Frame 1 and Frame 8 (Frame 8 being the full out-of-breath frame), so I’m going to leave that in. And I want him to look like he’s slowing down as he gets to the end of his breathing out, so I’m going to leave in Frame 7. Now when he rises back up, I can probably re-use Frame 7 instead of using Frame 9.” etc. etc.

The end result, as you can see in the video above, is that the 4 frame version keeps the same feeling the 12 frame version has, and at a glance you really don’t notice the difference…except if each frame is 35k, I’ve just saved 280k. And that’s just an idle animation…an animation of a character attacking or celebrating something could be 100+ frames. And it could probably be reduced to 20.

I’m off to the Global Game Jam 2011 in a couple minutes! Just wanted to give a shout-out to anyone coming here from Hacker News! You guys blew up my server for a bit, but talk about a quality problem haha Hope ya like the blog!
- Quickdraw

I’m doing up the rain effect today.  I’m hoping to get this game to run smooth on older devices, so I wanted to make the rain easily modifyable.  I’m not sure how many sprites Cocos2d can push at a time on, say, a 2nd gen iPod Touch…I’m sure I don’t have anything to worry about, I’m not making Smash TV here or anything, there’s basically a ninja, some stuff being thrown at him, and a couple background images, but I always like to stay on the safe side because it’s way nicer to find out you have excess memory at the end of the project than find out you don’t have enough haha

My early days in the game industry were spent working on cell phone games where we’d make an S60 version, which would be something like 260×320 and let us do badass full screen art and everything.  But we’d have to then make an S40 version, which was like 120×208 and way less powerful so I’d have to replace artsy backgrounds with color bar gradients and stuff.  We also had to do a third version…S30 maybe?  Can’t quite remember.  But it was a piece of crap.  Like a 128×128 screen and super weak power, where we could do the absolute most minimal stuff.  So I got in the habit of thinking in terms of “how can I strip this down if I have to”?  I found it was easier to just work efficiently from the start.

So this is how I usually do rain…I stole this method from some RPG on some console back in the day.  I have a raindrop graphic and a water splat animation:

The actual drops in-game are super long, but having a giant graphic like that is a waste so I just make a shorter version and stretch it vertically in-game…the above is for the 1024×768 iPad.  I actually had a much shorter drop but I would have had to scale it like 2000% and I get nervous about how the game’s going to handle a bunch of 2000% scaled images, so I like to size it so that when I stretch it out I only have to stretch it between 200% – 500%.  The rain splat is just a quick doodle of a drop blipping into some ripples.

Now I combine these by showing the raindrop randomly all over the screen, I also show the rainsplat randomly around the screen.  So the drops aren’t ACTUALLY hitting the spots where the rain splats appear, but when you look at them together the overall effect is that rain is pouring.  If I had a splat where each drop lands I’d have to figure out the depth/height of objects, which surfaces can get a drop, if there was 50 rain drops I’d need 50 splats as well, etc.  With this method I can have 50 rain drops but only 10 splats and get the same overall effect.  In the end I have about 11 drops shown at a time and maybe 5 splats shown at a time.  The layers look like so:

I figure if I run into slow-down on older devices I can just remove a few raindrops or splats until it runs smooth.

I like this method for making rain in an RPG because you can specify in your tiles which ones should get rainsplats and which ones shouldn’t (so you’d have the roof tiles on a house splattable but the wall tiles wouldn’t be).

- Quickdraw

I’m actually changing up my workflow a bit.  As I’ve mentioned before, I’m planning to out-source the programming to a freelance programmer or group of programmers from freelance sites.  Originally I was going to try to work in-sync with them, so I’m making the art as they program, because that’s the traditional method, working hand-in-hand and bouncing ideas off eachother.  But I’ve got this game planned out down to the pixel in my head and in the Game Design Document, so I know what art I’m going to need and how it’s all going to link together…as long as I provide the resources to the programmer, they should be able to construct the game without me doing more than checking in on their builds and sending lists of tweaks to make.

My first few games will be super simple, so it’s not difficult to visualize them all in my head.  I predict that when I DO hire a programmer for this first game, at least 95% of the art will be done and final and they may need a little tweak here and there from me but for the most part it should be a simple process.

This frees me up to design the gameplay and draw up the art for my NEXT game.  So my original schedule looked something like:

Since I’m wearing so many hats, I have to cover Design, Art, Music/SFX/etc., Testing, and Marketing myself.  Down the road I can out-source some of that but for now I’m the one juggling all of that solo.  With the traditional in-sync method I’d bring on a programmer when I had some of the basic art done and work alongside him.  Unfortunately that creates this massive block of two weeks where I’m juggling a ton of work all at once.  I’d love to say I have the work ethic and amazing unstoppable drive to push through that but realistically after running into that once or twice I would probably burn out.  The whole point of starting my own studio was so that I could avoid the ridiculous overtime burnout the game industry is notorious for.  I believe that if you schedule things properly, you should be able to create a game stress-free, working normal hours, and if that game sells decent you should be able to take a week off after a project and de-stress before starting the next one…that’s idealistic, I know, but it’s my goal.  Except I want a month off between projects.  Paid.  For everyone in-house.  haha

So now as I work on the art and realize just how much of this game is already planned out and just needs to be drawn up, I’m going to be going with something like:

With this setup I’m creating all the resources in advance, and then hiring a programmer once they’re all complete.  When the programmer is working on the first game, I’ll have them send me builds daily to test to make sure the game is on track and I can send them a list of stuff to fix/tweak, which should take maybe an hour or two of my day…the rest of the day will be used to design and start the art for the second game.  So I’ve staggered my development instead of lumping it all together.  I’ll be designing and drawing the next game while the programmer is piecing together the previous game.  This results in less “clumping” of my tasks…it also means I’ll have more time to handle any issues the programmer brings up.  Like if I convert a bunch of PNGs wrong or have to redraw something, I’ll have the free time to do it, VS the first schedule where I’d be busy juggling finding music and testing the game while I have to suddenly re-convert all those PNGs.

I believe this is the optimal method for my situation.  It gives me a week of design/concepts, 3 weeks of art, a week as I finish up the art to get the Music/SFX going, and then I just causally test the game while the programmer develops it and the testing overlaps casually designing the next game and just starting the art.  Whereas in the original schedule, I’d have the difficult chunk of doing the art (the middle to end of it which will be the most work) overlapping the testing, overlapping finding Music/SFX…too much work at once for me!

The interesting part is that I still end up releasing a game a month.  I still have a programmer hired for 3 weeks a month so if in theory when the programmer is done I can release the game, then down the road my release frequency is the same as before, and I’m still hiring a programmer for the same amount of time/money (if anything I’ll end up hiring them for less time/money because they won’t have to wait on any art assets or anything, it’ll be a quick piecing together of the elements I hand them instead of them having to make or request temporary art and such).  By staggering the games, I’ve changed nothing except eased up my workload into something less stressful.

I still love working in sync with an in-house programmer, I think it encourages cool creative ideas to be bouncing back and forth with someone else on a project as you go.  But is trying to force that workflow a smart business decision when you’re a solo guy with a limited amount of money to risk, making tiny simple games?  Down the road I’ll switch to that model, I’m sure (I plan to write up a post about my plans for studio expansion), but for now I’m interested to see if this works out and I feel like it makes logical sense.

- Quickdraw

This is going to be a fun week!  I’m almost at the point where I get to start drawing/re-drawing new art.  Because I started with a game that I already had some art done for, and I had to find a good workflow for converting it all to various screen-sizes I haven’t been able to do the FUN stuff like making new art…which will also be the more interesting stuff to anyone reading this blog regularly haha  But the video below signifies my passing into the next stage of making actual progress:

Sure, this LOOKS like it’s just the same video from a few updates back.  But no!  It’s actually much awesomer because the guy on the left is for the iPad and the guy on the right was generated from the iPad guy’s art/animations and everything the guy on the right does should be in exact proportion for his size to the guy on the left.  The timing should be dead on too, so in theory all versions of my game will play exactly the same down to the frame timing.  I was REALLY worried I’d have to re-animate everything by hand for different screen sizes, so this makes me happy!

I figure I should be able to get the already made art all finished converting today, and then I get to start drawing new stuff, oboy!

- Quickdraw

Powered by WordPress | Theme: Motion by 85ideas.
©2010 Bulletproof Outlaws[ Back to top ]
Rss Feed Tweeter button Facebook button Reddit button Delicious button Digg button Stumbleupon button Youtube button