Jeff Hangartner, the founder of the gaming start-up, Bulletproof Outlaws has been a professional developer of games over the last half a decade. Creator of Pixelation, the 1st Pixel Art Forum and also originator of the Pixel tutorials which have been published in the form of a book. Jeff has always been a pioneer of the gaming industry.
CG Today is proud to present Jeff’s exploration as he shares the whole process of creating a start-up right from day 1. With the belief that gaming development is coming back to its original “one programmer in the basement roots” idea, Bulletproof Outlaws is chronicling every step of its start-up process from strategies, to marketing, setting goals and outsourcing, successes and failures. The aim is to help other developers who have ideas but are intimidated by the whole start-up process and are not sure how to go about it.
You can visit his website Bulletproof Outlaws to know more about him or send an email to get connected.
I’m going to be working with a programmer remotely, and I expect there to be communication issues and general slow-down going back and forth. In an attempt to minimalize these complications, I’m using a very visual way of developing my game. I’m trying to keep as much as possible in pre-made animation files that I create on my end, so that all the programmer wil have to do is stitch those animations together. The end result should be that the programmer has a light workload, which saves me development costs, and the game should be easily modifyable on my end.
That means that while normally I’d have to go “Hey, can you make the throwing-star move like 10% faster? And scale larger, I don’t know, 30% more as it gets about 1/3rd through the throwing curve?” on Day1, then getting a build on Day2 where it’s not quite how I want, and I try to describe it again, annoying the programmer who’s stuck trying to guess what I’m visualizing in my head, and now having to wait for the build on Day3 where it’s hopefully fixed the way I’m trying to describe…
Instead of that gong show, I can just open throwing-star.anm, drag the keyframes around, and boom, fixed.
So the above shows the 3 animation files that go into the throwing-star:
Star_Spawn – The throwing-star coming from the bottom of the screen all the way up to the frame where it detects if it’s hitting the player or not. At this frame, the game should check the collision detection.
Star_Vanish – If the throwing-star hasn’t hit the person, it plays this animation that starts from the last frame of Star_Spawn and just shows the star fading out (I could make it zing off into the distance instead of vanish, but I won’t be able to tell if the player slides into the path after it’s playing this animation… although I realize as I type this that Star_Vanish could always be played on the layer behind the player’s sprite and that would work out perfect. Maybe I’ll tweak that)
Star_Deflect – I haven’t put the art for it up yet, but the ninja will have a panic button that makes a glowy force field for a second that deflects a throwing-star coming at him. If after Star_Spawn plays, it detects that it’s hitting the player and the player is in his Deflect animation, it’ll play Star_Deflect.
All the objects will work this way. And not just the objects, but the Title Screen and Menus, etc. Imagine you’re a programmer, wouldn’t it be nice to get a nice clean guide like this:
Most of the hard work is contained in the animation files, and the end product will look super polished because menu items will slide, fade, scale, rotate, etc. as they appear and disappear. I’m a big fan of polish and I always hate when I have to have menus that are just static images that appear/disappear. There’s no reason an indie game can’t look polished up!
Email: This e-mail address is being protected from spambots. You need JavaScript enabled to view it | Web: Bulletproof Outlaws