Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Online Last Active Today, 01:24 PM

Posts I've Made

In Topic: How to set a namespace properly in this case?

Today, 11:15 AM

You can't write a "using" declaration for a namespace the compiler has not yet seen, and by the time the compiler is seeing the preprocessed WindowsMain.h you haven't declared the NameOfGame namespace. Do something to declare that namespace (even if it is empty) above WindowsMain.h:

// NameOfGame.cpp
namespace NameOfGame {};
#include "WindowsMain.h"

That said, this seems like a rather backwards approach as it requires what appears to be a general-purpose, library header (WindowsMain.h) to know something about the game-specific code that is consuming it (NameOfGame). It also requires a very specific and somewhat unorthodox code structure. There are definitely better ways at both the IDE level and the C++ level to handle this.

 

At the IDE level, you can pretty easily put multiple projects in a single solution (or multiple targets in a workspace, etc etc for whatever terminology your IDE of choice uses). Those multiple projects can share the same common source tree, except for their game-specific parts, or statically link to common functionality built into a library.

 

At the language level, you can write your main windows driver (main() or WinMain() function) to instantiate and use a Game object that implements a specific interface (e.g., IGame, where all your required entry points from WindowsMain.h are currently defined). Then, even if you don't want to go the route of creating multiple projects in the IDE, you can simply switch the game you run by changing main():

int main (...) {
   AsteroidsGame actualGame; // Change this to BreakoutGame or whatever to switch.
   IGame & game = actualGame; // illustrating interface only, not actually needed.

   return game.run();
}

You get the same result without the brittle nature of the technique you're trying to employ right now. I still don't think it's a great idea (you still have all that other code for other games sitting around and getting potentially rebuilt all the time), although you can alleviate some of the weirdness further with macros and preprocessor tricks. Really should just learn how to use multiple projects at that point though.


In Topic: Are Third Party Game Engines the Future

26 May 2016 - 09:35 AM

a team has full control over how an internal engine changes or evolves but do not have the same control over a third party engine.

 

 

 

Not necessarily true. It's quite possible to get full-source licenses to several popular pieces of middleware, including Unreal. At that point you can do anything you want, generally (including not take further updates and evolve in whatever direction you choose).

 

One could make the argument that it's still harder because you didn't write the code and so you don't know it as well as code you'd write in-house, but it's usually pretty easy to learn, and that argument washes out as soon as the internal engine gets old enough that the original authors of pieces of code leave the company.


In Topic: Game Engine success question.

25 May 2016 - 01:57 PM

You're also, I think, placing far too much emphasis on the "engine" as being the crux of the "success" of the games. But that's not really true; you can make two games on the same engine and one of those can exhibit all the "problems" you described while another will not. There's a lot more that goes into the production of the game's own systems and content that can factor into the quality of the resulting product. It's not just about the engine.


In Topic: 'Week of Awesome 2016' Game Jam at GDNET?

25 May 2016 - 09:23 AM

Does "participate" in the first question mean "participate in any way including just judging?" Or does "participate" just mean "make a game for?"


In Topic: Best gaming platform in the future with marketing perspective.

19 May 2016 - 10:27 AM

I think this discussion of the pros and cons of various Microsoft products, services and strategic decisions is veering a little too far off-topic at this point.


PARTNERS