This is an unfinished article posted to save it sitting in Draft limbo forever.
Now that we have our game state we can move on to working out what move we should make. We could, if we wanted, just click randomly on the game board and hope for results but that wouldn't really be in keeping with the project's aim, we want the system to actually play the game.
Deciding what the best move is depends on what we feel best means. Imagine a shoot'em up game where we are flying through space blasting aliens. We might decide it is best to go for the power up first and then dispatch the enemies or we might decide it is better to clear the screen of enemies and think of power-ups as a secondary objective. If we really wanted we could create a machine leaning algorithm that decides itself what is best based on experience, but that is for another day! For now we will stick to deciding ourselves what our goal is and that will help us decide what the best way to achieve it is.
A blog discussing my successes, failures and in-betweeners whilst working on computer vision related projects.
Showing posts with label Game Player. Show all posts
Showing posts with label Game Player. Show all posts
Wednesday, 28 January 2015
Tuesday, 9 October 2012
Game Player - Step 1.5 - Tidying Up The Code
We have done a lot of work over the last few posts and looked at some interesting features of OpenCV.
As it stands there is a lot of this stuff, although handy for debugging, we don't need in our final system. Things like the calls to printf and cout slow the system down unnecessarily so we can remove them. We can also take this opportunity to separate the majority of the code into its own method that completes the task of getting the game state. This will make the flow of the call to C easier to see and allow us to easily replace ways of completing a task (such as finding the colour of a game piece in an image) easier which is handy if we want to try out new algorithms.
As it stands there is a lot of this stuff, although handy for debugging, we don't need in our final system. Things like the calls to printf and cout slow the system down unnecessarily so we can remove them. We can also take this opportunity to separate the majority of the code into its own method that completes the task of getting the game state. This will make the flow of the call to C easier to see and allow us to easily replace ways of completing a task (such as finding the colour of a game piece in an image) easier which is handy if we want to try out new algorithms.
Wednesday, 26 September 2012
Game Player - Step 1 - Finding the Game Board
I seem to be spending a great amount of time writing blog posts and not a huge amount of time actually progressing with the program. I think this is because a lot of my time so far has been spent capturing screen shots for the setting up portion of the system so now that that is over with things should proceed a bit more briskly.
So we've got our image data in C and we also have the ability to generate a window, let's combine the two so we can see our image from C and that way we can be certain that we do in fact have our image data and not just a jumble of non-sense.
So we've got our image data in C and we also have the ability to generate a window, let's combine the two so we can see our image from C and that way we can be certain that we do in fact have our image data and not just a jumble of non-sense.
Labels:
arcLength,
C,
C++,
drawContours,
findContours,
Game Player,
imshow,
inRange,
Java,
JNI,
Mat,
OpenCV,
rectangle,
Scalar,
sleep,
Step 1,
V0.1.1
Wednesday, 8 August 2012
Game Player - Step 1 - Setting Up and Using OpenCV
This is the part I hate the most because it can be fraught with errors and you can end up spending masses of time on what is essentially just setting up the environment. I don't mind spending ages on a problem when it is a problem in development or trying to work out how to solve a tricky algorithm issue but spending ages on just setting something up drives me mad. Hopefully it will go smoothly this time...
Labels:
C,
C++,
cvNamedWindow,
cvWaitKey,
Game Player,
Java,
JNI,
OpenCV,
Step 1
Friday, 3 August 2012
Game Player - Step 1 - Transfer BufferedImage to C
When we ended the last post we had our screen captured and stored in a Java BufferedImage object. The problem we face now is that we want to do all our reasoning inside C using OpenCV, not in Java, so we need a way to gain access to the image data from C. This is where JNI and our native methods come into play.
So far we have only defined one native method that prints a line to the screen letting us know the library has been loaded successfully. In reality we don't need to print this message as an exception will be thrown if the library doesn't load but we'll leave it in for now just for the added reassurance. We will also define another native method but this time we will pass in our newly acquired image with it. There is just one small task we want to do before hand though...
So far we have only defined one native method that prints a line to the screen letting us know the library has been loaded successfully. In reality we don't need to print this message as an exception will be thrown if the library doesn't load but we'll leave it in for now just for the added reassurance. We will also define another native method but this time we will pass in our newly acquired image with it. There is just one small task we want to do before hand though...
Saturday, 7 July 2012
Game Player - Step 1 - Capturing the Board
Right, Step 1 in our Game Player program is capturing the game board.
This is actually an incredibly easy step so before we do that let's do a little setting up of our system's architecture. Yuk, I hate phrases like that, over complicated computing science terms are a pain in the butt and will not feature in this blog where avoidable. I'd much rather say let's get all the bits of our system in place...
As mentioned we are going to use OpenCV for all our reasoning purposes so we need a way of accessing OpenCV from Java. In order to do this we make a native library that we can call from within our Java code using the Java Native Interface (JNI). What is a native library you ask? It is code written in another language, often C, that can be called from other programs. All those .dll files in your Windows system or all those .so files in your Linux distribution are examples of native libraries and are what we are about to make. Don't worry, it's not as scary as it sounds!
This is actually an incredibly easy step so before we do that let's do a little setting up of our system's architecture. Yuk, I hate phrases like that, over complicated computing science terms are a pain in the butt and will not feature in this blog where avoidable. I'd much rather say let's get all the bits of our system in place...
As mentioned we are going to use OpenCV for all our reasoning purposes so we need a way of accessing OpenCV from Java. In order to do this we make a native library that we can call from within our Java code using the Java Native Interface (JNI). What is a native library you ask? It is code written in another language, often C, that can be called from other programs. All those .dll files in your Windows system or all those .so files in your Linux distribution are examples of native libraries and are what we are about to make. Don't worry, it's not as scary as it sounds!
Labels:
C,
C++,
createScreenCapture,
Game Player,
Java,
JNI,
loadLibrary,
Robot,
Step 1
The Game Player Project
I've decided my C and C++ skills really need to be improved since more and more of my work appears to depend on them. So in order to improve them I've decided to take on a project in my spare time that covers both programming in C and C++, OpenCV, Java and JNI. These are all pretty useful tools to use together so hopefully these entries will be of help to others as well.
The project is going to be called 'Game Player' and the aim is to develop an automated system, based on computer vision techniques, that can be used to play games. I make a point of emphasising the computer vision techniques part because there are already lots of automated game players out there that use data held in the computer's memory to play games and that's not what I'm looking to do. I want to build a system that can play a game based purely on what it can 'see' in front of it, the same a regular player does.
The project is going to be called 'Game Player' and the aim is to develop an automated system, based on computer vision techniques, that can be used to play games. I make a point of emphasising the computer vision techniques part because there are already lots of automated game players out there that use data held in the computer's memory to play games and that's not what I'm looking to do. I want to build a system that can play a game based purely on what it can 'see' in front of it, the same a regular player does.
Subscribe to:
Posts (Atom)