KenBot: Postmortem or New Beginnings?

So, I put a lot of work into the most recent framework for KenBot, and I created something that was usable for more than just me. I brought it to EVO, but I wanted to spend more time enjoying EVO than sitting around babysitting a Kenbot station,  so not many people got a chance to play it. The code repository I published has been used by multiple people to create SF4 playing bots for different characters, to the point where I consider it to be a success.

However, I am not satisfied with the framework. It is clunky to use, and I want to make something that I can modify and use for any game, period. To do this, I need to abstract some major features out of my current codebase.

The basic loop that an AI bot goes through is a bit like this.

  1. Collect information about current game state.
  2. Make decisions about what needs to be taken.
  3. Send Inputs back to the game
  4. Repeat

Out of these steps, a lot of it is game specific, but a lot isn’t. I attempted to create a framework that enabled easy coding of a state framework, but I feel like I failed. The issue I had was that it was hard for me to return from the state framework from frame to frame, maintaining state variables, etc.

I think if I ever try this again, I would want to transition to using Python 3 instead of C#. I really like Python better than C# for fast, incremental development, and there many built in language functions that benefit an AI framework, such as the yield and yield from keywords. However, the more and more I think about this, the more and more it points me towards my ineptitude in both C# and Python.

I suck at Python?

Why didn’t I do this in Python to begin with? Because the C# path for doing this was easier. The main things that I didn’t understand were how to call the Windows API functions I would need to call to read memory or send keystrokes to a process, and those were easily found in libraries in C#. I let the ease of using libraries for those functions steer my direction towards a language where I could get things running ASAP, at the expense of the meat of the AI coding.

I suck at C#?

But even though I feel like Python is better suited for this, I also feel like this shows that I am not as adept in C# as I want to be.  There is definetly a better way to structure the framework I made, but my limited usage of different design patterns in C# probably made it much harder than it needed to be. As my program grew and my bot got more sophisticated, I began to feel like I was just tacking stuff on, and nothing really felt as elegant or as focused as I really wanted it to be. That was one of the reasons why my work on the bot kinda stalled. The simpler bot was performing better, because the framework structure I implemented was actually making things worse.

The solution?

I have too much on my plate to revisit KenBot right now, but it is a nice project to have to look forward to. Street Fighter 5 is on the horizon, and I will be trying to create a new KenBot once the PC version for that is out, if possible. There are a lot of neat things I could try to do to make a 100% unbeatable bot, and that is still my goal with this project.

If you made it this far in this undoubtedly unfocused rant of a blog post, I commend you!

3 thoughts on “KenBot: Postmortem or New Beginnings?”

  1. Thanks for your work on KenBot! I’m interested in making a similar thing for SFV, so I’m reading through these blog posts and the code for some inspiration. I’d be doing this in Python, my C# is way too rusty. So far, I’m just sending inputs on time.sleep delays, but ideally I’ll use the sorts of yields you mention to clean the whole thing up.

    Do you have any advice on where to look to grab position and action data out of memory? I assume you did the reversing to get that debug info out of SF4? Right now, my bot can’t even tell if it’s on the left or right, and while pywinauto can do screen scraping and image recognition, I think it’d be way too slow for the AI to make a decision.

Comments are closed.