next »

[Mr. Yes]

New one:

Code:

int main()
{
    Game game;
    game.letsGo();

    return 0;
}

[Ina Vegt]

Code:

(def main (fn [] (
  (var gameInfo initData)
  (var gameState (titleMenu initData))
  (gameLoop gameInfo gameState)
  closeGame
)

What lisp dialect is this? Or is it a part of some custom scripting environment? Looks interesting.
 

Clojure (Runs on the JVM, interacts just fine with Java and Java libraries, without any annoying porting or wrapping.)

[mirosurabu]

Code:

int main()
{
    Art art;
    art.speakForYourself();

    return art.emotions();
}

[Impossible]

In my current C++ game it looks like a lot of other people's loops

Code:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstnace, LPSTR lpCmdLine, int nShowCmd)
{
	ShadowGame ShadowApp;

	if(ShadowApp.Init())
	{
		return ShadowApp.Run();
	}
	else
	{
		return 0;
	}
}

I'm liking some of the templated versions of this though.  Might incorporate that later. (I also just realized I completely mispelled hPrevInstance ).

[Eclipse]

Code:

int main()
{
    Art art;
    art.speakForYourself();

    return art.emotions();
}

art.emotions() returned 0, sad.

[Melly]

 

[B. van Stokkum]

New one:

Code:

int main()
{
    Game game;
    game.letsGo();

    return 0;
}

This may be a stupid question, but are you using your constructor to initiate the game?  Or is that part of "letsGo()"?

[Gold Cray]

I don't know that you can use the constructor if you don't use a pointer. I guess I've never really thought about it though. If I were using the constructor I would do

Game* game = new Game();

[B. van Stokkum]

I don't know that you can use the constructor if you don't use a pointer. I guess I've never really thought about it though. If I were using the constructor I would do

Game* game = new Game();

Is a constructor not called every time a new object is created, regardless of whether it's on the stack, or the heap?

i.e.

Code:

GAME* game = new Game(...arguments...);
//or
GAME* game(...arguments...);

I wrote a quick program with a simple class that took an integer argument and printed it to the screen and it worked both ways.

I was just wondering because some of these examples have something along of the lines of:

Code:

GAME* game = new GAME();
game->init();
game->mainloop();

While others seem to just call a function that sounds like it's the game loop and not the init function, but it's hard to tell just by function names.  Is there any reason why you shouldn't init your entire game through the game classes constructor?

[Will Vale]

Constructors are always called when an object is created, whether on the heap or on the stack. Best not to allocate on the heap if you don't need to.

[AaronAardvark]

Some people like to have better granularity over when 'heavy lifting' is done by an object.  For a 'big' object like GameEngine, you probably anticipate heavy lifting to occur off-the-bat.  But, being able to delay when such things occur is usually desirable for the reason that Will Vale gave.

[mewse]

Code:

int main( int argc, char* argv[] )
{
	UNUSED(argc);
	UNUSED(argv);
	
	vsSystem *system = new vsSystem();
	
	/*  Create our game  */
	
	core::Init();
	core::SetGame( coreGameRegistry::GetMainMenu() );
	core::Go();
	core::Deinit();
	
	delete system;
	
	
	return 0;
}

This is the 'main()' from all of my VectorStorm games, such as MMORPG Tycoon.  "core" is the default game manager;  you can plug in an arbitrary number of games, and it'll let you swap between them at runtime.. though most of my releases only actually have one game in them.  The main loop itself is inside Core::Go, and it looks like this:

Code:

/**
 *  core::Go
 *
 *    This is our high-level game-running logic.  It brings new games in and out, as requested.
 *    It also initiates memory validation checks between games, and prints out game statistics at that time.
 */

void
core::Go()
{
	// Create the basic game systems which are shared among all games.  (Physics, input, etc)
	coreGame::CreateGameSystems();

	// In theory, everything persistant has now been allocated.  Anything allocated
	// from now on will be allocated by an individual game inside our special s_gameHeap, 
	// and will need to be deallocated by that game before it exits.  Tell our game-only
	// memHeap that it's at its position for leak testing.
	memHeap::Push(s_gameHeap);
	s_gameHeap->SetMarkForLeakTesting();
	
	// 's_exit' is set when a game requests the whole VectorStorm application exit.
	// Usually this is done by the coreGame watching for the 'esc' button, but
	// any game can also set this value manually, by calling core::SetExit().
	while ( !s_exit )
	{
		if ( s_nextGame )	// if we've marked a game to switch to
		{
			if ( s_game )		// if we're already running a game
			{
				s_game->StopTimer();	// stop gathering game stats first, so we don't
				s_game->Deinit();		// penalise a game's average FPS for how long their Deinit() takes.

				s_gameHeap->CheckForLeaks();		// verify that game actually deleted everything it allocated
			}
			
			s_gameHeap->PrintStatus();			// print the current memory stats to our log
			
			s_game = s_nextGame;							// activate the new game, and start its profiling timers.
			s_game->Init();									
			s_game->StartTimer();
			
			s_nextGame = NULL;
		}
		s_game->Go();		// run a frame of the current game.
	}
	
	if ( s_game )		// if we're already running a game
	{
		s_game->StopTimer();	// stop gathering game stats first, so we don't
		s_game->Deinit();		// penalise a game's average FPS for how long their Deinit() takes.

		s_gameHeap->CheckForLeaks();		// verify that game actually deleted everything it allocated
	}
	
	memHeap::Pop(s_gameHeap);	// pop our gameHeap back off the stack.
}

..it's actually commented rather well, imagine my surprise!   

But it's really all about sanity checking when switching from one coreGame to another, or when exiting the program;  making sure there are no memory leaks or etc;  the real stuff happens inside  coreGame::Go(), which is called repeatedly from core::Go(), and looks like this:

Code:

void
coreGame::Go()
{
	m_framesRendered++;
		
	for ( int i = 0; i < GameSystem_MAX; i++ )
		if ( m_system[i]->IsActive() )
			m_system[i]->Update( m_timeStep );
		
	Update( m_timeStep );
		
	if ( m_currentMode )
		m_currentMode->Update( m_timeStep );
	
	vsSystem::GetScreen()->Update( m_timeStep );

	for ( int i = 0; i < GameSystem_MAX; i++ )
		if ( m_system[i]->IsActive() )
			m_system[i]->PostUpdate( m_timeStep );
		
	vsSystem::GetScreen()->Draw();
}

"m_system" is an array of things derived from coreGameSystem.. these are things like input readers, sound players, physics libraries, timers, etc.  So first we update all of these, then we call 'Update' on the coreGame (this is usually an overridden virtual function, where game logic happens internally), then we call an Update on our screen itself (which sends 'update' messages to everything within the game's scenegraphs, then we do a PostUpdate on the systems (really just for physics to be able to recover from whatever movements happened during the scenegraph update), and finally we call draw.

Yay, complicated!     

[zamp]

Yay, complicated!

KISS (Keep it simple stupid)

Code:

int main()
{
    try
    {
        Core::getInstance().run();
    }
    catch (Exception &e)
    {
        e.print();
    }

    return 0;
}

[shivoa]

Rather boring, but this is the XNA generic opening

Code:

static class Program
{
	static void Main(string[] args)
	{
		using (Game1 game = new Game1())
		{
			game.Run();
		}
	}
}

[Average Software]

Since I'm here...

Linux:

Code:

int main(int argc, char **argv)
{
    // Initialize Gtk stuff.
    gtk_init(&argc, &argv);
    gtk_gl_init(&argc, &argv);
    glade_init();

    // If the program was not launched from the command line,
    // the working directory is wrong.  Use argv[0] to switch
    // to the right place.
    ChangeToProgramDirectory(argv[0]);
    // Create the game's data directory, if necessary.
    CreateDataDirectory();

    // Build the starting window.
    OptionsWindow::Create();
    
    // Enter the Gtk event loop.
    gtk_main();

    // Kill the window.
    MainWindow::Destroy();
    
    return 0;
}

Windows:

Code:

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int cmd_show)
{
    // Register common controls.
    InitCommonControls();
    
    // Register custom classes.
    if (!GLArea::Register() ||
        !ColorArea::Register())
    {
        cerr << "Window class registration failed." << endl;
        
        return 1;
    }
    
    // Create the game's data directory.
    CreateDirectory(GetDataPath().c_str(), NULL);

    // Create the starting options window.
    OptionsWindow::Create(cmd_show);
    
    MSG message;
    
    // Start the event loop.
    while (true)
    {	
        // Get the next message.
        if (PeekMessage(&message, NULL, 0, 0, PM_REMOVE))
        {
            // Kill the loop if it's a quit message.
            if (message.message == WM_QUIT)
            {
                break;
            }

            TranslateMessage(&message);
            DispatchMessage(&message);
        }
        else
        {
            // If there are no messages, run the game loop.
            MainLoop::Tick();
        }
    }
	
    // Kill the main window.
    MainWindow::Destroy();
    // Unregister custom classes.
    ColorArea::Unregister();
    GLArea::Unregister();
    OptionsWindow::Unregister();
    
    return message.wParam;
}

Mac:

Code:

int main(int argc, char *argv[])
{
    return NSApplicationMain(argc,  (const char **) argv);
}