Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[G-Flex]

What isn't, exactly?

My advice, as much as I can remember, was similar to Blacken's: To learn the fundamentals of programming and its practices before jumping into things like graphics or games, and to be patient about it.

[Hippoman]

What isn't, exactly?

My advice, as much as I can remember, was similar to Blacken's: To learn the fundamentals of programming and its practices before jumping into things like graphics or games, and to be patient about it.

With you guys, I could never tell what the fundamentals we're. I thought I knew them but I guess having a 2 year degree from an online college in C++ is the fundamentals or something. As far as I know, I knew more than most people.

[Outcast Orange]

I've said it a hundred times before, but I'll say it again.
Learning C++ isn't a mammoth task.
I found it pretty easy once I accepted my dependency on libraries.
(I hadn't realized that in my old language, libraries were already in use automatically)
Note:
There are some very steep parts of the learning process once you get into it,
 but the initial climb is sugar coated and happy.

I think a rogue-like may have been too much for you as a learning exercise.
It became increasingly harder to tell you that you shouldn't keep piling on features,
 just because I knew how to do them.
You really need to go back to the beginning, look through the code,
 and figure out exactly how all of it works.

Once you can fully grasp how those houses in your code work,
 (including the double FOR loop)
 I think you'd be ready for adding in something new.
Classes though...
I struggled with glasses for a week before getting it,
 because I didn't really know what the purpose of them was.
I was looking to them as a way to capsulize my game,
 (which they are good for)
 but completely forgetting about there actual purpose.

Classes are like empty shell schematics for objects in your game.
You basically need some sort of class or struct to pull of any sort of rogue-like.

Anyways, I recommend you overlook the code with someone,
 and ask them about bits you aren't sure about, and things that are harder to understand.
Actually, your code would be perfect for Atomic Winter to take a gander at,
 as he seems to know all of the key concepts at work,
 just hasn't really seen them in action doing anything more complex.

I think the house code would even confuse him though. : )

[Alexhans]

Code: [Select]

#include <iostream>
#include <string>
int main (int argv, char* argc[])
{
std::string XD = "lol";
if("capsulize" != "encapsulate") std::cout<< XD << std::endl;
}For some reason I found that word incredibly hilarious...   

[G-Flex]

I think a rogue-like may have been too much for you as a learning exercise.
It became increasingly harder to tell you that you shouldn't keep piling on features,
 just because I knew how to do them.
You really need to go back to the beginning, look through the code,
 and figure out exactly how all of it works.

This is what we were trying to tell him: That he needs to learn how to program before trying to program something graphical, or a game, or anything arbitrarily complicated like that.

With you guys, I could never tell what the fundamentals we're. I thought I knew them but I guess having a 2 year degree from an online college in C++ is the fundamentals or something. As far as I know, I knew more than most people.

I have no idea what you think the fundamentals are, or how much you knew. That's why I consistently recommended learning them first.

If you (as Outcast Orange implied) have trouble with things like putting a loop inside another loop, then you don't know the fundamentals.

Really, "What are the fundamentals?" is an irrelevant question anyhow. The point is that you should be working from the ground up and not the other way around. Work at what you're already comfortable with and expand from there. If you're not comfortable with logic that's complex enough to need nested loops/branches, or basic usage of STL classes (both of these are invaluable or necessary for pretty much anything), then you certainly shouldn't be trying to make games.


So maybe fundamentals means the basics of programming logic (loops, branches, conditionals and comparisons, logical operations, any combination of the above), or maybe it means the basics of how to use the language you chose (classes, the standard template library, syntax and scope and all that jazz), or maybe it means something else entirely. It doesn't matter. What matters is that you don't overextend your skillset so much that you get involved in a project that completely overwhelms and confuses you. I would recommend small projects first, especially ones that involve the things you're trying to learn.

[qwertyuiopas]

"capsulize" != "encapsulate"?

I would say that it will *always* evaluate to true.
Why? Because both strings are pointers to diffrent parts of the memory conaining a sequence of characters. If they are identical even, it is up to the compiler to decide if it wants to keep each alone or have them point to the same memory location.

At the very least(This is from my C experience, mostly, so I hope it would work) cast one of them to actually be a std::string so that any operator overloading for inequality actually takes place, and std::string can preform any advanced comparisons such as testing each letter. It likely doesn't matter, since the issue would just be comparing two prewritten strings, as having one or both sides already a std::string would likely trigger the advanced features...

Spoiler: getting far off track (click to show/hide)

from http://www.joelonsoftware.com/articles/Wrong.html

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

When you see i=j*5 in C++ you are really on your own, bubby, and that, in my mind, reduces the ability to detect possible problems just by looking at code.

None of this was supposed to matter, of course. When you do clever-schoolboy things like override operator*, this is meant to be to help you provide a nice waterproof abstraction. Golly, j is a Unicode String type, and multiplying a Unicode String by an integer is obviously a good abstraction for converting Traditional Chinese to Standard Chinese, right?

[Alexhans]

"capsulize" != "encapsulate"?

I would say that it will *always* evaluate to true.
Why? Because both strings are pointers to diffrent parts of the memory conaining a sequence of characters. If they are identical even, it is up to the compiler to decide if it wants to keep each alone or have them point to the same memory location.

lol... I managed to screw up a joke... you're partially right... Instead of comparing strings with the class function I treated them as literals and ended up comparing character by character.  But it doesn't evaluate to false unless the literal strings are exactly the same, char by char.

But remember... I'm not comparing strings there... I think what the overloaded operator is doing here is taking each characters value and comparing it with the next.

Of course... You would never do that.  you'd be comparing a String or an array of chars with the respective compare function (strcmp or whatever)

Spoiler: getting far off track (click to show/hide)

from http://www.joelonsoftware.com/articles/Wrong.html

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

When you see i=j*5 in C++ you are really on your own, bubby, and that, in my mind, reduces the ability to detect possible problems just by looking at code.

None of this was supposed to matter, of course. When you do clever-schoolboy things like override operator*, this is meant to be to help you provide a nice waterproof abstraction. Golly, j is a Unicode String type, and multiplying a Unicode String by an integer is obviously a good abstraction for converting Traditional Chinese to Standard Chinese, right?

Then you'd hate C# from what I've been reading... 

and this is phrase is so true:
Stroustrup's classic formulation: "C makes it easy for you to shoot yourself in the foot.  C++ makes that harder, but when you do, it blows away your whole leg."

[Outcast Orange]

Oops, vocab slips kill turtles.

I don't necessarily thing that a graphical game is too hard for a beginner,
 as long as they understand math well enough.

Atomic Winter appears to be doing a great job with the small amount of information I've given him.
He understands everything thoroughly, and asks tons of questions when he doesn't.

I was most impressed when he saw a double FOR loop designed to loop through coordinates,
 and decided to take a break for a while and look it over and wrap his mind around it better.
Most would just like to ignore such a headache and pretend the understand it.

I learned making games.
My first program ever was a graphical game,
 and my first C++ program was a game.

Most people don't have the dedication to work hard on something boring
 that barely relates to what they want to do.
Interactive fiction is probably the best place to start,
 but for those who grasp concepts more quickly,
ASCII isn't a bad place to start.

I'm fairly new to this business though, so take it all with a grain of chocolate.

[Hippoman]

Oops, vocab slips kill turtles.

I don't necessarily thing that a graphical game is too hard for a beginner,
 as long as they understand math well enough.

Atomic Winter appears to be doing a great job with the small amount of information I've given him.
He understands everything thoroughly, and asks tons of questions when he doesn't.

I was most impressed when he saw a double FOR loop designed to loop through coordinates,
 and decided to take a break for a while and look it over and wrap his mind around it better.
Most would just like to ignore such a headache and pretend the understand it.

I learned making games.
My first program ever was a graphical game,
 and my first C++ program was a game.

Most people don't have the dedication to work hard on something boring
 that barely relates to what they want to do.
Interactive fiction is probably the best place to start,
 but for those who grasp concepts more quickly,
ASCII isn't a bad place to start.

I'm fairly new to this business though, so take it all with a grain of chocolate.

For once I am not bored. Only when i'm coding am I not bored.
And trust me. Once Eric switches to classes, he's going to have problems same as I did.

[Outcast Orange]

Yes, but he will be typing the code,
 not having someone tell him letter for letter what to do.

[Hippoman]

Then he knows more about classes then I do.

[Outcast Orange]

Not yet he doesn't,
 and only if he sticks with his initial expectations.

On another note,
do you think you'll continue trying to learn C++?

Surely you know a lot more than before.
I would be proud of you if you stuck with it,
 but I'm sort of reluctant to "teach" you anymore right now.

[Hippoman]

Of course I'll learn more.
Just it'll probably be another 4 years or so until I can get a class that'll teach me this since you've left after we crappily set up classes.

[G-Flex]

Oops, vocab slips kill turtles.

I don't necessarily thing that a graphical game is too hard for a beginner,
 as long as they understand math well enough.

That's the issue here: You have to understand the math and logic involved, and know when you've reached your limit and need to explore new concepts.

Most people don't have the dedication to work hard on something boring
 that barely relates to what they want to do.

If you want to become a good programmer, you almost inevitably have to, but I guess I see your point.


I think Hippoman is, in general, more concerned with the results he wants to get ("I want to make a game") than with the actual processes necessary to make them a reality (learning how to be a good programmer). Your "telling him letter for letter" comment reaffirms this suspicion.

[Outcast Orange]

I haven't abandoned you, we can still sort out bugs if you'd like.
I just think you might want to reconsider this thing,
 and maybe have a fresh go designing a game made 100% by yourself.
We are always here to offer tips.

It would really help if you were more willing to read though.