I am going to start programming, any tips?

[geekinside1]

I am going to be starting to program in the C++ Language and I wanted to get any tips on the programming language. Also, I am just starting to learn how to program and I want to make a game engine.

[cinedine]

Start small. Don't think "Game Engine". Think "Hello World" and build up from there.

[Buck]

geekinside1님이 먼저 게시:

I am going to be starting to program in the C++ Language and I wanted to get any tips on the programming language. Also, I am just starting to learn how to program and I want to make a game engine.

C++? You should start with something more simple, c# and java is good for beginners. Read a book and so on.

[geekinside1]

Alright, so what would be some good book and websites to research on C++?

[geekinside1]

Select, any good books on Java then?

[cinedine]

I don't now why so many people recommend learning by books. Books are quickly outdated in terms of best practices and most aren't well written. I wish I got a dollar everytime I see constants defined in an interface because a book said to do so. Or use an iterator within a while for code that doesn't mutate the collection instead of a simple enhanced for/for-each. Or use of Hungarian bloody Notation!

The best way to learn is to understand. Look at example snippets and try to understand why they are doing what they are doing. Google-Fu is your biggest weapon.

[geekinside1]

Thank you, cinedine for your help I will be sure to heed your wisdom. If any body elso wants to give any more suggestions or helpplz do so.

[aiusepsi]

cinedine님이 먼저 게시:

I don't now why so many people recommend learning by books. Books are quickly outdated in terms of best practices and most aren't well written. I wish I got a dollar everytime I see constants defined in an interface because a book said to do so. Or use an iterator within a while for code that doesn't mutate the collection instead of a simple enhanced for/for-each. Or use of Hungarian bloody Notation!

The best way to learn is to understand. Look at example snippets and try to understand why they are doing what they are doing. Google-Fu is your biggest weapon.

I disagree (apart from that Hungarian notation is evil, which it is); especially if you're talking about a relatively conservative language like C++, best practices don't evolve that quickly to make a relatively recently written (or updated) book obsolete (it's still a bit iffy, given the platforms we have to support, to adopt C++14 features at work. Lord knows when it'll be safe for us to adopt C++17...), and what a decent book can do that that examining random snippets can't is give you a holistic overview. A decent C++ book will tell you about things like the rule-of-five (née rule-of-three) which are pretty tricky to pick up from reading example snippets.

You're also just at risk of picking up bad habits from random examples. As an example: older code will tend to make heavy use of raw pointers; modern code should use std::unique_ptr or std::shared_ptr instead. Or using C-style arrays when you could/should be using a std::array. And so on.

What's wrong with iterators? The modern range-based for is, after all, syntactic sugar over iterators. The only real problem to my mind was their ludicrously complex types, which is solved by 'auto', and the aforementioned ranged-based for means you get the benefits without even having to worry about that.

To my mind, the major disadvantage of books is that they cost money, and your average community library isn't generally well-stocked with up-to-date programming books.

Personally, I'd say the best way to learn is a little of all of the above. A book will provide solid theoretical background, but it's just as important to write stuff yourself to help practice what you're learning from the books, and you can supplement that with looking at and understanding other people's code.

I would definitely not start by aiming at a game engine; 3D graphics is not a simple thing by itself, so setting yourself up trying to learn two complex things simultaneously is a really good way to set yourself up for failure.

[geekinside1]

Ok thanks for this essay to help I will be sure to that.

[Start_Running]

OP Avoid C# and JAva. While they are easier to learn. C and C++ will teach you more. With JAVA, C# and VB you will pick up bad habits that will get you into trouble. C and C++ on the other hand will teach you some good habit and is easy to add on to.

THouugh honestly if your goal is game development. I might actually suggest some game devbelopment tools. RPG Maker, Games Workshop, etc.

GAme development is a lotr more than nuts and bolts coding these days and learning to use these tools will give you a chance to learn about how 'you want to design games' From there you can decide what languages you'll need to compliment your prefered approach.

I can also recommend playing around with games that have their own editors. They tend to be more limited buyt again they will teach you the lines of thought needed for game development.

You could also check out the source engine and stuff like Gary's Mod.

[Blargo]

stackoverflow.com will be your new best friend.

[geekinside1]

Thanks guys.

[cinedine]

aiusepsi님이 먼저 게시:

What's wrong with iterators?

Nothing. But the way some people use them is cringe worthy. I've come across several examples from what I'd call an experienced Java developer who uses them instead of a simple enhanced for loop. It just bloats your code and doesn't add anything. And in those cases, they're not even typed checked.

if(!someCollection.isEmpyty())[
{
  Iterator it = someCollection.iterator();
  while(it.hasNext())
  {
     MyClass element = (MyClass) it.next();
     //do Stuff not involving someCollection
  }
}

Vs.

for(MyClass element : someCollection)
{
  //do Stuff not involving someCollection
}

Syntactic sugar? Of course! But sooo much more readable. Especially if the doStuff involves leel four nested coded in itself.

aiusepsi님이 먼저 게시:

A book will provide solid theoretical background, but it's just as important to write stuff yourself to help practice what you're learning from the books, and you can supplement that with looking at and understanding other people's code.

And that's really what I meant.
Start small and go forward in small increments.

* Learn how to display text to the user.
* Learn how to change this text based on user input.
* Learn how to display graphics.
* Learn how to play sounds.
* Learn how to differenciate sound and graphics based on state.

Baby steps.

As an example my first "more complex game" was written in these steps:
* display character
* make character face up/down/left/right
* make character move up/down/left/right in a 3x3 grid
* make character respect borders of the 3x3 grid
* display walls in a 9x9 grid
* display walls in the middle of the 9x9 grid
* make character respect walls in the middle of the 9x9 grid
* display objects in the world
* make character collision with object in the world
* make character interact with object next to it
...
and suddenly you have the base of a rogue-like.

Or a CCG:

* display card
* display board
* display board with cards
* display hand
* move card from hand to board
* display energy
* make card cost engergy to play
* display two players with health
* make card attack other player and deal damage
* make card intercept other card from dealing damage to player and allocate damage to intercepting card instead
* make card react to damage

... HearthStone clone in the making.

---

Learning a programming language is no different to learning a natural language. You have to learn basic vocabulary and grammar. Then learn to express concepts with it.
"Hello World" is no different to "I am cinedine", "Ich heiße cinedine", "Mi chiamo cinede".
"Hello, <user name>" is no different to "Who are you?", "Wie heißt du?", "Come ti chiami?".