I think this is a very good plan. It is good to make simple games (or merely demos of the concept) first, because the distance between no game and a simple game is probably greater than between a simple game and a complex game. So if you make a simple game, you solve the problems on simple instances, and then you are ready to deal with them in more complex situations, because the core ideas are now clear.

For example, even very simple games usually contain a lot of the following: loading bitmaps from files, displaying bitmaps, loading music from files, playing music, reading user input, calculating coordinates, calculating movement, calculating collisions, timing and animations, keeping values in variables, switching between introductory screen and game screen and victory/defeat screen. -- Which is a lot of things, especially if you are doing it for the first time. And each of those things can become a separate problem, with subproblems, such as: "what to display on the screen while the bitmaps are loading, and what to do if the loading fails". Also, the language and libraries may create additional problems, for example to make animations in Java you have to understand the thread model and synchonization, otherwise mysterious bugs can happen. And I am still speaking about a Pong-like game.

Then a complex game contains more of the previous things, plus: reading configuration files, saving and loading a game, AI opponents, perhaps an installation program. (And nicer graphics and music, but that is outside of the programming scope.)

So doing the simple game properly -- not just on the "it works (most of the time)" level, but having a clear design and understanding how and why the parts cooperate -- is a very good start for making a complex game.

(Here is a trick you may find useful: After making the algorithm, you can hugely improve the impression of the game by adding nice graphics, even when some parts of graphics are completely irrelevant to the algorithm. For examples if different levels have different background images; or if the level contains pictures that don't interact with anything; or if the same thing is represented by different bitmaps in different levels, like trees with different shapes and colors, a level with things covered by snow, etc. A textbook example is the game Knytt. Also, nice screenshots create a good halo effect.)