Making a game. Need some tips

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.

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?

You don't need to know anything to start(you can learn as you go if you really want to) but the more you know the easier things will be and the less likely you'll be to run into a brick wall. (The bigger your game is the harder it will be to avoid creating an unmanagable mess)

Keep your first game simple, If you havn't made a pong clone yet i'd strongly recommend that you make one, it will give you the basic idea of how games work and give you a better idea of where you stand).

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.

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

I actuslly love this advice. For a beginner working on a game you shouldn't have to worry about more "advanced c++ concepts." Sometimes it's not the project that's too complex for you, sometimes it's the code itself that makes it seem that way.

All those features are features you'll learn how to use on your own really (should read on them though so you know them). Their will just come a time when programming a project you'll say "wait I think I need to use this."

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.

Hey, i'm making the game with Thomas. I'm having trouble with installing SDL, does anyone know of any videos or advice? I'm using Code::Blocks

The first post I wrote in this thread links to a tutorial that gives detailed instructions in how to install SDL with Code::Blocks specifically.

Here's the direct link to it - I suggest following the entire tutorial as you go, because it was very helpful to me when I was learning SDL.

The first post I wrote in this thread links to a tutorial that gives detailed instructions in how to install SDL with Code::Blocks specifically.

Here's the direct link to it - I suggest following the entire tutorial as you go, because it was very helpful to me when I was learning SDL.

Alright I have SDL installed. But do you know where I can find some video tutorials that aren't outdated for SDL?

SDL, unless you are using the pre-release version 1.3 or 2.0, hasn't been updated for a number of years. The tutorials I linked to are perfectly up to date, and most tutorials you will find (even if five years old) are up to date, since SDL hasn't changed much. Once version 1.3 or 2.0 are officially released, then the tutorials will be out of date.

I wouldn't worry about 1.3/2.0, because SDL 1.2 is very stable and very usable, and trying to download from a remote repository and recompile the libraries yourself is not something I'd recommend a beginner doing.

As for video tutorials, I can't be of much help there.

Howdy all, I wrote the FixByProximity tutorials very basic so that people could follow along and learn while watching. It is certainly easier to know a bit before starting, however following along and looking things up has worked for a lot of viewers so far.

I would say to just start. If you keep waiting to "know more" then you will never begin. Instead, go as far as you are comfortable. Then go just a little farther. Then study until you are comfortable again. At that point start back up.

Anyway, your mileage may vary.

Hey, I suggest you to use C#+xna it is very easy to learn that, and c# is much easier language that c++ but it have some - - -. :)

Hey, I suggest you to use C#+xna it is very easy to learn that, and c# is much easier language that c++ but it have some - - -.

Signs seem to point to XNA going away. This is purely speculation at this point, but the XNA team at Microsoft was desolved (I believe).

The first post I wrote in this thread links to a tutorial that gives detailed instructions in how to install SDL with Code::Blocks specifically.

Here's the direct link to it - I suggest following the entire tutorial as you go, because it was very helpful to me when I was learning SDL.

Alright I have SDL installed. But do you know where I can find some video tutorials that aren't outdated for SDL?

The Biggest source of info is the forum itself, But you can find a lot of very educating tutorials on YT.