C++ Interface

[cinjon]

People have expressed interest in having a c++ interface so that the game could be simulated faster. This would be a larger endeavor and it would be great if we discussed what it would take and who would be keen to lead this here.

@tambetm @b-kartal @gorogm

[inoryy]

Hello,

I guess I can take the lead, I was planning to do this for my bot anyway . :) I'm currently in discovery mode, deciding on how to specifically approach this. I will probably start actively developing towards the end of next week.

Any particular requirements/requests?

[dist1ll]

Hey I have already started with some basics.

I haven't updated the README because the source is quite raw.

https://github.com/m2q/nips2018-agent

• The state representation is in bboard.hpp
• The agents can be declared in agents.hpp

I supplied a make file and a run.sh shell script, running it should simulate a couple of steps of the game with 4 random agents. The main.cpp has an exemplary Run() method.

The method bboard::Step(..) has some basic collision detection.

To really make this work I planned to integrate automatic unit testing, to really make sure the behaviour exactly matches the pommerman source.

Edit: This was only tested on Ubuntu 18.04, uses g++ and c++11

[gorogm]

Hi @cinjon @inoryy @m2q, It would be great! The 100 msec maximal response time seems thin for online search methods, so a C++ core would be really useful!

I know C++ doesn't have standard 2d drawing abilities, but I'm sure some basic visualization would also be helpful for any developers.

Later it would be nice if it had a prepared way to submit as a docker package with the needed interface.

I could give some time to develop one, let it be m2q's or an other one.

[b-kartal]

Hi all, I would be happy to give a hand as much as I can as well. I believe it will be very useful for particularly search based agents.

Sent from my iPhone

On 10 Jun 2018, at 12:54, gorogm notifications@github.com wrote:

Hi @cinjon @inoryy @m2q, It would be great! The 100 msec maximal response time seems thin for online search methods, so a C++ core would be really useful!

I know C++ doesn't have standard 2d drawing abilities, but I'm sure some basic visualization would also be helpful for any developers.

Later it would be nice if it had a prepared way to submit as a docker package with the needed interface.

I could give some time to develop one, let it be m2q's or an other one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dist1ll]

I'm currently printing ascii to the console. Not ideal but you can see what's going on (at least for bricks and agents)

[suphoff]

@gorogm : Probably easier and more portable to just export the data in the existing json format using file/socket/tcp and just run the existing python rendering interface for visualization as needed for replay/debugging.

[suphoff]

FYI: There are still a few bugs in the agent/bomb movement code. @cinjon is reviewing a patch. I won't have time in the next 4 weeks to help - but I can explain the movement rules if needed. I wrote a small python script to set up bombs/agents to test the patch for the step function. Running a few scenarios on the script may help to understand desired behavior. (Too ugly and incomplete for github - ping me on discord if you want a copy )

[lucasb-eyer]

I think I'm missing something, why would a C++ interface make the game (which is still Python code) run faster? Or are you talking about a re-implementation in C++?

[cinjon]

You're right @lucasb-eyer. I should have been more clear. This isn't about creating a C++ coding interface, but about coding a C++ forward model so that the game can be simulated much more quickly. That would be a big help for a lot of model approaches.

[lucasb-eyer]

In that case (just to add my salt :smile: ) it might be better to do it in C, so that any language can easily interface to it.

[dist1ll]

I think C++ is fitting because there is a pytorch library for C++. Imo (and this is purely subjective) C makes lots of stuff unnecessarily complicated, especially string manipulation.

Also, I can't think of any language that would have trouble invoking C++ functions, afaik

[lucasb-eyer]

Also, I can't think of any language that would have trouble invoking C++ functions, afaik

No, all languages have trouble calling C++.

Because the C++ ABI is undefined, it is only possible to call into C++ safely from another language if that language (or language's FFI) has been compiled with the same major compiler version as the C++ code it should call. For instance, Python's ctypes can't call into C++. Actually, no language can call into C++ unless they somehow know how the C++ code was compiled. Hence why people need to create C interfaces (extern "C" {...}) to C++ libraries for calling them. Think about how another language would call a templated C++ function? It can't.

Edit to add that I don't disagree with you on C making things like strings more complicated, but being called from other languages is the one thing that C++ makes unnecessarily complicated.

[gorogm]

Let's remain practical, I smell we won't have enormous resources. @lucasb-eyer, are you planning to use the lib from any other programming language?

[lucasb-eyer]

I can't say so with certainty, no.

Mind you, I know it's a lot of effort, I just wanted to point this out so it's a conscious decision. My last message might have sounded like "you really need to do it in C!!!", sorry for that it's not at all what I meant. I just wanted to clarify how and why "I can't think of any language that would have trouble invoking C++ functions" is not true. Especially since I cannot help in this effort, feel free to disregard my comments entirely :)

[dist1ll]

You're right Lucas, apparently C++ really has major trouble with meaningful language bindings. I've only implemented basic POD-functions for external use, so I never thought about the ABI of all the other c++ features

[gorogm]

Heyy :) Who will have time to code in the next some weeks? Actually, I think it would be nice to create something in a month so that there will be enough time to experience with it, what do you think?

Do you - who plan to contribute and use it - think that we should create a whole Agent in C++ with docker integration, or keep the upper layers in python, and only create a loadable shared library which implements the forward simulator?

[cinjon]

Heads up that we added a $1k GCE reward for community contributions (https://www.pommerman.com/competitions). A much faster forward sim would fall under that bucket. It seems like you all are a core group interested in making this. Want to regroup over in the Discord and we can come up with a plan together?

[AdamStelmaszczyk]

Hello :) C++ pommerman model is a great idea.

I'm currently printing ascii to the console.

I have a working code that can convert ASCII to nice GIFs, for examples have a look: https://github.com/AdamStelmaszczyk/gtsa

There's also more in that code that could be used here: unit tested (on 3 different games) NegaScout (with improvements) and MCTS implementation.

The state representation is in bboard.hpp

This can be easily integrated to GTSA, this is the primary use case. One only needs to specify pommerman game rules by subclassing State and Move classes and then can use NegaScout, MCTS, statistical significance tests (Tester class) out of the box.

My intuition is that even NegaScout with good heuristic can result in strong pommerman play, would be for sure a good baseline. Because Isola game is quite similar and NegaScout plays on superhuman level in that game.

The next step could be replacing the hand-coded heuristic with a neural net, trained with self-play. And then sky is the limit :)

Update: re "This can be easily integrated to GTSA, this is the primary use case. One only needs to specify pommerman game rules (...)". I realized that it won't be as easy as that. NegaScout and MCTS assume 2 players, so I would need to first generalize them to 4 players. Update 2: done, now GTSA handles arbitrary number of players.

[terryzhao127]

Is there still anyone interested in re-implementation of Pommerman which has better performance?

I think @tambetm 's implementation in Cython is a good start point.

And @m2q 's implementation is in C++.

Both of them have a much better performance. However, I have no idea whether their API is same as the latest of Playground. And they may be lack of Docker agent and so on.

[vladium]

I don't know if this topic is still of interest a year later. I came here after realizing myself I'd want to re-code pommerman in C++ -- unless the bulk of computation can be vectorized through Numpy, I am certain that Python will be 50-100x slower for pommerman training. (RL algorithms tends to be of iterative nature that's hard to vectorize.)

If I were to try to "modernize" pommerman while increasing performance and maintainability I'd consider Rust or Julia.

Rust is a kind of "better C++" with major selling points being safer/easier thread programming. This happens to be relevant to pommerman, I think, since I saw somewhere that multiple agents runs in concurrent processes/threads. Rust is rapidly gaining popularity and is likely to be a more maintainable solution going forward. (I say this despite being a very seasoned C++ programmer who is very comfortable with c++11/14 as one of his languages for research.)

Julia is more niche but is aimed squarely at R/Matlab/python users, i.e. it's a language for technical computing. Julia aims to solve the "two language problem" (that pommerman appears to be suffering from): often the best language to research in is not the best for running research at scale. Compared to, say, R or Python, Julia has more typing and a very serious JIT.

Both Rust and Julia tout ease of bridging into other languages. Julia has more plotting capabilities right now, but they are all instances of re-using python or R. I would imagine that saving traces into some form of JSON would enable visualization via toolkits like Plot.ly or some other JavaScript -- potentially opening pommerman to running on the web/in a browser.

[gorogm]

m2q's above mentioned c++ implementation is good enough to win the 1st place :) Fast and 99.5% accurately does what the python server does.

[vladium]

I suspect that's because there hasn't been much real competition yet 😛

Ok then, this issue is resolved then, no help wanted? Or is the research team behind pommerman interested in continuing with the benchmark? More contests, different contests?

[cinjon]

To date, we have had a strong push for C++ and python support and not for Julia or Rust. However, we are certainly interested in contributions that push the environment forward, especially if it is accompanied by strong agent submissions :).