|
The forum isn't a very good place to post large chunks of code, as the code formatting is a bit harder to get right.
That said, I skimmed over the code, and without checking it in detail, there are already a few things I would advise:
1. Don't declare all variables up front. In C++, you should go by the idiom RAII (Resource acquisition is initialization - Wikipedia[^] ). That is, declare the variable when you need it, and immediately initialise it with a meaningful value.
2. Don't put everything into a single function, and most certainly not into main. main() should only contain the main control loop of the game, e. g. a simple loop that checks whether you want to continue the current game, start a new game, or exit. Continuing the game should call a function to process the next step or do whatever else your game does until the next check. Then you obviously need some kind of input and output; these should also go into separate functions. And then you need the functions that process your input and change the state of your game.
3. I see an incredible amount of 'else if' statements trying to deal with different input options, but no 'else' statements. This means that while you check for every option, you may fail to check for invalid input (more precisely: for things you didn't check in your if statements). Moreover, you're micxing checks on different variables which makes your program flow extremely hard to follow (and likely incorrect). It is much easier to structure and read your code if you use the switch() statement instead, and provide a default case to catch invalid input.
4. Games like these lend themselves very well to object-oriented programming. You have a character, a shop, a mine, and probably a few other things that can (and probably should) be implemented as a class You seem to be playing as a character who has some gear and can perforem some actions. Equipment comes in different forms, but always have a price and a name; this can be encoded in a class, or a set of classes. E. g.:
class Equipment {
int price_;
string name_;
public:
Equipment(int price, string const& name) : price_(price), name_(name) {} virtual ~Equipment() {} virtual int price() const { return price_; }
virtual string name() const { return name_; }
};
class Helm : public Equipment {
public:
Helm() : Equipment(250, "Helm") {} virtual ~Helm() {}
};
class Pickaxe : public Equipment {
string type_;
public:
Pickaxe(int price_, string const& name) : type_(name), Equipment(price, " pickaxe") {}
virtual ~Pickaxe() {}
string name() const { return type + " " + Equipment::name(); }
};
class Miner {
int balance_;
vector<Equipment*> items_;
bool buy(Equipment const* item) {
if (item->price() > balance_) {
cout << "You only have " << balance_ << "$. You need "
<< item->price() << "$ to purchase a " << item->name() << endl;
delete item;
return false;
} else {
items_.push_back(item);
balance_ -= item->price();
}
return true;
}
public:
~Miner() {
for (auto item_it : items_) {
delete(*item_it);
}
}
void equipHelm() { buy(new Helm()); }
void equipPickaxe(int price, string const& type) { buy(new Pickaxe(price, type); }
};
Note how this design eliminates most of the repetitive parts in your code, and most functions are reduced to one-liners. Also, adding a new type of item now only requires a few lines of code: typically a simple class definition like the one for class Helm, and a new equip*() function in the Miner class.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 20-Feb-20 3:49am.
|
|
|
|
|
Not bad for start.
It is not that uncommon to start what my boss used to called "spaghetti code".
As long as your first code runs you can follow the flow and rearrange the actual code as you go.
The basic concept of the application is what is important.
You can identify the repetitive code and make classes or functions - as long as it continues to compile and run.
Personally I look at writing code and application separately.
And often I do not follow "top down " concept , but look at both application (tasks) and code as kind-off puzzle / mosaic.
Do not get discouraged by "code is too big, hard to follow..." comments.
I do understated that most folks just excpect to "cut and paste and run" posted code and if it does not they get frustrated.
You asked for comments on your coding style and you have received very good ones, if your posted does not compile / run is immaterial.
Now off the soap box and some real advise
When your declare a variable get into habit to initialize it and comment (what is) its purpose.
You are writing code to yourself , but do as is used to do in Chicago
"vote early and often "
comment and over comment what the code does - you will thank yourself later when it gets REALLY big !
Good luck
|
|
|
|
|
Alright, thank you for your reply and your opinion, you motivated me little bit As I mentioned in my topic, I am new to programming and have to learn many things, and as I was learning through I was getting too fast on it to learn new things, I should just stop at one thing and learn it as much as I can. Anyway, thanks for reply.
|
|
|
|
|
Chleba225 wrote: else if(startWay != 1 || 2){
cout << "\nError, try again.\n\n";
}
} //while loop
}else if(marketWay != 1 || 2){ I'm sure your intent was something closer to:
else if (startWay != 1 && startWay != 2)
...
else if (marketWay != 1 && marketWay != 2)
... Otherwise the OR part of the condition would evaluate to true and display the message.
Going one step further, since each of these if/else if pairs are only interested in the values 1 or 2, there's no need to check against those values at the end to determine if the message needs displaying. Just use an else by itself.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
modified 24-Feb-20 12:52pm.
|
|
|
|
|
I tried to build MicroSIP open source at VS 2017 and after solving some other issues, finaly got "Cannot open file 'hid.lib' in microsip".
Severity Code Description Project File Line Suppression State
Error LNK1104 cannot open file 'hid.lib' microsip E:\NybSys\0_Demo_All\MicroSIP\demo2\microsip-master\microsip-master\MicroSIP-3.19.17-src\LINK 1
I am stacked here more than 2 days. please help me.
|
|
|
|
|
|
My C++ compiler is not accepting string as a predefined class. No objects of string class could be created.
|
|
|
|
|
Do you mean the std::string?
Did you add the
#include <string>
|
|
|
|
|
Hello,
some more details would be helpful!
Do you mean std::string ? If this is the case did you include <string> ? :
#include <string>
then use std::string :
std::string astring("a string");
|
|
|
|
|
I've included the header file but "using namespace std" this line is also not working.
|
|
|
|
|
Quote: not working. What does that mean? Generally speaking: nothing.
Please do not expect us to guess what you are doing. Edit your question, show the code you are using, the exact error message that is produced, and which line of code it occurs on.
|
|
|
|
|
I agree with other messages, we can not guess everything.
My best guess is that you are compiling a C file? (not C++)...
|
|
|
|
|
Or, he could be using an ancient version of C++, like maybe Borland Turbo C++, that doesn't understand namespaces.
|
|
|
|
|
But of course, "not working" could mean anything at all.
|
|
|
|
|
The following code should compile (and run) fine in a decent (i.e. reasonable recent) compiler
#include <iostream>
using namespace std;
int main()
{
const string greetings = "Hello world!";
cout << greetings << endl;
}
|
|
|
|
|
Try adding #include <string>
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
There's no need, actually.
|
|
|
|
|
hi!
i wrote a very simple app to capture videos with VfW.
HWND hwnd = capCreateCaptureWindow ("MyWindow", WS_CHILD | WS_VISIBLE , 0, 0, 160, 120, hwndParent, nID);
capDriverConnect (hWndC, 0);
capDlgVideoCompression(hwnd);
capCaptureSequence (hwnd);
does anyone know how to store the compression settings to reuse them?
is there any possibility to access the internal data of the capture window?
thanks in advance
-arni
|
|
|
|
|
Yes, but it depends how the information is stored by the library functions. The documentation should help.
|
|
|
|
|
Thanks for the reply...you are right - that's the question! the documentation doesn't say anything about that.
|
|
|
|
|
How are these values set in the first place? And, surely if you can display them then you can save the results somewhere.
|
|
|
|
|
the call to:
capDlgVideoCompression(hwnd);
displays a dialog to choose compression an parameters, and after "OK" they are stored somewhere (in the hwnd?) this process does work for the current session, but when i restart my app everything is gone. none of the structures (CAPDRIVERCAPS,CAPINFOCHUNK,CAPSTATUS,CAPTUREPARMS,etc.) gives me valid information about the chosen compression. what i need is the COMPVARS or AVICOMPRESSIONOPTIONS structure, but to access these seems to be a completely different approach.
tia.
-arno
|
|
|
|
|
The HWND object only exists for the life of the application, so any values stored inside it will be lost when the application terminates. You will need to save all the values yourself in some permanent storage area. See Where should I store my data?[^]; it's written for .NET but can easily be adapted to a Win32 app.
|
|
|
|
|
ok, i know that my classes and variables won't survive - the question was not how to SAVE the data, it's how to ACCESS it!
thanks richard.
anyone else has any idea?
|
|
|
|
|
Quote: the question was not how to SAVE the data, from the OP
Title: VfW Saving Compression Options
Quote: does anyone know how to store the compression settings to reuse them?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|