A Project Update

Lately I have been working on something fun which is mostly finished. It is a script to allow certain textures to be swapped within the game, they just need to be called in some way (I have a couple of thoughts). Unity allows objects to “send messages” to other objects, so with this script attached, an object would be able to use something like:

target.SendMessage("function name", "parameters");

to call the function on the other object. This is nice since loading the script object on a specific object can be difficult.

Now that I am more familiar with how Leap Motion and the Oculus Rift work with Unity, I have come to the conclusion that some of my scripting for the boxer is unnecessary. As such, I have decided to focus on creating an enemy boxer.

I have spent a while working on getting the model and texture for the boxer setup so that creating for and using it will be a bit easier. Luckily, with the decision to go with a retro feel, I was able to make a simple model made of blocks. However, as the complexity of the texture will be significantly more difficult than what I have done so far, I only have a simple texture created for it at the moment. The image gives an idea of what I have so far:

Preview of boxer with test texture applied.

Preview of boxer with test texture applied.


The texture seen in the image is one I setup to help me know what I am making later on (the colors represent a certain side of the boxer).

My next plans are to make some simple animations for the enemy boxer, such as punches and “tells” so that the player might be able to know what the next action it will take is. After that, I hope to make some form of simple AI for the boxer.


It’s (Yet Another) Update

I have begun scripting the logic for things like punching. To go along with this, I have looked into methods for supporting multiple different types of inputs (like keyboard and controller) and how to make them configurable. This was surprisingly easy, the issue is knowing where to go to do it. Unity provides an “input manager” which makes it relatively simple to change the default keybindings for various actions, as well as create new ones. The biggest Issue I ran into while using it was figuring out how I needed to represent the particular key I wanted to set.

To help get my point across take the following image:


Notice that, for Cancel, the “positive key” is “escape”. This means that if the user presses the escape key, anything looking for the press of the cancel key will activate. However, for my own input, “Left Hook”, I wanted to use a button on the numpad for testing purposes. The documentation that I looked at, however, did not mention how to do this, and I later found in a forum post that the key must be represented as the desired number in brackets as seen in my screenshot. At the moment, I have not figured out which joystick buttons should be used for each action, so controller are not, by default setup. Luckily, the bonus of using Unity’s input manager is that the user will be able to customize their controls when they start the game.

The input configuration menu shown when starting the game.

The input configuration menu shown when starting the game.


Another issue I am having with the actions in my script is deciding how far things should reach. While some people will say things like “detect collision within x meters”, as our scene is not necessarily to scale, this is not so simple to do. As such, I will have to continue experimenting until I find a distance to use that feels reasonable.

(Another) Project Update

So, I have added the mesh collider to the punching bag. This means that other objects with colliders should not just go through it.

Other than fixing that small issue, I have started the scripts for some of the basic player controls. Unfortunately, there is not much to show on that front.

For now, I will continue to write the scripts for basic player controls. I may also look into a good way to allow different types of input, such as keyboard and controller, and ways to allow the player to rebind the controls (for either option).

These options are often very important for the player, as the controls you may like are not necessarily the controls everyone else likes. Allowing the player to reconfigure controls can also help work around some bugs where the input was not correctly detected.



Project update #2

So I believe I have figured out textures sufficiently enough to do whatever may need done for this game. A major problem I ran into was not having textures show up correctly in Blender, however it seems after restarting Blender things worked fine. Other issues include try to properly “unwrap” the model so that I could work with the textures in an easy to work with format.

I also made a simple little punching bag for us to use for testing mechanics (when we get that far) as well as for the users to punch. However, as I was writing this post, I remembered that I forgot to add a collision mesh to it. I am not entirely sure that it will be necessary, but it is probably better for the punching bag to have collisions then to not so I will be sure to add it over the next week.

punching bag and ring1

I have also decided that enough of the game’s scene is setup to finally start actually writing code. For now I plan to focus on some of the basic mechanics such as punching, blocking, etc, probably without going into too much detail.

Project Update

These past two weeks were rather slow. I spent some time working on something for the user to punch and creating textures.

The item I was working on was a simple punching bag. The model for this is obviuosly quite simple, composed of little more than a cylinder. However, texturing is not one of my strong points.

I have been using Blender for my more complex models. This tool is a free and powerful tool for creating models and animations. It can be very easy to do so, but only when you know how to do it, and for the record, I do not really know how to do texturing and animations.

There is some slight progress, however I still do not have much to show yet (other than the environment I threw together which was discussed last update).

Senior Seminar Project Update 1

The past week for me has been preparing the ring and other parts of the interior of the stadium which the player will see when they are playing the game. This ended up being a time consuming task as I decided to take a screenshot of the audience from the original game and modify it slightly to work for us.

One of the things that was worked on was getting the audience. Since we wanted something of a retro feel to the game, I decided to make use of the original audience. To do so, I took a screenshot of the audience from the original game:

The original ring from Mike Tysons Punch-Out!!.

The original ring from Mike Tysons Punch-Out!!.

Using this, I cropped the image to include just what I wanted, the audience.

Cropped to contain just the crowd.

Cropped to contain just the crowd.

However, this still includes the ropes, which I do not want in the image as we will have a 3d ring complete with the ropes. So, I spent a number of hours editing the image to remove the ropes and, at the same time, add back in parts of faces (as best I could).

The resulting image for the crowd is this:

Edited to remove the ropes (and add back in parts of faces that were "covered up" by said ropes.

Edited to remove the ropes (and add back in parts of faces that were “covered up” by said ropes.

And this is a rough view of the result:

crowd in game2

Though it took a while, it should help give the game a bit more of a retro feel.



A final update

With this being an unofficial and after the fact blog post, I am going to be very lazy with it:

The “secondary algorithm” that I have talked about is finished. There is also a fairly simple GUI that I made with WindowBuilder.

As the program works reasonably well as is, and because I don’t know if I will spend anymore time on it, I will post links to the latest runnable version, as well as the source code, in my “Downloads” page. These links may or may not be updated later in the future, and there may or may not be any post or other indication that they have been updated.


Optimizing and more

I worked on optimizing the solver some and have gotten some good results.

(And yes, this is in real-time.)


I did this by detecting opened tiles that bordered unopened tiles and adding them to a list, then working on that list. As you can probably see, this resulted in significantly faster speeds (roughly cutting the time in half or better). So, when I do win, I win on beginner difficulty in 1-2 seconds, and on intermediate in around 10 seconds (fastest so far is 7).

Also, I have found that, using the very simple algorithm, beginner levels can be solver somewhere between 60-70% of the time (this was roughly 50 games).

I have been working for quite a while on the secondary algorithm, which would take over when the primary one can no longer proceed. However, it has not been coming along well. While the problem is relatively easy to explain, getting an algorithm that actually does it has proved quite difficult.

Here is an example of what the current main algorithm cannot solve:


What the secondary algorithm would do, is add up the value of tiles touching each unopened tile.


It would then find which unopened tile has the highest value, and flag it.


Finally, it would then return to the main algorithm, which should be able to continue. I have also created a couple of other methods that would be used to solve potential ties. However, this secondary algorithm has yet to come together. Between the complexity of making this happen and the bugs that popped up it still remains unfinished, and it does not currently look like I will be able to get it finished in the next couple of days, but who knows.


A final note: sadly, even after revamping the board initialization, I still have not gotten this program to work on computers other than my own.

Early termination of the program and its first win

One day since my last post and already lots of news.

First, due to the nature of my project, it is quite important to have a way to terminate the program at any time to minimize any possible damage it could cause (as well as saving time and avoiding an infinite loop of doing nothing). However, it turns out that for this project that doing so is easier said than done. Since the program has complete, and almost constant, control of the mouse, using the mouse to manually terminate is impossible. The other option, then, is using the keyboard. Here again, though, there are many problems. Due to having my program interacting with a window that it did not create itself, it turns out that simply using a KeyListener will not have the desired effects.

The cause of this issue, from what I remember from the many StackOverflow and other help pages I visited, seems to originate from they way Java applications are run. Since they actually run in the JVM, which is what allows greater portability of Java applications, it essentially gets limited to working in the JVM. This makes it so that things, like listening for keyboard input when the application is not in focus like mine, impossible to do without knowing JNI or getting libraries such as JNA.

Luckily, through the heavy use of Google, visiting many StackOverflow threads, and spending much of my day on this, I have discovered yet another external library to help out. This time it is jnativehook. This library allows me to create a global listener for keyboard (and mouse) inputs. So, I should now be able to terminate my program at any time (it has at least worked fine so far).

Now onto some very exciting news: the solver has started successfully solving Minesweeper:

However, this is using a really simple method and, in a way, brute forcing it. Right now, all it can do is detect the mines where an opened tile’s number is the same as the total number of unopened + known mine tiles that it is touching. As for the brute force part, it is just in a for loop going from left to right top to bottom until the game ends or I terminate the program. Regardless of all that, it is very cool to finally see my hard work coming to fruition. Now I just need to make it be able to deduce mine locations when they are not so explicitly known and make it run more efficiently.