[Programmer Poya Manouchehri points out the the pitfalls that can trip up hobbyist developers' personal projects, and offers advice on avoiding them, in this #altdevblogaday-reprinted opinion piece.]
Finishing projects is difficult at the best of times. Finishing personal projects, those we do as a hobby and for fun, can seem impossible.
How many times have your started working on an exciting new game or demo, just for your motivation to drop after a few months, and the project to fizzle out (often giving its place to another fun new idea for a game)? I can personally recall a dozen or more.
I have, in this process, found certain road blocks which seem to come up time and again. Some of these you might already be familiar with, and in most cases they are common sense anyway and nothing profound.
My hope is that by putting these down in written format, first and foremost I myself can become more conscious of them and become more consistent in finishing the games I start to work on.
Please keep in mind that this is written from the perspective of a programmer. Of course, as programmers we often have notions of grandeur (especially in the beginning of a project) and like to take on everything, which leads me to the first challenge…
1st Challenge: The Art Deprivation
This one is probably the number one reason I have dropped projects. A lack of good art, mostly visual, but also audio. The problem is that after a while of programming, you start getting tired of looking at the same gray box representing your main character, or the old Quake 3 rocket launcher.
At this point one of two things can happen: 1) You find yourself searching "free tree 3D model" on your favorite search engine, or 2) You load up a 3D modeling program, or photoshop, and start having a go yourself. The problem with the first approach is, even though in the beginning it can be a good idea to just find whatever you can as place holders so you can write your code, they often don't work well in the long run.
You might find great art for some aspects, but not others. And you usually end up with inconsistencies: for example a low poly count, cartoony house model, sitting on top of a photographed grass texture… it just doesn't fit. The problem with the second approach doesn't need to be expounded on…let's just say there is a reason I stuck with programming.
Don't get me wrong though, I think every game programmer should at least try and play with game art and get a feel for how they're created. But it's easy to spend hours and hours working on something that ultimately doesn't look very good and can discourage you.
The Solution:
Collaborate, collaborate, collaborate. Yes this has many of its own challenges, but ultimately irreplaceable. Not only is working with an artist a great way to get your game looking as it should, it can create an awesome motivation loop.
You are motivated to code more game features, as you see great and consistent art come in, and the artist is motivated to create better / more works as they see their creation come alive in the game.
Ideally you want to work with an artist that you know in person, but there are also tons of people out there on places like gamedev.net who are willing to help you in your quest. If you're using a game engine, the forums for it are always a good place to look.
Some years ago, I worked on an RPG game demo using the Genesis3D (which most of the community at the time was using for FPS games). It really only became possible because of contributions from an artist which I connected with on the Genesis3D forum.
Tomb of the Necromancer
2nd Challenge: The Grand Plan
This obstacle arises on two levels. The first level is the design of the game itself. It's so tempting to want to make the next half life with dynamic global illumination, 12 weapons, and ragdoll physics. I'm not going to talk much about this one because it really comes down to being honest with yourself and your resources.
The second level has to do with the design and structure of the code. This one really has taken me some years to appreciate and understand, not only on my personal projects, but also professionally.
See, more often than not as developers we like to have a beautifully structured system, with all components and subcomponents laid out, communication between parts of the code streamlined. We like to build pluggable systems with lots of interfaces. We like to sprinkle design patterns and well known data structures wherever we can.
I used to find this one of the more fun aspects of the beginning phases of development. But then we start coding. And we start to realize that at every step of the way we are running into issues that we hadn't thought of, or incorrect assumptions we had made.
We find ourselves having to either put in hacks here and there to go around our initial design, or having to make significant changes to that design. In a way not only are we trying to solve the problem, but we are fighting against a monster (the design) which we created in the first place.
The Solution:
I guess if had to summarize "agile development" (as overloaded as that term is) in a sentence it would be: Write enough code to do the job, no more, no less. Every line of code should correspond to an actual feature. The idea is to have a design that is constantly changing and improving to accommodate new features.
I have myself debated against this with people, and even though I still think there are situations where you need to step back a little and do more design up front, for the most part I have seen how practical the approach is. It's conducive to…well…agile development, keeps your code much simpler and easier to read, and ultimately keeps your motivation high because you are writing more functional code.
Unnecessary?
3rd Challenge: The Tunnel Vision
Have you ever banged your head against a problem way longer than you should have? There is a voice inside you that's saying: this isn't worth it, it's good enough, let's move on. But there is a stronger voice that says: I can't let this problem defeat me, I have to keep going.
This is the classic tunnel vision. Getting pre-occupied with a specific problem or feature to the point that you lose track of the big picture and the significance of that one feature in context of the whole game.
The Solution:
Give yourself a time limit. If I say I'm going to work on this fur shader for 3 evenings, I better bet sure on that third evening I'm wrapping up and cleaning things up so that I have something functional, if limited, by the end.
Remember you can always come back and improve a feature, but as far as overall motivation goes, it's better to keep the whole project moving forward.
4th Challenge: The Wheel
This is another built-in challenge for many programmers which we must constantly fight against. It's this idea of purism, and wanting to do everything from scratch. Writing your own rendering engine, writing your own physics system…you almost feel like cheating every time you use someone else's code (actually I have a very similar feeling whenever I use a pre-recorded loop in a piece of music).
Of course every time you do choose to re-invent the wheel, you are committing a whole lot of time in development and testing which does not directly move your specific game forward.
The Solution:
Don't get me wrong. I absolutely think every game programmer would benefit from writing some of these systems. I learnt an incredible amount from writing my first BSP tree, first CLOD terrain, first particle system, … I think the solution here is to decide what your goal is.
If your goal is to learn a new technique or understand it better, you should absolutely write it. But if your goal is to make a complete game, you should be writing exactly that: your game. Not the engine, not the audio system, but your game. So you should use as many resources as possible to make that easier.
5th Challenge: The Overprotective Parent Syndrome
The game you're working on, especially if it's something you've been doing solo, is like your child. You attend to it lovingly, often at ridiculous hours of the night, you grow and nurture it, you enjoy playing with it even if it's not really fun, and sometimes you get angry with it and you call a time-out for a while.
As such, sometimes you become overprotective of the project, not wanting anyone to see it until it's perfect and reflective of what you had originally envisaged. There is always a bug to fix, a character to add, and an art piece to replace. You end up telling people about what the game is going to be, rather than showing them what it is.
The Solution:
One of the greatest motivators is human feedback. Dare I say both positive and negative. Showing your game to friends and even letting them play with it will give you a sense of progress which no amount of code check-ins will do. And even though you are probably not going to implement every piece of feedback you get, this is still a great way to keep objective.
Anyone who's ever worked on a piece of art (which a game in many ways is) knows that after a while of staring at or listening to something over and over again, you start losing objectivity about how it is really perceived. A fresh pair of eyes or ears are always helpful.
One of my earlier games was a written on a CASIO graphics calculator which we had to use in high school. The game involved maneuvering a dot through an ever narrowing path of obstacles. I remember how sharing an early version of it with a few friends and watching them play it under their desks during class, really motivated me to improve it and share it with others!
Ahhh, those were the days…
6th Challenge: The Surfing Fail
This one is really subjective and vague but I'm going to throw it out there. With all of my projects I have sensed that motivation and progress seem to come in waves. You start off with a good pace and make good progress for a while but it seems to slow down and potentially come to a stand still.
But if you put in the effort and just get those blocking problems ironed out, you usually go into another phase of good progress and motivation. The key is to accept you are going to hit these tough spots and just keep moving, be it at a slow pace.
[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
For problem 2 I find dynamic programming languages provide a significant amount of adaptability to your code, and in fluid design situations this is big win in my opinion.
Also language environments that provide reasonably rich interactive programming such as Lisp or Python can also ease 'agile' development, nothing really beats being able a call a function in isolation quickly.
Related to #3, the suggested solution to #2, and a general feeling of satisfaction in overall productivity, I highly recommend time-boxing [ http://en.wikipedia.org/wiki/Timeboxing ]. It's as simple as a timer sitting next to you as you work, set to go off at regular intervals, like 15 minutes. (also called the Pomodoro Technique) Just reset the timer, no matter what; whether you've finished something, or you decide to continue on it, or you've decided on a break.
I think you'll will find that to be the case with most technical people. There seems to be a severe unbalance in this department. You'll find an overwhelming number of coders who can't find reliable artists.
I'm not trying to ding artists, but they tend to be more about the moment and generally get bored easily and are often jaded from previous failed projects. That means they won't even reply to your requests unless it's pure freelance; rigid build-to-cost work with no future investment.
Coders tend to be a little more excitable over a project despite the 299 previous failures and are more interested in the new challenge that comes with the next attempt. There is always something new that you learn from each of those failures and so you push on. Artists just don't see it that way. If they did, we'd have a lot more high quality visuals in indie games out there.
As it stands, my experience with artists has always been that they would rather do nothing than work on something that may fail; even if it means adding assets to their portfolio. It's just a different frame of mind.
I think you'll will find that to be the case with most arts people. There seems to be a severe unbalance in this department. You'll find an overwhelming number of artists who can't find reliable coders.
I'm not trying to ding coders, but they tend to be more about the moment and generally get bored easily and are often jaded from previous failed projects. That means they won't even reply to your requests unless it's pure freelance; rigid build-to-cost work with no future investment.
Artists tend to be a little more excitable over a project despite the 299 previous failures and are more interested in the new challenge that comes with the next attempt. There is always something new that you learn from each of those failures and so you push on. Coders just don't see it that way. If they did, we'd have a lot more mechanical depth in indie games out there.
As it stands, my experience with coders has always been that they would rather do nothing than work on something that may fail; even if it means adding honing their skills. It's just a different frame of mind.
Its funny you say that. I am having the hardest time finding a coder for a small project. My designer pals and I are ready to go, but we cant seem to find a coder.
I think part of the issue is that as a programmer, I often get excited about an idea and start designing and coding well before I approach an artist. This is good and bad. On the one hand I'll have something tangible which the artist can look at and basically see that I know what I am doing. On the other hand they might feel their creativity would be restricted because I've already decided what the game should look like and what's going to go in it.
Perhaps finding a collaborator needs to happen earlier on so that the artist has more ownership in the process...
@Poya I don't think there is a solution to this. Honestly if you include someone early in the project, they are likely to be very excited, throwing ideas out there and brainstorming like a mad-man. It also means that they will be involved for a longer period of time and are subjected to boredom when the high of game designing wears off. That means that you'll ultimately waist even more time, scheduling work for them, expecting them to produce and end up with a stream of excuses on why they can't do it anymore and leaving you with a game design that was meant for 2+ people. You just lost 50% of your team. So, I couldn't just sit here and tell you "this is what you can do" because the answer is as clear as mud. Damned if you do, damned if you don't...
Ben, you talk about artists like some jaded single guy talks about women. Maybe the problem is you and how you handle communicating with the artists. What you have here, from the sounds of it, is artists backing away from the project not because they are bored but because they can't handle working with you anymore.
One thing that coders tend to forget, and I know because I'm married to one and I do the artwork for him, is the importance of interpersonal relationships. Coders tend to forget that people have feelings, that they are not a piece of code where you input x and end up with y result. Also, it really helps to find an artist who either works in the industry or who has had at least some college level coursework. This will give you someone who is better prepared to handle harsh and unrelenting criticism, which is something I'm going to guess you give a lot of without bothering to temper it with any positives.
In the words of one rather wise comedian, "If you've been married nine times, hell, maybe it's you."
"finding a collaborator needs to happen earlier on so that the artist has more ownership in the process"
This is true for all and any kind of collaborator, be it musicians, coders or artists. If there is no money going to be involved, you can kickstart a collaboration with a brainstorming session based around the game concept you have. You'll be surprised how better your "succesful collaboration" ratio will get.
@Brandy Haha, no it's not that. You misunderstood. You don't know me so I'm sure you wouldn't know that I treat anyone I work with with the up most respect. Do unto others, etc. I have feelings to Brandy.
I was framing my original comment in the context of one programmer to another. I never mentioned artist/programmer in my second comment. Honestly, it's doesn't really matter on what side of the fence you are on, it's all getting cats and dogs to play nice with each other. It's not impossible but it requires some luck.
I didn't mean to imply "damn those artists" because the opposite is easily the case albeit for slightly different reasons. You are likely to find hard working people on both sides, but it's important that you manage your own expectations because most people would rather just do nothing than risk anything. It's a special kind of person who wants to put it out there and use their short life to better themselves and entertain others at the same time.
Finding those special people is like finding a wife/husband and well... Divorce is mighty common in this line of work. Of all the problems facing indie developers, this is the one problem that hard work will not solve.
Excellent! Though the article itself is very much focused on solo game development, the suggestions offered here can be applied to almost any type of project or work. In my particular case, I found the points on avoiding "Overprotective Parent Syndrome" to be quite helpful, due to how frequently I find myself doing exactly that.
Also language environments that provide reasonably rich interactive programming such as Lisp or Python can also ease 'agile' development, nothing really beats being able a call a function in isolation quickly.
That's because every round of waiting for an artist, I've added more and more features and functionality into the game world.
And even find collaborators is hard regarding graphic art.
(it is not hard regarding music, I have tunes from several people, including music wizards like Alexander Brandon...)
I'm not trying to ding artists, but they tend to be more about the moment and generally get bored easily and are often jaded from previous failed projects. That means they won't even reply to your requests unless it's pure freelance; rigid build-to-cost work with no future investment.
Coders tend to be a little more excitable over a project despite the 299 previous failures and are more interested in the new challenge that comes with the next attempt. There is always something new that you learn from each of those failures and so you push on. Artists just don't see it that way. If they did, we'd have a lot more high quality visuals in indie games out there.
As it stands, my experience with artists has always been that they would rather do nothing than work on something that may fail; even if it means adding assets to their portfolio. It's just a different frame of mind.
I'm not trying to ding coders, but they tend to be more about the moment and generally get bored easily and are often jaded from previous failed projects. That means they won't even reply to your requests unless it's pure freelance; rigid build-to-cost work with no future investment.
Artists tend to be a little more excitable over a project despite the 299 previous failures and are more interested in the new challenge that comes with the next attempt. There is always something new that you learn from each of those failures and so you push on. Coders just don't see it that way. If they did, we'd have a lot more mechanical depth in indie games out there.
As it stands, my experience with coders has always been that they would rather do nothing than work on something that may fail; even if it means adding honing their skills. It's just a different frame of mind.
Perhaps finding a collaborator needs to happen earlier on so that the artist has more ownership in the process...
Poya Manouchehri
http://gamesforsoul.com/
@Poya I don't think there is a solution to this. Honestly if you include someone early in the project, they are likely to be very excited, throwing ideas out there and brainstorming like a mad-man. It also means that they will be involved for a longer period of time and are subjected to boredom when the high of game designing wears off. That means that you'll ultimately waist even more time, scheduling work for them, expecting them to produce and end up with a stream of excuses on why they can't do it anymore and leaving you with a game design that was meant for 2+ people. You just lost 50% of your team. So, I couldn't just sit here and tell you "this is what you can do" because the answer is as clear as mud. Damned if you do, damned if you don't...
One thing that coders tend to forget, and I know because I'm married to one and I do the artwork for him, is the importance of interpersonal relationships. Coders tend to forget that people have feelings, that they are not a piece of code where you input x and end up with y result. Also, it really helps to find an artist who either works in the industry or who has had at least some college level coursework. This will give you someone who is better prepared to handle harsh and unrelenting criticism, which is something I'm going to guess you give a lot of without bothering to temper it with any positives.
In the words of one rather wise comedian, "If you've been married nine times, hell, maybe it's you."
"finding a collaborator needs to happen earlier on so that the artist has more ownership in the process"
This is true for all and any kind of collaborator, be it musicians, coders or artists. If there is no money going to be involved, you can kickstart a collaboration with a brainstorming session based around the game concept you have. You'll be surprised how better your "succesful collaboration" ratio will get.
This:
http://www.escapistmagazine.com/videos/view/extra-credits/2443-So-You -Want-to-be
-a-Game-Designer
Everyone has ideas, and the designer is not a dictator (I resent their use of the word director tho, as in film, the director ain't a dictator).
@Benjamin, Meant no disrespect by the way, but it's good to look into the mirror.
I was framing my original comment in the context of one programmer to another. I never mentioned artist/programmer in my second comment. Honestly, it's doesn't really matter on what side of the fence you are on, it's all getting cats and dogs to play nice with each other. It's not impossible but it requires some luck.
I didn't mean to imply "damn those artists" because the opposite is easily the case albeit for slightly different reasons. You are likely to find hard working people on both sides, but it's important that you manage your own expectations because most people would rather just do nothing than risk anything. It's a special kind of person who wants to put it out there and use their short life to better themselves and entertain others at the same time.
Finding those special people is like finding a wife/husband and well... Divorce is mighty common in this line of work. Of all the problems facing indie developers, this is the one problem that hard work will not solve.