Well for modding, what would you describe something like multitek.txt where you can modify values and those have an effect ingame? Aren't those values member variables of some class or they just regular variables?
That's a data file. How it gets loaded into memory and the structure of the program is a completely different question. I would choose to store the tech info as members of a struct (or class), and have an array of such structs. The tech data will be present throughout the level, and is of likely variable size, so it's more likely to be stored in a data structure on the heap, rather than local or global variables. Consider for a moment how you would store that data as non-member variables? It almost doesn't make sense when you consider how much data is being loaded. You would need a lot of variables to store that much data. Trying to store the data without a systematic way of putting it into data structures would be a nightmare.
What do you mean by hooks in the code (I understand the concept, but have no idea how one would code a "hook" in); I ask because I'm very interested in making a game moddable as it really helps to extend the life of a game?
Pointers.
It's very easy to replace a pointer. It could be a function pointer, or an object pointer. It can be a simple atomic memory write to replace an entire component of a game. The game might even be designed with extensibility in mind and allow for registration of event listeners. That might be implemented as having a method to add a pointer (to a function or an object) to a list of event listeners. When an event happens, all listeners are notified, either by calling the function, or calling a method on the object.
An important topic for this is interfaces. An interface as basically a class that contains no data members and only pure virtual functions. Another class then inherits from the interface and provides an implementation for those virtual functions, as well as defines the needed data members. Any class that implements the same interface can be used in place of any other class implementing that interface.
The COM (Component Object Model) documentation actually gives a very good description of interfaces, which are really at the core of COM. COM has been deprecated though, and all the other gory details outside of interfaces are not quite so useful now. The interface part is still quite useful and widely applicable. They are a fundamental programming concept. The rest, GUIDs, registration, instantiation, error handling, late binding, interprocess communication, and so on, not so much. Those are just the gory details of the COM implementation, which attempts to solve all kinds of problems you likely won't encounter.
As for the semicolon thing, well I suppose because that's simply how the grammar was defined. The semicolon ; is a statement terminator. The braces {} as used in an if/else statement, or a for loop, are a compound statement. The braces already implicitly terminate a compound statement, which grammatically groups a bunch of statements into one (compound) statement. Contrast it with an if/else statement that doesn't enclose the branches in a compound statement, and does need a semicolon to terminate the branch statements.
I guess one simple rule, is whether or not something can follow the close brace. For if/else and for loops, or function bodies, no there is nothing that can grammatically follow which applies to the brace block. For struct and class definitions, you can also declare a variable of that type at the same time, and so you need the semicolon to close it off. Similarly, a do/while loop has the post-test condition after the closing brace, and needs a semicolon.
As an exercise, try writing a double nested if/if/else with/without blocks and semicolons. Those semicolons can change the meaning of the code, possibly causing it to not compile.
Also as an exercise, try looking up the do/while(0) macro idiom, which wraps the contents of a macro into something statement like that must be semicolon terminated. It's important when trying to use some macros in the context of an if/else statement. The repercussions become clear after playing with the above exercise.
