• entries
628
1454
• views
1011986

# Become a Good Programmer in Six Really Hard Steps

175918 views

One of the more popular topics here on the GDNet forums goes something like this:

"Hi, I just [bought a computer | wrote a simple game | discovered a game engine] and I want to know where to go from here. I'd like to [accomplish some particular goal] eventually. What do I need to learn to get there?"

First of all, understand that Peter Norvig nailed this on the head a long time ago: it takes ten years to learn to be a programmer. There's a glut of "learn X in some small number of days" type books out there; there are hordes of blog posts about "how to improve your programming-fu in a few easy ways"; and in general a lot of people come around looking for advice on how to become a whiz with minimal effort.

I'm going to change up the pitch a bit. Instead of Five Easy Ways to Make Your Code Amazing in 21 Days, I'm going to tell it like it is. Welcome to How to become a good programmer in six Really Hard steps.

Step One: Suck It Up. Get in it for the long haul, or take up bird watching.
Sure, you can fiddle around and make nifty shell scripts and maybe a small game or four; if you're content with a limited skill set, by all means, go for the fast-and-easy route. I'm not trying to diminish the legitimacy of that option at all - some people don't have the time (or even the desire) to become a master programmer. If you don't relish the idea of practising this craft for ten years before you get good at it, then don't bother - but don't be fooled, you'll always be limited in what you can do and do well. If that is a reasonable trade-off for you, cool! You don't need to finish this article.

For the rest of us, though, there's something alluring about getting Really Good at programming. We want to be experts, ninjas, gurus - whatever noun of superlative mastery strikes your fancy. For us, ten years seems like a reasonable investment. Maybe a bit hefty, but hey, if it's worth doing, it's worth doing right... right?

So the first step to being a really good programmer is to bite the bullet. Accept that this is not just a ten-year process, but a lifetime process. And as Norvig so rightly notes, do it because you want to. Nobody becomes exceptionally good at doing something they'd rather not be doing; the world record holders don't make it into the history books because they kind of accidentally ate the most hotdogs ever in one sitting, but didn't actually feel hungry that day.

Step Two: Write Lots of Code
It doesn't have to be good code. It won't be good code, for a long time. Just crank stuff out. Any time you encounter a small annoyance in your daily computer life, think about how you could write a program to help solve that problem. Any time you find something interesting that you want to experiment with, do it. Play with new concepts and tools and languages, as much as possible.

The learning process is never going to stop, so if you approach this with the attitude that you get the most mileage out of cramming as much learning as you can into a given day, you will go far. Get into the mentality that a day/week/month in which you have not learned something interesting is a failure. There's enough stuff out there that you surely can learn something cool every day; this gets harder after the fifteen-year mark or so, but it's still totally possible. No one mortal can assimilate all of the knowledge there is in the world about programming, so if you ever feel like you've run out of stuff to learn, find a new project and write more code.

While you're doing this, pay attention. Look for patterns - things you do often that might be useful to automate, or things you write a lot in your code that you might be able to separate into shared libraries or other centralized locations. Look for languages that make certain tasks easy. Look for other languages that aren't so good at those same tasks, and figure out why one is more productive than the other.

But most of all: write code. Every day, even if it's just a regular expression to search through your email history or something. Do something programming-ish as often as you can. And remember, if this stops being fun, go do something else; there's no point in this if you aren't enjoying yourself.

Step Three: Read Even More Code
Once you have a small body of projects accumulated, start reading other people's code. At first, it will be difficult; they will do things you haven't seen before, or use styles you aren't used to, or even languages you haven't learned. If you find something cool, read its code if at all possible. Don't worry about deeply analyzing any given project, at least not at first; it can be a full-time job just to understand existing code bases like those of many large projects. Pick one or two things that you wish you could learn how to do, and find out how they were done.

Reading new code exposes you to ways of thinking that are new, and this helps stretch your brain. Stretching is vital to keeping up progress, and it will help ensure that as you go along you keep discovering new stuff to learn.

Be sure to talk to other programmers, too. Ask how and why they did certain things. Ask if they would do things differently in retrospect. Ask if they have any suggestions for your code. (But be polite; a lot of high-profile programmers are extremely busy and don't necessarily have the time or inclination to dredge through other people's work for free. Respect will carry you a long way; this is a tight-knit industry and reputation means a lot.)

Step Four: Learn Many Languages. Master a Couple.
You will not have a practical surplus of time, at least not enough to master many languages simultaneously, unless you are exceedingly lucky. Therefore, learn as many languages as you can at a shallow level - enough to learn what makes them tick, what makes them good at their specific jobs, and what their weaknesses are. Stretching is important here; don't just stick to imperative languages like C, or "object oriented" languages like Java, or whatnot; expand into functional languages and declarative languages as well.

Learn a Lisp dialect. This is why. It won't do anything for your day-to-day programming because you aren't going to use it; but it will make you a better thinker, and it will give you a deep understanding of the beauty of simple recursive systems. Stick with it until the "aha!" moment occurs; until then, it will seem like a soup of weird syntax and bizarre conventions. After that, it will remain with you for the duration of your career as one of the most astoundingly elegant concepts ever devised by mankind.

Then, learn a purely functional language. I recommend Haskell for this, because it forces you to be pure in ways that other functional languages (including most Lisp dialects) do not. You will have to bend your mind a bit, but once the inevitable "aha!" moment occurs (sometime around the point where you understand the purpose of monads, in my experience) you will again move forward a level in your thinking and ability to design elegant systems.

Finally, learn a declarative language. SQL counts, although it's a bit weak-sauce to just learn SQL. Prolog is often recommended but isn't necessarily hugely accessible. In the realm of the practical, XAML, XSLT, and XQuery are good tools to know and will introduce you to the concepts behind declarative programming. (In a nutshell, you tell the computer what you want it to do, and it figures it out; this is in direct contrast to imperative programming, where you tell the computer how to do things and hope it does the right "what", and functional programming, in which you describe transformations of data and types.)

As a bonus, learning XML-based tools after you learn a Lisp dialect will make it painfully obvious how desperately hard XML is trying to reinvent s-expressions, and just how poor a job it does.

Step Five: Create a Language.
It doesn't have to be complex, or rich, or sophisticated, or even particularly elegant. It doesn't even have to be original; I often suggest writing a Lisp interpreter (bonus points for doing this in a Lisp dialect!) as a good way to learn the basics. In essence, you want to get a feel for the fundamentals of computer programming design: lexing, parsing, compilation, interpretation, virtual machines, and the myriad ways in which basic design decisions in a language affect how useful it is for various tasks.

This will accomplish three things for you:

1. You will gain a deeper understanding of how your tools of choice work, which will give you the ability to be more effective with them.
2. You will start to see reasons behind the design decisions of major languages and tools, which will both fascinate and irritate you (if you do it right). This insight will help you choose your tools more effectively when starting new projects.
3. You will glimpse the untapped possibilities that still exist in the creation of tools and languages, and hopefully, open your horizons to a host of new opportunities for cool things to learn about and experiment with.

Step Six: Learn Something That Nobody Else Has Learned Yet
This is the hardest and final step. Up until now, you have primarily been learning things that are already known; things that you can find out by reading other people's code, or books, or academic papers; things that are good to know, but not novel.

Now it is time to break free of the boundaries and truly ascend to mastery. Now it is time to blaze a trail into territory that nobody else has ventured into yet.

Make no mistake; this is something you won't want to tackle until well after your "tenth year" of experience, mainly because until then you are far more likely to just be reinventing a wheel than actually doing original, novel research. But once you have a good grasp on the field, it isn't exactly difficult to find the sweeping frontiers of untapped knowledge that await computer science.

Chances are, this will take you another ten years, if not forever. Don't give up; remember, this should still be fun. If at any point in time you stop enjoying it, go do something else. Life is far too short to waste time trying to do something you don't want to do anymore.

Not everyone will succeed here, but everyone who makes an attempt will benefit from the effort. Don't let the odds get you down. Even if you never win the Turing Award, your continued growth as a programmer and your journey towards ultimate mastery depends on you constantly stretching - and, to that end, tackling hard, unsolved problems is the best way to stretch.

Congratulations! You are now a good programmer!
Oh wait... actually, you just died of old age. Sorry. Better luck next life!

In all seriousness, though, don't expect to ever finish. The instant you stop making forward progress in your journey, you start to die, and become irrelevant. Some of the saddest failures I've seen in the world of programming stem from people who got a certain way down the path and decided they were done learning; to a man, they are now completely unimportant in the software world, and will likely never move beyond their current situation - unless, of course, they decide to start learning again.

Now, go forth, and code! Maybe someday when you're a great programmer, you can tell me how you did it.

I'd love to learn.

Excellent article, and I agree 100%. Most people aren't going to get nearly as far as is possible, or even realise how far it's indeed possible to go. This ent up on Hacker News, by the way.

U'r rigth dude, I've been coding for 10 years. I've seen from black screens to mobile programming, passing through visual object-oriented programming. You need to know databases, language fashion of the week (Anyone remember visual foxpro or delphi ? what's CORBA or SOCKETS ? and so on). A old saying says "Renew or die" I think i'm a older programmer but while i have some free time to learn new things i keep in the line. Regards

Nice article

I like the "bite the bullet"part. I am student and I have female peers that think just getting good grades at college will get them the job. They have no idea what is waiting for them . I have top grades too, all A's actually, but I don't give it importance. Coding everyday my projects is much more important.

Haskell, what an experience that was. I solved around 50 Euler problems in it. Boy was it a mind stretch at first, but it was worth it. I back you up on learning as much programming paradigms as possible, imperative, functional, oop, logic and so on... Assembly programming is good too.

Step five, I plan to start a simple language soon. Tried it once and failed, now I am better, I will be able to pull it off. Will be a cool project.

About step six, that is possible only if you are in Microsoft, Google or one of those. Doing it on your own is kinda hard I guess.

Cya and God help us all become ninjas

@davoy9 -

I've been programming for something in the neighborhood of 19 years, give or take, so I'd say I have at least some room to talk here ;-)

[quote]I don't buy anything from step 5 on. Sure, writing the odd compiler brings insight, but there are so many other things at least as valuable. Write one or more of: DBMS, stand alone operating system, file system, device driver, game engine, test harness, text editor, CUI, GUI, logging engine, source code library, web framework, virus, disassembler, encryption library, code generator, maths library, sort library, etc.[/quote]

All of those are certainly valuable; I've done all of them at one point or another, and they certainly contributed to my skill set as a programmer.

However, my point about building your own language is not that it is merely a complex piece of software to write; my point is that it yields fundamental understanding of programming itself. Not every programmer works with databases or game engines or math libraries; every programmer works with programming languages. If there is one thing that any programmer can learn from, regardless of specialization, it's building a language.

Note that merely writing a compiler/interpreter/VM for someone else's language doesn't count - you have to design and implement something new. This is what provides the insights and opportunities for understanding. Building on someone else's design may teach you things about language implementation choices, but it won't teach you anything about design choices and how those affect the outcome of the language ecosystem itself. My argument isn't that there is nothing more valuable than writing a language for any given programmer; my argument is that all programmers stand to benefit from tackling this particular challenge.

[quote]There is nothing magic about knowing or learning stuff other people don't -- that's for academic papers. The magic lies in producing code that other people use and value, and the worth of a programmer is how many people use and value and are affected by the code you write. If you can write it and a thousand programmers value it and a million people use it, then you're a great programmer in my book. [/quote]

I didn't intend for step six to be a blanket requirement per se; but anyone who succeeds at step six will be considered at least a damned good programmer, if not outright great. My point isn't that you have to do something novel to be "good" - my point is that to ensure that you are good, you have to be willing to venture into places that are foreign, scary, and unexplored. It's more about never stopping the learning process than about a mandatory milestone on the road to success.

Success will be defined differently for every individual programmer anyways; that's a personal decision and it isn't my intent to dictate to people how they measure their own progress towards what amounts to a subjective personal goal. I just want to encourage people to move beyond what is already known; far too many programmers are content to shrug off pioneering research as the territory of academia and ivory-tower theorists, when I personally feel that there is much fascinating discovery waiting to happen on the fringes of practical, applied software development.

I certainly wouldn't claim to know absolutely everything or hold a monopoly on valid perspectives on the issue, though; that was sort of the point of the article's conclusion.

@calculemus1988 -

I disagree that you can only do novel research at a major company (or even in an academic environment). Plenty of people do new, interesting things every day who are not at such locations. Startups often do this; many famous successful projects began that way.

I think it's self-defeating and ultimately a bit tragic to decide that one can't do anything cool and pioneering just because of where one works (or doesn't work).

I've worked as a programmer (in the sense that I get paid for it) for 26 years, but I've been a programmer since before I knew what the word was. When I first found the [url="http://catb.org/jargon/"]jargon file[/url], I felt as though I'd found the elder scrolls of my long lost people.

Writing a new language, or at least a compiler/interpreter for an existing one, is extremely valuable, and I do recommend it. Creating a DBMS is also good. Any project like that goes as far as possible under the hood gives a person skills that spread across all other programming activities.

I would also recommend learning some sort of machine language or assembler. For most people there won't be any real practical application, but that's where all the work gets done, regardless of the language being used, and knowing what's happening down close to the bare metal has been enormously helpful to me.

I also find studying mathematics and physics (which I enjoy on their own merits) to be a great help in my programming. Learning the specific symbols and caveats that the author of a particular paper has used to create formulas for a human to read gives me great insight into to the algorithms people create for a computer to read.

Actually creating a new idea or learning what has never been learned may not be acheivable for everyone, but yearning for that goal is absolutely what sets the great programmers apart.

Great article, I really enjoyed it.

I am a programmer for around 4.5 years (Professionally anyhow, programming for approx. 12 years)
I've done most of these things myself and they are quiet valuable.

In my opinion there are 3 things missing from the list.

Communication - I know it's a bit cheesy but this is something that has to be kept in mind during ones professional development\career. Programming is not all about paradigms and technologies (which are completely awesome), it is also about cooperating with peers in a productive way.

Books - Read a lot of books about these subjects, they are amazing resources. Code Complete, Design Patterns, Mythical Man Month, Silver-Bullet etc.

Design theory - I am guessing it is implied that you're bound to run into this doing such diversified programming activities. Personally I have found a lot of merit in reading books that deal specifically with software design.

good article, will recommend to friends

I love the article, working my way through step 4 with ventures back to 2 and 3 A LOT. In the pursuit of my B.S. I took a formal languages class, maybe I'll bust the book back out and see what I can do about step 5...

nice article...!
am a game programming student, so i am just a beginner.
and this article helps me to see the real world of programming. great..!

nice article...thanks

I like the article in general, the only exception is that I would suggest that step five be cut down to "create a domain language". Maybe 10+ years ago writing a language was a good idea, anymore it is a serious waste of time unless you focus on a specific problem. Given that you can name about 50 "script" languages and probably another 50 variations of full compiled languages available which could be used without much effort. Unless you have a real purpose for the language don't do it, it is more useful to learn to bind say Lua or Python into your code base than trying to write a generic script language from scratch.

As to domain languages, I write them quite often and they can be very useful. Say I want to script the input of a game to reproduce random inputs, a simple little domain language is a great way to deal with this. You don't have to get fancy with this but the effort leads directly to the items of learning needed. As you increase the abilities of the language, bad things usually happen trying to parse the extensions to the language and generally explain how we ended up with C++ complexity.

I was learning programming in the high school (actually we were the first generation in the school who learned informatics), then abandoned it to study politics and philosophy . After 8 or so years I'm engaged again into programming, unfortunately only as a hobby, but this give me so much motivation and engagement to pursue my current preoccupation and learn as much as possible. Now somehow i'm sorry that I gave up and not continued, and sometimes wondering if it's possible to bridge the gap? Opinions?

@esimov

In my opinion it is very much possible, the real question is if you'll love programming or not.

Great article!

I have to second Nick's first point of communication though I'd like to build on this a little. As programmers, communication doesn't always come naturally. However, there are numerous tools available to facilitate communication without requiring the programmer to do anything more than they [i]should[/i] be doing. What should a programmer be doing?

1) Commenting code!
2) Using cource control and actually typing messages with each commit.
3) Writing code that tests their code

We can probably go a lot further here but I'd like to keep it as brief as possible.

[b]1) Commenting code![/b]
We need to communicate how our code works so that other programmers may find it easier to work with. Commenting does this but doesn't serve as a reference. Using a standard format for commenting allows documentation to be generated automatically with the build. Use DOxygen, JavaDoc, etc.

[b]2) Using cource control and actually typing messages with each commit.[/b]
We need to communicate that we [i]are[/i] in fact working. Our higher-ups are rarely all technical people and, even for technical supervisors, we don't want them to have to look over our shoulder or, worse, "facilitate" meetings where we run down our list of work completed. Our commit messages may be scripted to send e-mails or, better yet, generate a log. Even better yet, there are online services that do just that, even providing ticketing systems to allow for a two-way conversation between employer/client and programmer. I use repositoryhosting.com (SVN) which provides Trac for ticketing and hooks-in to Basecamp (this further generates an RSS feed of all goings-on including commit messages from RH).

[b]3) Writing code that tests their code[/b]
We need to communicate that our code works but, more importantly, when our code is broken! If a change elsewhere in the software breaks our code, we should communicate that immediately. When writing modules, I typically write test applications for them. However, when I've completed the module, I move the test code from the application and place it into a static test() method. This function serves as a regression test that can be called during the build process. If something breaks, it usually sets a red flag right away.

[b]...[/b]
So, you're doing all of this anyway, aren't you? (If not, then [i]BAD[/i] programmer!) Why not convert the common things you do as a programmer into communications to your team and employer? I'd say this would be the #7 step to being a good programmer, but the title is "Become a Good Programmer in Six Really [b]Hard[/b] Steps". This isn't hard and therefore doesn't qualify.

This is a great and very accurate post. It is interesting to note that alot of what you said can be transposed to other diciplines.

[quote name='nick--' timestamp='1315484695']
@esimovIn my opinion it is very much possible, the real question is if you'll love programming or not.
[/quote]

<br><br>oh, definitely. As a matter of fact i'm trying to engage myself as much as possible into coding, but unfortunately only in my spare time i have the occasion to tinker with code. At my current job, where I'm a server configurator technician there were periods when I had a lot of time to read, learn and try, but at the moment the situation has changed a lot. Nevertheless I'm fully motivated and committed to code learning and want to pursue my goal. The ideal situation would be to have all the day at my disposal, because there are a lot of good books, sites out there, and I'm very convinced the development is inevitable. thanks<br>

## Create an account

Register a new account

• ### Similar Content

• I am currently an undergrad several months from graduation. My major is in Game Programming and Development. During the course of my studies, we've had a few modeling classes and I really took to it and feel that is the direction I really want to go, specifically I would love to become a character artist. I keep hearing about your portfolio being super important, but I've really never been able to find out what kind of work is best to put into my portfolio. There's no "put 2 of these and 1 of those in," kind of tips. I get that I'll want to put some characters I've modeled in there, but I guess what I really want to know is, if I want my portfolio to be noticed and taken seriously for a character artist position, what is the best way to present it? Since most of my courses have dealt more with programming, I need to build everything for my modeling portfolio on the side, outside of class on my own time. I know there are no specific numbers like: put 3 realistic humans, 2 robots, a creature, and a stylistic character in your portfolio. But as a general rule is there some kind basic guideline or tips for what to make to get your portfolio off to a good start?

• Hi!
Is there by any chance you can give me an idea/concept that's different but related to the game Tower of London? (Is it called Tower of London?)
Can you show me some reference images, games or videos related to the same?
I've attached a reference image.
Thanks!

• Hi everybody,
So, me and my colleagues are now joining Unity Game Jam. It's gonna be two weeks and we are trying to make a Third Person Shooter with RPG and RTT mechanics video game. We've started yesterday with the main concept and this is what we have:

Game Storyline
Nobody could imagine the falling of the whole world until the deaths woke up. That nonliving ones became something we cannot consider as human being. They change into a new creature, stronger, more frightening, and almost unbeatable. Society broke in pieces and the few ones alive had to survive at any cost.
As the Major of a ranger platoon you have found an abandoned Military Outpost crowded of helpless people closer to one of the coldest parts in the world. You must keep them in safe until the reinforcements arrive.
There’s only one way to kill the damn zombies: the BlockchainZ Ammo.
Search for the BlockchainZ Ammo and destroy the hordes of zombies, but beware of the raiders: they will take your BlockchainZ Ammo whatever it takes.
Right now the Raiders have all the BlockchainZ ammo, you must fight them and spoil it, but be on guard, they will counterattack.
Remember, the survival of the people depends on you. Don’t let them down!

Gameflow.
Once you start playing Project BlockchainZ, you must defend the bunker against the hordes of zombies and raiders on a fixed map where you'll fight with your troops and traps.
The bunker is basically the main area where you'll not only have to keep the people within alive, but also yourself during the reinforcements arrive.
The zombies are extremely resistant, so you will need a type of ammo called BlockchainZ, which contains a very strong poison that acts directly against the brain traveling through the body.
The BlockchainZ Ammo is hidden in Raiders's Facility Bases and you must spoil it from them. The more  B-Z Ammo you spoil, the more Raiders will attack you, increasing the game difficulty level.

Features.
Third Person Shooter. Tactical map to manage your troops across the battle. Deploy defensive elements to direct the action where you want. Post apocalypse - scify style. RPG character development.
Right now, we've just opened our Project page in the forum. We only have two weeks to develope this idea. Our team is formed by two programmers, one game designer/ scriptwriter and one artist. So, we will update this thread to show you our improvements. Hope you like it. Any suggestions are always welcome. Thanks for all the support!

Whilst a lot of people find programming to be a stimulating activity, for others, traditional programming can be very intimidating; needing to remember what seems like arcane symbology, and seemingly endless streams of specific keywords into an editor can be very off-putting.  As many of us know, this actually gets easier with practice and soon becomes a less daunting task, but fortunately for those who struggle, there are other options available.
Many modern game engines offer different types of visual interface with which you can set up an environment and characters, and input the logic required to turn those pieces into a functioning game.  In this article, I aim to give a brief overview of some of the currently available options for creating games without traditional programming.  This list will not be exhaustive, but instead, aim to cover a few of the more popular and capable options, and I will leave it as an exercise for the reader to further research those options and choose what may be most suitable for their own goals.
Features and prices listed are current at the time of writing in October 2018.  Many of the options presented offer free trials, which I would encourage you to try out before spending your hard earned money -- in the case that no trial is available I would suggest checking out some written and video tutorials of the software to see if it looks like something you could understand and work with, as well as some games made with the software to see if it may be able to create the types of games you have in mind.
The first option I'm going to introduce is a simpler one suitable for introducing programming to younger would-be developers and is more limited in its capabilities, so if you're interested in more complex options please don't be put off and keep scrolling to the following items.  Below the list of options you'll find a few thoughts on visual systems.

Scratch
Scratch is a freely available programming environment created by the Lifelong Kindergarten Group at MIT Media Lab, and allows you to create games, interactive stories, and animations.  There is also an active online community of people sharing their creations and giving positive feedback.  Programming in Scratch is done by snapping building blocks together to input your logic, and although it's usable by people of all ages and abilities it's specially designed for younger learners ages 8 to 16.  Scratch works right in the web browser via the Flash plugin, so there are also no large downloads.  If you prefer working offline, there is also a downloadable version available.

Honestly, you're not going to create a smash hit video game with Scratch, but it's the perfect introduction for a child with an interest and may be a valuable starting point for people who find other systems intimidating.  Working with the visual system in scratch will encourage logical, structured thinking that can be applied to more complex systems or even to traditional programming at a later stage, and although it's fairly basic children will be excited to see and play with their own creations.  You can view (and play with!) some projects created with Scratch in the Explore section of their community.  Note that while you can share and play your creations with the Scratch community, but won't be able to deploy to other platforms such as mobile, consoles, etc.

Game Maker
Game Maker is a popular option amongst hobbyist and indie developers and is able to create games for a wide variety of platforms including mobile and many of the consoles. The engine has only rudimentary 3d capabilities and is not intended for making 3d games, but is very capable when it comes to 2d.  A number of very successful games including Hyper Light Drifter, Hotline Miami, Risk of Rain, Nuclear Throne and more have been created with Game Maker.  Check out the Game Maker Showcase for examples of what the engine is capable of.
Developers can use a simplified programming language called GML (Game Maker Language), or with a visual "drag and drop" system, and almost anything that can be done with GML can also be done with drag and drop -- albeit sometimes it might be a bit more clunky.  As a popular engine, you'll find plenty of tutorials (including lengthy series of officially provided video tutorials), sample projects, and people willing to help with learning and creating your projects.
You can get started with an unlimited free trial, and publish to additional platforms with a yearly subscription starting from US$39/year for Windows, up to US$1500/year for all available platforms.

Construct
Construct is a browser-based game engine that allows you to create games with a visual editor - in fact, in this case, programming is not even an option.  Games are created by applying and configuring "behaviours", and by using a visual "event sheet" that runs commands in order, and you are able to create most types of 2d game.  Because the editor runs in a browser you can create your game from any platform with a suitable browser, including mobile -- although you'll find it awkward to work with on a smaller screen.  A downloadable version is also available, and many functions of the editor are able to work offline.

Note that Construct is strictly a HTML5 engine, so exports for other platforms are provided via wrappers -- essentially packing your game up with a cut-down web browser to create an executable for the platform in question.  Their is an active community using the software, and plenty of tutorials and examples available to help you get started.  A free trial is available with some limitations, with full features available via subscription starting at US$99/year for a personal license or US$149/year for a business license (which you'll probably want if you're planning to monetize).

Stencyl
Stencyl is another visual editor aimed at creating 2d games, and able to publish to a range of platforms.  Stencyl's editor uses logic blocks similar to those available in Scratch, but also allows more advanced users to write some code if they wish to do so.  You can view some games created with Stencyl is the showcase.  Stencyl seems to have a slightly less active community than some other options, but there is some help available, and plenty of tutorials.  Some of the tutorials seem to be for previous versions of the software.

Unity + PlayMaker
Unity is an incredibly popular and very capable engine that can be used to create great games.  By itself, Unity doesn't provide visual scripting capabilities (programming is done with the C# programming language), but a third party add-on called PlayMaker comes to the rescue by adding a visual system and allowing developers to create games without writing code.  PlayMaker will currently set you back US\$45.50 (or cheaper with a Unity Plus or Pro subscription).
PlayMaker games are created with a flow-based system that involves toggling settings on nodes, which you connect in different orders to achieve the desired behaviour.  You will find PlayMaker more limiting than programming Unity with C#, but the experience you gain with the visual system may encourage you to try to C# and give you some fundamental logical thinking skills to build upon.

Unreal BluePrints
Unreal is another popular engine used by professional developers.  In this case, a visual system is built into the engine in the form of Blueprints, intended to allow non-coding designers to work with the engine and create interactive content.  You can get started using Unreal with no upfront cost, and pay just 5% of your game's earnings once you surpass a certain threshold.  Like many of the other options, there is an active community using Unreal, and plenty of tutorial content available, although most users do the majority of their Unreal development via C++ programming, with Blueprints used by non-coding team members.

Are There Limitations?
Honestly, yes.  Just as those using an engine might find themselves more limited than those developing their game "from scratch", you will often find that visual systems are more limited than traditional development.  Some things may be difficult or more time-consuming to implement in a visual editor, or if the creator hasn't exposed some data or a function you need your idea may be impossible.
However, many find these options to be more approachable, and some very impressive and successful games have been created using them.  Just be sure to do your due diligence about any limitations you might face before spending money hoping to create your dream game.

Other Options
The above are just a few of the popular options that can allow you to create games without traditional programming, but there are other options available if you're willing to do some further research.  Some others you might wish to look in to include GameSalad, RPG Maker, Unity + uScript Professional, Buildbox (,I found this editor to be especially limiting), and more.

Why Do I Keep Calling It "Traditional Programming"?
You may have noticed I keep saying "traditional programming" rather than just "programming".  Some people don't consider visual systems like those provided by the engines above to be programming, but I would disagree.  Wikipedia describes programming as:
and goes on to say:

I would argue that you are still doing the same task with a visual system, just via a different input method where you join blocks (or whatever the system in question provides) rather than typing special keywords.  Although some people find this type of visual programming less intimidating and easier to understand, you'll find that you're developing the same skills of logical thinking, planning out solutions, and finding (hopefully elegant) solutions.  After some time with visual systems, you may find the concepts used in traditional programming more familiar and approachable.

Conclusion
There are numerous options available to create games without traditional programming, and with the right selection you can likely find something capable of the type of games you wish to create.  Remember to research your options carefully, and don't be bothered by those who try to tell you it isn't "real game development".  I hope the above list helps to get you started with finding a suitable option for your project.

• I have a project with a bunch of different .java files. Is there a way for me to organize them in eclipse while still allowing them to access each other?
If I split the project in different folders, Eclipse can't find the different files when they're called in a different file.
×