the biggest influence in getting a good design is experience. Someone who has been there before, and knows what to expect.

This suggests you can start anywhere with Pong.

But herein lies my problem. I haven't been anywhere, I haven't done anything, I have no experience. (Discounting having a graphical user interface which codes on your behalf, leaving you clueless as to how it solved that problem.)

Whether you burn through a codeacademy course in an hour or so, or whether you buy an impressive-looking thick book that will take you weeks to read; (at least in my experience) all you will learn is stuff about variables, mathematical operators and functions / classes. You will be able to print text to the command line, and do some number punching on a calculator behind the scene.

At the very high level of abstraction, a game is a program that produces output. To be precise, mostly graphical output.

None of these things, designed to outfit beginners with what they need to know before chucking them out there and saying 'go program now', even begin to address graphics.

If you bought a really thick book, you might know how to save a high-score to an external file for use next time you run the game, but not if you changed your mind about which language to learn after buying the book (Usually because you're advised strongly to start with a simpler language, but occasionally because you're told that of the options available, despite all the sales-hype for why this is the book you should buy, this is not a language worth bothering with.)

So unless you only want to print keyboard characters to the command line, you have zero experience of the tools or code you will need to tackle even the most basic task, but the advice boils down to, you have everything you need now, go read the API. And the API is like a huge reference book with no search function, and tells you a lot of technical information that is indecipherable to a beginner for the most part, and seems to lack any layman's definition of what the thing actually does. Now maybe I'm missing an obvious trick here, but it seems like I took one swimming lesson and I'm now expected to be confident enough to jump into the pacific ocean without any water-wings, and if you find you are unable to do that, your only recourse is to buy more books in the hope that they will be better than the last, sight-unseen, or trawl through forums asking questions of people that seem so simple it makes you wince to ask them. Even if you ask an experienced programmer how they learnt, they can only reply that they just started writing code, and more code, and more code, until they got 'experience'. This doesn't explain anything, although it sounds like it should.

Yes Frob; in reply to what you just posted before I hit post, we could all do text-based games. We could do that in BASIC as well. I was designing stuff like this when I was 10. Moving through mazes and answering choice gates. The only difference is learning how to do that in OOP. Nothing from that experience helps me move beyond that. In a sense you are still using a GUI because you couldn't put anything on the screen other than ASCII characters that the language already knows how to output to a command line prompt. You can't draw a single pixel, except in letter-graphics.

Text based 'ski' game where you have two bars indicating the edge of the board and a mark in the middle the player moves.

I have no idea how to do this btw. Maybe I have misunderstood your suggestion. Do you mean a progressive print-line execution where you can move a character left or right or just continue forwards, without using any appearance of animation or requiring the screen to be overwritten with blank pixels each time ?

But herein lies my problem. I haven't been anywhere, I haven't done anything, I have no experience. (Discounting having a graphical user interface which codes on your behalf, leaving you clueless as to how it solved that problem.)

Whether you burn through a codeacademy course in an hour or so, or whether you buy an impressive-looking thick book that will take you weeks to read; (at least in my experience) all you will learn is stuff about variables, mathematical operators and functions / classes. You will be able to print text to the command line, and do some number punching on a calculator behind the scene.

It does indeed. You can read as much as you like, but actually doing it is very different from reading bout it.

So close your books, and start coding? Use Python+pygame, or C++ + SDL or SFML (no experience in the latter), and code a pong display, or tetris or a ski game. Something just outside your comfort zone. Try to make it work. When you get stuck, post about it, and ask for help. When it works, ask for feedback on the code.

The only way to get experience is by making your hands dirty. Code things. Try building something and fail. Understand where you went wrong, get up, and try again. Repeat until success. There is no book "make a successful game without errors". If it existed, literally everybody would use it. It would be all over the Internet. gamedev.net forum wouldn't exist (or at least it wouldn't have a "Beginners" section :p ).

I get the feeling that you believe there exists a way you don't know to scale up from small to bigger programs. I think you are looking for something that doesn't exist, or rather, you already have it. Know how OOP builds an abstraction? Instead of thinking in the elementary data, you think in terms of instances.

Bigger programs just have more abstraction layers. The class instances become elementary data again, and you build another abstraction to manage them. Top down design works similarly, your lower level is still too big and complicated, so you repeat the trick, and sub-divide further.

You build more layers of abstraction on top of each other until you can handle the entire game in a few methods. It gets more complicated, as you continuously jump between abstraction layers, and have to make decisions what layer is responsible for what part. There is however nothing new, it's just more and more complicated to get right, just as OOP for the first time was more complicated than it is now.

I think I understand now what it is you're looking for, but there is a reason you are having difficulty finding that other 'end' of game design.
Because you are approaching the concept as a system of objective states and methods when it is an entirely subjective field.

You are finding an abundance of information on one 'end' and not the other because those concepts can be applied to a very large range of potential uses.
Network code can be used for any form of game that involves communication between players on separate machines, regardless of the larger design.
Writing the physics of a simple Pong game lays the foundation for everything from collision to impact dispersion and ad/absorption of energy and can apply to games as simple as "flappy bird" or scorch, to one centered around real-universe astrophysics.

Trying to approach it from the other end, you have to narrow your aims to a very small subset of 'games' to find any information at all, because they can be literally anything.
A single sentence posing a choice, and a selection of sentences as a response based on the choice made.
The chemistry of protein 'folding' expressed visually through its mathematical qualities so that 'players' can experiment so as to resolve real life mysteries in fields that utilize the information for things like medical solutions to genetic maladies and preventing extinction of endangered species.

Game creation is art.
You can ask a painter who paints predominantly human subjects about their methods of making the hair look real, or how they know the correct scale and shape of eyes. You could ask for more general concepts on their painting such as how to achieve a 'style' across a selection of subjects.

Or you can go to the small end, asking them which paints are best on what canvases, or how long they take to dry.

But without the narrower focus, you are in essence saying "Without speaking about paint or canvas, or specific styles or subjects, tell me how painting is done."

It is a question every single painter will have a different answer for, and their answer only really applies to their own works, so you never actually find the answers.

--
In other words.. you will find a lot more help if you narrow the scope of the question.

If you ask about the general concepts behind RPG design, you can find entire books discussing the protagonist and the conflict with antagonist either as a 'boss,' an environment, etc, and the value of lures and obstacles and story-line development without ever mentioning actual coding or game assets.

If you ask about FPS games, you can find similar regarding how games in the genre with designs of a certain character, maps/worlds lain out in certain ways are more popular because of various psychological triggers and how such game can be designed to play on aspects of the psyche that motivate someone to play longer, more often, etc.. again without any reference to actual code.

But you need to narrow the aim to something that has traits that are at least most often the case.
While a game could be created in the FPS style but revolving around a story, where the tactile 'action' input of the player was of no importance, but choices on a decision tree are, is entirely possible, you won't find many examples of such games compared to FPS games involving shooting or melee combat in some way.

One of the best things I've ever read in a computer programming book was this: 'There is no one right answer to anything. Just a collection of answers that are each less-wrong.' Or something like that.

Alright, stay with me. I'm going somewhere with this. I've been where you are. I'm STILL where you are. There are a lot of voices out there yelling out the proper way to do things, the best way, the most efficient, the cleanest, the least memory intensive... But programming doesn't always work that way. I've found, in most cases, making something work is infinitely better than getting it RIGHT.

So I just did what I wanted. I came up with a game concept, and I started working. And I failed. Over. And over. And over. And over. But it's been a few years now, and my massive online text adventure that I'm working on is actually starting to look like a game. I'm still having to learn new concepts every day, but it's easier and easier with each new concept, and I understand them faster and faster.

See, what I've learned about learning programming, is there are three stages to really understanding a concept, be that from a book or a forum or a teacher.

The first stage is being able to look at some example or some explanation that's given and just being able to understand what the hell they are saying LOL. I'm talking understanding Vocabulary, intent, what the heck a semicolon is for. In the beginning, this takes forever. And when you're done, you're like well I'm never going to use that, not in my game. Why did I need to learn this? Because you don't really get it yet. This is just the first stage.

The second stage is when you look at what they're telling you and you're like wow! That really makes sense. I see exactly what he's doing here. You look at it and you're like, I could totally put this in my game and use it. Like, the whole idea just makes sense. This stage is problematic because it gives you a false sense of security. You feel like you really learned something. And then when you try and put it in your code, you can't seem to make what they are doing work for what you want to do, because it doesn't really fit. It's his interpretation of his solution, and it doesn't apply to your problem. For me, I got stuck at this stage for so long because my ego told me I was smarter than I was LOL. Then I finally discovered the third stage.

It wasn't until this year that I really understood the third stage. The third stage is when you can look at a problem and not only understand the verbiage and the terms, and not only understand what he's using it for and how it works, but you can understand the underlying theory and the implications of the knowledge. You can literally boil down what is being said to what is happening, and abstract that out to 200 different scenarios. This to me is the beginnings of mastery. Because you can look at their solution, and take that back down to the problem, and work from there toward your solution.

When you first begin, the distance between stage two and stage III is massive. Like, you can't even see stage three and understand it even exists at first. Then one day, after going over some example for the 1500th time, you're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three grows shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tie together and everything just suddenly starts making sense. And it's awesome!
You're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tied to gather and everything just suddenly starts making sense. And it's awesome!

My advice to you on that is, when you find a concept that you want to understand and implement, go find about 10 different people doing it their own way. Try to figure out what they're doing and why they're doing it the way they're doing it. And then really the more people you understand the closer and closer you will be to understanding stage III of that topic.

But above all? Just get started. Program. There is no better way to learn than to try an idea, and fail at it miserably.

Thank-you all for such wonderful answers. As a friend of mine is fond of saying, 60% of solving a problem is defining the problem. When you're sitting there staring at a blank page, and the only advice you've been given doesn't feel as if it is relevant to whatever is holding you back, all you can do is go on a fishing expedition - an open-ended question thrown in the direction of people who hopefully know what they are talking about, and try not to get frustrated or impatient as you wait for comprehension to dawn. In a couple of days, I have learnt more than I've learnt in the last few years trying to figure out how to start coding.

Like everyone who wants to learn how to code games, I do have an ultimate game format in mind; but I am very much aware I have to set that bias aside and find enthusiasm for simpler applications of code, because I can't wave a magic wand and make years of experience download into my head. I am also aware that my ideas will change beyond recognition long before I have the expertise to create it, so talking about what I aspire to program seems a bad idea ... at best I would be told to set that aside and think smaller, because mighty oaks must start with simple acorns; at worse I would be flamed for having such huge ambitions and I really need to avoid negative attitudes because I have enough of a fight on my hands convincing myself that my dreams can come true if I am prepared to believe in myself and that others can give excellent advice given half a chance.

I would like to take this opportunity to say a particular thank-you to NoAdmiral; because this video playlist appears to be pure gold for someone like me who wants to know how everything works with an even greater passion than I want to program my dream-game. It's not in the language I thought I would be concentrating on, it's not the format of games that match my dream-game, but it does present everything I need to get experience and understanding of computer games off the ground in a passive methodology of watch-and-learn, explained to great depth so I'm not constantly distracted and frustrated by having to track down incomplete answers, or having things I consider fundamental glossed over, with the promise that these 500+ hours of application on my part which I can do at my own pace, will lead to a fully realised game and an understanding of everything it takes to make it work, with plenty of opportunities to get distracted into messing about with the code to make it do something else, without, MOST IMPORTANTLY, losing the thread of where to go next and getting bogged down in only knowing what I already know.

My problem was that I could come up with tons of ways to put together the code I already knew in different ways, and none of this ever led to new functionality. I had no books, no videos, no teachers talking about what comes next. As Theis_Bane so clearly models, I knew stage 3 must be out there, and I wanted someone to tell me what programming looked like from standing there, because I'm still at stage 1; and stage 2 is just stuff I trip over every now and then that makes sense, but I can't use it yet. At least now I can understand that most of what a game is, is a rendering engine. I don't know what I thought it was, before this thread made it clear; it was just an idea with a title, called game programming, which ought to be able to be built with pure math, but I had no idea how math could do that. I still don't, for the most part; but that's another chapter.

For anyone who has been following this discussion to see what gems might be thrown up, I would like to append that I have also found this resource : http://www.nand2tetris.org/ which others may find useful or interesting.

You will be able to print text to the command line, and do some number punching on a calculator behind the scene.

I have been there

Actual programming is not far from this, the way you understand a program- a long spaghetti, which when entering a cycle will just loop unable to do anything else- is absolutely correct.

Consider a console basic program, when it does something else besides the input waiting from OS (what is a point in which it does nothing, only OS programs does- to serve the blinking cursor), it realy stucks itself dedicated on a task it passes through. Now, you may wander how program can "give away" its proccessing to gain something? There are a plenty of calls that couse your program to free the cpu while specifying when it should come back (a time, a state) and will proceed from that point, functions like: socket operations, sleep, input in cmd. Also, your program is able to "look" at any sort of stuff from OS (peripheral state, etc.).

Consider a console application, you still can hack it to gta5:

-make a conditional loop, behind which the console program ends

- store time at begining of a cycle, do tasks, and at the end of cycle put sleep() function with desired time

- you can be writing the frame to a socket, to emit it to internet, or to some applciation that is able to display it, or file save it.

- collecting inputs can be harder, since it is a console app, but you can read them from a socket still, served by some app that collects

The sleep function has made sure your program gives its proccessing back to OS, so OS can advance as it wishes, in single core computers this was vital.

But this was a silly description of a hack, which can be modulated/encapsulated to some application base, (message looped peek of win32 app?). I would stress yet, that physical run-time of program is not important to know at all when designing a software, the important is the logical run-time of the program.

But I think you need a concrete pushing - I will give it to you. Let's ask questions to you instead:

- What prevents you form compiling basic empty application the can display pixels?

- Install professional development IDE, like MS VS for example

- Find out what empty applicaiton type suites you

- learn about input registering/collecting

After you did, I give you first ToDo-

Make an application that will display all .bmp pictures in a directory that its .exe is run in, put ability to scale down and up the picture and navigate them by arrows.

This application is then all ready for some nasty 2d game, you have production assets available (.bmp pics), you will be able to 2danimate (atlased .bmp), you will have ability to write and define any pixel of the application, giving you freedom you may demand, also, when you will start to wish to rotate the pictures, in 2d manner of course, you will see first challenges, of abstract logical problems.

Since having an internship in a high end sofware developing company is not that easy (unless you are some top UNI), and getting an open source engine/library can just couse you stuck on it after learning to use it (not code it), I encourage you to keep in the way of staying "low level, all possible" .(pixel apps/directX/opengl)

I have sort of understood your struggles right now, so my post might be some more "enlightning", but the core rule is the same "go experience". I wish you the best of luck, don't give up, I have gained best advances when I accepted I am the worst programmer who knows nothing, and, there is a lot of joy waiting for you :)