I understand what the syntax for the languages do, how to use them, etc.

Problem is. When it comes to solving a problem (ie making a simple console game of tic-tac-toe). I struggle to figure out HOW to solve it, like what variables, etc are needed. Is there a way around this? I have a book called "How to Think Like A Programmer". But is this really something I can work around?

This mostly just comes with experience. When I started programming (which was well before the internet mind you), my solutions to solving problems were horrible. I had limited knowledge of HOW to solve the problems, so I solved them the only way I knew, which was massive global variables, goto's, and other ugly practices.

But, I kept working at it, kept reading books and I had a friend who programmed as well, and we would bounce ideas off each other (what the internet is good for these days). Eventually, i got better at it, learned new ways to solve problems, and I could make new things.

So, I'd say stick with it. It's not going to be easy, but eventually, things will start to "click" and you'll woner why you didn't think of that before. Good luck!

When you're trying to come up with a solution to a problem, don't immediately start thinking in code.
Your code has to be a tool to implement your solution, not a tool to come up with a solution.

The first thing you should do when trying to solve a problem is breaking it down into smaller and more manageable sub-problems.
For tic-tac-toe you have several simple aspects: You'll require a representation of your game board and a way to manage your game logic (ie. managing who's turn it is, checking for winning conditions, etc.)

A potential breakdown for a game board could look something like this:
-You need a game board, containing 9 squares. This means you'll need:
-A way to represent a square. Each square can hold 2 values, so you'll potentially need:
-A simple structure which can represent these values

So now you have a very basic and manageable overview of what you need to implement for a visual representation of tic-tac-toe.
Now you can do a similar breakdown for your game logic aspects.

Once you have these two major aspects figured out you'll have a complete overview of your program. Now you can start thinking about how you want to implement your solutions in your language of choice.

If you are struggling with it and learning from it, then it is good. You are gaining experience.

If you are struggling with it and failing, or struggling with it and not learning anything from it, then it is not good. In that case you need to try to solve easier problems until you gain experience.

I struggle to figure out HOW to solve it, like what variables, etc are needed.

I find this common lament kinda odd. I never have run into this. I never really have problems thinking about how a syntax element might be used to solve problems... Granted, what I come up with (especially starting out) isn't always the best or most practical solution for things but it's a solution.

I understand what the syntax for the languages do, how to use them, etc.

Problem is. When it comes to solving a problem (ie making a simple console game of tic-tac-toe). I struggle to figure out HOW to solve it, like what variables, etc are needed. Is there a way around this? I have a book called "How to Think Like A Programmer". But is this really something I can work around?

Problemsolving is what programming is all about, the language is just a tool you use to express your solution.You get better at problemsolving with practice, (start with simple problems and work your way up).The key to solving all big problems is to break them down into smaller, more managable problems.

I don't suffer from insanity, I'm enjoying every minute of it.The voices in my head may not be real, but they have some good ideas!

This is the key here. If you know how to solve the problem in your head, or on paper then you just need to learn to slow down your thinking and break it into the smallest possible logical steps. Then just turn each of those steps into a piece of code.

For instance when I think about playing a game of tic-tac-toe:

There's a 3x3 board made up of blank spaces. (Need to think of a way to express the board in the language - and a way to display it to the players)

I put an X in a space every time I get a turn, and my opponent puts a O in a space every time they get a turn. (Need to think of a way to place different markers.)

Our turns alternate back and forth between us. (need to set up a sequence that alternates turns)

Eventually either the board is full or else one of us gets 3 of our symbol in a row and therefore wins. (need to be able to check for end conditions)

Another thing that helps a lot is to try not to think about your program as 'what's happening on the screen'.

Try to implement your solution in a sort of 'theoretical space' that's just pure logic. Then make a way to represent that logic on the screen. I see a lot of new programmers try to form their logic around their presentation rather than the other way around and this causes no end of confusion. Think about it like 'The Matrix'. You are 'The One'. The players of your game see the illusion - the graphics on the screen - but you see the truth - that the graphics are just a lie that represent a hidden reality. Develop that reality in the world of pure logic and then teach it to generate graphics.

Feel free to take a whack at stuff and then post it here if it's not working out and ask questions about it. As long as people see that you're thinking about things they'll often give you a lot of advice about structure and such.

Hope that helps. Good luck.

Actually, if you don't mind dealing with LISP a little bit you can watch some SiCP videos here. I don't know if that's what you need, but maybe it will help you out. If you start watching it and it doesn't make any sense then just close it. No reason to add confusion at this point - you can come back to it later.

Edited by Khatharr, 29 November 2012 - 03:27 PM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

And I think your progression is a textbook process for skill advancement and experience programming: new programmers rapidly learn how to use the tools, but their solution is brute-force or inelegant and often resource-wasteful. The more practice (with a paradigm or problem domain) the better the solutions become. Just like a pianist knows how to hit the keys, but a beginner's music sounds all clunky and off compared to a master.

OP: it just takes time and practice. But mostly practice. If you're not attempting solutions and writing code, you're not making any headway.

I'll keep at it. I just switched back over to C++ after a couple years learning C# (for XNA). I just recently (read: about 8 months ago) started understanding C# finally, and now things click easy (thank you Head First C#).

But with XNA being all but dead. I feel it's best to stick with C++ from now on, then eventually learn OpenGL/Direct X, and whatever else I need to start making simple games. But first I gotta start making sure I can solve these problems I face. The syntax/language is a non-issue.

Do you have the free time to enroll in a Data Structures or Algorithms class at a local college? Once you know what all the tools in the tool-box do, its easier to pick the right ones to solve problems.

Do you have the free time to enroll in a Data Structures or Algorithms class at a local college? Once you know what all the tools in the tool-box do, its easier to pick the right ones to solve problems.

I plan to go to a University here soon, I just need to see if they'd have the right classes.

I find this a problem common among beginners. If I give you code, you can understand the process and what the code does. But if I tell you to write a brand new code from scratch, you are stuck right from the beginning. Did I run into this when I first started? I don't remember. But I see this all the time.

The era of the Internet today makes it easy to copy and download code snippets, which encourages lazy thinking. You see this all the time on blogs. People would comment "Code doesn't work! HELP! HOW DO I FIX!?!?". And this is coming from using a simple code how to convert a file to a string object, for example. I'm not pointing out that the code doesn't work, but I'm pointing out the sheer laziness in people that they expect things to fall on their lap and work. When things not operating the way they expected, they don't bother to find the solution themselves.

It only comes from experience, and it has to be the right experience. Always write code from scratch. It's okay to look at code from web, but only as a reference, not meant to be copied directly to your code. 90% of the time that code won't be compatible to your code anyway. Never, ever, copy-paste and use code you get from web, conferences, CDs, or anywhere else. It's okay to use prepackaged libraries (like STL, SDL, Ogre, 3rd party libraries), the ones that you don't have to look at their code to use it.

How can a writer be a writer, if all he does is copy someone else's work? Programming the same way.

I find this a problem common among beginners. If I give you code, you can understand the process and what the code does. But if I tell you to write a brand new code from scratch, you are stuck right from the beginning. Did I run into this when I first started? I don't remember. But I see this all the time.

The era of the Internet today makes it easy to copy and download code snippets, which encourages lazy thinking. You see this all the time on blogs. People would comment "Code doesn't work! HELP! HOW DO I FIX!?!?". And this is coming from using a simple code how to convert a file to a string object, for example. I'm not pointing out that the code doesn't work, but I'm pointing out the sheer laziness in people that they expect things to fall on their lap and work. When things not operating the way they expected, they don't bother to find the solution themselves.

It only comes from experience, and it has to be the right experience. Always write code from scratch. It's okay to look at code from web, but only as a reference, not meant to be copied directly to your code. 90% of the time that code won't be compatible to your code anyway. Never, ever, copy-paste and use code you get from web, conferences, CDs, or anywhere else. It's okay to use prepackaged libraries (like STL, SDL, Ogre, 3rd party libraries), the ones that you don't have to look at their code to use it.

How can a writer be a writer, if all he does is copy someone else's work? Programming the same way.

That's a main problem of mine.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

You just have to break up a problem into smaller chunks. Go find a sheet of graph paper and get it out. Start drawing a flowchart of your game loop and its variables, start planning out your program. It really helps sometimes, and gets you motivated.

C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

Then forbid yourself from looking at anyone else's code until you've completed your own. It's just like playing a game. You can play with a strategy guide your first time through, but you're just cheating yourself out of the accomplishment. Finish it once yourself and then look at the guide to see what you missed.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

Then forbid yourself from looking at anyone else's code until you've completed your own. It's just like playing a game. You can play with a strategy guide your first time through, but you're just cheating yourself out of the accomplishment. Finish it once yourself and then look at the guide to see what you missed.

^ This

When I was a beginner I did this too. I constantly looked at others code and thought "But this guy does it this way, isn't that a better solution..?" Well, maybe it is a better solution, but it's not your solution. As I realized that, I also realized how ugly my own code was, but it didn't matter, as long as I was the one who came up with the solution. The ugliness of the code goes away with practice. I'm not saying you shouldn't look at other peoples code, only that it's bad for your problem solving skills to do so.

I struggle to figure out HOW to solve it, like what variables, etc are needed.

I find this common lament kinda odd. I never have run into this. I never really have problems thinking about how a syntax element might be used to solve problems... Granted, what I come up with (especially starting out) isn't always the best or most practical solution for things but it's a solution.

I dunno... did I just play with too many Lego's as a child?

I think the problem is more in how do I express the solution I came up with, and that is a problem when you start programming, as you are learning how to program and how to express this problem at the same time.

If the problem is just how do I express a solution in my language Mathematical equations like Greatest Common Divisor, finding the zero points for quadratic equations and stuff like that is great to figure out how to express this in a language. The reason behind this is that maths already split these up into steps for you and you only have to express those in your language.Working out the solutions for these equations and learning the algorithms involved on the other hand is a great way to learn how to divide problems in to more manageable chunks I found.

That's a main problem of mine.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

It's not a problem to take code you find on the internet and use it, you just have to play with it until you actually understand what it is doing. From reading source code you get the major gist of how it is doing it's job, however what you usually don't get is what is the problem that this code is solving. When you start modifying it and it breaks and you start debugging why it is breaking that is where the understanding of the algorithm comes in, because at that point your are forced to go through the same thought path as the original author. How soon that understanding of the code kicks in is experience and your familiarity with the problem area. Once you start working this is the most useful skill you can have, "read and understand(debug) other peoples code". It is very seldom that you get to work on writing an application from scratch when you work for somebody.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

If you can't think of a solution for a tic-tac-toe game, then maybe it's too much of a challenge for you. Step back, and start something much simpler, like a number guessing game, text-based adventure, dice rolls. I have no idea how many useless/random programs I have written back in my GW/QBASIC days: draw random lines, circles, rectangles, compound interest calculators, address books, fake shell, etc.

It's a good thing that you are doing this because you want to learn. Keep this attitude, and never stop writing code.

For example, the Tic Tac Toe game, I keep trying to do it the exact way that the other guy does it, and I get stuck, and constantly refer back to his code to see what I am doing wrong. Not to mention whenever I try doing it by myself, I constantly think about that persons code. So I can never try it myself.

What I learned, and I think everyone learns, organically just by going through the process of programming without any professors, is that to improve your ability to problem solve, you must be able to focus on specific problems without thinking about all the 600 other problems you'll have to solve before you're done. To do that, you need to plan out what you will program before you ever program. The first time I did that, it gave me a huge boost in productivity, and it was a lot easier to focus on specific problems rather than be distracted by the fact that I don't know what's next or why. If you sit and write it all out, you have your own notes to refer to, not anyone else's code.

It should be super high-level, too. Like:

Tic Tac Toe: - UI: - There will be a main menu, and you enter a number to choose an option: --0 is Exit --1 is New Game

etc, etc, etc.

Notice there that I'm not talking about any code. I'm just describing the game or program or whatever. You start with concepts, at the highest level possible, and then you work your way down. You do this because working from the highest to the lowest level of design means you decide that a certain thing is necessary before you decide how you implement it. Working from the bottom up would be the opposite: You'd be coding functions that do things, but you don't know why you need them to do that yet. That means later you're almost definitely going to change those functions.

Aside from that, I think you should quit on tic tac toe. Forget it. You're gonna keep looking at the other guy's code, and you're probably tired of it by now. Do something you only have a small idea how to implement. Are you familiar with dynamic arrays yet? Make a "Database" where users will specify the amount of entries they need to make, and then create a dynamic array of that size. It can be an array of objects that the user fills out the data members of, and then the user can delete, move or change things around in the database, which means you'll have to manage the memory, make new resized arrays, and play around with different C++ features. Don't worry about actually saving the data. But if you're interested, you could use fstream, or if you're on unix you could use I/O redirection, and that'd be something else to learn too. But the point is to just do stuff that takes thought and taxes your knowledge of the concepts of programming and the specific language you're using.

Other ideas: Hangman, a calculator with factorial, square roots and powers, rock paper scissors, a text adventure (if you like writing, too). A personality quiz? An IQ test? When I was first starting, I tried to come up with ideas for iPhone apps that I could implement little prototypes of in a console program, sort of like proofs of concept. This was great because I honestly believed in the idea, planning to actually make them real, usable applications, but I was also realistic about the current scope, limiting it to console programming and simple user input/output.