The hardest damn part
20/08/09 12:42 Filed in: My Game News | Game Design Tips
If you knew me for awhile you would find that I’m a tinkerer. If something is broken, I’ll fiddle with it till it’s fixed. Or until I break it to the point where I need to buy new parts. But if I can fix the problem with duct tape and an old cereal box, you know I will. I like to think I’m pretty good at tinkering. And I think that’s mainly because I am pretty good at improvising. Seeing solutions to problems using what I have around me. However, what I’m certainly not good at is the conveying of my solutions into written form. If you asked me to write down how I’m going to fix something beforehand, I would just get frustrated and angry. “It’s in my head, and I don’t need to write it down” is what I would say.
The same applies to game design. The first step being: “come up with an idea”. I love this step. I’ve come up with hundreds of games in my head. I figure out mechanics, levels, characters, backstory, and most everything needed in your standard game nowadays. I will lie awake in bed till the early morning hours figuring out everything to do with a game and when my wife wakes up, tell her all about it. This step is the most important one. But close behind it is the actual process of writing it down.
This is the grumpy making part. My struggling to convey ideas into the written word is an exercise in futility. Often times I’ll lose interest halfway through and just abandon the project right out. Normally this is due to my biggest problem. I tend to think up games that are too large in scope for my feeble programming/3D animation/modelling skillz. And it’s the writing it down process that makes me realise just how massive a project I’m undertaking.
That’s why I normally don’t write things down. At least not in great detail. I can make a prototype fine enough without writing something down. I’ve made maybe a good half-dozen of them or so in the past. Some of them even being kinda fun. That’s because of my love for tinkering. I’ll fiddle with scripts, models, and physics until everything functions the way I want it to. But I’ve never actually published any of these games that I’ve made. Mostly because the code was a poorly executed jumbled mess and broke rather easily. So how do I ensure against poor coding moving forward? Sigh...I have to write it out in great detail. So here goes.
I’m working on an archery/artillery title for the iPhone. And I’m going to sell it for $0.99 on the apple store. I’ve committed myself to doing this. It will happen. But I have got to write it down first.
So how am I going to do this? I’m starting really simple. Pen and paper. I’m finding the best way to get through this process is to think through myself playing the game. Listing the order in which things happen in the game. Once I finish this step, on to the more detailed look at each event. I break it down into it’s base components. I think about an event and figure out what needs to be done programming-wise. I figure out what graphic assets are needed for this to function. And I figure out what I may be limited in doing due to engine/platform constraints.
It’s quite a chore honestly. Something as simple as an arrow firing from a bow, and arching towards a target has a whole bunch of little components. Graphically it’s got to have a 3D model for the arrow. A texture to map to the object. The object has to animated being loaded onto an archer’s bow at the beginning of it’s life. It has to attach itself to a collider launched out of the bow, piggybacking itself onto this collider gameobject all the way to it’s target. All the while being affected by gravity. Fucking Newton. Life would be easier without stupid gravity. Then the gameobject needs to orient itself appropriately based on how far along it is on it’s arching trajectory. When that object hits it’s target, the arrow needs to detach from it and attach itself to whatever it hit. So if it hits another archer’s arm it will embed itself into that arm, and move around with that archer in a realistic manner.
And there’s an awful lot more to it than that as well. I skipped over so much. And I don’t know if it will actually work out this way in the end. Still, I need to write it all down. Because if I can break everything down into it’s components I can compartmentalise everything in a way that if something doesn’t work, the problem is only limited to that one aspect of the game. And I can then get to the tinkering with it until it does work...I hope.
We’ll see how much longer it takes to write this sucker out. I’m about half-way through this process. Hopefully I will be able to get back to it on the weekend and finish it off. After I finish that step, I’ll move onto the next. Which is...well...writing it down. To be more precise, I’m going to be moving all my pen & paper work into a wiki. Something that can be easily searched through, edited, and updated throughout the rest of the project. But I’ll talk about that step when I actually get to it.
The same applies to game design. The first step being: “come up with an idea”. I love this step. I’ve come up with hundreds of games in my head. I figure out mechanics, levels, characters, backstory, and most everything needed in your standard game nowadays. I will lie awake in bed till the early morning hours figuring out everything to do with a game and when my wife wakes up, tell her all about it. This step is the most important one. But close behind it is the actual process of writing it down.
This is the grumpy making part. My struggling to convey ideas into the written word is an exercise in futility. Often times I’ll lose interest halfway through and just abandon the project right out. Normally this is due to my biggest problem. I tend to think up games that are too large in scope for my feeble programming/3D animation/modelling skillz. And it’s the writing it down process that makes me realise just how massive a project I’m undertaking.
That’s why I normally don’t write things down. At least not in great detail. I can make a prototype fine enough without writing something down. I’ve made maybe a good half-dozen of them or so in the past. Some of them even being kinda fun. That’s because of my love for tinkering. I’ll fiddle with scripts, models, and physics until everything functions the way I want it to. But I’ve never actually published any of these games that I’ve made. Mostly because the code was a poorly executed jumbled mess and broke rather easily. So how do I ensure against poor coding moving forward? Sigh...I have to write it out in great detail. So here goes.
I’m working on an archery/artillery title for the iPhone. And I’m going to sell it for $0.99 on the apple store. I’ve committed myself to doing this. It will happen. But I have got to write it down first.
So how am I going to do this? I’m starting really simple. Pen and paper. I’m finding the best way to get through this process is to think through myself playing the game. Listing the order in which things happen in the game. Once I finish this step, on to the more detailed look at each event. I break it down into it’s base components. I think about an event and figure out what needs to be done programming-wise. I figure out what graphic assets are needed for this to function. And I figure out what I may be limited in doing due to engine/platform constraints.
It’s quite a chore honestly. Something as simple as an arrow firing from a bow, and arching towards a target has a whole bunch of little components. Graphically it’s got to have a 3D model for the arrow. A texture to map to the object. The object has to animated being loaded onto an archer’s bow at the beginning of it’s life. It has to attach itself to a collider launched out of the bow, piggybacking itself onto this collider gameobject all the way to it’s target. All the while being affected by gravity. Fucking Newton. Life would be easier without stupid gravity. Then the gameobject needs to orient itself appropriately based on how far along it is on it’s arching trajectory. When that object hits it’s target, the arrow needs to detach from it and attach itself to whatever it hit. So if it hits another archer’s arm it will embed itself into that arm, and move around with that archer in a realistic manner.
And there’s an awful lot more to it than that as well. I skipped over so much. And I don’t know if it will actually work out this way in the end. Still, I need to write it all down. Because if I can break everything down into it’s components I can compartmentalise everything in a way that if something doesn’t work, the problem is only limited to that one aspect of the game. And I can then get to the tinkering with it until it does work...I hope.
We’ll see how much longer it takes to write this sucker out. I’m about half-way through this process. Hopefully I will be able to get back to it on the weekend and finish it off. After I finish that step, I’ll move onto the next. Which is...well...writing it down. To be more precise, I’m going to be moving all my pen & paper work into a wiki. Something that can be easily searched through, edited, and updated throughout the rest of the project. But I’ll talk about that step when I actually get to it.