Action Games Programming

Perhaps the essential foundation course for the game programming degree at DePaul, is Action Games Programming. My first true training in the use of OpenGL, the course utilized Professor Linhoff's QE Engine completing assignments and projects using the core OpenGL pipelne from immediate draw mode to the use of Vertex Buffer Objects, mapping and lighting. In addition to learning how to use the graphic system, the objective of the course was to teach us the fundamentals of gameplay and mechanics, requisite linear algebra, collision, physics + motion, control, sound, and heads up display.

Each week a new assignment was completed with three small game projects as milestones which reiterated the weekly lessons leading up to them. Each of the three games were realized as fully 3d environments with 2d focused game mechanics

The first week long project was to create a two player pong game. The keyboard is used for the control of both paddles. Physics of the ball includes collision with walls and paddles, including “english” with off center hits. Two different power ups become intermittently available, one changes the size of the receivers paddle the other increases the speed of the ball. A simple hud keeps track of scores, wins, and title screens.

Pong Revisited from Thomas Kearns on Vimeo.

The second week long project was a recreation of asteroids, playable by keyboard or joystick and as a single player or two player game. Consistent with the classic game, the world wraps the edges with asteroids and players able to drift from one side of the screen to the opposite fluidly. A successful shot into an asteroid will break the rock into smaller pieces once the third smallest size is shot it is destroyed. Players change the orientation of ship with left and right arrows, thrusting with down arrow and firing with up. Space bar engages hyperspace transporting the player to a different but random location on the screen. Player art inspired and derived from Muybridge.

Asteroids Redux from Thomas Kearns on Vimeo.

In the final project short project, we were able to design our own game. I opted to complete the game individually rather than in a group. At the time I was logging a lot of time in the iPhone version of Canabalt, a fantastically simple 2d game of rooftop running. Inspired by the game and considering how it would logically be made I began thinking about the opposite approaches of player moving in static space vs. player staying in place and objects moving. While the former is of course the logical narrative model for such a game, and given that I could never do such a perfect game justice, it became more interesting to think about the space just out of frame of the camera and how my version of the game might add a gameplay mechanic, while also revealing (in a kind of extra diegetic moment) a mildly humorous narrative twist. As in the original, the players character is running, and staying alive depends on the players ability to time jumps across the gaps between buildings, with speed increasing as time goes on. In my version however, players are provided with the ability to climb back up (in a Prince of Persia inspired ricochet jump between buildings) when falling in the gap. Should players continue to fall they eventually encounter a ground plane. If they aren't careful, they will then soon realize that the ground plane is actually a conveyor belt on which the buildings are placed. This conveyor belt will carry a player backwards from their objective direction and eventually to their death when they collide with the wall of death.

Roof Runner vs. Wall of Death from Thomas Kearns on Vimeo.

I would also like to mention that this particular course was by far and away the most tightly organized and delivered course that I have had the opportunity to experience as either a student or fellow teaching colleague. anThe way in which each weeks lecture enabled the week's assignment and the way each assignment coherently built on top of the prior week was very impressive. It makes complete sense that Professor Linhoff has been crafting a textbook from his course content and when it's complete I highly recommend others check it out. Thanks Joe!

AI for games

In Robin Burke's "AI for games" course in my graduate studies at DePaul we learned about many common core systems used in creating "Artificial Intelligence" for video games.  I should probably chime in now and make my overall commentary that while these methodologies are involved in creating "AI" characters for video games I would suggest that this is not "AI" in the strict sense of the term.  As an introductory survey we are not investigating machine learning or neural networks which would begin to move us in the true direction.  That said, the programming exercises were good insight into the practice as it relates to game development.

In the soccer team development project we individually created strategic and tactical team game play using a combination of state machines, messaging systems, and steering behaviors.  The core framework for the game, graphics, etc was provided as part of the text we were using for the course and it was our responsibility to refactor an existing team, adding behavior and increasing computational performance.  The success of the assignment was then evaluated through a class tournament, pitting students and instructor teams against each other, with match scores and a computational performance rating determining the winner.

AI Soccer Team from Thomas Kearns on Vimeo.

To achieve a winning team my primary goal was to implement a man-on-man defensive strategy. In this strategy a player within a defined proximity would attempt to remain “on” the offensive opponent while positioning themselves between the player and their defending goal. To achieve this and other tactical performance increases I increased the granularity of both the team and individual states and I tracked more than the original single closest player to the ball. I also added a defensive support positioning grid similar to the existing offensive support grid. From this grid defensive players were provided with cues as to optimal positioning. Among simple code optimizations I added a kind of persistence of state or delay mechanism which attempted to reduce the processor usage by reducing the number of phase transitions, which also added to the tactical performance of the teams gameplay.

Ultimately my team came out on top of the class of 20 some students and our instructor, undefeated in points scored and computational performance. Goooooooo Team.

DeathMatch AI from Thomas Kearns on Vimeo.

Unfortunately I did not fare as well in the second project of the term. A 2d deathmatch game played similarly as an in class tournament. In this second project, we built upon ideas explored in the first project. Adding to it systems of sensory memory for sight, sound, and touch which allowed the ai player to respond to current and past events. Seeing an opponent, hearing a weapon attack, taking fire, etc. With the memory, we utilized goal driven behavior which allowed the ai player to switch objectives or strategies given particular conditions, attack, retreat, find health, etc. In addition, we utilized fuzzy logic systems to make determinations about which weapon and which target a player would would focused on.  Sadly, my pacifist strategy did not work and I got pwned. On a related note, this project was also my introduction to using LUA as a scritping language for games.

In the end, I really enjoyed the coursework, focusing my precedent research assignments on a specific areas of AI in the game industry which I am particularly interested in, spatial perception and awareness, and the procedural narrative of the AI director used in Valve's Left 4 Dead franchise.  I am very interested in pursuing these and other aspects of computional decision making in projects in the future.

Thesis: digital game progression [obstacle engine]

thesis: digital game demo 2 from Thomas Kearns on Vimeo.

This video is demonstrating basic character control, camera logic, and obstacle generation.

The character control is built upon the bullet library and integrated with irrlicht based graphics and input. For the time being walking, running, and jumping are the only required character control mechanics.
most importantly what we see here is the base functionality of the obstacle engine, which manages the dynamic creation of obstacles for an ever expanding game space. The engine is overseeing the instantiation of new obstacles based on active zones within the physical game space.

Abstractly the engine allows for unique obstacles, in this case represented by simple planes or floors. each obstacle can have a number of connectors associated with it, which parametrically define the possible relationships with future obstacles, effectively controlling the location and dimensions of the gap. While subtle, in the video you can see a growing number of obstacles with their orientation being determined by the orientation of the obstacle it is connected to and on which side. Each obstacle can also define an ideal view point, which we see in the video as the camera is controlled entirely by which obstacle the player is currently engaged with. While still requiring some finessing, the camera’s dynamic quaternion based control is functional.

The engine is also managing the state of the obstacle whether its untouched, yellow, or conquered by the player green. To win in the digital game players will be racing to conquer, similar to qbert, each obstacle in the system. With the space expanding with more and more obstacles the players will be racing to be faster than the generation. The rate of generation is also tied to the status of players in the physical game.

Future additions to this system will be the telepresence representation of physical players, and what I am currently working on now, the ability for designers to create custom, animated, obstacles in 3dsmax with the ability to define connection points, conquer triggers, and ideal view angles, these custom obstacles will replace these simple boxes with creative spatial obstacles for procedural combination into an interesting, dynamic landscape for players to navigate

making space ships fly

ship flying and dynamic camera control mechanics from Thomas Kearns on Vimeo.

This is a short video from a project I worked on last summer.

I must disclaim: I had no responsibility in the creation of the graphics for the art assets or the heads up display.

This video demonstrates the full 3d freedom control/physics of the space ship, with the ability to fly up + down, forward + backward, banking naturally and rotating + re-aligning properly relative to the camera.

Camera control is simple full 3d, 3rd person follow cam, with ability for player override for optimal viewing relative to environment.

When I have time I will upload more videos of the design development of the control mechanics which explored many different approaches, ultimately settling into this fluid but conventional approach