KenBot: C# has yield!?! and other relvalations

So, it just hit me that the yield keyword that I wanted to use to use to implement a bot in Python can actually be used in C# in an iterator. This has inspired me to update my design to use yield.

Let me explain what I mean. Now, normally, my bot goes through a loop like this.

  1. Collect information about current game state.
  2. Check and see if something is happening that requires the bot to stop what it is doing to react
  3. Continue doing what the bot was doing.

I implemented this using a simple state framework, where each state has variables it uses to store how far it is along doing whatever its doing. Each frame the state is called, and it presses what every buttons it needs to press that frame. The annoying part about this is that if you wanted to make a state that say, presses D, F, D, F, HP, you would have to write it so that it’s a function that gets called 5 times, and inputs the proper button on each frame. That would look something like this.

int i = 0;
function example()
 if(i == 0)
 if(i == 1)

I don’t like this, and it was the primary thing that made me get annoyed working on KenBot.

Now, the yield keyword isn’t normally used the way I am preparing to use it, but it actually solves more than one issue. The updated code will work like this.

function example()
    yield "I just pressed D";
    yield "Oh yeah, just pressed F";

In this example, it may seem like its the same about of glue code in between the code for each button press,  but there’s normally a lot more decision making and programming going on than this.

I am going to try to refactor my code this weekend and see how far I get into this and see if it helps anything.

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.

Continue reading KenBot: Postmortem or New Beginnings?

The Legend of KenBot #3: Reaction Based Beast

KenBot v1 was very basic. Most of his gameplay revolved around one specific chain of events.

Is the opponent doing nothing? Mash DB,DF.

Is the opponent doing something near me? Mash D+PPP,F+PPP.

Am I being thrown? Mash Tech!

This alone proved effective, but with some limitations. I can’t seem to get past about 3 frames of input delay. This means that KenBot will never be able to react to a 3 frame move on reaction! However, since he mashes DB,DF, he has a 50% of randomly blocking one of them anyways. Command grabs will hit him, unless they are slow like Abel, Honda, etc.

Here KenBot counters cr.LP and cr.LK, but NOT st.LP or st.LK, because they are 4 frames So, this means that many jabs, and a ton of command grabs will just hit KenBot! And Shoryukens! And…a bunch of other stuff too. At this stage KenBot didn’t understand overheads, or moves that were too fast to punish with DP or Ultra. You could Focus backdash at the right distance and KenBot would fierce DP!

He had to become smarter! He had to become more aware! And in order to do so, I needed to get more feedback from the bot! So, I took KenBot, who at this point had a ton of hardcoded reactions for a few character states, and rewrote the code and added a GUI.

My next article will be about training KenBotv2 to…do a lot more than DP.


So, the world likes KenBot.
Twitter followers.

Thanks to all that have been spreading my work around. Its pretty awesome to see something I made in the past week get thousands of views.
Normally I work on boring things like modding tools, or reference sites. Its fun to work on stuff that is a bit more entertaining for the average gamer out there.

The Legend of KenBot #2: Creating a Monster

So, how does KenBot work?

Well, lets think about how any AI needs to work. Not even that, lets think about how any game is played. Almost all gameplay can be summed up kinda like this…

The player makes inputs based on stimuli provided by the game.

Its easy to think about this from a real players perspective. You see your opponent jump at you, you wait until they are on their way down, input a Shoryuken motion (forward, down, down-forward)  and press medium punch…and then you hold focus attack, dash forward, and input your ultra!!!

This sequence is common, but what does it take for a bot to do this?

  1. The bot must be able to input commands.
  2. The bot must be able to read game state.

For example, in the above example, the bot may need to know…

  1. The X and Y location of it and its opponent. It needs to know when the opponent leaves the ground, and how close they are, in order to know how to time the SRK
  2. How much meter it has, so it knows whether it has ultra or meter to FADC ultra with.

To input commands, the bot simply sends keyboard events to the game. To read gamestate, the bot reads the memory of the game’s process to determine what is happening. The values were found through Cheat Engine.

Seems pretty simple right? However, what happens if the person jumps backwards? The bot would see the person in range, but in reality the person will be out of range by the time the SRK is inputted and comes out!

KenBot v1 wrote status information to a file. I then used OBS to overlay the status information onto the game in my recordings.

When KenBot loses, I look at the footage frame by frame and adjust how things work, coding exceptions, new rules, and some character specific matchup knowledge!

Here is a good example from my previous post.

In the last two rounds the bot keeps getting hit by long range pokes. These moves are so slow that the bot SHOULD be blocking or SRK’ing on reaction based on distance…so what was happening?

Two failures. The bot tried to SRK backdashes, and failed multiple times. Then the bot got stuck in its Karathrow script.

This was unacceptable. Time to take KenBot to the lab.

In this video, you can see KenBot’s accuracy in offline play. It won’t walk forward unless Balrog goes to neutral, and its SRK mashing is fast enough to ATTEMPT to shoryuken Balrogs EX headbutt (even though HP shoryuken happens second, the EX headbutt wins)

In my next article ill write more about making KenBot…PSYCHIC.


The Legend of KenBot #1: Intro

KenBot playing ranked.

So, I have dabbled in messing around with Street Fighter 4 PC, reverse engineering the  file formats,  building the Ono! editor, and trying to rip framedata…but…this post is about a new project.

I stumbled upon lullius’s, a site where he has made a variety of tools that do things in realtime while the game runs, such as a hitbox viewer, camera controls, and a macro playback engine…and even a Bot.

You can check out his bot here.

And here’s a video of it beating arcade mode.

His bot is pretty good. Beats arcade mode on hardest using no continues.

Now, this got me thinking. With my intense knowledge of the game, could I make a bot that can not only accomplish this feat, but beat people online?

Enter KenBot. Here’s a vid of KenBot v1 winning a match online!

But KenBot v1 wasn’t perfect. Some people figured out his patterns within one match and abused his robot nature.

To view all the KenBot v1 videos, check out this youtube playlist!