Every ‘idea’ in your application should be a class. This idea can be the score logic, the database connection, the player, a certain type of monster and so on. A class is something you create objects from, so things like a player, a monster or a window do seems like logical candidates. And they are. But just as well can a class be a more abstract idea, like a scoring system, everything related to the network or a database connection. Or a class could just be responsible for retrieving and updating the data from one table in a database.
Everything that is related to that idea, should be part of the class. Take a score class, for example. The following concepts clearly belong together:
When creating a class, it is a good idea to think about the class itself for a moment. What methods could you might need later on? Maybe you won’t need a reset method, but there’s a good chance you will. Instead of thinking about your application, you should think about the class itself.
Beginning programmers often make the mistake to focus on their application a bit too much. The result of that is a programming session like this:
The problem with this is that within a few minutes, you’re working on three or more classes at the same time. Programming is hard enough as it it! When you’re trying to keep track of the content and changes of different classes at the same time, you’re making everything much harder for yourself.
This is why you should try to focus on the current task: creating the class. Maybe you will implement a few methods you won’t even need later on. That’s OK! It is much harder when you constantly have to revisit your class because you need something which doesn’t exist.
That’s rule number one: think about the class, not about the application.
Rule number two is: logic and interface don’t mix. It’s just a bad idea. We try to make a clear distinction between GUI classes, logic classes, network classes, database classes and so on.
Think about the score class one more time. You could decide that the score will be visible on the screen and implement a score method called ’draw’ to do just that. But later on you need to display the score when the game is over, in a slightly different way. Will you create yet another draw method? Or when you have to line up the drawing of score with the drawing of the current level. Will you add the level to the scoring system? Level management could very well deserve its own class.
A far better approach is to create a method to retrieve the score itself. And write classes for a GUI during the game and a GUI during a game over. Those classes will retrieve the current score and decide on how to display it.
class score {
int points = 0;
void reset() { points = 0; }
5 void get () { return points; }
void inc () { points++; }
}
score Score; // object
10// this class will be used during the game
class overlay {
void draw() {
D.text(Vec2(0, 0.9), S + ”Score: ” + Score.getPoints());
}
15}
// this class draws a gui during game over
class gameOver {
void draw() {
20 D.text(Vec2(0,0), S + ”Score: ” + Score.getPoints());
}
}