Introduction to GuiltySparkPosted: January 14, 2011
For my undergraduate directed project, I have decided to continue the development of my program GuiltySpark. As a requirement of the project, I will be using this blog to record the details of my progress.
I’m an avid player of the PC game Halo, and I’ve been involved in its modding scene for around 4-5 years. During that time, I’ve picked up 3D modeling and texturing skills, and I’ve joined the staff of the community’s most active site. These days, I mostly create custom skyboxes for mapping teams, which I enjoy because Iove drawing with my tablet. It was only natural for me to try programming applications for Halo after going through first year CSC. Programming for Halo usually involves reading from or writing to the running game’s memory. This opens up new possibilities for players and developers alike that didn’t exist before. For example, a community member developed an wrapper API for the game engine that allows the addition of extensions to the game such as postprocessing and removing various limits that once held map-makers back.
I was inspired by the work of these community members, but I always lacked the experience to make these applications myself. Near the end of CSC 115, I wondered if I could make a program that, using only the player’s coordinates, navigated the player around a map (one of the ingame levels). So I began work. First, a failed Java attempt, then I decided to learn C# as it would be easier to perform “memory hacking” with. I worked all through the summer and when I could during the Fall 2010 semester. What I’ve ended up with is a fully automated, user-programmable bot. Not only will it travel around the map, but it will actually target and shoot at other players. In other words, it plays Halo by itself.
How does it work? Users need to create a special node graph for each map. The bot uses it for path finding and path following. GuiltySpark contains all the tools a user needs to create these node graphs, and I believe it’s quite user-friendly. Once the bot could travel around, I knew I could take the program a step further and add some sort of aiming and AI system. I began to brainstorm for the AI system. It needed to be able to react to changes in the environment and make decisions. The decisions should depend upon information from the environment. Some tasks should have a higher priority at times than others. Using these requirements, I made up a sort of programming language to define the bot’s behaviour. Users of GuiltySpark can write these AI files themselves, and it’s actually “compiled” into a usable form when they load it into the program. It’s easiest to think of it as a tree of tasks, each tree node having a priority. Priorities can incorporate data from the game environment. At each step of the AI, it finds the highest priority path down the tree. This represents a decision.
GuiltySpark is currently in beta testing. I have 8 testers from the Halo community looking for bugs and requesting features. It’s about a month or two from release. However, for my undergraduate directed project I will be further working on the program before and after release, and including my changes in a future version.
If you’ve read this far, you’re probably wondering what exactly I want to do for GuiltySpark as my project. Right now, target visibility is checked using a cheap trick. When you aim at a target ingame, their name shows up on screen. The text won’t show up when you aim at someone through obstacles, so I can see if that text is visible or not to determine if the bot has a clear shot. The problem is that the text doesn’t show up if the target is too far away, even if visible. My bot can also aim ahead of moving targets to compensate for projectile travel time and network latency. Leading too far ahead makes the text disappear. I need a better solution.
The better solution is to extract the level geometry from Halo’s memory, then perform some kind of ray casting on it. This is something totally new to me and I’m excited to try it. It will be a challenge to correctly extract the geometry and work with it in a real-time fashion. Luckily, my program already has a small overhead of about 2-4% CPU usage (by task manager) when running the AI, aimbot, and path following. I’ve made sure to optimize where I can because I didn’t know how expensive the AI system would be, especially since users can write their own AI behaviour files to program the bot however they want. I tried to safeguard the program against them using too many resources with complicated AI files.
Anyway, once this project is cleared and official I will start doing my research. A lot of work needs to be done before I can even work with the level geometry, and further work needs to be done to integrate this all seamlessly into my existing program.
I will try to update this blog at least once per week.