Hello.
Me and my friends want to make a 2d game with C++ but don't know where to start. I've heard of Allegro and SDL but I can't seem to get those installed.
So if anyone has any tips on where to start my game and what I'll need, Please comment. Thanks! :)
Do you already know the C++ language? If so, here is a SDL tutorial. And here is a SFML tutorial.
If you don't know C++, you need to learn the language itself before you learn SDL or SFML or even before you make a game.
In the same way that you can't write a book without first learning english, you can't write a game without first learning the language you are going to write it with. 
There is a good 2D tutorial series at http://fixbyproximity.com/2d-game-development-course/
This will give you a great introduction to using Allegro 5 to build a 2D game. Technically its in C++, but this course doesn't us OO. There is a follow-up course (also on that site) which redoes the same game in a more OO methodolgy, but you need to do the other course first because its the one that actually explains Allegro
oh yeah this assumes you at least understand C/C++ already
There is a good 2D tutorial series at http://fixbyproximity.com/2d-game-development-course/
This will give you a great introduction to using Allegro 5 to build a 2D game. Technically its in C++, but this course doesn't us OO. There is a follow-up course (also on that site) which redoes the same game in a more OO methodolgy, but you need to do the other course first because its the one that actually explains Allegro
oh yeah this assumes you at least understand C/C++ already
How much C++ do you think we need to know before we can start?
We could list random "features" of programming languages that you "must know", but that's purely speculative.
If you want to start right away making games while you learn C++, then the typical solution is to make text-based games so you don't have to learn APIs and the features the APIs use while learning C++.
But if you start with SDL or Allegro, you could just start messing with it and see what you can do. But there's something important to understand: If you get confused and want to give up, that's because you're not bothering to learn the language first and are trying to jump into the deep end of the pool before learning how to swim. So if while working on your project you want to give up on programming entirely: Don't. Instead, scrap what you know, pick up a solid C++ book (without any game-related words in the book's title) and learn C++ first.
If you want a speculative list of "basic C++" knowledge, then:
- Functions
- Variables, reference variables, and pointer variables.*
- if(), while(), for() statements
- Classes and structs
- std::vector, std::map, and std::string
- Variable scope
*Pointers and references are easy to learn if you learn them at the same time you learn about regular variables.
Things to avoid using in your own projects when starting out: (learn but don't use in your first few projects)
- 'new' and 'delete', malloc() and free()
- Inheritance (especially polymorphism)
- Custom templated functions and classes.
- Exceptions, goto
Well....according to the author for that tutorial here is what he says....
Introductory C++ programming is outside of the scope of this text. That being said, I have been very careful not to include any topics that would not have been taught in any introductory C++ course (or that could not be easily learnable from a few internet tutorials). If you’re not sure if you have the required knowledge, see the side bar.
<Note: Topics that are generally used in this text are: variables, functions, structs, and arrays. If I hit upon any topics outside of this list, I will briefly describe it in a side bar (like this one) and give you information on where to go to learn more.>
That being said he does pretty much type everything out for you...the problem is if you don't understand the language, I don't know that you would really LEARN what is going on. Of course if everytime he mentions something you don't understand you go and look that term up, try it out, etc...then it may be a great jump start.
Honestly though like Servant of the Lord said...you have to learn a language before you can write anything. If you're really concerned about your skill level with the language take a look at the first couple of videos on the site. if they don't make any sense you need to go back and spend more time learning the basics of the language before you proceed.
There is a good 2D tutorial series at http://fixbyproximity.com/2d-game-development-course/" href="http://fixbyproximity.com/2d-game-development-course/">http://fixbyproximity.com/2d-game-development-course/" href="http://fixbyproximity.com/2d-game-development-course/">http://fixbyproximity.com/2d-game-development-course/
This will give you a great introduction to using Allegro 5 to build a 2D game. Technically its in C++, but this course doesn't us OO. There is a follow-up course (also on that site) which redoes the same game in a more OO methodolgy, but you need to do the other course first because its the one that actually explains Allegro
oh yeah this assumes you at least understand C/C++ already
How much C++ do you think we need to know before we can start?
Ask yourself why you want to use C++ for your game. Do you want to also learn C++ along with making the game, or did you just hear that C++ is "what's best". If you can make your dream game idea using another language or even a program like Game Maker, then go for it. C++ takes a long time to learn, and while it provides an excellent platform for producing high quality work, it is not the easiest path. For the most part any low to medium performance 2D game can be completed with C#, Java, Game Maker, etc. Once you are ready for 3D action, you may want to consider C++ again.
I guess I'll be the guy to jump in to this conversation on a bit more of he nae sayers side. I don't mean to directly contradict what seems to be emerging as the popular opinion but my personal feelings are that no you can not learn the programming language as you go. To put it simply yes you can learn features pretty easily, but properly using and implementing features in programming relies quite heavily on having a good base understanding of programming itself. Think of it like speaking to someone in a foreign language you have never spoke before (maybe not the greatest example but here we go). Say you don't speak Chinese and you move to china. You may be fine with your little pocket translator to ask for directions or to order a beer, but will you be able to have an on going conversation on the side of the road concerning the financial situation of the world? Likely not, although you can look up the phrase "where is the bathroom?" and between their answer and where they point it's pretty easy to "talk". But in order to have a real conversation you need to understand the grammar, the words and know in your head how to put them together, otherwise is it really likely that your chat partner will engage in the conversation with you if every other word (or maybe every word) you have to look up before you can talk? Not likely...
With that said and keeping with that same example programming is no different. All be it that the words you type might appear to English it's not exactly your every day English that we are speaking right now. That is to say in order to hurt a player for 10 points of health you need to tell the computer (eg your game) to do that in the programming language. So where you and I might say to each other "Player A takes 10 damage" you need to tell the computer...
PlayerA.Health -= 10;
Ok, that's simple right? I'm full of it so to speak that's very easy to learn, heck you just learned it! But what is PlayerA? (Duh it's "Player A"). False! Player A in this example is a class object and the health is a public member of said object defined as an integer value that stores the amount of health that "PlayerA" has. Why? Cause I say so. I'm the one who wrote up the class and defined all that behavior outside the scope of this message. Now why would this matter and what is the big deal that I'm trying to portray here? Simply that just because you can easily learn to type "PlayerA.Health -= 10;" would remove 10 points of health from the PlayerA class that we are using to store our player's information doesn't mean that you can check that player's defense rating to see if it should have been less or more damage than that. You don't necessarily know how PlayerA came to be, what else you may or may not want to interact with and so on. Ok that's fine, more reading. You can go backwards now and figure out how to write a class, you can learn about data types, declarations, definitions, functions, methods, members (the list goes on and on and on).
This is why I personally believe that it is imperative to first learn the basics of coding and a good portion of the actual language itself. You need to learn the grammar that the computer speaks in (the syntax of the language), you need to learn key words and operators (excuse me I'm not an English major but the "And", "Is" "The") and all those fancy little words that actually make a sentence first. I might know that "Konichiwa" means hello in Japanese (Or Chinese not sure exactly) but do I know how to say how do you do? Is that even how you pronounce it in the Chinese equivalent or would it be "How are you doing?"? Granted in real life people can look past proper grammar and still understand what you mean but a computer isn't built to do that. It expects absolutely perfect grammar and it will follow your instructions to the T. If you write something slightly out of order, even though your human eye understands what you mean the computer will do it exactly as typed and in some cases this can lead to horrible distastes
Now with that said and hopefully I make a bit of an impact with some of that there are other vital parts of programming that aren't writing code that also matter. Namely the design of the end result. Programming is an art of speaking a foreign language, to a computer, issuing instructions to obtain and end result or your choosing. With that said how is your game design? Let's assume that your making a simple action beat em up game, something that seems pretty self explanatory Player moves around the levels, punching kicking and smacking down all those nasty bad guys in the way. Cool, easy enough right? Well lets ask a question that would be very important to this game working correctly. What is the mathematical equation that is used to determine how much damage is done to an enemy when you flick him in the eye? Sounds stupid and not important right? Wrong! The computer needs to know this, even if the answer is "That's one hell of a flick, one hit one kill that easy". This is why I've always said that the design document is the first and most important step for game development for any and all members of the team. Programmers need this design document so they have reference and knowledge of what they are telling the computer to do, artists need this design document to know what they are drawing, writers need this document to know how to wrap their story around game event and how to keep the suspense going so your player keeps playing, composers need this document (and maybe more so the story) to get a feel for how to compose their works...
So in the end, my suggestion is that if you are just getting in to game development for ANY reason, be it as a coder, an artist, a writer, a composer or hell even just the idea guy. Start by writing up as many pages of design documentation as you can, something that you can hand to me who knows absolutely nothing about your game, and as I read through it to the end I should know everything about it. I highly recommend doing this right now, ignore everything all of us are telling you about C++ an write your design document. It will have an enormous impact on your selection of programming languages, technologies, engines and so on. A good example, if you plan to target iOS you don't use C++ you use Objective-C, if you plan to target android you should be using java, if you plan to target XBox you either need C++ and an official publishers backing like say capcom or you need to go with C# and XNA. You may just come to find out that C++ is not the appropriate language for your goals as a game designer and as such you may not want to invest 3+ months learning a good foundation of something you won't be using.
So all in all, I would keep in mind that you should NOT be expecting to have a playable demo in front of you any time soon. I would recommend that you start with the design document even if you don't have a particular project make something up as a practice project. You are actually worth 100% more to development studios if you can do design and coding (or art or whatever). So this is something good to learn anyway. Once you have a good thorough design document outlining what it is that you are trying to create you will be able to use that to ask informed and educated questions on what language you should be learning, what engines, api's or technologies you might need and why and so on. Once you determine what language, engine and technologies you might be using you should "start from scratch". Meaning that you should get a book or a good LONG online tutorial set that starts out as a beginner and works up to advanced topics. Do the entire book or the entire tutorial set, and it is highly likely that it will have nothing to do with games. That's fine, your learning how to talk to the computer so you can tell it how to run your game later. The more important knowledge is knowing the syntax and operators (grammar and sentence structure), once you know that it's actually very easy to to tell the computer what to do. Be it a program, a network server, a video game.. Whatever you have the power and knowledge in that you know HOW to talk to the computer and you understand how to properly issue instructions.
