A programming language is not a game development framework

I think many people fall into this trap. You have an idea for a game, so you start coding. Everything goes well at first and by next week you have an awesome demo to showcase your upcoming game: your player can do some awesome moves, the graphics are slick, and it all looks promising. But then...months go by and progress has sharply declined. Sometimes there is nothing more to show. What happened?

From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.

There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.

The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.

A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.