When conceptualizing a game, my imagination generates an ideal. When the project kicks off polish is paramount and planned detail is intricate. Then reality sets in. I think it's easy for indie devs to become intimidated by the enormous amount of work ahead of them. When that pressure sinks in, things get rushed.
Two weeks ago I made a post about animations for my game. All of the animations in that post along with their implementation took less than 8 hours total. In other words, it was very rushed. Since art is the field I'm most confident in, I spent the week working on bugs and then sped through the animations the day before posting. The result was half-baked work. So, I took a deep breath and started fresh.
Old
New
It really took very little time to drastically improve this jump animation. My whole game is about jumping, so the visual feedback for the jump is among the most important animations I'll do. Slowing down and doing it right was absolutely worth it.
Starting fresh is something I've had to do a lot with this project. I mean a lot. In fact, I've reprogrammed the entire game four times...
Before starting Dueling Dev blogs I shambled together a buggy prototype for a game where you wall jump up giant enemies. I had no idea how to program so this was mostly a Frankenstein of various programming tutorials.
Even in this broken ass state, it was pretty fun. When William and I decided to start Dueling Dev Blogs, I did a post about my early prototyping, in which I took this concept and expanded it. Now the player was deflecting projectiles.
Hey this could be fun
This prototype took the project from a vague idea to something I could happily work on for a year or more. Unfortunately, my programming skills were still hardly existent. As such, the systems in the game were clunky and nearly impossible to expand on.
This is not fun
So, I scrapped the entire project and opened up a blank file. this time I was going to make the game's systems infinitely expandable. Now, if you're a programmer, you're about to shake your head. If you're not, I'll help you understand why you should shake your head. I not only made my systems way too open ended to be stable, but I had almost no comments anywhere in the code. Comments are just text accompanying code to remind you later how things work. When you have hundreds or thousands of lines of code without comments, the project becomes helplessly confusing.
Anyway, I managed to pull this together.
I love this gif. It captures the ninja-like feelings I had envisioned from the beginning. However, my code was scrambled and hard to read. Even though my programming abilities had gotten to a reasonable place, the project was too messy for me to be productive.
This gif, however, sparked interest in my game from a few different people. Most notably, an insanely talented programmer friend of mine. He asked if I'd be interested in us producing the game together. It took me quite awhile to decide, but ultimately I felt like my current code was going to be impossible for me to move forward on.
We decided to make the game 3D in Unreal Engine. The project's scope expanded as I began work on a fully 3D world.
A month into this, the programmer I was working with got a job offer for a senior position at Blizzard. It would be ridiculous to turn a position like that down, so I happily encouraged him to take it. The project had been my baby for a long time anyway, so I was uncomfortable from the get-go involving another party and evolving the concept.
I knew I couldn't go back to the project I had built. It was a total mess. So, once again, I opened up a blank document. This time I wrote a detailed outline of the systems I needed and how they would interact with each other before starting on any code. I then filled my code with detailed comments, allowing me to read through every inch of it clearly. Most importantly, I've been testing this thing nonstop. What has come of this is a project I feel is rock solid. The bugs I encounter are easily located and fixed and I'm able to expand on the game quickly and efficiently.
I am by no means a world class programmer, but my systems accomplish everything I need them to. I am confident I will redo some things occasionally, but no more starting fresh. This is the real deal. It feels great to play and I am excited about the future.
William's Comment:
In the first chapters of Malcolm Gladwell's book Outliers, Gladwell discusses how people become masters of certain mediums or skills. The general idea that Gladwell gets at is that the major ingredient is time (10,000 hours, a little over a year). The example that stood out the most to me, however, was The Beatles (minus Starr, plus Best) who had gotten their start in a club where they were allowed to experiment musically and still make a living from spending hours a day in this way. The obvious result was John Lennon, Paul McCartney, and George Harrison becoming some of the most innovative and prolific musicians for decades to come.
I'll let you all in on a little secret: Gabe's got way more passion than I do about making games. With me, it's an almost obsessive need to develop that works as a way to let loose some of my anxiety, and when I don't develop I become more anxious than your ex's tiny, yappy dog. But Gabe? My man Gabe has got passion. Gabe makes stuff that he believes deserve to exist in well-executed form, and I know that this wall-jumping game is one of those things that he wants to see out there in the world.
Three out of four ain't bad
What's interesting to me is the processes that two people go through. Since I've spent so much of my life developing out of obligation, I've amassed thousands of tiny games of wildly varying quality to scratch an unbearable creative itch. I've learned how to program by experimenting with every stupid idea I've gotten, finding out what works, what doesn't work, and how to program a wide spectrum of ideas. I practice a little bit of space invaders here, a little bit of turn-based RPGs here, a little bit of faux-3d FPS games there, and a little bit of side-scrolling platformers there.
Gabe is doing a similar thing as a beginning programmer, but he isn't making a dozen different projects. No, no, he's doing the same project repeatedly until he's got it right, and just like how I learned how to make games in general over time, Gabe is learning how to perfectly make his game.
I think that the result will be a very finely tuned, cohesive, polished, and innovative product by the time Gabe is done with it. The question for the future, however, is whether or not repeated do-overs on one project will either help Gabe start from a more stable place to begin with when he eventually begins programming his next project, or if he'll have to start somewhere near square one all over again. Alas, time will be the only indicator of that.
And this motherfucker is going to be damn good at rollin' balls
If your interested in these posts, click below for a weekly notification when they go up!
No comments:
Post a Comment