Trust me, I found out a long while ago that the 'dream game' is not something to go with first. I want to start from the ground up, I just want a recent, relevant C# tutorial where I can start, and then find some projects to complete.
so I should plan things out very carefully more, should I use pseudocode or flowcharts or uml
A combination of all 3, depending on how big your application is. It is best to visualise everything before you start coding. The amount of times I code something, have difficulty understanding it (drawing with your finger in the air only goes so far!) and then map out everything (coordinates, the next positions, grid squares, calculations) really helps me understand what is going on. Trust me, draw it out on a big sheet of A4!
Back to the original question, I really think you should have taken on repeated advice by now of eliminating magic numbers from you code. This:
if(x>=300 && x <=350 && y>=225 && y <=275)
if(x>=350 && x <=400 && y>=225 && y <=275)
I can only assume means that you are checking for a collision in a top-left quadrant, or top-right quadrant, and then setting font_rect at a new position. I also guess that board_x = true means that you are setting that grid box to no longer accept shapes. I can only assume because it is impossible to tell with properly named variables to represent these coordinates. I am unable to help to the fullest extent if you are unable to provide enough information.
On a side-note, a calculator application might not be as simple as you might think depending on what you want it to do. Alas, it won't work without proper variables..
Where you detect if the character coordinates hit a certain edge. If the character does, you set the coordinates to that of the edge, preventing the character from moving off-screen. The same sort of theory can be applied to the most basic collision type, collision between two rectangles.
You check if the coordinates of one object overlaps those of a second object. If they do, they fire functions that react to this; i.e. walking over gold increases the gold count of the character by 1. A quick example of this is:
int x1, y1, w1, h1; //object one
int x2, y2, w2, h2; //object two
// check if 1 or more of the points overlap
if(x1 < x2 + w2
|| x1 + w1 > x2
|| y1 < y2 + h2
|| y1 + h1 > y2)
// if they do, then react to that event here.
do_function_related_to_collision_here(); // increase gold by 1, pick-up item etc.
This is a good place to start, but doing this all over the code can get lengthy, and messy. At this point you will want to look into encapsulating this into a function of its own, but that can be for further research.
On a side note, you also make use of alot of magic numbers in your code, think about changing these to constants as it will become harder to track bugs later.
Use a for-loop where for each increment, you change the coordinates so that each pyramid is drawn at a certain distance away from the last. This will put them into a single row or column of pyrmaids.
If you wanted a pattern, try using a second for-loop nested in your first. The first can move the pyramids along the X-axis, then the second moves them on the Y-axis. This results in, for example. five triangles being drawn in a column, inner loop exits to outer loop, column start moves to the right. This is repeated until you have 20 drawn on the screen, in 4 columns of 5 pyramids.
When I saw this I thought it was a complete game. However, you have posted your exe for feedback far too early into its development cycle. These issues are ones you should pick out through your own tests and try to iron out. The best way to achieve this is to write down all the rules of Tic-Tac-Toe and tick each off when the exe is able to run them.
What you are likely to do on this current path is upload a new exe every time you make a minor change. After a while, people might be more inclined to ignore it if they think "it's just another exe". What I recommend is that, if you find you are unable to complete one, or more, of the rules and are struggling, present your problem here. Include source code, highlight where you have narrowed the issue down to and use the feedback to work yourself out of the bugs.
Here is a list of bugs I found:
Multiple '3 in a rows'.
Window name as 'Triangle'.
Mouse click near edge of one square places in another square.
Grid too small.
Game does not reset.
Game should show a small text line saying 'Left click... Right click...'.
Work through these and then you should have a basic version of the Game, and post back here on your success.
I had a lot of these similar issues when I posted my code for review. In fact, it was @rip-off who listed me things I needed to change. What I would recommend doing is copying this list into word, and deciding the easiest things to do first, do them, then highlight the bullet point. It shows you that you are making steady progress towards your goal, and keeps giving you that feeling of achievement.
Let me present you with a different way to look at it.
You say you don't know, or don't have a clear understanding however, by learning Java (in my opinion) it seems you are now able to see the (potential) flaws in what you were doing, pre-Java. This is a GREAT thing! You now have a new insight in order to identify where you have been going wrong. Use that knowledge to push through with C++. You can look at your current projects and identify areas which you might say "What the heck was I trying to do there, it would be much better this way!". You then note these down so that, if you come across a similar problem in a new project, you can avoid tackling it in the old way, and implement a cleaner, more concise solution.
If you do go the way of, "I'll learn a new language instead" then you have this great insight, and whilst you can apply it to correctly learning said language, you will actually be holding yourself back a bit. The best way anyone learns is by making mistakes. It's how we treat these mistakes that makes us more knowledgeable. You can either give-in (I'm not saying you are, it's more of a general statement) or, you reflect and build on how to you are going to correct these.
Keep learning Java, keep learning C++, maybe learn Python (only if you have time, or you might burn yourself out too quickly).
Regarding responsibility, you should really take a step back from your code, and probably this project. It might take too long to modify with different naming conventions and changing all the responsibilities however, what you can do is take away the lessons you've learnt into a new project. One where you can start from the ground up, get your names correct, decide on the responsibilities of each class and method. Ask yourself as you code, using the current problem as an example; "I have named this method XXX (DrawText) however, I am processing YYY (brick logic) in here, is it correct?" Of course the two will link in a small way, how can you display text about the number of bricks on screen, if you don't examine the list of active bricks to see which are alive? But is DrawText, a general helper function probably used multiple times, specific to brick logic?
This is a very specific example, but if you generalise as I did with XXX and YYY, then it is applicable to most areas. I would like to point you to an article on this very site about the subject of pre-visualisation, which touches on Responsibilities in a light way that should be easy to understand:
Read these two articles in conjunction with what I have given you, and you should be off to a better start with your next project. Aim to resolve this issue, try and get the text to display, then write down what you did wrong, how you fixed it, and you can use this to identify early issues in your next game.
A final thought; you have been working on Breakout for a long time, and I admire the perseverance, but it might be time to start a fresh. Build your game design with Responsibility and good Naming conventions, and you have an easier time when it comes to coding.
Feel free to ask for any more information,
P.S. I agree with BeerNutts here, make life easier on yourself and use SFML or Allegro instead for your next project. It's a bit of a minefield getting into programming without using a hardware accelerated graphics library such as OpenGL. It's a good step-up once you have the principles of an API such as SFML down, but right now, focus on something simpler. There are a lot of videos on these sorts of libraries such as this YouTube channel: http://www.youtube.com/user/CodingMadeEasy?feature=watch
In addition to JTippetts post, it seems that there are some vague naming conventions. Now these may seem okay to you however, people trying to contribute in assisting you (like myself) will have a hard time navigating the "what does this function do?" minefield.
The method lives() to me should be renamed to something along the line of 'handle lives', 'do lives' etc. At its basic level it should check to see if some lives altering event occurred, such as the ball going off screen or you make contact with a power-up that increases them. Then you increment/decrement 'num' (should also be renamed, paddle_lives would suffice) by the appropriate amount. This would then be included in the portion of the loop JTippetts describes as:
Detect, handle, respond to and resolve collisions and other object interactions
DrawBitmapText would then occur when you Draw the UI Elements. Can I ask, what do the 3 methods brick(), paddle(), ball() do? Are these the same as lives in that they handle the logic for those objects? Does this mean that in your code you effectively repeat their actions more than once per loop? Or, do you remove them for where they were and put them in the new method you think they should be? Either way, it will start to become messy, un-organised and can actually do more damage when problems like this occur.
Remove these methods from you DrawText function, have the function do what it says on the tin, and perform any action related to drawing text. Keep it simple.
Back on topic, I have to agree with stannic. What probably happens is that, when the ball goes off screen, the lives gets drawn for a split-second and then disappears. If you remove the DrawText from lives and move it to the correct position in the loop, untying it from any sort of 'if' clause, it should show the text constantly. I assume that it works for the Bricks code you posted because 'brick[N][N] == true' refers to the brick existing?
When you implement the Splash-Screen, try to ensure that you don't just render it over the top of the game field i.e. the actual game logic doesn't run at the same time. This could lead to the user viewing what they think is the beginning page, but then entering the game whilst the logic has been running and starting out with, for example; less lives than expected, some bricks missing, or even the Game Over message.
What I'm trying to get at here is, now that you are looking at another component (The Menu), try researching into State Machines to break up the code, and ensure not everything is trying to be run at once. It can be as simple as using a Switch-Case to make sure only the Menu runs until the player decides to enter the Game, then the Game runs and the Menu is only accessed again, when the user wants to quit.
A lot of information here, I got a bit carried away. Feel free to ask a question if there's anything unclear.