Week 6 - Trick Shots

This week I went back into the Nuke launch system as well as spruce up the goal orientation. Originally with the original Path-builder it was safe to create nukes from a specific area of the planet. This week I went back at made it possible to nuke from any location and it will avoid shooting  itself and is ready. However due to the ability to only move the first three node and the remainder go in that direction there are some slots it can never hit. So in future weeks I will need to go back and have some checks based off of the angle the missile would need to go at launch time. So technically if the angle from initial launch to the desired location would be about Pi / 4 or 45 degrees it wouldn't be able to make it if its to the right side of the planet. However that's an estimate, of course I would write something to figure that out at run time if the nodes would change and it can figure out where it can hit. Also I added in the faction upgrades this week and set the goal for being able to use those actives. Specifically to get it tested I put in the Ruskie chrome upgrade. For two reasons, one it just takes one turn to use its upgrade, and second its the only one in the game atm, the others are being programmed and implemented this upcoming week or two.

It works very nice except for the fact it cost nothing. Therefore as long one chromium drill is upgrade to that, it will cast on that turn. This has two effects. One it can always cast this event. Since currently we want the AI to use up all resources and possible events so it ends with as close to no resources as possible. Eventually before it ends it turn, since the goal it will only be able to shoot straight. I will have a modifier that checks if it is in a spot that will even hit the enemy planet. This will decrease the automatic uses, however it will also make sure something get hits. Currently it will go through the enemy planet, since its a drill it makes sense.

So for this week a neat thing the AI can figure out is a shot that goes up over a couple buildings than comes back. On a plus once it hit the command center perfectly which it would have missed if it went straight for it because it would have collided with another building first. However most of the time, it still does it sometimes even when there are no buildings and because it has a slight offset, it has also come turned around and gone all the way to its on planet and blown up its own command center. So for this shot that it can select its 1 win and 1 loss for its own nuke. Of course for this to work, it has to select the target and launch from a very specific rotation where it figures out the amount of turns is the right amount. Although it is still very neat it figured this out without any specific type of ray casting at the moment. Since we have no rigid bodies or anything unity related tied to the objects they are not on the ray casting layer. In the upcoming weeks, I will need to find a way to raycast and only set its planet on it. Since nukes only blow up enemy buildings or either planet. Players can shoot nukes through their buildings. However this will also take some ray casting which I will create this week. It will allow for better shots in less turns. Thus being more accurate as well as taking one or more turns less in order to get to a location.

Week 5 Fun with Nukes

This week I have had fun trying to figure out what we want to happen with nukes for the AI player. For now the main target is the command center and this week has a first pass on a new way to create nukes. Alex created a new method to create nukes paths overall to help with the transfer from mouse click to touch. The old method tended to work one way or the other and had problems switching back and forth. So I took this and developed a method on top. Initially missiles automatically shoot out a distance directly from the center of the planet. This way unless you try hard you can't nuke your planet accidentally on the first turn. You can turn it back, but that is a problem for another date. So, my method uses just a little bit of trig. Missiles have a launch distance that they go for each rotation and each rotation the planet moves one away. So when you check if a missile could hit you check with the adjacent 5 spots to the direction its rotating. So if its the left planet you search its left location 5 times.You check how many turns it would take going directly from the first place out to each location. You add one for the original launch which happens automatically by creating a nuke. if this number is within -1 to 1. Say it takes 3 turns and either and the location is either 2, 3, or 4 it will blow up. So if its 3 its 100% chance. 2 or 4 its put at 60% chance. You don't add perfect straight to location, that would be too predictable as well as easily countered. When it confirms which of those spots its going to nuke it figures out at each point the angle from the center of the spot to the last nuke location. It has a hypotenuse which is the full vector length, as well as an x so you can use cos^-1 to get the angle in radians, which our system uses. Than you have to add an offset so its not likely to fly straight at it, and add zig zag similar to a real player. This can cause it to miss, as well causing the enemy to have a hard time hitting one of their nukes into the computer players. This path on the first go is working well. As expected hits target about 60-70 percent of the time which is decent and not to high. However about 10% of the time it does seem to shoot of the screen for an unknown reason. We will be looking in this week to figure out if its a math or logic error. Or a weird new pathbuilder error. As well, we are looking to do a similar goal orientation for the enemy nuke selection as its building. This way it all works goal orientated which is how the game has been developed to be seen. The command center being the biggest object, both to explode and secure. We will than work our way down based on some small changes. This being how the AI wants to win. Starve the opponents resources, go for shield generators, kill all nuke paths etc. Each will have a multiplier to help decide and create AI that have a variety of goals in different games. This way they aren't too easily predicted game after game. These numbers can and will change in the midst of games if that Player changes his gameplay as well, but that is to be added in the much later stages. We are currently quite happy with the initial AI both for its nuking and its building and survivability. The last piece to be added is the boost resources which the intro AI won't do a hundred percent of the time. In the later and more difficult will use all resources to its advantage every turn.

Week 4

Moving towards this week the goal was to get the basic works for everything into the game. The AI now has total control over everything. As we move forward now I can focus on using a different Algorithm in order for the AI player to be a little less easy to guess. To get it all going I gave everything just and importance value and left the modifier alone at so it would not effect at all and I could check everything. This week I will push for getting the Computer to choose a building or building slot it wishes to nuke and figure out where it will be in the amount of turns a nuke will take to get to a location. Exactly how I will be going about this I am uncertain. For the first attempt, I will most likely be picking a spot than checking the following 4 and seeing how long each takes to get nuked. If the spots away is the same as the time, I would choose that location because it will collide quite well. However since we will want levels of perfection for the AI, I will also add a chance to pick the one before and after. As well as it won't use a perfect path at each section. So there is a chance it will miss, just like a player could miscalculate. After the Missiles are done, I will be sitting down with a designer and figuring out the importance values of every ability or action, and than modifiers in situations. This way they can also plan future events based off of what we have chosen. As well it will be made so the designers can go back in and change them when they want. Most likely to be loaded from an XML document that they can easily swap in and out for testing.

Week 3

This week our team is getting ready to push for Greenlight presentation. On Monday we discussed during class what left was needed in order to achieve what we set for our Greenlight goal. For Greenlight you were to take what you had last semester and make changes and push for new concepts. In order to pass Greenlight you needed all these new features into the game in some shape or form, that would look reasonable. Our team chose to push for several; Tablet usage of the game was the first priority as its what we wanted the game to end on. Next we were moving away from the multiplayer basis of the game and creating a single player campaign. In order to move towards that we needed to have a faction system, level progression, and an AI implementation. So to show the designers needed to come up with the faction system, and I came up with a goal orientated AI implementation in the first few weeks which will get built farther upon in the semester. Later in the week when we had a basic form of everything we wanted I met with Alex and we went over changes in the next week. Since we believe we will pass Greenlight, we have pushed towards refactoring some of the Unity wrapper we are using. When Alex created the wrapper and system, it was built for player vs player and played on a pc. Since these are completly different from our new goals being single player and tablet, a lot of the organization of systems is no longer appropriate or reasonable to progress at a steady rate. We have already had some problems switching, and we have discussed many more. So this next week, we will start to get the system written for our new end goals. This will allow us to progress not only at a quicker rate, but our code will be much more legible.