How difficult is it to move from C# to C or C++, and which language should I use for a game-playing bot?
Asked by
MellowKite47
I'm comfortable with C# from developing games in Unity and using it for other projects. I'm interested in creating a bot for an open-source digital card-game simulator that explores every possible sequence of inputs, records the resulting playthroughs, and compares them to determine an optimal strategy. I may also want a search tool for examining specific lines of play.
The simulator is primarily written in C and C++, with only a small portion using other languages. Would learning C and C++ feel like learning two completely new languages, or would my C# experience provide a meaningful head start? For this project, should I work directly in the game's existing language, or would it be more practical to write the bot in another language and connect it to the game?
Answers
The shared syntax is useful: loops, conditionals, functions, types, and basic program structure will look recognizable. Your existing programming experience is a much bigger advantage than the language similarities themselves.
However, the standard libraries and common idioms are quite different. C and C++ also give you much more responsibility for managing memory and resources. If possible, focus on either C or C++ for the part youโre writing rather than treating โC/C++โ as one language; they diverge significantly in larger programs.
Reply to this answer
Your Unity experience may give you an extra head start if youโve worked with unsafe code, native collections, marshaling, pointers, or manually managed native memory. Those topics are closer to what youโll encounter in C and C++ than ordinary C# classes and garbage-collected objects.
A good starting plan would be to inspect how the simulator represents its game state and how actions are processed, then build a small tool that can read one state and choose one legal move. Once that works, expand it into a search algorithm. Exhaustively exploring every possible playthrough may become enormous, so you may eventually need pruning, memoization, heuristics, or a limited-depth search rather than storing every complete line.
Reply to this answer
For this project, using the simulatorโs existing C or C++ code is probably the simplest option if you need direct access to its internal game state. Since the project is open source, you may be able to add the bot directly or expose an interface that lets an external program query the state and submit moves.
Another language can still work if the simulator has a modding API, a network interface, or a clean way to communicate through a foreign-function interface. But adding a bridge introduces extra complexity, so itโs usually better to start with the language and architecture the game already uses.
Reply to this answer
C# will help with the general programming concepts and some basic syntax, but it isnโt especially close to C or C++. C# is more closely related to Java, while C and C++ require you to understand things that managed languages usually handle for you, such as pointers, manual memory management, object lifetimes, headers, compilation units, and undefined behavior.
C may feel familiar at first, but memory allocation and pointer usage can make it a major adjustment. C++ adds another large set of concepts, including templates, references, RAII, operator overloading, and multiple inheritance. You can learn them, but donโt expect the transition to be equivalent to learning a few new keywords in C#.
Reply to this answer
You may not need to rewrite the bot in C or C++ at all. If the game state is available as a simple array or other structured data, you could keep the search and optimization logic in C# and connect it to the simulator through an API, a plugin, or a small native wrapper.
The best approach depends on how the simulator exposes its state. If thereโs no useful interface, modifying the open-source game to call your bot directly will likely be more reliable than making an overlay that reads the screen. Screen recognition and simulated input are possible, but theyโre usually much more fragile than accessing the actual state.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions