[Opinion] What newbies to gamedev should make

So - I notice the same old thing when a newbie posts on the forums asking what is a good way to get into programming.

"Make a Pong clone" one says.
"Make a Breakout clone" another says.
"Make a Pac-Man clone" another pipes up.

While these games are simple and very easy to make. They are not fun to make.
Learning should be fun as should the goal that you are trying to accomplish.
There are a plethora of online tutorials for Unity3D or Unreal 4 that teach by doing.

Examples ranging from -
Making a mount and blade inspired game
Making editor extensions
etc.

I think that we need to ask people what they want to make. Give them feed back on how to do it and watch them fail or succeed. I do not mean that in a way that is at all harmful to newbies. But as a way to help them out.
You learn more when you fail or make mistakes opposed to when you succeed. Watch them pick themselves
up then keep on going.

So those people who want to make a MMORPG by themselves. Tell them go for it! But at the same time. Give them advice on how to solve problems that they will encounter.

If they manage to learn from their mistakes and keep on going that is great! If they don't or Just give up. Oh well cannot help everyone.

- HeadClot

 

I'm not one to point people along those lines, mainly because that isn't how I learn. I learn by doing things I don't know how to do.

But by the same token, making games, especially as a individual, requires a huge base of skills. Theory, concept, logic, engineering, art, or at least a solid grasp of computer graphics and design. And those are just the fundamentals. If someone wants to start with something very complex without those fundamentals, more power to them. They'll either rise to the challenge or get bored/frustrated and find some other hobby.

But for those going that route, my only advice is learn the fundamentals first. Beyond that I have no other help to provide. I don't help noobs, and have no interest in doing so.

It's like learning guitar, or anything else, you need the core stuff first before you start selling tickets to your first performance, you need to know how to hold it, play chords, tune it, where you place your fingers to make notes, etc. While learning twinkle twinkle little star may be boring, you know how the song is supposed to sound and helps you aquire those fundamentals along the way.

People learn in different ways. That should be encouraged. As long it is understood that if your way is jump in head first (not a bad thing, that is what I do), that also means that you need to be resourceful enough to research and grok fundamentals along the way. And that is not the same as expecting tons of people to hold your hand at every step, or that building a game is nothing more than grabbing and tweaking stuff you found on the net.

 

I think it's important to have a first project that you'll actually be able to complete so you don't instantly get demotivated. Pong for example is relatively simple, and by making a "clone" which you can put your own sauce over you can learn to understand how and why certain games are the way they are. When I give the advice to make a pong game I am not saying make an exact copy of pong and you are done.. give it your own twist, go 3D instead of 2D, add power ups and so on. Rocket League seems like an advanced pong game to me in that way.

 

This thread again? I'm over it, make whatever the hell you want.

Just don't expect to be taken seriously here or in any game dev context until you have made something. With that in mind the quicker you can have something made the better.

 

I'm just starting out with my first game, but I have a background in mechanical design so the overall process is easier for me to plan out than the average newbie. I've read through a lot of threads and seen all the common "go make pong" responses. No-one has said that in response to my questions but I disagree with the go make "generic game here" as your first project.

For someone to be engaged with learning they need to be doing something they're interested in. If they want to make a top down shooter but someone tells them to make pong they aren't going to see the connections and if they try to make pong will likely get bored and stop.

So I say re-invent the idea of the "small game" and help them break their game down into a series of small games or small steps. Take the top down shooter...get them to make one room, one player moving, one enemy. Add in health system for the player and make the enemy deal damage. First game complete! Objective is to avoid the enemy. Next step/game is give the player a weapon, give the enemy health..kill it....next game add more enemies and spawning, maybe larger room with obstacles, scoring system etc.

This method will both teach the new dev and also help them progress their game idea. Most newbies just want guidance on where to start with both tutorial videos and what to do first in their own game. By breaking it down for them this will accomplish both and keep them interested and progressing their own game idea.

 

Any project will get boring after a while (even your dream project), better learn soon to deal with the boredom of making a Pong (or a tower defense, top down shooter, simple mobile game, whatever) than to discover it when you already spent a year with little progress and completely burned out.

Finishing a project is a skill, that's why you start small. Before starting with my current project I made 2 small mobile games, only then I feel ready to make something like Nomad Fleet (and is not even that big as my actual dream projects, just another step in that direction).

 

While I agree that developing an interesting game can help you push on, there will always be some aspects of development that will simply be boring. If they cannot handle a little bit of boredom then they aren't likely to get very far along. Starting with a game like Pong is excellent because there is very little to get bored of.

 

Define a project though. You can quite easily take someone's game idea and break it down into small projects for them to complete and get the same/more out of it than just making pong. Do 5 minutes of googling and you'll find a step by step guide of how to make pong in unity anyway, so you can complete that challenge and learn nothing or spend the time to do it properly and learn a lot.

If their game is broken down into small projects they'll still face the reality of boredom and difficulty curve but won't have the issue of making something they're completely uninterested in and don't see the point of.

 

...and while I'm all for telling them to go ahead and work on their dream game by focusing on a tiny model of it I'd say if they find nothing interesting about creating a pong, arkanoid, space invaders and similar scoped games they seem to be lacking in appreciation for game design and development and perhaps games themselves. A game shouldn't need to be some epic AAA scope to be interesting. If it is you might as well just buy AAA games and play em and focus on getting a job for a AAA studio.

And to clarify because I know someone is reading this with fire burning their backside I'm talking about these new devs who act like it is a major insult to suggest they "lower" themselves to starting out with small scale games. Just seems like a lack of appreciation for games and lack of respect for all of the great game designers who have come before them.

 

This.

Most of the simple clones I advocate starting with can be done in an hour by an experienced user. Stretch that out to a day if its your first time touching Unity. And a week if you have never programmed anything before in your life. If that time line leaves you bored then game dev is not for you.

The problem with most 'dream' projects is they would actually take an established studio with a ton of money and experienced people years to complete. Work that out in man hours and you suddenly find that there are not enough hours in a human lifetime for a skilled individual to complete the project. Let alone a new dev.

Then there is the fact that during the actual building of the project the day to day work is pretty much the same for pong as it is for the biggest AAA dream game. If you don't get excited by working with code and algorithms and data structures, the type of game you work on isn't going to make a difference. Dreams will only motivate you so far, you have to be interested in the work and the process.

 

I enjoy working on code, 3D models etc but for me personally the grab behind making a game (or making any product at all) is seeing it come together, seeing it develop as I work on it and get the end result.

If I have an idea for a game that I think is really exciting but then get told to go make pong I'm not going to have anywhere near as much fun making pong compared to actually starting on my idea. Making a player character and moving it, making the first basic enemy AI and getting to to chase me. These things are simple, useful tasks to learn and yet fun because they're the first steps to my own game.

If someone is excited by coding just because it's coding then by all means working on pong is no different to working on their own game. If they instead derive their enjoyment from seeing a product come to life then there's a vast difference between the two and making pong as a first game could see a lot of other ideas die from boredom.

 

It doesn't have to be pong. Pac-Man and dozens of other similar scale games would work very well for the scenario you are describing.

I think maybe there is just a miscommunication going on. When new devs ask for help and are told to make these games that is the more experienced people providing some help. They are guiding this new developer to focus on understanding the underlying systems by suggesting they make a smaller scale game first. It has nothing to do with trying to crush people's excitement for their project and everything to do with trying to help the new dev filter out all of the noise and focus on learning the things they need to know.

When you are dealing with massive games such as the kind many new devs want to start out with there is so much they need to understand how can anyone be expected to walk them through it all in a forum reply? To think that is possible shows a real lack of understanding of just how much is involved in making such games. So the best that can be done is to either suggest they focus on a tiny model of what they want to build (like a single small very simplied area of their game) or to focus on making a smaller scale game period.

I do think people probably throw out things like pong too often. It'd be better to suggest smaller scale games that have more of the systems (although simplified) required by their dream game.

The point is any game you want to make there are already smaller scale examples that have been made in the past. So... start with those. Focus on learning the important things the systems such as the player control and AI you mentioned. The idea is the asset production is minimal and the scale is much smaller more focused so you can spend more time focusing on the important things. Things that can be carried forward to your dream game. You could even evolve the small scale game into your dream game through iterations over time.

 

I'm personally working on tic tac toe as a small break from my other thing.

 

This would be perfect. I was suggesting to break the game into smaller projects because 80-90% of the time someone just tells them to make pong. If they suggested a game that would more directly help usher the new dev into their concept then that would be awesome.

I think the key is just to actually read and understand what the new dev is trying to achieve and provide an individual response that suits them rather than the generic go make pong.

Also saying "Go make pac man" on it's own isn't necessarily better, but saying "go make pac man because it'll teach you how to control a player, basic enemy AI, level structure...etc" is a much better response as it helps the new dev understand why you're giving that particular bit of advice.

 

I agree, Pong is kind of a representation of "classic games" but I'd advice new developers to start with making one of those. For one it teaches you how far along gaming and game making has come and secondly it teaches you how to make certain features that are expanded upon in modern games. Try to recreate a "classic game" that has elements that you'd have in your dream game. That doesn't have to be Pong, but I'd advice them to look at "classic games" to recreate.

Making and completing one of these small and relatively simple games can give you a good impression about how much time and expertise larger projects take. When I went trough the tutorial game in Game Maker I suddenly had an Eureka! moment and I saw every game I had ever played in a completely new light. For example think of Pac-Man, but in 3D, you could say that was the first survival horror game.

In short when I advice someone to make Pong, it's not simply about making a Pong game. Yes, you could explain them why you advice them to make that, but I'd say it is a much more meaningful experience when they discover the teachings for themselves.

 

Perhaps we could turn this thread into something productive and suggest a bunch of small games to clone to hit the most commonly asked for mechanics?

I'm thinking a question - game to clone type set up.

How do I make an object move? - Pong paddles
How do I build an enemy AI? - Pong versus the computer
How do I build an MMO? - Network Pong
How do I make a character controller? - Pong paddle controllers
What do I do once I finish a game? - Try market pong
How do I do physics? - Pong ball

These are just off the top of my head, feel free to suggest better clones

 

My pong game had multiple modes (time and score) and even had a character select screen which gave you different sized paddles with different abilities. You could apply this knowledge to a Fighting game or even a Shooter. As you say there are a lot of features in Pong that you could expand on that teach you valuable knowledge that you can apply in other games.

*I'm a new developer myself by the way since Pong is my only completed project so far, but because of that I see how valuable that learning experience has been to me.

 

LOL! Excellent. I was drinking some water while reading this and started laughing. Not good for the lungs!

Those certainly make sense and I like how you worked pong in for each one.

I think it would be a great exercise and actually was thinking of adding a page to my website that maps various modern games back to classic games based on the systems involved.

It'd be fun to do it here as a community effort though. And when complete one of us can create a new thread and post it and we can simply direct all future devs to that post. I will still make a page for my site so I can refer people there in the event the thread here gets buried.

Pac-Man is a great target for player control, enemy AI, ability changing "gear" and so forth. It could even be a fine target for procedural level generation.

Galaxian provides basic player control, acquiring enemy assets and putting them to work for you, enemy patterns and perhaps flocking and steering behaviors (depending on you you implement the little squads doing their attack runs).

I'd need to take some time to really think about it to come up with a good list.

 

This is relevant. Every one I know who has completed smaller projects first is an advocate of it. I've never heard someone say "I wish I hadn't wasted time on building small projects". Nor do I recall any devs saying "I started with my dream MMO, and it was a success". I have heard "I got three months into a big project before I realised it was too much for me." I've heard it a lot, and said it myself a few times.

You may correct me now if your story is different.

It started out as a less trollish post. Then I realised I'd picked pong as an easy example for most of the mechanics. I edited it to what you see now. I hope I didn't cause too much of an injury.

But on a serious note, I think the mapping idea of simple games to more complex mechanics is great.

 

I've always agreed with starting small and completing something first. Just haven't liked the generic cookie cutter one size fits all approach of go make pong that I've seen here.

Just that little bit more direction that matches the fundamental aspects of their idea appeals to me much better. Replying to someone who says "I want to make a space sim" with "ok, go try make Asteroids" sounds so much better than go make pong.

 

True enough. My goto advice is typically to make flappy bird first. Its generally simpler then pong, and more in line with techniques needed for modern games.

 

One of the big challenges that comes with being a noob is language barrier. They simply don't speak the same language. And no amount of metaphors (sorry @Graham Dunnett ) is going to solve that. Understanding comes from application. Yes, people learn differently, and those that can, become self evident by asking intelligent questions and I am more than happy to help if they have put in the time and effort on their own.

However, most give themselves way too much credit, jump in way over their head, and in a week are frustrated because they can't increment a score, make a menu, have one script talk to another or broken all their scripts by doing something stupid like renaming them. All of which you would learn by making pong in a few hours.

The challenge with more involved games like asteroids or space invaders is that to a noob there are distractions like graphics, ip,ai and generally not fully understanding the actual game loop. They often get lost or off on a tangent quickly and aren't learning. There was one a while that wanted to do space invaders and it derailed into a discussion about how he was going release if he just use the original art. Pointless and a waste of time.

Let's be honest here, if someone has gone to the effort to post "where/how do I start?", they have already demonstrated that they are not a special snowflake, and lack the resourcefulness to skip ahead a few chapters. They need start at the beginning and do the beginning tutorials/pong/roll a ball and THEN, after that, they should have enough ground work to ask intelligent questions and start branching out.

You start with the chanter, and work your way up to the pipes.*

*For anyone who doesn't understand that analogy, don't worry, it's never too late gain some culture in your life.

 

Then call me lacking..but I can recreate any mechanic out there. I jumped in the deep end. There is the underlying assumption those doing first games are 14 year old noobs.

 

Silly really: http://unity3d.com/learn

 

You were also a seasoned developer before you ever touched Unity. I'm pretty sure GarBenjamin was referring to those people who have never written a line of code and come here asking for advice on making their first game. Building your first game/application in the days before Unity existed counts as having gone through the paces already.

 

When it comes to absolute beginners, who have never touched a line of code before, I think we have to treat it like beginners in anything else. Billy Joel's first notes on a piano were likely Chopsticks, or Hot Cross Buns, but certainly not Scenes From an Italian Restaurant. No one would suggest to an aspiring musician that has never played before that they just begin composing their song. The same goes for anything that is both skill and art. You need a foundation from which to build on. That foundation may very well simply be exposure to other programming languages or tool sets. But lacking that, jumping into the deep end of anything isn't likely to result in much more than frustration.

 

The exact nature of what you create first is irrelevant. The important element is that it is achievable, within a reasonable time frame. People often recommend Pong because Pong is achievable. Even absolute beginners can make Pong using Unity in a few hours. The vast majority of what you need is drag-and-drop.

But what you actually end up creating can be more personal. I recently used a tool that I had created to cook up a quick prototype of the room-movement features from the original Legend of Zelda. This is more complex than Pong. But thanks to the tool I had made, I was able to get the prototype working in a reasonable time frame. I put a character on the screen, had them move from room to room, and even simulated the functionality of the Lost Woods.

It is worth noting, however, that I did not attempt to replicate the entire game of The Legend of Zelda. That would have been an unrealistic scope for a basic prototype or a basic game, and a bad project for an absolute beginner to tackle. I'm not even a beginner, and even I would scope such a project out to several months or more.

The point here isn't targeting a specific game or project to emulate. Your first project can even be entirely original, that's fine. The point is to keep expectations and scope as modest as possible, so that success is more likely in the short term. This is a good lesson for any fresh developer to learn, as it often serves as the bedrock of modern programming and project management. I'm always dividing larger projects into smaller sub-projects and feature demos, and tackling them one at a time.

 

This is brutal but anyone getting past it, probably should carry on going.

I don't care particularly what newbies to game dev should make. I'd rather they made nothing and went back to doing whatever like choking with glee watching xfactor or putting fingers in plug sockets. This is because if I have to really (I mean really, wtf?) hand out advice what to make then I pretty much don't ever want to hire them or work with them.

Basically it's about love. Artists who are real artists, they can't help themselves. They'll grab anything that makes a visual and go nuts with it. It's the same with game dev. If you have to tell someone how to start then they probably do not have the all encompassing love for it that breeds genuinely good games.

So to everyone starting: just get on with it.

 

Back in my day, we had the BASIC reference manual and source code listings for games printed in 3-2-1 Contact magazine with no explanation of how they worked. We didn't have the internet, or an endless supply of tutorials. We had to learn, and for the most part we had to teach ourselves. As a result, only people who loved the idea of programming got into making games. Loving the idea of making games is something very different than loving the idea of programming. I think you probably need to have both. But that's a point that someone who just wants to make games isn't going to want to hear.

 

Nobody ever really made something worth making without ignoring people. Everyone says no. Even the computer says no. It's the fury of your yes that fights them. It's the yes that conquered Everest. The yes that reached Mars. And on a smaller scale but in some ways no less important, it's the yes that made a game.

 

I would still suggest experienced devs build a small clone first if trying out a new framework or engine. If I was to jump to unreal today, the first thing I would do is set up a basic level with some 2D sprites, user input, simple scripts, basic physics, a score system, game over conditions and a basic menu. I would also run it through the build process.

That game could be pong or flappy bird or a basic platformer or space invaders, depending on the mood I was in at the time. But the two hours spent "learning the ropes" of the engine would pay off massively in whatever foolish dream project made me change engines.

 

First computer interactive thing I wrote was an interactive Table of Chemical elements in Flash in 1999. Second was a tricorder type phonetics decipherer. From there I wanted real looking artwork and had to wait ten years for Unity to pop up on my radar.

 

I think a lot of what is being said is missing the point. It doesn't really matter if someone makes pong, pac man, asteroids or works on the first steps of their own game. Any one of these will help them learn, just some of them will be more engaging for learning and when the newbie gets frustrated they'll be more likely to keep fighting it. If you're working on something you're utterly uninterested in and it fails would you care enough to try make it work?

Could always look to how this stuff is taught at University...when I started learning C++ and CAD the first thing both those subjects did was provide a complete work as an example and then go through the steps of how to make it - These are equivalent to Unity's tutorials. The next step is to re-create that product yourself, type every line of code, sketch every shape in CAD etc. This helps get a feel for the program.

After that the next step is to use those tools you've learned from the tutorial and apply it to a basic extension of the principles that you've been taught. This is where pong, pac man etc comes in. In terms of learning it doesn't matter what you're working on, as long as its another step forwards. In terms of being engaged by the content and wanting to learn, being encouraged to learn and wanting to stick with it and figure out what's gone wrong when you make a mistake there's a world of difference.

It boils down to teaching methods, good ones engage the student, bad ones don't The best teaching methods are always catered to the student which is why I dislike the "go make pong" responses so much.

 

Too be fair, if you can't think of a game to (re)create on your own and go on the Unity forum to ask what we advice as a first project then you don't have much right to complain. There are hundreds if not thousands of tiny games to choose from and it's up to you to pick one that you find interesting and want to learn from.

I think we all agree that Pong isn't "the" game. To broaden the advice I'd say look at classic games (NES era) and pick a game you enjoy and recreate that, I think that is a fun and engaging way to learn how to make a simple game while also learning about gaming history. But too younger people I'd say take a look at mobile games and maybe try to recreate the Angry Birds or Flappy Bird mechanics.

After I finished my Unity tutorial game (Flappy Bird) I thought of new simple projects myself and I ended up with Pong, but I had also thought of Tetris, Pac Man, a Mario clone and so on. If I had gone on the Unity forum and they had adviced me Pong I would be like: "Seems like I had the right idea, lets make a Pong game first".

 

Depends on the person who is asking for advice. I was meaning more someone who has an idea for a specific game already in their head (might be way too ambitious, MMO etc) and says "I've got an idea for a game and want to make it, where should I start". So you point them at tutorials that give an example of the tools they'll need to use/develop and advise them to try make a game similar to their idea or point out for them how to get started on their own.

When people ask "where should I start" it isn't necessarily because they can't think of a game to re-create, but because they need a direction and are too inexperienced to figure out what a logical starting point is.

 

In case someone has an end goal and says what kind of dream game he/she has than that makes it much easier to advice and give a fitting starting game. But most people kind of ask "I want to make games, where should I begin" and than the answer is going to be obvious. I agree with what you are saying though.

 

Not sure what they teach in CS classes these days but I would have freakin loved to make Pong instead of a reservation system for a fictional airline in Turbo Pascal.