I've always had a drive to take apart anything electronic and figure out how it worked. Even better if the thing had a microprocessor since then I would try to start up a conversation with it. I think my first experience with this was hooking up an old teletype machine given to me by my junior high school to a VIC-20 computer to use a printer. Then came the first XBox. I enjoyed playing games on it, but I wasn't really a gamer. Then I found out about modding the darn thing...I think the main reason for this was to be able to make *back-ups* of your games. I really didn't so much care about that, I wanted to find a version of the XBox SDK and get my own Hello World programming running.
That brings us to current day, Microsoft did something really cool and made game development main-stream for the XBox 360 in the form of the XNA Game Studio. Last summer I downloaded Version 2.0 of the SDK and started my journey on learning this new technology. Other than playing around with the Hydra Game Development Kit, I knew next to nothing about game programming, this was a chance to learn a brand new technology.
I'm still in the process of learning but I thought it was interesting on how I'm building my first game. Most of the time when I write an application, I really want to have an in depth knowledge of what's happening with the code. I don't like calling methods, even if they are in a library or frameworks unless I at least have a general knowledge of how that software will be ran by the processor. In January I started a project that I will be publishing in March as a Community Game on the XBox 360. To make this work, I needed to do a bunch of stuff I really had no clue how to program. These were things like explosions, smoke from a missle trail etc... I found some great tutorials and started cutting and pasting my way to an application that pretty much did what I needed to, although the program was a mess. I did feel dirty doing this, but just reading about code isn't enough, implementing it into something that actually runs is a much better way to learn things.
So I figured out how to create 3D models with the XSI Mod Tool, that was no small chore, but kind of fun and something I did on the couch while watching TV. Next I found some code to render the model in my game, I cut-and-pasted that into my application and be-hold the model was spinning in 3D, although I didn't know how it worked it was rewarding. Then I added a few more models and decided that the code just didn't "smell right" anymore. It was a good time to create a class that knew how to render models in my game, this was important since my game had some specific needs and I couldn't just cut-and-paste anymore I needed to know how the code worked. This is when the lights started coming on. Next was implementing the flight of a missile. I found some algorithms for acceleration and gravity as well as a smoke plume and cut-and-pasted the code. This got me about 75% of the way there and was a mess, but at least it sort-of worked and was rewarding. I refactored the code, learned how it worked and the light bulbs came on again. I repeated this process for other things such as rendering water and implementing a generic controller that works with either a keyboard or game controller. So the basic pattern here was add the features, you may need a dependency that you don't know how to implement, that's OK, instead of just banging your head against the wall for 3 days, find some code the sort-of does what you want, get it working. Then the real critical part, refactor the hell out of it and make that code your own!
This was a project I wrote for myself, most of the time people pay me to write software so I can't recommend this process for any client work. However now if a client contracted with me build an XNA game (fat chance, but you never know), I can point to some real world experience and feel good that I'll be delivering a solution and not learning on the job.
I think to a certain extent, this is probably how we learn to implement technologies most of the time, but in smaller steps. This was just very obvious since I had to start from scratch with many core concepts and the process of turning the cut-and-paste code into my own code was very clear and effective. So don't feel bad about cutting and pasting code, just make sure you don't leave it like that once you get it working. Apply your style, refactor, rinse and repeat and make the code your own!
-ec
That brings us to current day, Microsoft did something really cool and made game development main-stream for the XBox 360 in the form of the XNA Game Studio. Last summer I downloaded Version 2.0 of the SDK and started my journey on learning this new technology. Other than playing around with the Hydra Game Development Kit, I knew next to nothing about game programming, this was a chance to learn a brand new technology.
I'm still in the process of learning but I thought it was interesting on how I'm building my first game. Most of the time when I write an application, I really want to have an in depth knowledge of what's happening with the code. I don't like calling methods, even if they are in a library or frameworks unless I at least have a general knowledge of how that software will be ran by the processor. In January I started a project that I will be publishing in March as a Community Game on the XBox 360. To make this work, I needed to do a bunch of stuff I really had no clue how to program. These were things like explosions, smoke from a missle trail etc... I found some great tutorials and started cutting and pasting my way to an application that pretty much did what I needed to, although the program was a mess. I did feel dirty doing this, but just reading about code isn't enough, implementing it into something that actually runs is a much better way to learn things.
So I figured out how to create 3D models with the XSI Mod Tool, that was no small chore, but kind of fun and something I did on the couch while watching TV. Next I found some code to render the model in my game, I cut-and-pasted that into my application and be-hold the model was spinning in 3D, although I didn't know how it worked it was rewarding. Then I added a few more models and decided that the code just didn't "smell right" anymore. It was a good time to create a class that knew how to render models in my game, this was important since my game had some specific needs and I couldn't just cut-and-paste anymore I needed to know how the code worked. This is when the lights started coming on. Next was implementing the flight of a missile. I found some algorithms for acceleration and gravity as well as a smoke plume and cut-and-pasted the code. This got me about 75% of the way there and was a mess, but at least it sort-of worked and was rewarding. I refactored the code, learned how it worked and the light bulbs came on again. I repeated this process for other things such as rendering water and implementing a generic controller that works with either a keyboard or game controller. So the basic pattern here was add the features, you may need a dependency that you don't know how to implement, that's OK, instead of just banging your head against the wall for 3 days, find some code the sort-of does what you want, get it working. Then the real critical part, refactor the hell out of it and make that code your own!
This was a project I wrote for myself, most of the time people pay me to write software so I can't recommend this process for any client work. However now if a client contracted with me build an XNA game (fat chance, but you never know), I can point to some real world experience and feel good that I'll be delivering a solution and not learning on the job.
I think to a certain extent, this is probably how we learn to implement technologies most of the time, but in smaller steps. This was just very obvious since I had to start from scratch with many core concepts and the process of turning the cut-and-paste code into my own code was very clear and effective. So don't feel bad about cutting and pasting code, just make sure you don't leave it like that once you get it working. Apply your style, refactor, rinse and repeat and make the code your own!
-ec
No comments:
Post a Comment