Once my code gets to this size it gets hard for me to keep track of stuff and its harder for me to make things work properly.
|
You need a design.
I think its actually a good idea to keep rewriting this until its coded properly. I mean im not trying to get a job in programming or anything, i just want to learn enough to be able to code a 2D game in SFML without running into too many snags.
|
You still need a design.
The single page homework assignment with a handful of bullet points of things to do is fairly easy to "wing it" without doing much of anything. You write and debug in a single session, hand it in, then forget it.
But if you can't instantaneously visualise the whole program in your head, then you need to start writing some stuff down.
See seeplus's post on UML.
You don't need to go to extremes, but a few hours sketching out the major classes and their relationships will serve you well when implementing the code.
A good thing to have is an A6 pad / index cards / postit notes (anything approx 4"x6"). On each one, you write out a class.
You don't have to list everything, but you should capture it's essential points.
+--------------------+--------------------+
| Class Name |
| One line description of it's purpose |
+--------------------+--------------------+
| Member Functions | Member Variables |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
+--------------------+--------------------+
|
If it's not fitting on the card, that's a hint you need to be splitting the class up into smaller units.
You start with user action like "User wants to fire the pistol".
Right there, you may see
- an abstract class called weapon, and a specialisation of that called pistol
- the need for a 'fire' method (or perhaps more generally, use).
- the need for a consumable resource like ammunition.
Guns, bows have ammunition that can run out (or maybe it doesn't, it's your program).
Swords have indefinite use.
Then you think about other things your user wants to do.
The point of all this is that you can quickly revise your design in minutes.
When you're done, you should be in the position where you can mentally walk through your class structure given an action like "fire pistol".
You don't embark on a long journey without looking at a map.
Don't code large programs without a design - it's your map to the code!.