Breaking UNIEL: Part 1

July 24th saw the release of a new fighting game, Under Night In-Birth, on both PSN and retail media. As with any fighting game, understanding move properties is very important to getting an advantage on your opponent. In the past, this data was gathered through intensive training sessions and extended periods of gameplay. After hundreds of hours of gameplay, you can figure out, X move is faster than Y move, etc.

However, its 2014 and I don’t have time for that. Kappa.

Lets get the data we want!

The first thing I did was buy the game, and get it running both on both the retail and jailbroken PS3. Then I examined the games disc structure. A quick glance around showed a folder called script. A quick glance in that folder showed a bunch of plan text scripts.

There was literally a text file with the words “NoLocalDebug” in it! And in it contained a list of constants for debug mode, with everything set to 0 (off)

So, I look this file and changed all the 0′s to 1′s, enabling all the listed debug functions available in the game, and booted it back up! The result was some extra data appearing in-game! The game now shows the startup, active, and recovery frames of each move, as well as frame advantage on hit/block. Heres a video of it in action!

And heres another!

However, this was not good enough for me. Its one thing to be able to see the framedata in-game, but its another to be able to review the framedata offline. Ideally, youd want all the info laid out in front of you in a table, allowing you to study it when away from the game.

I will cover the voyage towards that in my next post

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.

Publicity

So, the world likes KenBot.
Twitter followers. http://twitter.com/dantarion
/r/Kappa. http://www.reddit.com/r/Kappa/comments/2bbmy1/someone_created_a_sf4_bot/
Eventhubs. http://www.eventhubs.com/news/2014/jul/22/computer-controlled-kenbot-goes-online-and-terminates-competition/

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.

Capcom PLS

Also, testing Facebook/Twitter WordPress integration.

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 http://www.slitherware.com/, 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!

Doors and Such

http://www.lizengland.com/blog/2014/04/the-door-problem/

This blog post was very interesting to me, it definitely reminds me of working on the Project M team, as well as interactions with my coworkers at work. Everyone has their own take on things, depending on their role in the project, and while it can be frustrating, it really helps to be able to understand all the perspectives that come with software development.

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.

http://watissf.dantarion.com/sfultradiff/

code and chaos