Blog for Dan Keller at GarageGames.com

Nuclear Asteroids (beta testers wanted)

Dan Keller — 2008-07-29T20:51:01+00:00

For those of you who didn't see my last blog post, I'm working on games that teach chemistry concepts. This one is about nuclear reactions and decay. (If it's been a while since you've last taken chemistry (or physics), I'd recommend skimming this before playing.) The game is now at a beta state, so I'm putting it up here as an open beta for anyone to download. If you encounter any problems, post them here. I do ask that people not redistribute or mirror copies of the installer. You can download from here, and the scoreboard is here.

So, try it out, tell me if it's too easy or hard, or there are any other bugs or gameplay issues I should know about.

Summer Jobs, TGB, and Nuclear Fission

Dan Keller — 2008-07-20T16:30:53+00:00

I've decided to get a summer job. But not bagging groceries or flipping burgers. I'm making games. Specifically, I'm working at Brandeis, and making games to teach various chemistry concepts to freshman. I decided to use TGB because I already have used with TGE and TGEA. But in ease of use, intuitiveness, and just plain awesomeness, TGB blows the other two engines out of the water. Big thanks to GG for this one.

Anyways, the first game was going to be about equilibriums. And I had thought of the most creative title ever for it:

Behold: My leet inkscape skills.

The premise of the game is very simple (if you understand chemistry). You have a reaction at equilibrium, and you have to get all the chemicals to the indicated levels. You can remove chemicals or add them, but your score is determined by how little you waste. The catch? Everything you add or remove affects the levels of the other chemicals.

If I remove some hydrogen, that unbalances the reaction, so some water will react to form H2 and O2. So H2O and H2 go down, and O2 goes up.

The reactions get progressively more complex. For example, If I add SO4 2-, do you think the amount of H2SO4 will go up or down?

So has your brain exploded yet?

As I was making this, I was wondering "What the heck am I gonna do next?" But as I was riding my bike to the train station, inspiration struck.

Asteroids. With radioactive atoms. (And yes, I will add my own graphics eventually.)

I think I can say truthfully that this game has more realistic physics than crysis.
Well, sort of.
That is to say, it uses the correct decay patterns of over 3000 isotopes, collected (with some difficulty) from Mathematica (a really hard to use program). Of course, the half-lives are shortened a bit to expedite gameplay a by a few thousand years. The goal of the game is to create stable isotopes. You shoot various sub-atomic particles at the nuclei, causing them to decay. Once an isotope is stable, it explodes (why not?) and shows up on the right. The smaller it is, the more points you get.

My favorite part is this.

You can choose what particles you want to shoot, depending on how you want to play the game. So if you want to try splitting those big atoms and getting more points (not to mention the possibility of neutrons flying everywhere in a somewhat comical fashion), you can use alpha particles. And if you want to stabilize atoms without making them any bigger, you can use electrons and positrons.

The great thing is, this is the result of only 80 hours of work. (Incidentally, it would be very nice if there were behaviors in the 3D engines... *wink wink nudge nudge*)

So, here are some more screenshots:

A* Again (but this time it's done and you can downlad it)

Dan Keller — 2008-04-05T01:20:40+00:00

After some work, the a* system is finally good enough to be posted as a resource. The algorithm is fast and ready to be used in any sort of ai system. If you want to know more, look at my first blog.

resource link

And here's the requisite blog picture.

Complete AI System for Torque

Dan Keller — 2008-03-10T03:12:09+00:00

Well, it's done. I've finally finished my ai system, except for a few minor things. (Well, I actually finished it a while ago, but I've been too busy to post it up here.) My basic goals in this project have been to make an opponent ai that is flexible, extensible, and, once completed, easy to implement. This has probably been one of my most ambitious coding projects yet, and I'm glad to say, I'm quite satisfied with the results. It uses a three-layered system: At the top layer, a genetic algorithm causes the bot population as a whole to learn and adapt over time. In the middle layer, a each bot uses a neural net to evaluate relevant input information and make a decision as to what to do next. And at the bottom layer, an A* pathfinder tells the bots how to get where they want to go.

Now down to the nitty-gritty description. When the game starts, the AIManager is created. It loads the neural net gene pool from a file, or creates a blank pool. (It has to be randomized from the console because of certain annoyingnesses with global object constructors.) When an AIPlayer "bot" is created, the AIManager combines two random nets from the better half of the gene pool, and gives it to the bot.

Then, the thinking begins. Each bot's thinking function is called, every other tick, by the AIManager. (I'm considering, for efficiency's sake, doing this some other way.) The bot converts all the information is uses into values from -1 to 1. There are currently 7 inputs: Whether the bot is doing anything, how long it's been since it last saw the player, its health, the player's health, how far away the player is, what it's doing, and one blank input that's there for a very good reason that I forget. This information is fed through a feed-forward neural net. There are five outputs, and the bot uses the highest of the five to decide where it wants to go.

Now the A* part begins. Back when the map was loaded, another global object, AStar, used a bunch of special NavMesh SceneObjects to create a grid of navigation points spanning the map. I have a good picture of this in one of my previous blog posts (a picture is worth a thousand subclauses). When the bot decides where to go, it calls one of five functions. They are stopMove(), findPathTo(), sneakUpOn(), findCoverFrom(), and wander(). The AStar object uses variations on the classic a* algorithm, and returns a list of points for the bot to follow. The bots use the original AIPlayer path following code, however keeping track of paths has been moved to c++ for simplicity's sake.

Each time the bot inflicts damage on the player, the bot's fitness score is incremented. This is how the effectiveness of each net is kept track of. When the bot dies, the AIManager::removeBot() function is called. (and a string of passive voice sentences are written) This replaces the lowest scoring net in the gene pool with the bot's net. The gene pool is then saved back to a file.

Read it again, it might make more sense this time.

Neural Network AI

Dan Keller — 2008-02-07T13:40:26+00:00

In my last blog, I talked about an a* system in torque. The pathfinding behaviors were chosen by a simple state machine that I added temporarily to test the pathfinding. Over the last few days, I've been implementing a neural net system instead. The nets are generated randomly, so the bots are somewhat "stupid," but they still work OK. The benefit of using a* in conjunction with the neural net is that even with no training, the bot can still look like it knows what it's doing. (Except for the ones that just stand there.) So a random net will just make the bot always run away, for example, instead of spinning in circles.
This is the second part of a three-part AI system that I'm working on. The third part will be a genetic algorithm to "evolve" smarter nets from existing ones. The idea is that, on a high level, the genetic algorithm will cause the population to adapt and get smarter, on a lower level each bot will use the neural net assigned to it to decide what to do, and on the lowest level, a* will tell the bots how to get where they want to go.

When You Wish Upon A*

Dan Keller — 2008-01-12T05:33:58+00:00

Although Torque is an essentially complete game engine, it lacks one major component: AI. I'm sure you know what I'm talking about. You open the aiPlayer files and think, "Is this it? Where's the code that lets the bot, you know, try to kill me? Or even find me, for that matter?" Well, the first part is another subject for another day. The second part is where I decided to begin. The general consensus on the internet seemed to be that a* was the best and fastest pathfinding method, so that's what I chose. Using the information from this excellent article, I began. I won't go into the gory details of a* here, the article explains it better than I ever could. Now, a week later, I have a working (although far from finished) implementation.

Now, I know that there's another a* resource out there, but I still prefer to use my own. This is mostly because of flexibility. The other resource (part of the iAI engine) places nodes for the entire mission area, and only on the terrain. Of course, there are some major things iAI's a* system has that mine doesn't, like doing more than a castray to see if two points can be linked, realistic move costs, path smoothing, etc. However, mine is (at this point) mostly a proof-of-concept.

In my implementation, small grids of nodes are added with NavMesh objects, and the nodes are then linked together.

Because the nodes are stored separately from the NavMesh objects, a path can go across any number of objects without a performance drop. (I went over the path in red for clarity)

Some things I hope to add are
-smooth paths
-better walkability tests
-optimize
-track down the annoying bug where the paths are re-calculated 4 or 5 times when an object is moved
-add real AI

More screenshots and (hopefully) code to come!