Welcome to the forums!

I recommend you reading this two articles, they were helpful for me, hopefully they will be helpful for you as well :)

http://lazyfoo.net/articles/article04/index.php

http://www.koonsolo.com/news/dewitters-gameloop/

Basically, a game goes through an initialization phase setting up everything it needs, then enters the game loop, which repeats until an exit condition is satisfied (such as the player choosing a Quit option from a menu).

Several things can happen in a game loop. Typically there's a means to keep track how how much time has passed since the start of the previous loop. Input can be polled from the player (also any AI routines for enemies or input from the network if your game is multiplayer).

The game updates based on this input and what state the game may be in (menu, ingame, paused, win/loss. . .). Game objects may be moved, stats may be altered, physics may be simulated, the game may enter a new state. A lot of things can happen here.

Graphics and/or audio is updated and rendered based on whatever logic has been updated.

Rinse and repeat.

That is true for a subset of games. Most of the interactive console style games follow it on a broad spectrum.

Many of the popular games follow the model.

However, it is not true for most games on the market. Many are event driven, turn driven, input driven, or compute driven, rather than a tight loop of render/simulate.

For a few....

Text adventures are not render/simulate.

Chess and checkers and forms-based games are not.

At the extreme, Deep Blue, a massive chess simulator, is not based on a render/simulate loop.

A large percentage of mobile games are turn based where they take some action and wait for input, are not tight render/simulate loops since that rapidly drains batteries.

Many online games may present a client that does its own graphical things but under the hood are REST-based turn oriented games where the data tells the database to run a small update, and the client happens to be visual but is unnecessary; the client may present lots of graphical and visually interesting effects but they are completely irrelevant to the actual game component.

The loop adds a lot of difficulty because you are suddenly in the realm of soft realtime requirements. You must update regularly or it is a defect. That means you need to restructure all your algorithms to run within the time frame, or structure them to span frames somehow.

So while the tight render/simulate loop is one of many possible options, it is also one of the more compute-expensive and annoying routes to implement.

Games are really one big complex loop.

The actual model is.

Initialize Executable

-Reserve a Memory Pool = The game can actually outrun the Operating systems Memory allocater. So having a knowledge of how much you need ahead of time helps a lot.

-Initialize Objects = Usually what ever the game needs either at the moment or in the future.

- normally a Do While Loop = Faster close outs, rather than looping for one more frame and then exiting.

Event Functions

- End of loop

And then for Consoles on exit, a common method of a lot of older games is simply to force the system to reboot.

PC games... is a little more complicated on exit, as memory isn't freed automatically for older systems, and Vista. Newer systems "should" free memory on program's shutdown.

What language the game is built on greatly depends. You can make games with any langauge, but performance is something that usually matters a lot.