superman3275

I'm sorry, I mixed up that funtion. What I meant was std::to_string. When I had a score counter in Pong, I had an integer that I used to keep track of the score. To display the score, I had to convert the integer to a string, so I used std::to_string. I must have mixed that up with a function to convert strings to ints, so I'm sorry. Either way, I would use std::stringstream for this. Very Sorry !

Just to get this out of the way: as a programmer, unless someone who can't program has a good portfolio, I won't join their project.

Everyone has a game idea they want to make. Unless it was a game idea I was passionate about (I'd helped conceive the game's mechanics), I won't work for you without pay. Right now, I like to do smaller contract jobs on the side (Imagine writing a program to do something specific for someone, and getting payed when I finish it). It'd probably be better, if you're going to pay people, to pay them by program / mechanic, than by hour. Since your indie, paying someone by hour won't work at all. There isn't an office, and there's no way to keep track of how much they worked.

For your portfolio: Use GameMaker. If you're an artist, employers will far rather see a smaller game made with a tool that represents your art, rather than some hard-coded game. They're looking for an artist, not a programmer. I can guarantee you that if I was hiring an artist, and one came to me with a portfolio of good sketches / 3D Models, and the other came to me with 1-3 Games made in GameMaker with good art in them, I'll pick the latter.

For an artist, I'd look for:

• An understanding of sprite-sheet creation
• An understanding of basic Art Logic / Drawing
• Good 3D "visualizing" skills
• A game they'd made using their art.

That last one is very important. It's not that hard to make a simple game that shows off their art. Sure, it may be small and not really a game, however you need to show me that you understand what I have to do, even a little bit. I want my artist to know that if I say something isn't possible, I'm not trying to get away without doing work. I'll only work on projects I'm passionate about, I would never even try to join a game that I didn't care for.

I think about it like this:

CPU does the math, GPU does the rendering.

Ta-Da (I'm not a smart programmer ).

Do this right now:

1) Get a piece of paper and a pencil

2) Write as a header: "Function"

3) Think about exactly what your game is and right it down.

Example for Pong:

Pong is a 2d game. There are two paddles. One is player controlled and the other is A.I. controlled. There is a ball that moves around the screen. Whenever the ball hits a paddle I reverse either it's x or y velocity depending on which side it hits. The paddles are both next to the top and bottom of the screen. If the ball goes past a paddle the game ends....

This is important. You need to define your goals, limits, and conditions right now. You need to understand the rules, and the extent of your game. Write it all down.
Then list it all. List all the functions and rules.

4) What is in your game? Write it down. You need to know what the actual objects are before coding. Making mario?:

1) Mario
2) Coins
3) Bricks
4) Mushrooms
5) etc.
6) etc.

Write EVERYTHING down. You need every last object.

5) Figure out the system level things your game needs.

Example:

I need a window. The game will have custom art so I'll need something to load images. I want music and sound to be played, so I'll need audio too. The only way to control the player is having an Input manager. Oh, there's collision? That means I'll need some collision code too. Yet, handling collision will take Physics...

6) Now find out the actual objects.

1) Write down as a header of a page of notebook paper: "Objects"
2) List all the objects in your game. Adhere to the single responsibility principle, and feel free to go back and change things.

7) Write down the objects functions. You need to know the objects responsibilities and functions. Take a page per object and write down EXACTLY what it does. Make sure to note any interaction it has with other objects.

Now start coding, using all of these pages as a guide. Remember to use small incentives. Build a playable, small game, and than expand it with your other ideas.

I don't have anywhere near as much experience with game development as I would like to, and I have an ever increasing amount of school work to be completing, leaving me less time to work on my projects. Apart from feeling that the platformer I was working on is far more complicated than it should be, I'm just not getting anywhere with it. Due to my entity management system, I'm struggling to fix bugs with the collision detection and movement without breaking something else. I feel like I've either bitten off more than I can chew at this point, or am simply over complicating things.

Everyone has already told you to work on something simpler, and I agree with them, however here is a collection of important things:

1) Every day, when you come home, finish school work, then program.
2) Finish school projects in your normal "programming time" instead of procrastinating.
3) Read a Programming book. Read it at school, at home, while waiting for something. Just read it. It'll keep your mind focused and help further your understanding.

Now, about your platformer.

1) If your code is breaking, as detailed in the quote above: Your code is suffering from a case of Multi-Responsibility (Oh The Horror !).

Essentially, ideal code utilizes the single-responsibility principle to the best of it's abilities. What is the single-responsibility principle, you ask? Well:

I'm sure all of the senior programmers here understand the fundamentals of object oriented design, but this is for the beginners. First, let's define object oriented-design:

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem.

That hits the nail on the head. One important thing to note about object oriented design is this, you're planning a system of interacting objects. That means you're objects will work together. Many a beginner programmer, including me , don't grasp this. You're objects should work together. They shouldn't be isolated from each other so you only make separate instances of them, you should be using them together.


This leads into the first Principle of good object-oriented design

The Single Responsibility Principle

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

This is the fundamental building block of object-oriented design. Before we continue, let's take a closer look at what a responsibility is. In programming, a responsibility is something the class handles or does. Let's use a pong example:


When I first programmed pong, I had my Paddle class drawing itself, checking for collision, and updating itself. <-This was how all my other classes were designed too. This led to fragile code that would break if I changed any class, and the only way to fix it was to go through all my source and header files to fix the problem. The single responsibility principles goal is to make the above problems nonexistent in your code, and it largely succeeds.

Let's look at how we could fix this:

Have the paddle classes main goal to only update the paddles position and values. It doesn't draw the Paddle to the screen anymore. Do the same for the Ball class and the AIPaddle class. Then create another class called GameDraw. This has one AIPaddle, one Paddle, and a Ball. All this class does is use my get() functions to draw my objects to the screen. This means making a change to how I draw the screen doesn't affect my classes at all, and changing how I update my variables doesn't change how I draw my objects. Then I create a gamelogic class. This class calls all my Update() functions, thus making a change to how I update my objects won't change this class, and making a change to the order I update or what I update won't change the other Object's classes. Then, I create a BaseGame class. This class' responsibility is to run the game. It includes the gameobjects I need and a GameDraw/GameLogic class. Now, changing my class' won't mess up the rest of my code, because my classes are handling their responsibility, and the rest of my classes don't have to deal with them.


I hope all beginner programmers can read either this, or another article about this, because the Single Responsiblity Principle is extremely important to writing bug/error-free code, and will save you a lot of headaches by isolating what's causing problems, while still letting your classes work together.

(I wrote this article myself, just copying and pasting )

Essentially, that's why your program is breaking. You should try to follow this principle (And please do more research on it, I'm not the best explainer.)

I'm going to stress something I did, and that really helped me:

Get a large, well written (Easy and amusing to read), reference book.

1) Read it all the way through. Don't use the examples, don't code anything. Read the whole thing without coding.
2) Re-Read it, this time coding all the examples, doing all the practice questions, etc.
3) Start making programs in the console you think are cool. Any-time you have a problem consult your book.

This should take 3-4 months if you are really focusing (Reading the book in detail, doing ALL the examples, and writing your own console-code for at least a month.)

Then, pick a Graphics API and download the documentation.

1) Read the documentation. Remember this: Use every chapter / new thing to do something with it that wasn't in the tutorial.
2) Make knock-offs of classic game, consulting the documentation constantly. The reason you make knockoffs is so that you focus on learning programming rather than learning game design.
3) Embark on your own project! Also, remember to pre-visualize! Here's some articles I wrote to help you along the way:

Pre-Visualization is Important!
Stop the Catch-Alls!
Instant Gratification (And Why It's Important)!

Have fun!

What I believe the author of the article meant was that (And I'm paraphrasing here):

Once you understand the fundamentals of game programming, please don't make knockoffs of popular games and sell them for easy money.

Which essentially means: Once you've already made the knockoffs while you were learning, and you understand how to program a game, start making your own games instead of knocking off other games.

For beginners, starting with well-known games is fine, because it lets you focus on the programming rather than the game design. The concept of pong is fairly simple, and most people know it, so using it as a learning tool is great.

Now, when you're fully capable and you start making knockoffs of games that you sell for money, that's a different story to me. However personal knock-off projects to further yourself programming doesn't hurt anybody.

Goto can also make spaghetti code. A lot of times what ends up happening is that your code is jumping from place to place, making it extremely hard for other people to understand what you're doing. It also makes it hard for you. (Example: Code an awesome enemy system. A month later you need to extend it. Go to look at it and it keeps on jumping to a bunch of places, and you don't understand it, so you scrap all your code.). Now, GoTo isn't always evil. There's an application for everything. However generally using Goto is frowned upon, and the problem you're solving with it can be solved by using object oriented programming.

Brace yourself for the horrors of memory management. That is all.
However in all seriousness, some pointers:

1) C++ Is Unforgiving. Your code's errors can be extremely weird.
Example:
I had my Breakout game. In debug mode everything worked fine, however in release mode whenever the cursor crossed a certain Y position on the screen the game would just close. I eventually found out that I had an undefined Boolean value that I was referencing in a Class. The bug was annoying because it was working fine on my machine, which made pinpointing the error extremely annoying. And of course, the IDE in debug mode didn't give me the error (Or even a warning message).

2) Memory Management Tips
First Tip: Delete dynamically allocated memory as soon as possible. Whenever you do, set the pointer to null.
Also, try to use the new operator as little as possible. Using auto-pointers is fine, and you generally don't need the normal new and delete operators.

Also, I use Visual Studio, however there are many good IDE's. The debugger in Visual Studio is amazing.
I've used Code::Blocks. It doesn't have precompiled headers and the library support is good, however a lot of the auto-linking libraries don't work (SFML 1.6, as of now, doesn't work correctly).

It really doesn't matter which IDE you use. Just try them all out and see which one you like.

The best way to learn is to do. C++ and SFML didn't click for me until I started writing my own code. I rigorously copied down the examples. The key here is to change the examples. Experiment with them. Look at, say, an images functions and try them all out. As you read constantly think about how you can apply this knowledge and you'll have it in no time. The only way to learn is to do.

The only way I'm learning good programming habits is to code. I'm slowly figuring out where to apply the single responsibility principle, how encapsulation should be implemented, good design patterns / principles, etc. The only way to actually understand a subject is to rigorously practice in the subject.

thefollower, it seems like you don't have a firm grasp of the language and it's systems yet. I recommend reading some articles (Read this article and this one).
Once you have a firm understanding of classes, try making a button class. For the files question:
The Class Definition goes in the .cpp file. (Source File)
The Class Declaration goes in the .h file. (Header File)

Here is the basic class syntax:

class Button
{
public:

     void DrawButton();
     void CheckForButtonClick();
     void CheckForButtonHover();


private:

     Window * WindowUsedToDrawButton;

     Image ButtonImage;
     Sprite ButtonSprite;

     Rectangle ButtonCollision;

}

You'll soon find that it's not the programming language that makes the game, it's the programmer. Could I have programmed all of my games in Python or C# or Visual Basic if that's what I'd learned instead of C++? Of course I could of. If you are comfortable with Visual Basic, then make games with that. If you find that you want to use another language or are trying to broaden your horizons, there's no-one stopping you from pursuing Python, C#, or C++. Here are some links:
Python!
C#!
C++!
Honestly however, it doesn't matter what language you choose. If you're determined you can use any of them to crate any game.

Python's a great starting choice. It has an insane amount of applications and has 2 large libraries specifically tailored for game development. It's also good because it's fairly easy to incorporate it with more advanced languages later on as a scripting language. I'm planning on learning Python myself eventually. If you do go with python, here are some good libraries:

PyGame
PyGlet

For downloading and learning the language:
Python Official Website!

I'm still a beginner, working my way up from pong clones, tic-tac-toe and the like. I'm currently doing a simple mario style platformer. I've run into a fair amount of problems, asked on the forums, read articles etc. and played around with the code until I can solve them. In my personal experience, things are never as simple as they initially might seem.

Unless you are a god-tier programmer, there are two commonly suggested routes to take:

1. Take your current idea, and simplify it to the point where you can accomplish it with your current skills (or those not far out of your reach.)
2. Start smaller, with something like SFML (I find this a lot nicer to use than SDL), and create classic arcade game clones. Working from extremely simple - like tic-tac-toe, through pong, tetris, pacman, mario etc. until you have the understanding required to create the games you actually want to make.

Are you new to game development or programming?

I'm in the middle of developing my first Tile-Based game (Just finished Breakout !) and I can say nothing is as simple as it seems. I've been able to work through a lot of problems by thinking extensively about my code before and while programming, however there's always trouble spots. It's good to have trouble spots though, because with every one you learn new things. That's the point of starting with Tic-Tac-Toe and making ever more complex games. With every one there is something new involved that you'll probably use later, and running into a problem in the middle of developing an actual game is far worse than running into a problem in the learning stage. If your dreams are actually a passion and it's not something you'll give up on, then go through the development ladder and see if it's something you like.

For example, file input and output. This is a large part of a Tile-Based game and I had no idea how it worked or what it's uses are. I can now successfully say I fully understand how it works and how to create my own maps. My hope is to eventually create a level editor for my game using my knowledge, however you must take it one step at a time (Despite how annoying it is !). There's an insane amount of knowledge that you're going to to need to make your dream game, and if you go through the steps of development chances are that won't be your only dream game, you'll have many!

Unity3D will be the easiest and require the least (and easiest) programming.

1) Unity is mainly 3d and suits your needs for a psychological research.
2) As long as you're not selling you're creation to other companies you should be fine
3) Has built in support for this, even has it's own plugin.
4) All game engines are interactive, and Unity is as well.
5) Completely possible, there are even sections in the documentation about this (Saves).
6) Programming is good and easy, there isn't much.