Big frameworks like Unity make difficult things easier, but easy things more complicated. I would recommend starting with a simple game, in the programming language you are most fluent with. An example of a simple game would be a minesweeper. An example of a complicated game would be a massive online multiplayer strategic 3D shooter with artificial intelligence... in Unity ;)
Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects.
None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game.
Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button).
As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color.
When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.)
Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced).
How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you.
The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key.
Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.)
Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed.
...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).