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!

SFUltraDiff v0.1 release!

So, with the clock running down, and the date for Ultra fast approaching, I set to work last weekend, laying down the basis for what would become SFUltraDiff. And now, without a minute to spare…the first version is done.  Wait, what? 

Well, Ultra comes out in June so…I am very early. It turns out that I am a much better programmer than when I originally wrote Ono!, my GUI tool for editing SF4AE PC, and having the source code to Ono! accelerated development, even though Ono! was written in C#/WPF and SFUltraDiff is written in python and outputs HTML pages.

SFUltraDiff is written for Python 2.7 and uses the fantastic Twitter Bootstrap project for most of the formatting.

There is still a lot of stuff to do. It only displays raw data, without much formatting, even for values that have been known and understood for years. For example, it shows hitbox types as a number, even though we know 0 means PROXIMITY, 1 means MID, etc. That is the next easy step in terms of  making it readable.

Also, it doesn’t output in game frames ATM, it outputs in animation frames. Let me explain. Commands in scripts are timed to the frames in the animation, and then the animation is sped up based on multipliers. For example, the animation for a move might have 60 frames even though the move in game might not be anywhere near that long. The commands for when hitboxes come out, SFX, GFX effects, etc, are timed to the animation. Then, a speed multiplier is applied to the animation that changes how fast it is played, and how fast the script is run. This allows for Capcom to change the startup of a move and still have everything else line up with the animation! Its really clever and I will be stealing it for any game I make!

Anyways, more updates in the future from me.

SFUltraDiff: My New Project

Ultra Street Fighter 4 is on its way, and it looks like it may be the last version of the Street Fighter 4 series we may see. Last weekend at Southern California Regionals in Irvine, California, Capcom announced a new feature that has the community hyped.

Dubbed “Edition Select” it allows for the selection of any version of a SF4 series character, from the original Street Fighter 4 release (vanilla!) all the way to the latest version, Ultra Street Fighter 4. These older characters will only have access to moves and functions that were included in the game they are from, but it remains to be seen how accurate these will be. In particular interest to me are the vanilla-only glitches, as well as some things that affect the community now in AE2012, such as unblockable setups.

Introducing SFUltraDiff

My goal is to create a tool that analyzes the files and provides a machine generated list of changes from Vanilla SF4, all the way through Ultra. I think it will be interesting to see how SF4 has developed as a whole over the last few years, and as Ultra is most likely the swan song of the SF4 series, it will be fun to see if there are any changes that are undocumented that affect gameplay, or bugs that were never discovered.

Who are you?

In writing this, it may seem kind of random for some guy no one has heard of to be wanting to do this. However, even if you don’t recognize the tag ‘dantarion’, I can guarantee that you’ve heard of a few game mod things I have had my hands on. I reverse engineered the file formats for AE and SFxT already, and produced a tool called Ono! that can be used to edit them. Shoryuken has posted articles about things people have created with Ono!, but I don’t think they have really covered the program itself before. I think SF4Remix is probably the most prolific thing that has been made with it, and they were the primary catalyst in the improvement of the program after its release. In addition to reverse engineering the SF4 series engine files, I am one of the founding members of Project M, a competitive mod of Super Smash Brothers Brawl on the Wii.

The Challenge

The challenge here is to see if I can complete this before June, and provide a full list of changes, framedata, etc, within one week of the release of Ultra Street Fighter 4 on Console.

There will actually be a lot of difficulties in terms of making this happen.

1. The file formats could change.

Right now I am betting on the BAC and BCM formats remaining the same or similar as they are in AE. From Super all the way to AE2012, the format hasn’t changed, but the original release of Vanilla has a slightly different format than games after Super. I am assuming that for ultra, Capcom has converted the vanilla files to the Super format. If this isn’t true, or Ultra is using some brand new format, I will have to hussle to get the work done.

2. I don’t know how to actually automate frame data for certain moves.

Many of the moves are coded to end when the character lands, so as a result, I would need to determine the size of the collision box, how long it takes to touch the ground again, etc. This is bit beyond the scope of what I want to do. I will most likely have perfect data for all normals and most specials, but for some moves, the only way to get frame advantage data is to test in game.

3. Even with a text-based diff of the files, I am not sure how to present all changes.

For example, lets talk about one nerf we already know happened in the SF4 series. Ryu lost range on  cr.MK. Now, without a screenshot or hitbox display, if I told you the hitbox shrunk in width by .2 units, does that mean much to you? Probably not.

There are likely a lot of small changes like that that are hard to visualize even though we know they exist.


I know this is a lofty goal, and that in the end, the changelists provided by Capcom may actually be completely accurate. I am using this as a programming project for myself more than anything, but if I am able to provide the community with a look behind the curtain in terms of how the game works, I hope that is appreciated.