Writersface13

C++ For Absolute Beginner

Recommended Posts

Hello again! I'm looking for a really good place (or books, but the internet would be my preference) where a COMPLETE beginner with NO programming knowledge can learn to understand and code C++ (if this helps, I'm using UE4 for my game development needs). Thanks!

Also, just as a side-note question, is the process of debugging the same as programming? Curious as to how that works. Thanks again!

Share this post


Link to post
Share on other sites
44 minutes ago, Writersface13 said:

I'm looking for ... COMPLETE beginner with NO programming knowledge can learn to understand and code C++

"Accelerated C++" by Koenig and Moo.  It should get you started quickly. It is a little dated, but still one of the best.

"C++ Primer" (5th Edition) by Lippman, Lajoie, and Moo if Accelerated C++ is too fast. This is slightly more current.

44 minutes ago, Writersface13 said:

Also, just as a side-note question, is the process of debugging the same as programming?

Debugging is finding errors in the code and correcting them.

The process is different, just like editing text is different from writing text.  Before either can be done well you must be literate. It is difficult to read code and search for errors if you don't know how to write and interpret code in the first place.

Share this post


Link to post
Share on other sites

I would second C++ Primer (I would avoid the closely named book C++ Primer Plus - it's not from the same series) Accelerated C++ is also a very good book as well.

You will pretty much need the following to get started:

(Took this list online from SFML - It's a good reference)

  • Compiling, building
  • Basic program structure (main(), header includes ...)
  • Basic data types
  • Composite data types
  • Control structures (if, for, while ...)
  • Basic functions, function signatures
  • Function parameter passing
  • Classes and general OOP
  • STL - Standard Template Library
  • Dynamic memory allocation, pointers
  • Type casting
  • Advanced OOP, inheritance, polymorphism
  • Advanced program structure, header files, linking
  • Debugging techniques This is important to be able to help yourself when the situation arises.
  • Templates
  • Operator overloading
  • Namespaces
  • Move semantics and other C++11 features
  • Metaprogramming

Then you would want to move into learning UE4 specifically. I strongly do not recommend moving into game programming until you have a good grasp of the above in C++.

You can learn online if you wish, but I strongly suggest learning from books that teach best practices. The investment in one of those books is well worth it.

Edited by Rutin

Share this post


Link to post
Share on other sites

Another discussion is fairly relevant to your case -- you might want to consider learning C++ outside of Unreal (at least initially).

See some thoughts on that here:

 

Share this post


Link to post
Share on other sites

I would recommend C++ Programming: Program Design and Data Structures by D.S Malik.  I had this as a text book for two semesters of C++ in college.  The book isn't the best written C++ book I can think of, but it provides solid examples and good exercises.  No matter which book you choose as a tutorial I would recommend that you use C++ Programming Language 4th Edition by Stroustrup (The creator of C++) as a reference.  This books provides solid, but somewhat academic examples, but it also provides valuable details about proper use and even some insight into why the features of the language exist.

A little advice on C++ somewhere around class implementation and pointers most people start to fade.  They see that they can accomplish much just using procedural programming and fail to understand why grasping these complex concepts and the details of their proper implementation is crucial to their success as a C++ programmer.  The simple fact is if you fail to grasp these concepts you are not a C++ programmer at all.  I encourage you to approach your study of the language with the idea that the complex concepts within the language are valuable milestones in your development as a programmer not unnecessary complexities.  

Lastly, congratulations on your decision to take the first steps toward completing your game. 

Share this post


Link to post
Share on other sites

My only advice would be to keep an open mind and don't just do the minimum.  Type out examples in the book and change them, break them, then fix them.  Learn code by reading and studying but also interact with the code.  

Specifically, when it comes to pointers forget your first inclination.  Everyone's first inclination is to say, I don't need a value that points to the location of a value when I already have a variable that labels the memory location of that value for reference.  Without spoiling the surprise or typing a book in the chat window.  YES YOU DO!!! LOL.  Accept that and read up on pointers and use them.

As far as Classes.  Classes are mechanisms that allow you to combine data and operations into a singular unit.  Think of a class as a blueprint for a machine.  You will be constructing objects from these blueprints and they will perform simple tasks.  These object will interact with objects to perform complex tasks.   These classes are blueprints for workers who know and do things in your programs.

By the time you reach classes you will have learned many of the built-in data types and utilized their associated operators and functions.  Just know that classes are really just Abstract Data Types.  When you create a class you are defining a data type.  You are defining the data it holds, the functions that it can perform and the operations that can be performed on it.

Polymorphism a big word, but the gist of this one is that once a blueprint is created a more specific version of the blueprint can be created by adding the details that make it unique from the original.  The original is the base, parent or polymorphic type, the other is the derived, child or subtype.  You may have a class such as Hero.  The hero is defined by his attributes of Strength, Speed and Health.  He performs the function of acceptQuest().  The Hero may then be the parent class of the child class Fighter who has all of the above but also has member variables sword and armor.  He may additionally perform the function swordAttack().  Another child may be Rogue who has all of the attributes of hero but also has a dagger member variable and a lockPicking() function.  This one of the types of relationships defined in concept of polymorphism.

These analogies are intentionally vague and will likely grow weak and useless overtime as you acquire solid knowledge of the associated concepts,  but I hope to give you a general idea of what these concept are and a feel for why they are powerful.  C++ doesn't have that steep of a learning curve.  It just has some really rough speed bumps and a long road toward mastery that we all inch along daily.

Oh last thing,  I have recently been reading a book called Level Up.  It has some good information on the elements of game development and offers practical advice.  You may want to check it out!

Share this post


Link to post
Share on other sites
1 hour ago, Lucas_Cage said:

...

I have a small question, let me hijack the topic for just one second, sorry :P

I remember watching a video on youtube where a similar example where made (with items, ice and fire sword which inherit from sword and what would happen if you then need an ice/fire sword, which is, it inherit twice from sword and either won't work or is not efficient, not sure which one is...), so what if you now want a Rogue/Fighter character? Inheritance would be bad cause you inherit twice from hero, right? Would the "Component design pattern" be commonly used to allow this "mixed hero stuff" in games?

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

 

The example is trivial and only exists to represent simple inheritance.  The structure given may fall apart at a certain level of complexity as all analogies do. 

To answer your question directly the inheritance is generally used when the design lends itself to a hierarchy of classes that are defined by what they are.  This is simply defined as a "is a" relationship.  The Sword is a wood sword.  Composition becomes more appropriate when the relationship is better defined by a "has a" relationship.  The Sword has an enchantment.  When making the decision between inheritance and composition we decide in simple terms if each instance of a Fighter is a Hero or if some instances of  Hero simply have the attributes of a Fighter.  In many cases both answers will be affirmative, but when we give a more practical look at our classes and how they will function in the program one solution generally emerges as superior.  Remember that this is about ownership.

To further illustrate I provide a more specific application.  We consider the hybrid class exists in a leveling system where the Rogue/Fighter begins as a fighter for the first 8 levels selecting only those abilities appropriate to his class.  Then at some certain level we will say 8 he can now choose to increase his level to 9 as a fighter or can take abilities as a level 1 thief.  Inheritance now seem obviously inappropriate.  It is clear that the hero has the attributes of the class (fighter, thief, mage).  The fighter is not truly a type of hero and certainly does not exist autonomously among the other proposed children.  At anytime he may need to be bound to another child class of the same parent.  Not only does this reduce the usefulness of the child classes it makes them an obstacle.  When we consider that the fighter now has certain limitations imposed on the thief class via the rules of the RPG system. We can see the ownership relationship is more accurately expressed by saying The Hero has attributes of a class(RPG class), rather than by saying a particular class(RPG class) is a hero. 

In a simpler relationship where we have a class sword.  The sword has attributes defining its damage and also another defining its enchantments.  We naturally picture the ice sword as a sword that has an ice enchantment rather than an ice enchanted sword that is a sword.  Therefore, we can see the composition model more readily applies.  We would define the sword class through composition so that it can posses multiple enchantments as member attributes.  However, in an instance where we wish to define the sword itself we would use inheritance.  So that the parent sword class would have child classes wooden sword, iron sword, steel sword.  In this case inheritance becomes more appropriate as a wooded sword is a sword. This phrase can easily express the ownership relationship.

 

Edited by Lucas_Cage

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now