Roaming around on the internet, have you ever seen someone say that? Or something along those lines?
They'd say "video games are dead" full stop but companies like Sony are seeing to making sure that that's not true. Indie games, however, are a little different. It's hard for small studios and indies to thrive.
Read that again.
Hard to thriveĀ does not meanĀ dead.
So what if it's hard to make it in the indie game scene? That just means the pat on the back you give yourself at the end of the day is well-deserved.
In that same vein, people constantly say that rock and roll is dead. Hip hop is dead. This is dead. That's dead. People talk all the time how everything's dead or dying and yet there's still plenty of content being created and consumed.
"Indie games are dead" is just an excuse.
Don't be one of those people who makes excuses.
If it's hard to make something work, then it's up to you to work ten times harder.
How many times have your friends said, "Whoa! You make games? That's so cool! I want to do that too! How do I start?"
But no one has the time or patience to teach someone or guide them along. So, here! Next time this happens to you, just direct them to this post.
Let me start this post by saying that if you have any suggestions of things to add to this list, please either reblog or message me your suggestion! And I'll add it with a little "suggested by _____" credit. This list is composed of what I personally used and still use. Help me help everyone else.
Indie Resources - This site is best known for its big lists of links spanning all kinds of topics such as designing, programming, portals, and documentaries. I think everyone can agree that this really is the #1 resource for new gamedevs.
Gamasutra - Kind of a given for both new and old game developers. But for new developers it gives them a really good opportunity to see the business side of things and what kind of stuff you can learn from new releases as well as old favorites. It covers both indie and AAA games - because there's a lot to be learned from big names too.
Gamedev Tuts - As the name states, game development tutorials. Covers a vast array of topics from games to languages and even programs for art. Making games in Unity is covered often. Scroll to the very bottom for the categories and away a new developer goes.
Resources @ Newgrounds - Newgrounds is a portal that hosts Flash games. You can submit and it gets judged. If you plan on making Flash games, you'll probably end up submitting it to some portal or another. However, not only does this give guidelines on how to submit to their site, it also provides resources on how to make Flash games in general.
The Art of Game Design - This is a favorite book among new and old game developers alike. Not only is it a hella reference on game design in general, it provides 100 prompts (called lenses) for you to consider and answer when designing your game. I use it every time I start with a new idea. It's great.
Game Architecture and Design - This was a favorite book of mine as I started out. Takes you from the spark of an idea to the release and post-mortem following. Good for whether you're designing by yourself or with a partner or team.
Game Development and Production - Another favorite of mine. This is written more for if you're working on a team but you can still draw a lot of value from it even if you're working alone. It also focuses a lot on the business side of things and developing to sell rather than just developing for the sake of developing.
Game Career Guides - Although these are out of print, you can still find them hanging around online. Written for students who are considering going to school for game development, are already in school, or are fresh out of college. But, whether a developer is in college for games or not, they're a student anyway. Always learning new languages and techniques, you know?
Actionscript 3.0 Game Programming University - Literally the best resource for programming games in Actionscript. Those are those games you see on Armor Games and Newgrounds and such. Essentially stuff you play in-browser.
Beginning C++ Game Programming - This is what I used when I first started learning the C++ language. Actually, it's the only thing I used. Because it covers enough basics to get you through a lot of things you'll need to do to make your game work. Should you run into a problem that's not covered in the book, Google makes for a quick fix. And this book steps through it in a way that makes it easy for anyone to understand.
Focus on SDL - A reference book on the SDL graphics library. You will need a graphics library if you plan on programming in any language that's not Flash. I personally use SDL so those are the only graphics libraries books I have to offer but this is an amazing guide. It was my best friend throughout the learning process of it and is something I still fall back on when I need to use a new part of SDL.
SDL Game Development - Another SDL reference. Not nearly as good as Focus on SDL but still has its perks. I suggest using them both alongside each other. Focus on SDL covers SDL as a whole. SDL Game Development covers SDL as its used in a game. It's kind of a learning as you go along sort of reference. Applying theory to practice and all that.
Indie Game: The Movie - This is a documentary and I've watched it more times than I've watched Fight Club. It focuses mainly on the creators of Super Meat Boy and Fez - all of which have been very influential to the indie scene as a whole. There's also a kind of sub-plot of the creator of Braid - another indie influence. In the beginning there's commentary from a few other faces that will become very familiar as you dive father into the gamedev rabbit hole.
Adventures in Game Development - A (very long) Youtube series of a team of hobbyists documenting the creation of their own game. Keep in mind they were just kids in high school when they created this series so if you can handle kids being kids then you can enjoy watching this series.
MS Paint - No, I'm not bullshitting. New devs might feel like this is too elementary school to use but if you're into pixel art or old school shit, this is the way to go.
Photoshop - 'Nuff said.
Gimp - This is similar to Photoshop except it's free and more lightweight. It won't make your computer breathe heavily like it's just run up a flight of stairs - because computers can do that, you know?
Maya - If you're not looking to do 2D art and would rather get into the 3D stuff then Maya is a program you can use for that. From what I've heard, although it's confusing to learn at first, it's rewarding.
Notepad++ - You write your code in it. Now, it doesn't allow you the option of compiling and running the code. It's just a fancy text editor. Kind of like Microsoft's Notepad (hence the name) but made especially for developers.
Flash - I personally use CS3. It gets the job done and isn't as loaded as the newer versions. The more loaded a program is, the more memory it takes up. So CS3 is good if your computer isn't exactly new.
Code::Blocks - This is the compiler I use. Compilers are important because the put your code together into an .exe file that you can run. So, if you plan on programming anything that's not AS3, you definitely need a compiler.
Dev-C++ - A rather old compiler but still used. I've used it and I've had no issue with it. Although I do prefer Code::Blocks. Sue me.
Productiontrax - Royalty free music and sounds. Important to keep in mind that you still have to buy a license, however. If you don't know the ins and outs of licensing and royalties and those kinds of things then, as a new developer, it's best to get in the know of those topics. Or else get tied up in some legal issues.
Audio @ Newgrounds - Plenty of sounds and music loops. BUT!! Please keep in mind you can't just download these files and use them in your games. You need to ask first. Most producers will be thrilled that you want to use their music/sounds in your game as long as they're credited. Don't be one of those asshole developers who take and use things without asking and without crediting.
audioformat.com - Free. Converts .wav to .mp3 without it sounding like shit. Choose from whichever quality you need.
Scrivener - This will be familiar to you if you're a writer. It cost $40 but it is well worth it. I definitely recommend it. I'm pretty cheap but this is one purchase I don't regret.
Evernote - It's like Scrivener with less features but free. I use both. This is definitely helpful if you have more than one game design document to keep track of and manage. Plus, you can make notebooks for all other things too.
IndieDB - The Indie Database. Now, I don't use this site myself (even though I probably really should)
Desura - As far as I know, anyone can submit a game to this site. Whether it gets accepted and put in with all the other titles is another thing entirely, however. Again, this is another site I haven't used myself but it is affiliated with IndieDB.
University of Reddit - "Has some cool programming tutorials." Java, C++, PHP, Python...just to name a few while scanning the front page. (suggested by zenodevblog)
I'm writing this as I've been inspired by how many people say, "Oh! I have an idea for a game/character/whatever" when I talk about game development. Sometimes they'll launch into what their idea is about but I usually cut them off by asking, "Why don't you just do it yourself?"
To which, as we all know, they reply, "Well...I'm more of an ideas kind of person..."
But of course they are.
These kinds of people are talked about a lot in game development - they're a game developer's bane. But, as much as they're talked about, no one ever really talks about how to effectively deal to them. Rather: What to say to them and their little ideas.
How can you shoot these kinds of people down without killing them?
Their ego is going to be bruised no matter what you say - so now it's more of a question of how to bruise their ego in such a way that they'll (hopefully) grow from. Whether they do or not is up to them completely. People tend to have a hard time seeing past their own pain and rejection - and right there, already, proof that game development would eat them alive.
Hell, I'm an ideas person too. So are you. Would we be creating games otherwise? No, because we wouldn't have a game to create. We need ideas for games before we can actually make the game.
So, in response to their own response, I usuallyĀ ask, "How many projects have you taken on that you've completed? How many projects have you started but then dropped? Which number is more - the number of projects you've finished or the ones you've given up on?"
Red flag if the second number is the one that's the highest.
Game development is full of these red flags.
Question: How many times have you gotten an idea in the middle of a project you were working on? Probably a thousand times and then some, right? The easily distracted will pursue those fresh ideas, risking never to finish what they start - whereas the more disciplined will write the idea down and continue working on the task at hand. The point is, whether you're the idea chaser or the idea recorder, you have ideas. A lot of them. All the time.Ā
You have plenty of ideas. What you don't have is the time to pursue all of them. Your job as a fellow idea guy is to pick the best of the bunch, buckle down, and finish one idea at a time to the best of your ability.
To these "idea guy" kind of people, explain to them that ideas are not the problem.Ā Getting shit doneĀ is the problem.Ā Finishing what's startedĀ is the problem.
Ideas are, as commonly stated, a dime a dozen. But if those ideas aren't brought from start to finish, they're useless.
Game development doesn't needĀ ideaĀ guys. What game development needs areĀ finisherĀ guys.
Having an idea is one thing. Creating and completing that idea is something else entirely.
My birthday shares the same day as my gamedev anniversary - the day I decided to start seriously pursuing this game development stuff - so here I am to share 15 things I've learned in one year of programming.
1. If itās taking a really long time to program or if it seems too overly complicated, Iām probably doing something wrong.
2. Likewise, if itās too easy and compiles without error on the first few tries, thereās probably a very tiny error lurking in the dark corners of a forgotten bit of code somewhere - just waiting to fuck shit up at the most inopportune moment.
3. In that same vein - the smaller the error, the bigger the problem. The bigger the error, the more better off Iād be just commenting out the code and rethinking whether or not this programming thing is such a good idea after all.
4. Iāve never experienced the woes of feature creep because if I canāt even get my current features to work, how the fuck am I supposed to get anything else to work?
5. Insignificant features will almost never be buggy and, if they are, itās a quick fix as a result of a spacey mind or just pure stupidity. Core mechanics, however seemingly simple, will always always always be a son of a bitch.
6. Thereās nothing wrong with the code. I just forgot to include a file in the assets folder. Yet again. And again. And again. And again and again and again. Or maybe I justĀ misspelledĀ something in the file name. Which is equally ridiculous.
7. Smart people save and recycle a good amount of their code. Too bad Iām a total dumbass 99% of the time.
8. Computers are the very reason for that old adage, āItās not you, itās me.ā
9. Memes arenāt funny because they support stereotypes that arenāt true. Programming memes arenāt funny because they are true.
10. The harder I try, the harder I fail. So the solution I try on a whim of āsure, why notā is usually the solution that fixes the problem. Refer back to lesson #1.
11. If I skip or skim over any - and I mean any - part in a book, tutorial, or video, Iām gonnaā have a bad time.
12. 3000 milliseconds doesnāt seem like a long time until Iām waiting for something to happen in the program Iām testing.
13. Although prototyping is important, sometimes the best way to solve errors is when I put all my chunks of code together.
14. There are at least twenty different ways to do one thing. Each of those ways come with their own set of errors and headaches to deal with so youāre stuck choosing the lesser of two evils or the really evil solution that does everything you want. Fuck.
15. Compilers only report the errors they feel like reporting. It just might not know how to break the bad news to me. That's why I have to compile twice. That's the only way it'll fess up. And I quote: "Okay...if you insist..."
And a bonus - seeing as how this isn't necessarily something I learned, rather, it's just common sense: Even when I think I know what I'm doing, I actually don't know what I'm doing at all.
andulkaphoto
romaincrisis
gracieabrams
2087
areudirty