The problem with making video games is that it is long not hard.
Designing your game is about 3-5% of the time spent making it. The rest is in tweaking animations, inverting arrays for better performance, refactoring, adjusting physics, fixing weird bugs, creating metaformats, and wishing desperately that floating point numbers did a bit less floating.
Exactly this. I just tackled this question in a podcast interview about my freshly released board/card game. As gamers, we can all have ideas. Video gamers in particular like to dream up their holy grail of gaming... but making a video game takes FOREVER and is mostly NOT fun.
Making a board/card game, however, is accessible to EVERYONE. If you can manipulate a pen and a pair of scissors, you can have a functional game in a matter of minutes. Then you get to spend 90% of your time working on the game design and not figuring out how to fix bugs in the physical medium.
From my personal experience, the two main challenges when it comes to making video games are:
1) It's a multidisciplinary effort. Unless you're someone with multiple talents, you need to put together a team to work on it. You might try to pull it off all by yourself using free resources you can find on the Internet, but it's next to impossible to make a truly great game that way.
2) The biggest amount of work will be spent on "polishing" things. Dotting the i's and crossing the t's, testing your levels and tweaking them, all that stuff is a lot of work. And videogame players are a lot less forgiving than other application users.
I would say the persistence needed to make something does make it hard. I understand what you're saying, but I don't think you can say it makes it any less difficult to ship something.
Or you can go for art, fun, raw passion, and a novel point-of-view.
There's an interesting take on this in the book Rise of the Videogame Zinesters: How Freaks, Normals, Amateurs, Artists, Dreamers, Drop-outs, Queers, Housewives, and People Like You Are Taking Back an Art Form
I know that stealing content happens, but as a developer that wants to stay on the up-and-up (read:not steal the hard work of others), I don't wan't to rely on a resource that has this sort of attitude on stealing others content. From the 2D Art section[1]:
"If you really don’t want to make your own art, steal it! There are a ton of sites with sprite rips of classic 2D games. You can’t make a career on stolen game sprites but no one is going to be sending you legal threats for you making your first few simple games that way."
They are placeholders, not final art. I've been working on a game, and I rip sprites from wherever I find them. Not because I am a callous thief, but because the art is temporary until I can get a prototype, and convince an artist to join.
Not to say that stealing other's content is okay, but I could certainly understand "borrowing" images to use in games when you're just starting out. I actually think it's usful because you can make clones of your favorite games in order to learn how to program.
So presumably you're against fanfics and sprite comics too? As with everything that can be copied (digitally or otherwise) and used in derivative works, fair use et al. concerns apply. (Hence the other commenters noting that it's common and fine to do this for self-education.)
That's not how fair use works. Simply making a derivative work is not enough to take advantage of fair use. The derivative work must fall into certain categories of use. A lot of fanfic and sprite comics would not fit into fair use, though many would. It is a very fact-specific analysis.
Indeed, I don't think I accidentally made the assertion that being a derivative but original work was sufficient. Similarly profiting off your work does not automatically dismiss any fair use claims.
I've been using Unity at work for almost 6 months now, and I can highly recommend it. Coming from a game development background it's incredible the amount of pain removed and productivity boosted by using it. If you know C# or JavaScript (or Python I guess, as Boo is some Python dialect I think) then you're halfway to learning how to use it already. Give it a try!
I'd wish people made normal tutorials (text + screenshots) instead of video ones. It's difficult to make a good one (that won't distract because of noise / recording quality / speaker without annoying voice), and at the same time you sacrifice low-bandwidth users and lots of time for the high-bandwidth ones - the important feature of a written document is that one can skim it, skipping the parts one doesn't need, focusing only on parts one doesn't know, while being able to see the entire context for the whole time.
Been working on a turn-based role playing game framework (the Ikosa Framework) for 7 years. Originally because I got sick of all the rote pencil pushing or being a game-master and wanted an optimized database of game-play mechanics and data, but eventually because I just enjoy the challenge of converting 960+ pages of RPG rules into code to automate the entire game system (senses, languages, lighting, initiative-based turn tracking, etc).
I've been working in WPF, WCF, and throwing in PLINQ and TPL (all .NET desktop/server-stuff) mainly because that's where I come from, but also because I've always thought of what I've been doing as a proof-of-concept.
And I think that was the point of the site. It will take that level of enthusiasm throughout the long dev cycle to make a game. Even if you can do an iPhone game in 3 months, to someone who is new that is LONG, not hard, as some else said earlier.
I have had a lot of fun working with Unity but not for making a game. I have actually been using it at work to use as the platform for an experiment which is being done in our Universities Geography department. what it truly taught me was how much scripting can save you a lot of time in the tweaking department. As this is my first real project that I'm doing on my own, it really helped in understanding how important making your scripting generic really is. It also has shown me the weakness of Unity's GUI library as there are some limitations with it.
If anyone's interested, I'm working on a fully web-based game-making toolkit project, as well. Not public, but slowly opening up: http://gt7k.com/
The genesis of that project is a high school class I teach -- see http://www.auscillate.com/post/300. But it's proving attractive to a broader audience as well.
Anyway: End plug. Just thought I'd throw it out there!
I had been doing my own research recently on 2d frameworks and engines to use, and while I don't have any experience with the following, they do seem to have a fair amount of respect within the game dev communities:
I was just talking about this last night with my brother! He made a prototype for a puzzle game in PyGame. Since he has a full-time job now, I decided to continue it's development.
Designing your game is about 3-5% of the time spent making it. The rest is in tweaking animations, inverting arrays for better performance, refactoring, adjusting physics, fixing weird bugs, creating metaformats, and wishing desperately that floating point numbers did a bit less floating.