This entry for the fresh faces in the GDNet forums that have at one time or another asked what languages, libraries or applications to use to get started with game development. This is also for the ones who HAVE started developing games, without any concern over the implications of their decisions.
Confidence is vital to a developer. We know that a solo operation can be left dead in the water thanks to a lack of motivation, and sometimes the brains behind the project might feel inclined to reach out and ask others how to keep thing moving. On the other hand, self-proclaimed programming gods are fully prepared to write an engine and teach the industry how to REALLY make games before discovering that hard work is involved.
I won't take a Randian approach and try to objectively cram everyone into two groups, although I do think that a developer's motivation (or lack thereof) leads to recurring problems caused by two kinds of attitudes. These attitudes are addressed by GDNet on an almost daily basis, and I don't doubt that other members have tried to blog about them elsewhere. Still, as someone who has been both timid and arrogant at many times in his life (and likely still will be), I want to try and help reduce the influence that the motivational extremes of humility and arrogance has on our future developers.
Hopefully I can finish this post before my new kitten paws my fingers off as I type!
[size="5"]"I don't know what to do, so think for me!"
One of the more intimidating parts of a project is determining what you need to do it. This is especially true for unmotivated beginners; Deciding to make a game for the first time without knowing about programming languages, compilers and engines is like deciding to make a house without knowing about hammers, nails and lumber. Novices need to learn the tools of the trade, but the abstract nature of programming makes it difficult for a game development veteran to decide the best route for an aspiring developer to take.
I wanted to stress to our to-be programmers and designers that if you are starting alone, all of the burden for making decisions falls on you. It sucks to be asked to make a choice when you don't even know how to make it, but even more experienced developers are sometimes put on the spot to decide what they need to do about a new problem they have not seen before. Not too long ago, I was asked to choose a new eCommerce platform to support a retailer's family of websites. I was still a freshman and had no experience with enterprise-level eCommerce at all at that point, so the only thing to do outside of getting fired was to do my homework.
The big snag that is almost universally felt, yet often not addressed, is a lack of motivation. If it helps, know that if you have decided you honestly, truly (pinky-swear) want to make a game, you have already started. And, like in all software projects, knowing what not to do about something is a natural (and hopefully temporary!) way to react to a problem waiting to be solved. Keep going!
As implied earlier, a great deal of people (including myself) have at some time asked the hivemind about what they should use to make a game, and concrete suggestions have been offered. I could link to one of these threads, but I won't for one reason: YOU need to look for this information. Being ignorant is ok, as is making a bad judgement when you get around to making one. That's part of learning, and everyone has to endure "being human". Motivation is understanding that you know nothing, but moving toward your goals in spite of that. You will learn as you go, and problems like the one's you eventually overcome become easier with experience.
So, before you ask GDNet or another community how to approach X, how to design Y or if Z is something you want to use, understand that someone else making a decision for you does nothing to help you become a good judge of what is relevant to your needs. On the other hand, asking if you MADE a good decision shows that you have discovered what your options are and evaluated them to the best of your ability. Ask others to help you learn as opposed to asking them to decide things for you.
If someone gives you good advice, make a habit of asking them why they came to the conclusion they did. Determining relevance and knowing how to make good judgments are powerful skills, and you can only hone them by doing. Start with what you know by opening Google and searching for something relevant to your current knowledge. No matter how in-the-dark you may feel, there is always a little thread of experience that will help lead you to new information that matters.
It's up to you.
[size="5"]"I'm writing an app that perfectly models atoms!"
[size="2"]Sometimes people don't know what they are talking about, and we appreciate it if they recognize that. However, not everyone sees their own limitations. I was really bad about wanting to complete projects that were out of my league, and had wanted so badly to make a game engine before I made a game, when all I really wanted to do was make a game. Sometimes people are so sure they have the ability to handle projects bigger than themselves, they completely forget that they have to do any work at all. A common problem that many GDNet veterans recognize is a sudden desire to make an MMO game, and one of our moderators wrote an excellent post about this newfound enthusiasm in aspiring game developers.
The problem is not wanting to do big projects as much as it is allowing the ego to run amok. This often leads to a harsh realization that one is in over his head. Sometimes the only cure for narcissism is an event that demonstrates the consequences of presuming on one's experience, and these consequences can be brutal. Chronic information overloads and often inevitable failures can convince someone to have a nervous breakdown and quit game development altogether! This can be embarrassing, especially after boasting to friends about your awesome new project.
[size="2"]Being too humble can lead to fearing your own experience and depending on others, while being arrogant leads to fearing the experience of others while depending on your own experience. Both paths can lead to disastrous results if you look at yourself in only a positive or negative light. Growing to be both a good developer and a good person is a complex journey that cannot be defined objectively, but it does[size="2"] involve recognizing your strengths and limitations. Context is central to the decisions you need to make, and although you might have experience to be proud of, your decisions should be based on what you know, not who you are.
[color="#111111"][font="Georgia,"][color="#111111"][font="Georgia,"]I remember being so excited about learning new things that I would often share my growing vocabulary with others. Of course, rattling off GPU model numbers and introducing my peers to my work with terms I made up made me feel smart, but it did limit my audience. I'm not just talking about an audience of middle-aged parents or users who ride the short bus, I'm including other geeks who actually knew what I was talking about.[/font][/color][/font][/color][color="#111111"][font="Georgia,"][color="#111111"][font="Georgia,"] [/font][/color][/font][/color] [font="Georgia,"][color="#111111"][size="2"]Human language is great for not just sharing ideas, but also putting them in perspective. Even some of the most brutal mindf*s like quantum phenomenon can be clearly explained in accessible ways by people like Dr. Michio Kaku or Dr. Richard Feynman. The interesting thing about these men is that they do not really describe systems and relationships separately based on their knowledge alone, they mix together their knowledge AND the knowledge of their audience to create a mutually beneficial message: The audience gets it, while the speaker enjoys a boost to their reputation (assuming they were accurate!).[/color][/font] [font="Georgia,"] [/font] [font="Georgia,"][color="#111111"][size="2"]I know that the point of speaking simply has been discussed since Einstein weighed in on it, but I really want to express my appreciation to people who don't use jargon, even when I understand it anyway.[/color][/font][color="#111111"][font="Georgia,"] [/font][/color] [color="#111111"][font="Georgia,"]I tried this "walking encyclopedia" shtick: A few years ago when I tried too hard to "sound smart" to a fellow developer I met in Starbucks. I remember referring to acronyms and taking care to spell each one out. I may as well have stood up, puffed out my chest and screamed "BOW TO MY SUPERIOR, HYPER-COMPRESSED VOCABULARY!" I later realized just how inhuman I sounded.[/font][/color] [color="#111111"][font="Georgia,"] [/font][/color][color="#111111"][font="Georgia,"]Since then, I get a little impatient when someone uses jargon because I genuinely want to hear what they have to say! Why am I being led down some linguistic detour that takes more work to listen to?[/font][/color] [color="#111111"][font="Georgia,"] [/font][/color][color="#111111"][font="Georgia,"]To illustrate how far this could go, I recently stumbled upon an interesting library, and the page describing it included this text (translated from French).[/font][/color][color="#111111"][font="Georgia,"] [/font][/color][font="Georgia,"] [/font] [font="Georgia,"][size="2"][color="#111111"][quote]A pipeline [/color][/font]P[color="#111111"][font="Georgia,"] is a chain of functions [/font][/color]F1[color="#111111"][font="Georgia,"] , ..., [/font][/color]Fn[color="#111111"][font="Georgia,"] such that P (x) = (Fn ? ... . F1) (x). Therefore, if the function F [/font][/color]i[color="#111111"][font="Georgia,"] defined by F [/font][/color]i[color="#111111"][font="Georgia,"] : E [/font][/color]i[color="#111111"][font="Georgia,"] ? S [/font][/color]i [sup][ 1 ][/sup][color="#111111"][font="Georgia,"] , then E [/font][/color]i +1[color="#111111"][font="Georgia,"] = S [/font][/color]i[color="#111111"][font="Georgia,"] and S [/font][/color]i-1[color="#111111"][font="Georgia,"] = E [/font][/color]i[color="#111111"][font="Georgia,"] . In other words, the output of F [/font][/color]i[color="#111111"][font="Georgia,"] is the entry of F [/font][/color]i +1[color="#111111"][font="Georgia,"] [/quote][/font][/color] [font="Georgia,"] [/font] [font="Georgia,"][size="2"][color="#111111"]This gets the point across, but it just does not seem necessary. Why assume that the audience is familiar with composite functions and basic set theory? If you are not in a formal setting that expects you to get technical, why is the below so dirty?[/color][/font] [font="Georgia,"] [/font] [font="Georgia,"][size="2"][color="#111111"][quote]A pipeline is a series of functions that are processed in a fixed order, where the output of each function is passed on to the next one down the line. The output of the entire pipeline is the output of the last function.[/quote][/color][/font][color="#111111"][font="Georgia,"] [/font][/color] [font="Georgia,"][size="2"][color="#111111"]When you write documentation, or are just plain trying to explain things to someone, how do you frame what you say or write? Is it better to communicate with people on your own level, or to make everything you say understandable to a ten year old?[/color][/font]
I had a discussion with a fellow Hacker News dweller named Loup on the Fallacy of Gray and how it applies to programming. After looking at his assertive, yet intriguing blog, I was motivated to continue the discussion.
Since gray is often visualized in the spirit of avoiding extremes, being a "gray developer" might conjure up images of flexibility. However, Loup reminded me that even "Grays" can be dogmatic about the chaotic nature of programming.
The problem Loup mentioned can be illustrated if Alice says to use tool A and provides the appropriate evidence to suggest it is better for the job, but Bob refuses because most languages are general purpose enough to suit their needs, and he is more accustomed to B. Bob's central argument is: "What does it matter?" The attitude effectively says "everything ultimately does not matter, but don't question me".
Although it is silly to get caught up in the countless zealous A vs. B wars around the net because we know that each tool has its pros and cons, it is equally silly to look at the chaotic nature of it all and refuse to defend tools that are obviously better for a job than others. Loup continued by pointing out there exists an underlying double standard in some corporate environments when considering a new, better tool (that could carry risk) along with an old, inferior tool that the staff is familiar with:
Assume that you had a job that could be taken care of with only one language. If you found that Lisp was better than C++ for a job, when Lisp is largely unknown in the company and you are the one who suggested it, the chances of you getting fired for a project failure is far greater than if you had suggested C++. But, if Lisp WAS better for the job, blame could only rightfully be assigned to people for misusing it. Still, a bias against Lisp might develop as a byproduct of the project's death! People should be disciplined appropriately for acts of stupidity, but should the discipline act against their good contributions as well? This is not to say that any tool choice is 100% objective, but context allows us to sort our options from best to worst based on our experience.
What I learned from Loup is that everything is gray, everything is chaotic and everything is uncertain in reality, but that should not stop me from feeling justified in calling someone out for taking a plane down the street instead of walking. Timidity is no excuse for not doing the best possible job, especially when you use chaos as a back door out of an argument you are losing.
When do you feel confident that in the midst of all the nuances of your field, your choice might be best?