- Published on
Stuff is Hard
- Authors
- Name
- Linell Bonnette
A friend and I once had a bit of a disagreement about how hard video games are to make.
He said that he didn't think they're very hard to make. He even used a game that I submitted to a game jam that my ACM chapter held as an example of a game that he could do better. I was just a little upset by that. I heard some guy sitting there saying that he, who had never made a game before in his life, could just sit down and make a game better than mine. I heard him saying how easy it was. It felt like he was saying that anyone with half a brain could make a AAA game -- no problem! Heck, this guy was even saying that he was going to do it all in just C++ using nothing but OpenGL. For his first game! Scoff.
In reality, as you can probably imagine, he didn't quite mean that. He meant that my game wasn't very complex or complete -- which was true! He meant that drawing pixels to a screen was a doable task that he was confident he could accomplish -- which was true. He meant that it was an easy enough task to make a basic game -- which was true. He also said that he didn't think it was very hard to make a pretty awesome game. He was wrong there, but he didn't know it.
And of course we were both too upset to really get our points across. So we just got angry at each other. I went home and did some research on the actual number of people doing independent video game development in C++ and doing all of the graphics stuff themselves. He went home and drew some pixels to a screen. We both thought we were right and the other was wrong because we both validated our claims.
We both got over it pretty soon. It didn't really matter anyway, right? People can say whatever they want about something. That's their privlidge. What bugs me, though, are people (especially those who have no experience in something) claiming that it's "easy" when they don't really know what all goes into it.
You're wrong.
I've done that plenty of times myself. Especially before the disagreement above, I was really bad about not considering the whole problem before jumping to conclusions about how hard or easy something is. During one of my internships, another team of interns was tasked with implementing (what I thought was) a small feature. Easy as pie! Heck, I had the logic, which was the only hard part, pseudo-coded in like ten minutes. Their solution was soooooo slow that it made me cringe. I was even vocally opposed to their solution. The mentors liked theirs, so it made it into the application. A month later, we were having some problems with their code. I got that smug little look on my face and opened the code. It was at that moment that I realized how dumb I had been.
It was much move complex than I thought it was. My solution would have only worked for the absolute most basic and simple case. Their solution was slow and needed some optimizations, but it was correct.
That's the trap that it's much too easy to fall into: looking only at either the most basic case or only at the very top layer of a problem.
Going back to the video game example, my friend was only looking at the very top layer of the problem -- drawing pixels to the screen. My game wasn't a very good example, since it barely went past that. It did go past though. There was a map system, a (crappy) physics system, and a few other little things you've got to have for a basic game. And that's a very basic game that's really not very fun. For a real game, you're going to need decent artwork. You're going to need a good physics system. You're going to need a good idea for the game. You're going to need a level designing system that allows you to actually make levels that don't suck without spending years making a matrix of numbers representing tiles. You're going to need a lot of stuff I'm not mentioning here. Every game is a little different and requires different things. The difficulties I selected here would drastically change if, for example, we wanted to make a mobile game.
These difficulties that are "hidden" exist for almost any project that you'll encounter in the wild. I believe that this is why younger people, including myself, seem to jump to the "it's so easy!" routine faster than older, more experienced people.
Better Example
Let's think about Reddit for a minute. Reddit is a very simple looking web application. Let's break down some of what you do on Reddit:
- Look at links users have submitted.
- Vote up or down on links that users have submitted.
- Submit links.
- Subscribe to subreddits.
- Leave comments on links.
- Karma things (related to up/down votes)
That seems so simple. That sounds like something any competent web developer could make in a day, right?
Let's take a step back, though. Reddit gets something like 150 million pageviews per month. That means you're either going to have a pretty hefty bill for your servers or you'll need to do some hardcore optimizing. Even arguing that our version wouldn't have that many views, let's think of all the other things that go into Reddit. There's the ranking algorithm that has taken them a few years to get right. There's the whole subreddit system, which sounds simple, but would take a lot of work when you really think about it. You've got to support hundreds of thousands of users, each of which can be subscribed to any number of subreddits. Those subreddits each have have their own rules, their own CSS, and their own moderators. OH THERE'S A MODERATION SYSTEM, TOO. And that brings us to user accounts, which we just realized need permission to do things other than submit and vote. That's no big deal, we can move on from there. Let's talk about the up and down voting system and how we can make sure that users aren't somehow cheating the system (too much) and that each user only gets one vote per link. What about how karma is calculated for each user? What about the fact that we can create our own subreddits? Reddit gold? Commenting? Private messages? The list goes on.
All of those simple little items add up quickly. Reddit has 4000-something commits that have been made to its repository. There's a lot of complexity there that we don't see by just looking at the surface. There is a lot of complexity that we, as users, can't even think of until we're the developers. In fact, I'd wager that in most cases, the lion's share of complexity is behind the scenes and we'll never know about it.
And that's for nearly any project out there.
Conclusion
So the next time you're laughing at some guy's hard work on Hacker News, telling yourself that you can make it 1,000 times better in just a few hours, stop. Just stop it and really ask yourself if that's true. If it is, well then do it. You're awesome. I seriously doubt that you can, though. I bet that if you ask the developer, he or she will have hit bugs that you would have never even thought about. They'll have crossed oceans that you thought would be streams. So give people the benefit of the doubt.
Stuff's hard.
Now, I will admit that this probably changes a bit as a developer progresses in his or her career. You'll know more and be better at what you do, which should really make things easier. That being said, I've rarely heard experienced developers call something easy without truly knowing that they could back up their claims.