Hello gamedev! (the irony!)

Thank you for having on the forums and thank you for taking your time reading my first post!

Background

Get this: I hated math, did horribly in school and high-school and never got along with it. I always considered myself to be more of a humanist (if that's how it's called) - I loved studying other languages (self thought myself English and German of which I'm proud, they might not be native level, but I'm content), philosophy, learning history and ultimately I finished law in the university.

At the end of the day I sort of started thinking that some humans are more math/precise science proficient, while others find themselves on the opposite spectrum (whatever that is).

Shortly put: I have a very limited math knowledge.

Reason

Maybe it was because the constraint to learn was set aside, and my curiosity set in for something I didn't understand for a long time (as a side note I'm 25 years old). I thought programming can make me a bit more of a whole person, and reconcile with something I disliked, and so, slowly I gained more and more interest on this subject, on to the point where I started learning c++ by my own about one week ago. Before learning about arrays, I wrote this in c++:

[spoiler]

#include "stdafx.h"
#include <iostream>
#include <string>
#include <cstdlib>


using namespace std;




int main()
{
/*

int mode;

cout << "Would you like to play with a friend, or against the computer?\n";
cout << "1. With a friend\n2. Against the computer\n";
cin >> mode;
system("CLS");
*/

char plc1 = 255;
char plc2 = 255;
char plc3 = 255;
char plc4 = 255;
char plc5 = 255;
char plc6 = 255;
char plc7 = 255;
char plc9 = 255;
char plc8 = 255;
char plcTot = plc1 + plc2 + plc3 + plc4 + plc5 + plc6 + plc7 + plc8 + plc9;



while (true)
{


cout << endl << endl << endl << endl;
cout << "\t-------------------------\n";
for (int x = 0; x < 9; x++)

{



if (x == 3 || x == 6)
{
cout << "\t------------------------- ---------------------\n";
}


if (x == 1)

{
cout << "\t| " << plc1 << " | " << plc2 << " | " << plc3 << " | 1 | 2 | 3" << endl;
}


else if (x == 4)

{
cout << "\t| " << plc4 << " | " << plc5 << " | " << plc6 << " | 4 | 5 | 6" << endl;
}

else if (x == 7)

{
cout << "\t| " << plc7 << " | " << plc8 << " | " << plc9 << " | 7 | 8 | 9" << endl;
}

else
cout << "\t| | | | | |" << endl;

}

cout << "\t-------------------------\n";


if (plc1 + plc2 + plc3 == 237 || plc1 + plc4 + plc7 == 237 || plc3 + plc6 + plc9 == 237 || plc7 + plc8 + plc9 == 237 || plc3 + plc5 + plc7 == 237 || plc1 + plc5 + plc9 == 237 || plc4 + plc5 + plc6 == 237 || plc2 + plc5 + plc8 == 237)
{
cout << "O wins!\n";
break;
}


if (plc1 != -1 && plc2 != -1 && plc3 != -1 && plc4 != -1 && plc5 != -1 && plc6 != -1 && plc7 != -1 && plc9 != -1 && plc8 != -1)
{
cout << "It's a draw!\n";
break;
}


int plaX;
int plaO;
cout << "\nX's turn: ";
cin >> plaX;



switch (plaX)
{
case 1:
plc1 = 88;
break;
case 2:
plc2 = 88;
break;
case 3:
plc3 = 88;
break;
case 4:
plc4 = 88;
break;
case 5:
plc5 = 88;
break;
case 6:
plc6 = 88;
break;
case 7:
plc7 = 88;
break;
case 8:
plc8 = 88;
break;
case 9:
plc9 = 88;
break;
}
system("CLS");




//////////////////////////////////////////////////////////////////////

cout << endl << endl << endl << endl;
cout << "\t-------------------------\n";
for (int x = 0; x < 9; x++)

{



if (x == 3 || x == 6)
{
cout << "\t------------------------- ---------------------\n";
}


if (x == 1)

{
cout << "\t| " << plc1 << " | " << plc2 << " | " << plc3 << " | 1 | 2 | 3" << endl;
}


else if (x == 4)

{
cout << "\t| " << plc4 << " | " << plc5 << " | " << plc6 << " | 4 | 5 | 6" << endl;
}

else if (x == 7)

{
cout << "\t| " << plc7 << " | " << plc8 << " | " << plc9 << " | 7 | 8 | 9" << endl;
}

else
cout << "\t| | | | | |" << endl;

}

cout << "\t-------------------------\n";

if (plc1 + plc2 + plc3 == 264 || plc1 + plc4 + plc7 == 264 || plc3 + plc6 + plc9 == 264 || plc7 + plc8 + plc9 == 264 || plc3 + plc5 + plc7 == 264 || plc1 + plc5 + plc9 == 264 || plc4 + plc5 + plc6 == 264 || plc2 + plc5 + plc8 == 264)
{
cout << "X wins!\n";
break;
}



//////////////////////////////////////////////////////////////////


// if (mode == 1)
//{
cout << "\nO's turn: ";
cin >> plaO;

system("CLS");

switch (plaO)
{
case 1:
plc1 = 79;
break;
case 2:
plc2 = 79;
break;
case 3:
plc3 = 79;
break;
case 4:
plc4 = 79;
break;
case 5:
plc5 = 79;
break;
case 6:
plc6 = 79;
break;
case 7:
plc7 = 79;
break;
case 8:
plc8 = 79;
break;
case 9:
plc9 = 79;
break;
}

// }

/*
else if (mode == 2)
{
if (plc9 = 88 )
plc5 = 79;
system("CLS");
}
*/


}



cin.get();
cin.ignore();

return 0;

}


[/spoiler]

I know a lot of people advised against learning c++ as a first language, but this is exactly I'm searching for - a challenge in terms of self discipline for the mind, learning new concepts to play with and interact. As the title says, it's not the complexity that scares me, it's the fact that I feel I have a total false approach on how I'm thinking. This book that I'm reading (jumping into c++) is indeed teaching me how to code (syntax and all), but it doesn't teach how to become more structured or coherent in your code.

My objective and final question

I want to program to keep in mental shape and to explore a totally new world for me, and in the same time have fun. I enjoyed writing the tic tac toe game. It was a revelation for me on how even a simple game can work. Personally I enjoy roguelike type of games very much (Dwarf fortress, rogue survivor, FTL, IVAN, Incursion, Liberal Crime Squad etc.) and I would look forward to develop some simple games like this to begin with - this being said, I don't fancy super graphics and all for practical purposes.

My question: How can I learn to be more concise in coding and to think more logical ? To properly implement whatever simple or complicated idea into code ? I'm the kind of person that believes in results by practice but the problem is I don't know what to practice. Sure I can continue coding and learning new "tools" that I can use, but I'm afraid I'm developing (or rather, I already have) a very messy method of approach. Would reading lecture on theory of coding help in this case ? Or maybe, going back, way back into the basics would help me understand the present better ? Like learning assembly code and how it works ? Or learning C ?

I plan to take this learning process slowly, constant and systematic, so I do not feel like there is a rush - I want to enjoy the ride, even if there are no immediate results to experience.

Again, thank you for your time reading this and I'm looking forward to read any post that lands on my topic!

Bonus question:

[spoiler]

Anyone who cares to join this discussion could also write at the end of his post, the answer to this question of which I am greatly interested:

"Do you think we are divided between leftists and rightists thinkers? just as well as we are left handed or right handed?"

[/spoiler]

What does the program do?

It's good to see your program code and that you're learning, when you share code with others though comments are great for conveying intent :)

Also you can use clrscr() instead of running "cls" :)

Keep going!

Thank you for the question Brian - the code is there just to exemplify my (non) programming style. Sorry for being misleading, but I am currently not willing to discuss on how the code could be improved (I'm sure there are dozens of possible improvements!).

You could just paste it in a c++ compiler if you wish to see what's it all about :lol:

, but I am currently not willing to discuss on how the code could be improved

But that is precisely the answer to your question.

How do you improve your ability to write more consise code and to think more logically?

By reflecting on and challenging what you are currently doing.

Practice on itself means next to nothing. Hammering random words on a keyboard in order to fill 300 pages every day does not mean you become better a writing a coherent story with interesting characters. For that to happen, you have to try, fail, and improve. Mastery takes both practice and effort.

This is a 2-part issue:

First, there must be something to reflect on and challenge. In order for this to be true, you have to make stuff. This is the practice part you mentioned yourself.

Secondly, you must look for improvements in the efforts you've made. This is a lot more open-ended, and can take on many forms. For example, just looking over your own code with the knowledge and experience that came with writing the entire piece of code -- "this piece of code would have been easier if I had taken this other bit of code into consideration first. I should remember that.". Input from others can also be invaluable here, as they can expose new ways of thinking -- or at least speed up the process of you getting there on your own. Either from feedback ("you could rewrite this part like this"), or by looking at code others have written to solve the same problem.

The question remains on how to pick new things to learn -- but here I in general feel that any answer is a good answer. As long as you keep trying new things, you will learn new things. Two people might not learn the same things at the same time, but they will still be picking up new skills. It's like asking "once I know the basic words and grammar in a given language, what are the best words to learn?". There is no always-correct answer, and it will depend on your goals (and what you find interesting, for motivation).

That said, at a beginner's stage, you should definitely progress through a few books aimed at beginners, as they will "force" you to encounter problems and solutions you might not do on your own, and which are vital when trying to approach more complex problems.

Lactose, v1Xus, thank you for the reply!

I enjoyed reading your comments - quite engaging and encouraging.

Hm, please forgive my second reply, I was very tired and didn't actually have the time or a rested mind to fully explain what I meant.

I was a bit scared that this topic might derail to "Let's help him improve his tic tac toe code". Also, by all means I am not afraid or irritated by critic (I hope it didn't look like that), hence I actually pasted the code to be seen by everyone, being aware that that is no piece of code-art.

And Lactose, you are right - exactly this (discussing with others and sharing experiences) is one of the strongest methods to improve.

Sill, as mentioned, I am interested to find other approaches of how to learn programming and how to apply them, rather than turn the topic into a very specific discussion revolving around my upper code. Here is an example of what I mean, and I've found on the internet:

"Every program that has ever been created can be reduced to three key phases: input, processing and output.

• Input comes from humans in some form or another. It may be mouse-clicks, key presses or data like numbers, names, etc. Without humans, there is no need for a computer, much less a computer program.

• Processing takes that human input and cooks it in some pre-determined way.

• Output is the result of processing and it is usually presented visually in some fashion."

(http://www.kathekonta.com/rlguide/index.html)

I found that passage very insightful, and gave me a raw idea on how programming patterns should look like.

Honestly coding is very similar to math in style as well as execution.

You can talk about the theories related to math and numbers all day long, but at the end of the day the way you generally learn to math is by reading, writing, checking your answers and repeating. You learn by repetition and memorization and over time you build a sort of mental encyclopedia of how to put together math problems and the steps to solve them.

Coding is similar. We can tell you all day about coding "theory" but the best way to learn to make programs is to make programs, and to see where they fall short and how they can be improved.

For instance your code could be improved quite a few ways but one of the simpler ones I can think of would be to use arrays for some of the variables instead of typing out uniquely named but similar ones. If you go read about arrays and how they work, and change your code to use them, then you just learned something. Now you'll remember arrays as a tool and probably start seeing other uses for them as well.

If you want to make games then get reasonably comfortable with the language. Start making little text based games, think of how to improve them. Eventually you can move on to the roguelike you want to work on.

To improve as a coder, I like to read books, read articles, and put the ideas I read into action. It's only through that feedback loop that the information truly goes in.

(Another way to improve, although I don't enjoy it, is to have my code reviewed by others. No matter how good I think I am, there is always something that could be improved, whether a small thing or a new way of looking at a problem.)

Programming (and math too) is about inventing a solution to a problem, in particular a verifiable solution.

For example, I have the problem of "what is the sum of the numbers 1 to 5?". "15" is the solution, but it does not indicate how I arrived at the solution. "1+2+3+4+5 = 15" is also the solution, but this time I also wrote how I got the answer. Under the assumption you also know what "+" means, you can read what I did, and agree or disagree with how it was computed. You can also do that same computation yourself, and verify that your answer is the same as my answer.

Either solution does not say how I arrived at it, it's answer to the question, nothing more. There is a magical jump from the problem to either solution. I believe this is inevitable. I cannot explain why "+" is needed to arrive at the solution, and why "*" doesn't work. I just know it works, I can tell you that it works and I can show you how to do it. You can agree or disagree. In the latter case, you likely also know where it fails, at least for 1 case.

Either way, by seeing the problem and the solution, you have learned something. In your head, information was added that "sum of numbers" is related to "+". If you already knew the problem, my solution was compared with the set solutions you already have for this problem, and you found you also already knew the solution. That solution is now a bit further enhanced as "the ultimate" solution to this problem.

So we transfer knowledge and solutions to problems without actually understanding how we arrive at the solution.

There are all these creativity courses and techniques, but in the end, it's the magic in your head that connects two separate ends to a new connection: "He, I know this problem Y, which looks a lot like problem X I am doing now, and Y has solution Z. Would it be possible to make a new solution Z' that could bring me closer to the solution of X?" and you try to make Z'.

Sometimes it works, and sometimes it fails. Either way you learn new facts about problems and solving them.

I think the only way to get better is to expand your knowledge about problems and their solutions. Books do that for common problems and solutions, scientific papers do that for very specific problems. Discussing problems and solutions with other persons does that too. The quality varies a lot, but it gives often a much wider array of solution directions.

How does programming fit in here? Simple, the end-result of programming is code. Code can be seen as an elaborate description of a solution. When you show code to someone else, you're showing a solution to a problem. When you read code, you see other, previously unknown solutions to problems.

You might consider this book regarding how to organize programs. Honestly, I haven't read it. It's on my to-do list but I haven't gotten to it yet. But you said you wanted to learn more about organizing code and such.