Some more information about your game would be useful e.g.:
1. Is it single player or multi-player?
2. What is an actual resource. What sources are there and what sinks?
3. Is the value of the currency fixed? Are you modeling it based on something? How does it enter and exit the world?
Anyways, more specific questions would help get the discussion rolling.
I kept investigating, placing breakpoints and playing the game, but nothing happened. It seems it was a completely useless class, I commented it all out and no compiler or linker error.
I mean, I don't want to say the code is bad, because I'm a novice and the game works. But dammit...
Actually you made good progress. You figured out that the class wasn't needed. If I was in your shoes at that 'aha' moment I would feel some (perverse) satisfaction. Determining what parts of the code aren't used or are not relevant is equally important to your goal.
About what is good documentation and bad documentation... I've never written a big document (like what doxygen generates) but I have never been in a large project before either, so I guess I just have to get used to the way doxygen wants me to document stuff. Anyways, about comments. In my opinion, when you create a class or function, there is a minimum of comments that it needs: 1. what is this class supposed to do (and what things isn't) 2. who is supposed to call it, and with what kind of parameters (nothing exhaustive) 3. maybe explain how it does it if it takes some unexpected approach to optimize it or something like that
Good documentation (inline code comments) includes why something was written the way it is. I like seeing comments like:
// Don't remove this line because otherwise component X will crash (bugzilla-2152)
Good comments answer what when it isn't apparently obvious. E.g. the comment /* Use Newton-Raphson algorithm */ at the top of the function is all that I need to know and is an excellent comment. Another good comment:
long duration; // in msec
Bad comments (apart from obviously incorrect information) is how something was written and sometimes the what. For example:
i++; // increment i [BAD]
myDict[i] = name; // place name into the dictionary [BAD]
I can determine that by looking at the code directly thanks.
Finally a good comment says the who.
// TODO: fixme [BAD]
// TODO-JS: fixme [GOOD]
With the second comment I know that my colleague John Smith is the one who I should put my hands around his throat... er go talk to.
My question: besides reading and debugging and tracing the code in the debugger... what else can I do?
Sometimes documentation can be a bad thing i.e. when it is incorrect. If I were you I would look into some kind of automated tool that could parse the code and show you its static structure preferably in a graphical format. Knowing the class hierarchy, the dependencies, and any tangles from a high level would go a long way in helping you determine what the heck is going on.
So in desperate help, I ask you to prove me false. I ask you to rebuttal each and everyone of these statements. My mind is going crazy these last few nights. The more I think about it rationally, the less I believe.
In my limited time here on this earth, here's my advice...
Why all the fear? Don't be afraid to question the very foundations of your belief systems. Even the things that you may have been taught that if you disbelieve you'll go to hell, be excommunicated, etc... For example if you're Catholic, you'll have to question if Mary was really a virgin, or if that's really Christ in the bread.
These aren't your beliefs, they've been thrust upon you by well-meaning parents, religious authorities, and countless others before you...
Until you can cross that threshold, you'll never know what's beyond. The funny thing is that God (if you believe in him) works in mysterious ways and even after crossing over, it doesn't mean that you need to abandon your faith that you grew up with. Sometimes you just see with new eyes and can now filter the hokey pokey from what really matters.
MAEnthoven, you have been very helpful and I thank you for your opinions and advice. I will update my resume accordingly. As it turns out, I have a lot more interviews now. I guess it took time for them to review and screen resumes. Now I have to prepare for the interviews. I thank you again for your help. I owe a lot to this community.
Congrats on your interviews. As long as you're getting them your resume is doing its job.
Original post by AntiGuy I'm wondering what people think about combat systems that rely heavily on blocking/guarding? Does it feel like a burden? Do you usually just hack away at the opponent with little care about defense? Does it make the game more difficult to control?
The devil is in the details. At the simplest level, blocking might be a decision on whether or not to go one-handed with a shield (sword-and-board) vs two-handed (think polearm or big weapon). After making that choice I don't have to micromanage where I place my shield because the engine takes care of the all the calculations. It's a simple balance of defence vs offence.
Or you can design your game where you need to control your sword arm and your shield arm separately. If balanced correctly then there will be monsters that you must fight with a shield that you would have no chance without and accurate timing is key to winning the fight. Perhaps you might fight a high-damage, low hit point monster that is easier to take out with a two-handed weapon.
The first mechanism works better in MMOs and games where the player controls multiple characters. The second mechanism makes more sense for FPS style games.