How to start making games?!

I have learned SDL2 a bit, but again I can't move further than a basic window with some sprites, that I loade

Sounds like you should be able to use that knowledge and move some sprites around based on user input.

With that, you can start making clones of Pong, Breakout, Pac-man, etc. Gradually making more and more complex games.

I have learned SDL2 a bit, but again I can't move further than a basic window with some sprites, that I loade

Sounds like you should be able to use that knowledge and move some sprites around based on user input.

With that, you can start making clones of Pong, Breakout, Pac-man, etc. Gradually making more and more complex games.

Yeah, I thought about it, but how can I start?

Yeah, I thought about it, but how can I start?

You said you can open a window, and load + draw sprites, correct?

That is already a start. Just go from there.

Figure out to move the ball in Pong.

Figure out how to read input so that you can use that input to move the player's paddle.

Create rules for the AI to follow when moving the computer's paddle.

Figure out how to keep track of score and displaying it.

Maybe add a menu to restart or quit.

Break things down into tasks that are managable, figure out what you need to learn if you don't know it yet, and just do it.

Yeah, I thought about it, but how can I start?

You said you can open a window, and load + draw sprites, correct?

That is already a start. Just go from there.

Figure out to move the ball in Pong.

Figure out how to read input so that you can use that input to move the player's paddle.

Create rules for the AI to follow when moving the computer's paddle.

Figure out how to keep track of score and displaying it.

Maybe add a menu to restart or quit.

Break things down into tasks that are managable, figure out what you need to learn if you don't know it yet, and just do it.

It sounds too easy, but I think you right! I should try it right now! Thanks, man)

As Lactose said, you really just have to decide what you want to happen in your games and make it happen. Make a basic game loop that handles game objects. Make different objects that has functions for handling logic and interaction between the objects and functions for rendering and just experiment around with making the objects behave in different ways. Start simple and then try something bigger. Once you have gotten into it a bit more, I would definitely recommend reading the book Game Programming Patterns as it can help a quite a bit with getting better structure and design of your game code, although it doesn't focus on teaching the basics of programming game behaviour. Good luck!

I would definitely recommend reading the book Game Programming Patterns as it can help a quite a bit with getting better structure and design of your game code, although it doesn't focus on teaching the basics of programming game behaviour. Good luck!

Ok than, thanks!

Download a c++ game off the internet. Study it, change it, refactor it, claim it and then blam, your game is made.

Hey you want my old demo to get started? I had this game demo I made a while back before I flipped my code to have polymorphism just because I wanted to say I can use polymorphism.

Please, don't suggest me some engines, cuz I want to get a deep understanding of game making to get the job that I want.

dude I feel for you, cause this is about where I am too. I don't want some one to hold my hand through the process like unity or unreal does, but I do wanna make a real game. here is what I've learned recently. video game programmers can be broken roughly into 2 categories. Those who use game engines and those who make game engines. game engines themselves aren't crutchs, they are the product of people like you and me who want to know the deeper things. That being said, engines are the results of teams of people working for years, creating tools, and helper programs to make a single game. look at Crysis(Cryengine), Unreal Tournament(UE4), etc. they then reuse that work and sell it to others.

to answer your question:

I'm not sure of your skill level but I'm assuming you know what a library is. (IE: #include )

you can build your own franken-engine using the host of open source libraries out there. be cautioned, this will involve a lot of non-game development programing to get it to work properly. here are some of the most popular libraries:

Graphics:

• Irrlicht
• Ogre3d
• sfml
• horde3d
• search google 'graphics library for c++'

Physics:

• Bullet3d
• box2d(2d)
• Nvidia's PhysX

?Sound

• irrClang

Download a c++ game off the internet. Study it, change it, refactor it, claim it and then blam, your game is made.

I heard about it and I even have a github account, I tried few times, but I can't understand where to start. How to understand somebody's code?

Hey you want my old demo to get started?

Yeah, it would be nice)

I don't want some one to hold my hand through the process like unity or unreal does

It's exactly what I think!) Thanks for libs, I'll try it immediately)

SDL2 is pretty nice because it provides enough functionality to do pretty much anything you will need, it gives you a lot of control over what you're doing and it's very stable. The problem is that its C syntax doesn't exactly encourage you to write clean and modern C++ code, which means you may have to abstract and make more wrappers, and it also probably has less high-level functionality than some other libs. I did try SFML once earlier and it seemed good for the most part, but because it had some small bugs that I didn't like, I decided to go with SDL2 instead. But they may have fixed those bugs by now, so it could be worth trying.

I have learned SDL2 a bit, but again I can't move further than a basic window with some sprites, that I loaded

A video game is basically an interactive movie. You display graphic images at some rate (like 50fps) to the computer screen. Each image is a bit different (ie taken 1/50th of a second later), and you get the illusion of movement, just like a regulat movie.

If you don't deal with user input (or the user doesn't provide input), you are just simulating, the world that you display continues running at wall-clock speed (assuming you don't have a 'pause' button), and you keep displaying images.

The user input means that whatever the user controls changes direction, color, start or stop firing bullets, make a jump, etc etc. Basically, you register what the current activity is of the user character (just like everything else that exists in the world), and the world will display the new behavior as it runs through time, displaying new images at 50 fps.

"make a game" in the technical sense is thus make a program that creates these images at the required rate, and sends them to the video. Usually, you need to keep track of all data (like position and speed of everything) in you world in order to do that.

How to understand somebody's code?

That's an art too, and it's different from programming.

Reading everything starting at line 1 of the first file, and ending at the last line of the last file doesn't work, it is too much information.

Instead, you look for specific parts only. For example, you want to fix a bug in Money payments.

Focus on that. You search for functions that deal with payment. Their name normally contains something that relates to what they do. You can perform a text search on "payment" or "pay" or "paymoney" or "debt" or "credit" (be a little creative in how people may name what you're looking for!). All these terms may give you a lines in files for a closer look. Alternatively, if it's player payments, find the type that represents money amounts, or the name of the variable that holds player money, or the function that handles money updates of player money. All those things have names that you can search for across all files. Read the lines and functions in that neighbour hood, and slowly you get a picture of how money gets dealt with.

Another way in are the files themselves. Check them. Can you see patterns in the filenames? eg tile_funcs.c may contain functions. "tile" may point to something that exists in the game. Read each filename and consider what it may contain. Open the file, and read the function names. Don't worry if it doesn't hit home immediately, you're exploring foreign code, these things take time.

If you get closer to what you want to know about, you have to really understand the code. My standard trick is to start adding Doxygen documentation to the functions and data that you think you understand. You don't get everything, but some stuff is understandable, so document it. Writing that text makes you quite aware of its function, and even better, you can now read your text instead of deducing functionality from the code, which is a lot faster.

If you do this for a longer period of time, the system that is used in the code will become clear. You start to understand the code, see how it works.

All this goes a lot faster if you have people that know the code nearby. Check if the project has a mailing list or a forum or an IRC channel, and read what they discuss. Ask questions where to find things, etc.