There is only one game

[GoogleCodeExporter]

fact:
Starcraft can only run once on a single PC. BWAPI connects to only one 
game instance.

deduction:
All Broodwar->doSomething() methods should be renamed into 
Broodwar::doSomething() (or Broodwar::DoSomething()?) functions. Whereever 
the Game object was needed, it's existence should be implicit.

what do you think?

Original issue reported on code.google.com by goo...@teabix.com on 28 Nov 2009 at 8:06

[GoogleCodeExporter]

Yeah I think this would be a good way to go. I've been annoyed by the need to 
use
Broodwar-> all the time, but never found a clean way to get rid of it, since 
all the
functions are member functions of Game/GameImpl. Right now only a pointer to 
Broodwar
is all that is passed during the newAIModule() function. Maybe we could pass 
all the
function pointers in to the AI Module as parameters, but I'd rather avoid that 
as it
would look messy. I suppose we could instead do something like this for every 
function:

namespace Broodwar
{
    int doSomething(int param1, int param2)
    {
       return Broodwar->doSomething(param1, param2);
    }
}

so Broodwar::doSomething() would really just call Broodwar->doSomething(), but 
maybe
there's a better way to do this.

Original comment by lowerlo...@gmail.com on 29 Nov 2009 at 12:10

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

then there is the question: should one AI module be able to connect to more 
than one 
starcraft instance simultaneously? (technically, this is possible)

Original comment by goo...@teabix.com on 2 Dec 2009 at 5:54

[GoogleCodeExporter]

> should one AI module be able to connect to more than one 
starcraft instance simultaneously?

No, seems like this feature would add a lot of complexity for negligible 
benefit.

Original comment by lowerlo...@gmail.com on 7 Dec 2009 at 6:12

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by lowerlo...@gmail.com on 7 Dec 2009 at 6:14

• Added labels: Priority-Low

[GoogleCodeExporter]

If we want to convert this interface to COM someday, we shouldn't make this 
class to 
a namespace

Original comment by goo...@teabix.com on 9 Dec 2009 at 4:24

[GoogleCodeExporter]

functions like "printf" and "Connect" are already exported from other .dlls. To 
avoid naming conflicts we would need to prefix all Game namespace functions.

This and the fact that if we want to make BWAPI a COM interface someday 
definetly 
cries for keeping Game an object and not making it into a namespace.

Original comment by goo...@teabix.com on 20 Dec 2009 at 4:14

• Changed state: Questionable

[GoogleCodeExporter]

morphing bwapi to COM someday turned out to be a bad idea.

The naming conflict solved itself because without need for portability we can 
use 
all C++.

Is fixed in BWAPIv3.0

Original comment by goo...@teabix.com on 1 Jan 2010 at 6:39

• Changed state: Fixed