# I AM SO SICK OF FAILING!

This topic is 4172 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I guess...I'm just not cut out to be a programmer. This is my 5th failure at creating a game now. All of these times I've had to ask you guys to help with one thing or another, and the damn thing still wouldn't work. I can't even get a simple game of tic tac toe to work. And it's always something stupid like "you used = instead of ==" or "you set this up completely wrong." Why does nothing work for me?! I don't just quit when one thing goes wrong though, I'll spend like a month working a project that seems to take the rest of you about 2 days (and that's the complete beginners, I've taken programming classes and got As too). Is there some sort of magic trick that you're pulling here...or have I just completely lost it? Alright...I want to try again, honestly. This is what I want to do with my life. But why does it have to be so hard to do such simple things? Look at this code for my tic-tac-toe game, and some one tell me how you would approach debugging it..because I can't see anything. I've got it to draw what I want initially, the array gets set up, I can click, but it will only draw Xs when it feels like it. My take on this was either in my detection for clicking in the squares, or a syntax issue somewhere. Here is my code in it's glitchy, ugly completedness:
//////////////////////////////////////
#ifdef WIN32						// Only way this will compile for some reason
#pragma comment(lib, "SDL.lib")		//
#pragma comment(lib, "SDLmain.lib")	// Dunno what this does...
#endif								//
//////////////////////////////////////
#include <SDL.h>
#include <iostream>

enum players {one = 1, two = 2} player;
int boardarray[3][3];
bool Won();
int GetCord(Uint16 x, Uint16 y);

int main(int argc, char * argv[])
{
player = one;
boardarray[3][3] = 0,0,0,0,0,0,0,0,0;
if(SDL_Init(SDL_INIT_VIDEO)) exit(1);
SDL_WM_SetCaption("Tic-Tac-Toe", "Tic-Tac-Toe");
SDL_Surface * screen, *board, *X, *O;
screen = SDL_SetVideoMode(500, 600, 0, SDL_SWSURFACE|SDL_ANYFORMAT);
SDL_Rect square[3][3];
for(int k = 0; k < 3; ++k)
{
for(int l = 0; l < 3; ++l)
{
square[k][l].h = 95;
square[k][l].w = 93;
square[k][l].x = 103 + k * 100;
square[k][l].y = 106 + l * 100;
}
}
if(board == NULL) exit(2);
int x, y, z;
if(SDL_BlitSurface(board, NULL, screen, NULL)) exit(3);
SDL_UpdateRect(screen,0,0,0,0);
SDL_Event action;
for(;;)
{
if(!SDL_PollEvent(&action))
{
if(action.type == SDL_KEYDOWN)
{
if(action.key.keysym.sym == SDLK_F2)
{
if(SDL_BlitSurface(board, NULL, screen, NULL))exit(4);
SDL_UpdateRect(screen,0,0,0,0);
for(int i = 0; i < 3; ++i)
{
for(int j = 0; j < 3; ++j)
{
boardarray[j] = 0;
}
}
}
else if(action.key.keysym.sym = SDLK_ESCAPE) return 0;
}
else if(action.type == SDL_MOUSEBUTTONDOWN)
{
if(action.button.button == SDL_BUTTON_LEFT)
{
z = GetCord(action.button.x, action.button.y);
if(z > 0)
{
y = z%3;
x = z/3;
boardarray[x][y] = player;
if(player == one)
{
if(SDL_BlitSurface(X, NULL, screen, &square[x][y])) exit(5);
else if(player == two)
if(SDL_BlitSurface(O, NULL, screen, &square[x][y])) exit(6);
}
SDL_UpdateRect(screen, 0, 0, 0, 0);
if(player == one) player = two;
else player = one;
}
if(Won())
{
for(int i = 0; i < 3; ++i)
{
for(int j = 0; j < 3; ++j)
std::cout << boardarray[j] << ' ';
}
break;
}
}
}
}
}
return 1;
}

bool Won()
{
int x = 1;
if(player == two) ++x;
if((boardarray[0][0] == x) && (boardarray[1][1] == x) && (boardarray[2][2] == x)) return true;
if((boardarray[0][2] == x) && (boardarray[1][1] == x) && (boardarray[2][0] == x)) return true;
if((boardarray[0][0] == x) && (boardarray[0][1] == x) && (boardarray[0][2] == x)) return true;
if((boardarray[1][0] == x) && (boardarray[1][1] == x) && (boardarray[1][2] == x)) return true;
if((boardarray[2][0] == x) && (boardarray[2][1] == x) && (boardarray[2][2] == x)) return true;
if((boardarray[0][0] == x) && (boardarray[1][0] == x) && (boardarray[2][0] == x)) return true;
if((boardarray[0][1] == x) && (boardarray[1][1] == x) && (boardarray[2][1] == x)) return true;
if((boardarray[0][2] == x) && (boardarray[1][2] == x) && (boardarray[2][2] == x)) return true;
return false;
}

int GetCord(Uint16 x, Uint16 y)
{
if(400 > x > 105 || 400 > y > 105) return -1;
if(x < 205)
{
if(y < 198) return 1;
else if(298 > y > 203) return 2;
else if(398 > y > 303) return 3;
else return -2;
}
else if(x < 305)
{
if(y < 198) return 4;
else if(298 > y > 203) return 5;
else if(398 > y > 303) return 6;
else return -2;
}
else
{
if(y < 198) return 7;
else if(298 > y > 203) return 8;
else if(398 > y > 303) return 9;
else return -3;
}
return -4;
}



##### Share on other sites
You may want to try Python/PyGame. It takes out a lot of the crap that is easy to screwup and not really relevant to what you're trying to do. When you get a handle on that, you can move back into C++ if you're feeling frisky. Even if you don't know Python yet, you'll be more effective with Python/PyGame in a week than you are now with C++/SDL, I promise you.

##### Share on other sites
Quote:
 Original post by CarlSagansMyBoyYou may want to try Python/PyGame. It takes out a lot of the crap that is easy to screwup and not really relevant to what you're trying to do. When you get a handle on that, you can move back into C++ if you're feeling frisky. Even if you don't know Python yet, you'll be more effective with Python/PyGame in a week than you are now with C++/SDL, I promise you.

I took python, but even the teacher of the class couldn't get the language to work have the time. So I guess you could say I've had a bad experience with it, and that's why I don't use it. I do have PyGame and Python though.

##### Share on other sites
Hey, my first suggestion is not to take failure soo hard. It isn't really even failure, unless you give up and even then it can hardly be called failure. You still learn something from each "failure", and if that is your objective at the end of the day then you are succeeding. Even if it is not exactly the way you hoped to start with. Everybody started somewhere, and I certainly remember when I started all the silly mistakes I made (not that I am coder superman now)!

I only had a quick glance at your code. What IDE are you using?

If you are using visual studio, it has an excellent debugger built right in. It will let you make single steps over code, examine the value of variables and all sorts of things like that.

I suggest that you spend a little bit of time working over your ide to find the debugger features (like breakpoints). I would go over this now but I don't know what IDE you are using.

Best of luck, you'll make it through!

##### Share on other sites
Quote:
 Original post by maxpenguinHey, my first suggestion is not to take failure soo hard. It isn't really even failure, unless you give up and even then it can hardly be called failure. You still learn something from each "failure", and if that is your objective at the end of the day then you are succeeding. Even if it is not exactly the way you hoped to start with. Everybody started somewhere, and I certainly remember when I started all the silly mistakes I made (not that I am coder superman now)!I only had a quick glance at your code. What IDE are you using?If you are using visual studio, it has an excellent debugger built right in. It will let you make single steps over code, examine the value of variables and all sorts of things like that.I suggest that you spend a little bit of time working over your ide to find the debugger features (like breakpoints). I would go over this now but I don't know what IDE you are using.Best of luck, you'll make it through!

Well thus far, none of my programs have done what I want them to as much effort as I'd put it them. My biggest accomplishment has been getting SDL to work with Visual Studio. Which was hard! I've tried using a couple of the features on my debugger, and using some printlining. Yeah, this solved some basic stuff, but never my biggest issues. I don't really get most of the stuff in Visual Studio, but it's a pretty big program, and to be honest, I only like it for writing code, compiling and running programs in it is just a mess.

##### Share on other sites
Visual Studio can be very daunting, all of the great stuff it does for you though is well worth the effort.

You have to help yourself here, I cannot magically pull the answer out of somewhere. I have never used SDL, but from "else if(action.type == SDL_MOUSEBUTTONDOWN)" it looks fishy to me. What is the Z for?

Put a break point there. Run the program. Click the button. See what it does (use step into/over to move through the program one step at a time), what did you expect it to do? Figure out what is different between what it IS doing and what you EXPECT. There is your bug.

People always make mistakes, the most brilliant programmer ever doesn't write completely bug free code (especially in projects 100 or 1000 times more complex than your project). This is why learning how to use the debugger is such a massively important skill (well, aside from actually learning c/c++). I spend probably 20-40% of my day in the debugger stepping through code, tracing down bugs in my 100,000+ line project.

Good luck, HTH.

BTW - I can't wait until they bring back Futurama [grin].

##### Share on other sites
well, I'd e willing to glance over it and figure out what may be wrong...if you can tell me how to get SDL working with VS. do you use 2005 express? if not, don't worry about it, I'll still try my best to figure out whats wrong.

##### Share on other sites
maxpenguin's right. Debugging is a skill you have to have... and it doesn't come very easy. I think you're just being way too hard on yourself. Programming takes a lot of patience and even if you are VERY patient, it can still be excrutiatingly frustrating. Don't look at your failures as failures. Just look at it as the same thing we all go through and find your way through it.

If you're really serious about this (and you really seem to be) get The Pragmatic Programmer. It explains a lot about programming practice and may open your eyes to what the everyday pro has to go through. Hehe, it's not just you. =b

##### Share on other sites
Quote:
 Original post by maxpenguinVisual Studio can be very daunting, all of the great stuff it does for you though is well worth the effort.You have to help yourself here, I cannot magically pull the answer out of somewhere. I have never used SDL, but from "else if(action.type == SDL_MOUSEBUTTONDOWN)" it looks fishy to me. What is the Z for?Put a break point there. Run the program. Click the button. See what it does (use step into/over to move through the program one step at a time), what did you expect it to do? Figure out what is different between what it IS doing and what you EXPECT. There is your bug.People always make mistakes, the most brilliant programmer ever doesn't write completely bug free code (especially in projects 100 or 1000 times more complex than your project). This is why learning how to use the debugger is such a massively important skill (well, aside from actually learning c/c++). I spend probably 20-40% of my day in the debugger stepping through code, tracing down bugs in my 100,000+ line project.Good luck, HTH.BTW - I can't wait until they bring back Futurama [grin].

It might have something to do with the SDL_MOUSEBUTTONDOWN. That's basically supposed to check if a mouse button is clicked down and then from that run through, get the location, check for a legitimate move, etc. The z in the program is returned from the GetCord function which gets a code related to the part of the board and then x = z%3 and y = z/3 translates that into parts of the boardarray array so that the one piece of the board is changed.

##### Share on other sites
It's not just you. It's programming. That's what it is: Writing some code, then figuring out why the code doesn't do what you think it should. :P

In my experience, at least. Maybe there are brilliant (or just very experienced) programmers who just write the code and have it work the first time. But I think for most people there's a lot of trial and error involved.

Edit: That said, you may not be cut out to be a programmer... which is to say, in light of the frustration and stress it entails, it may not be what you really want to do with your life. Personally, I know I couldn't be a programmer if I had to do it eight hours a day, with deadlines involved.

YMMV, of course.

[Edited by - Logodae on September 19, 2006 12:28:31 AM]

##### Share on other sites
Don't get discouraged! C++ is a bitch to start out with. I've been working with it for four years now, and I'm still occasionally posting questions about proper syntax.

Quote:
 //////////////////////////////////////#ifdef WIN32 // Only way this will compile for some reason#pragma comment(lib, "SDL.lib") //#pragma comment(lib, "SDLmain.lib") // Dunno what this does...#endif ////////////////////////////////////////

This makes your program link properly, not compile. Compilation is basically syntax checking (among other things). Linking is where the program connects the header files (.h or .hpp files where functions and classes are defined) with definition files (.c or .cpp files where functions and classes are implemented). This tells the linker to link the SDL and SDLmain libraries, which contain, basically, the implementation of these libraries. Another way in MSVC++ to accomplish the same thing is to go to Project/Properties/Configuration Properties/Linker/Command Line and enter this into the additional options box:

SDL.libSDLmain.lib

If it gives you a warning about msvcrt, add this line to the end of the above:
/NODEFAULTLIB:msvcrt.lib

It doesn't really matter which way you do this, though - your way works just as well, for your purposes.

Your message-handler loop is pretty messy. Try revising it along these lines:

int clickSquare;SDL_Event action;for(;;){    //Will retrieve messages until there are none left, then break out of the loop.    while(SDL_PollEvent(&action))    {        //Read up on switch statements if you don't know what this does        switch(action.type)        {            case SDL_KEYDOWN:                if (action.key.keysym.sym == SDLK_F2)                     //Reset the board using the same code you've got.            break;            case SDL_MOUSEBUTTONDOWN:                //Coord is short for Coordinate - you may want to revise spelling :)                /*Also, this function should probably return the actual offset (0-8) of the board square to change, rather than the arcane stuff you've got going on in the GetCord function right now.  I'm assuming you did that with this example code*/                clickSquare = GetCoord(action.button.x, action.button.y);                //Check to make sure this isn't an already-marked square                if (boardarray[clickSquare] == 0)                 {                     boardarray[clickSquare] = player;                     if (player == one) player = two;                     else player = one;                }                        }    }    if (Won()) //Doesn't need to go in the event loop        //Do what you're already doing    //Note that I extracted all your drawing code from the event loop above.    //I'm going to stick it down here, instead.  Also, we're redrawing the screen    //Every frame instead of just when a new square gets marked.    //First, clear the screen to black.    SDL_FillRect(SDL_GetVideoSurface(), NULL, 0);    //Next, draw the board    for (int y = 0; y < 3; ++y)    {        for(int x = 0; x < 3; ++x)        {            int square = boardarray[y * 3 + x]; //Get the value at the offset            //the value of 'square' is now equal to whatever was stored at            //(x, y) on the board.  Go ahead and do whatever drawing you want        }    }    //Swaps the video buffer so that we can see new changes.    SDL_Flip(SDL_GetVideoSurface());}

You'll also need to revise your GetCord (or, proper spelling, GetCoord) to use the basic idea I presented above to return an offset from 0-8 for the proper offset of the square on the boardarray. Also, you can't just drop this code in - its purpose is to give you an idea of some changes you could make. It's certainly not as clean as it could be, and may have some errors, since I typed it directly into the post box. Finally, you'll want to change the line last argument in your call to SDL_SetVideoMode to SDL_DOUBLEBUF.

In summary, it would be best if you had made the tic tac toe game in text mode first, so you don't have to worry about dinking around with the STL. Make it really clean code, and make sure you understand how *everything* - structure, logic, syntax - works. Then you will have better luck trying to make a game with graphics. It will help, when you use an API like SDL, if you understand what all those functions are really doing. I think your problem is that you haven't quite understood how all the structure or syntax of C++ that you're trying to use is supposed to work. My advice to you is to try and make tic tac toe in text mode. Once you've got it working, go back and figure out ways to make the code cleaner and easier to understand. Once you've got the game working, it should be a simple manner to throw some graphics over it.

Also, I cannot stress this enough: COMMENTS! USE THEM FREQUENTLY AND WELL! The way your program should be commented is that if you deleted all the code, and just left the comments, someone else would be able to understand the structure and design of your program.

Good comment:

Set the flag that the game has been won, so that we can stop the game from getting changed until the player resets it.

Set the value of b_victory to false.

Hope this is enough to help.

##### Share on other sites
Hey, we all experience failure.. sometimes its best to step away for awhile and come back later. I've had so many problems that seemed huge to me, but are very simple to others. But think, we're here to help! As long as you are willing to learn and explain the situation, use us all as a helpful tool for learning. We cant teach you everything, but the mistakes you make can be corrected by us, so just keep on codin' :D

##### Share on other sites
What it boils down to in the end is experience. Someone who has been programming for a long time knows more of the bends and quirks of programming than a novice. This applies to almost all things in life. Keep working and you will gain experience. I believe you can do anything if you set your mind to it.

##### Share on other sites
start simpler.

Get tic-tac-toe working with ascii graphics first, just put SDL aside until you get that working. Ok?

I spent about two years working in C and then C++ before I even attempted graphics. I started almost on day 1 in Qbasic with graphics because it was easy, but linking libs and stuff isn't really intuitive for someone who is not only learning the language, but also how to use their compiler.

Maybe set yourself up smaller goals before you start working in graphic librarys of any kind. Stick to the console for now and make a few neat little things and I guarantee you'll have success if you work at it.

##### Share on other sites
Don't give up; keep in mind that you are jumping head first into several different technologies at once, and this can complicate your efforts. For example, you are learning a new IDE, learning how to use it's debugger, learning an external API (SDL), and still learning gaining experience with a new programming language. Each one of these areas will have it's challenges that would be difficult enough on it's own, and combining them all probably only serves to exacerbates your difficulties.

If you aren't using Microsoft Visual Studio, I suggest you try it. Their express edition is free, and while it can be intimidating with all the extra support and features, you can turn off what you don't care about, and deal with only the portions you do. It's free, and it's what everybody uses for professional software development. (And yes, there's all kinds of technology and libraries and windows systems that I don't understand nor have to deal with).

My suggestion to you is learn to use your debugger; it's essential. Printf's may help, but sometimes you really need to scrutinize every step of your program. Programmers are problem solvers; we spend implement algorithms to solve problems, and then spend much more time figuring out what our implementation doesn't work (debugging). Try to focus on smaller scale projects to better learn the technology.

I don't know SDL, but glancing through your code, I noticed some bad logic with your GetCoords() function (which we were asking about); the if(298 > y > 203) syntax does not work as you expect. C/C++ will evaluate the first part of the expression first (298 > y), and that will evaluate to true (1) or false (0); then it will use that result for the 2nd part of the expression, being (true > 203) or (false > 203), neither of which will ever succeed. You meant to write if( y > 203 && y < 298 ) or some variation of that. Common mathematical syntax, but not something the C language handles. Common mistake; and after seeing it here you won't forget it. Of interest, a compiler set to a "high warning level" would probably warn you or that questionable syntax; comparing bools against int's is technically legal, but is generally not what people want to do, and the compiler can catch and warn you when it happens. Of course, on the downside, turning warning levels up too high will also complain about a lot of other picky things that you might not care about.

Hope this helps... It's just going to take time, practice, and experience.

##### Share on other sites
When people find something hard it is usually due to a lack of understanding on some level. This is quite evident in your code. If you take the second line of the main function as an example.

int boardarray[3][3];boardarray[3][3] = 0,0,0,0,0,0,0,0,0;

Now I am not sure what you think that does, but it almost certainly does not do what you wish. Ignoring the basics of the comma operator (which you can look up in any good reference book), the code evaulates to.

boardarray[3][3] = 0;

The rest of your code seems to show some understanding of the maximum accessible element of the array being boardarray[2][2], so you should be able to see that the above line of code is actually writing out of the array bounds, and not initializing the array as you think it is. That is the first example I could find of a lack of understanding of the basic rules of C++, there are probably more.

All I can suggest is finding a good text book. Accelerated C++ is one of the best beginners books.

##### Share on other sites
Quote:
 Original post by BringBackFuturamaAnd it's always something stupid like "you used = instead of ==" or "you set this up completely wrong." Why does nothing work for me?!

Because you used = instead of ==...

[grin]
Seriously though, if that's the kind of errors you run into, I don't see the problem. That's just a matter of habit, like knowing which side of the road you're supposed to drive in. Just something you get used to.

If it was errors you didn't understand, it might be discouraging, but you should be able to handle stuff like that.

Quote:
 I don't just quit when one thing goes wrong though, I'll spend like a month working a project that seems to take the rest of you about 2 days (and that's the complete beginners, I've taken programming classes and got As too). Is there some sort of magic trick that you're pulling here...or have I just completely lost it?

I can't recall seeing any beginners make Tic-tac-toe in two days. Actually I can't recall any beginners making that game at all (At least not with graphical interface and all)

Quote:
 Look at this code for my tic-tac-toe game, and some one tell me how you would approach debugging it

With a debugger. Used one yet?

Other than that, you might consider doing something simpler, something that doesn't involve learning so many things at once. (Hint, stay away from graphics until you're really comfortable with programming. Hint2: You might want to look at other languages than C++)

##### Share on other sites
Hi! I find myself in a state of perpetual beginner gamedev too. Even though I've been programming for like... 12 years... I just can't seem to get a full game together. Anywho, I had a quick scan through your code, and I believe I found an issue. I dunno if someone else covered this, but here goes.

Original post by BringBackFuturama
int GetCord(Uint16 x, Uint16 y){	if(400 > x > 105 || 400 > y > 105) return -1;	if(x < 205)	{		if(y < 198) return 1;		else if(298 > y > 203) return 2;		else if(398 > y > 303) return 3;		else return -2;	}	else if(x < 305)	{		if(y < 198) return 4;		else if(298 > y > 203) return 5;		else if(398 > y > 303) return 6;		else return -2;	}	else	{				if(y < 198) return 7;		else if(298 > y > 203) return 8;		else if(398 > y > 303) return 9;		else return -3;	}	return -4;}
[/quote]

In most of your comparisons there, you are using the normal Mathematical way of expressing a range (ie. 400 > x > 105). As far as I know, this is not valid in C coding. it becomes interpreted as (400 > x) > 105, which will never be true because the (400 > x) can only come out as 0 or 1.

These types of things have to be split up into two comparisons. You can join them with an AND thingy, &&, as follows:

// Original code:	if(400 > x > 105 || 400 > y > 105) return -1;// Revised code:	if( ( 400 > x && x > 105 ) || ( 400 > y && y > 105 ) ) return -1;

Give that a try, fix up the comparisons in that function, and it should work. Like I said, I just had a quick glance through, so there could be something else somewhere, but this should be the big one.

Anyways, like someone else said, things like this can hardly count as "Failures." It's the best way to learn. If you don't make mistakes when you start, then later on you'll never know how to correct them. Just work through them best as you can, and when you're out of ideas, ask around. A lot of the people here are professionals, they do this for a living. Just remember, they went through the same thing as you at one time :)

##### Share on other sites
From what I see, I think the main problem is that you just went too quick into writing games without having at least the fundamentals down. My guess is that you have a very vague idea about the rules of C++, and when you program you type things that seem logical to you and have maybe seen in other places like your math class, and if they compile you just leave them that way. I'd say things like "boardarray[3][3] = 0,0,0,0,0,0,0,0,0" or "298 > y > 203" show that, because I'm sure you haven't seen code like this in any book or tutorial, you just thought it had no reason not to work. Well, they work, but not the way you want them to. It's not a natural language, nor math. It's C++. You have to play by its rules, and believe me it has a crap load of those. It is definately not a beginner friendly language. Even the beginners that will say "But I learned it very easily, and love it!", are simply unaware of the fact that they probably ignore 90% of the language, and don't really have the rest 10% nailed down either. But now that you started it I'm not sure switching languages because you have trouble with your current one is the best idea.

I don't suggest going back to writing guess-the-number games, but I do suggest to slow down. Every time you write a line you're not sure about, go back to your book and check if that is the correct syntax C++ expects. And if it's not, then learn why it is the way it is. There is a very specific reason why "298>y>203" doesn't work. You don't know it yet, but you can't go on not knowing it. And that goes for a dozen other rules and subrules you're probably unaware of.

##### Share on other sites
Quote:
Original post by Queeble
Hi! I find myself in a state of perpetual beginner gamedev too. Even though I've been programming for like... 12 years... I just can't seem to get a full game together. Anywho, I had a quick scan through your code, and I believe I found an issue. I dunno if someone else covered this, but here goes.

Quote:
 Original post by BringBackFuturama*** Source Snippet Removed ***

In most of your comparisons there, you are using the normal Mathematical way of expressing a range (ie. 400 > x > 105). As far as I know, this is not valid in C coding. it becomes interpreted as (400 > x) > 105, which will never be true because the (400 > x) can only come out as 0 or 1.

These types of things have to be split up into two comparisons. You can join them with an AND thingy, &&, as follows:

*** Source Snippet Removed ***

Give that a try, fix up the comparisons in that function, and it should work. Like I said, I just had a quick glance through, so there could be something else somewhere, but this should be the big one.

Anyways, like someone else said, things like this can hardly count as "Failures." It's the best way to learn. If you don't make mistakes when you start, then later on you'll never know how to correct them. Just work through them best as you can, and when you're out of ideas, ask around. A lot of the people here are professionals, they do this for a living. Just remember, they went through the same thing as you at one time :)

Indeed. You just can't do what the OP is trying to do, like that.
This doesn't do what you think either:
	boardarray[3][3] = 0,0,0,0,0,0,0,0,0;
It is rather unfortunate that it will actually compile.
Good to see someone getting into the preincrement habbit right from the start however - nice. If only everyone was taught preincrement first...
I think that the problem is partly that you are pushing yourself too hard. How long have you been programming? For me it's at least 17 years.

Learn your tools. Don't expect to do so in a week, or even a month, however. Learn about a little bit each day. Seek out bits of the language that you don't understand and learn about them. Look at lots of sample code. When you see something that is unfamiliar, hunt around to find out about it. "Do one thing every day that scares you!". Seek out experts and learn whatever tips they offer you.
Quote:
 I have not failed 700 times. I have not failed once. I have succeeded in proving that those 700 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work. --Thomas Edison

##### Share on other sites
Man if i put a nickle into a sock for everytime i screwed up while programming, I'd have a pretty deadly weapon. :P. Screwing up when programming is the name of the game. Of course we dont call it 'screwing up'. We call it the 'debugging phase', which happens in every program. No one gets something working right the first time 100%. There are always typos, silly things you look back on and say 'what the hell was i thinking?'.

But a few things to keep in mind.

1. This happens to everyone. No need to do a backflip.
2. Are you making your programs in baby steps? I see you hopped into SDL. Did you try it in just a console application first? If you do it that way, you can show yourself that you have the game logic down, now you need to worry about making it look pretty in SDL.
3. Making mistakes is probably the best way to learn. Keeping at it and learning from them is one of the most important things you could do. If that "= instead of an ==" really pissed you off, I bet you wont be doing that again. And if you get an error on an If statement again, thats the first thing you will check.

Keep at it and dont give up!

##### Share on other sites
Quote:
 Original post by BringBackFuturamaI took python, but even the teacher of the class couldn't get the language to work have the time. So I guess you could say I've had a bad experience with it

I'd be more inclined to say that you've had a poor teacher with it.

Oh, and programmers fail all the time. Especially the experienced ones. The trick is to keep plugging along and not getting stuck in a feeling of defeat.

##### Share on other sites
Quick question: Do you know how a computer works? And no, I don't mean switch it on and click things with the mouse. I'm talking about the CPU, the chips on the motherboard and the stuff that plugs into it; why, for example, is a serial connection faster than a parallel one? I've found that the really great programmers know and understand this stuff. To take an analogy, suppose you wanted to build a car. The bodywork and interior look easy to make but you'd be buggered when it comes to the engine - unless of course you knew all about engines.

So, my advice is to get an understanding of the way computers work (all CPUs can do is add, compare and move stuff - the more complex stuff is just the simple stuff put together in clever ways). Then work up from there. Start with the classic "Hello World!" program - use it to learn how to use your compiler / debugger and find out how they work. Then try to implement some mathmatical stuff (recursive exponential is a good one). Then look at data structures (linked lists, trees, etc) and learn what their advantages and disadvantages are. Then look at algorithms (qsort, etc) and, again, their advantages and disadvantages.

From your post, you appear to have a drive to do this that I've not seen in some professional programmers - all you need to do is get those foundations sorted out, and the rest should follow without too much difficulty. It's not easy and it won't be quick, but it is fun!

Skizz (25 years as a programmer and still learning).

##### Share on other sites
I really think your biggest (maybe even the only) problem is that you don't programm in C++, you programm in C using C++ Syntax.

You don't use objects, no separated classes, inheritance (though this would not be needed in this game, probably).
Having a clear and logical code structure using the real power of C++ will make your code easier to understand, it will be easy to debug and you will be able to reuse parts of you code, build your own tools library / wrappers which would lead to creating a foundation for any new project you may begin.

##### Share on other sites
Just to let you know, it took me fifteen years of programming to get my first game published (which, incidentally was this). There were a lot of failed attempts leading up to that, but getting it finished and out there was a fantastic feeling. This is my most recently published game and I may even get my first royalty for it soon! There's not much money in game developing :-(

Skizz