January 1 - January 7
Our first week after Christmas break, and we have the optimism that comes with new toys to play with. The CRL (Categorization and Reasoning Lab) team has generously funded our change from Macromedia Director to GarageGames’ Torque Game Engine, so now a lot of problems of the first semester seem to be in the past.
After the total disaster of the end-of-term review (what with the flooding and the power outage and the almost total data loss), it’s a good thing that we have both the new client and the new software to keep us focusing on getting a new forward momentum.
Jay, Henry, and Jens met with the CRL team over Christmas break to assess their needs, and they came in to class to teach us about the goals of their study, which are our new goals for the game as well.
Karen Soh is now leading the programming team, freeing up Henry to go back to being the “Exporting Monkey”. It seems that Torque isn’t much easier than Director on the 3d model front, but at least it has better controls for animation. However, Karen and Jay and the CRL folks have also found a bunch of volunteer programmers who want to work on the project for fun.
We’re gonna make it, Thelma!
January 8 - January 14
Jay introduced us to a new sign language term that he and a former multimedia student made up: the sign for “movie” placed on the rear end, which looks kind of like a “pain in the butt”. This is their sign for “Multimedia Programming”. And it seems to fit. Although Torque is cool, the two books published on it have a TON of errors, and the online documentation is all being moved around on the GarageGames web site. A lot of it now says “To be finished by October 2006”. Come on, our project is due in April!! The same “disappearing resources” thing happened last semester with Director, so maybe we’re cursed.
However, we have made some rudimentary progress. Most of the class has done the Torque tutorial, which takes you through making a simple game in which you run a blue stick-man around the screen collecting Torque logos. Our theory is that we can take this game and add stuff to it to make our game, which, as one of the CRL team put it, is pretty much “glorified Pac Man”: eat, or be eaten.
Of course, what we want to do is add lots of cool AI stuff so that the creatures “learn” over time, but one of the requirements of the CRL team is that the actions within the game be reproducible between gameplay – which means no randomness allowed! A lot of AI “learning” schemes involve having the creatures make a random choice and then evaluate whether it was a beneficial choice afterwards, so that over time they gradually “zero in” on the best choices for a given circumstance.
In order to implement this without randomness, we’ll probably be using Finite State Machines (FSMs), one of the simplest forms of AI. Basically an FSM includes a bunch of “states”, or things that the animal can be doing, and a bunch of “transitions”, which are events that can cause the animal to go off and do something else. For example, an animal might be in an “idle” state, in which it sits still and occasionally scans for predators. If it “sees” a predator nearby, it changes to a “flee” state, in which it would run away from the predator it spotted. The spotting of the predator is the “transition”.
The hardest thing about all of this isn’t the code for the AI itself (Jay and Karen both have studied AI stuff); the problem is that we have to figure out how to represent all of these things on Torque: how do we “see” a creature, for example, and how do we “remember” which one to run away from?
January 15 - January 21
I think we just found the edge of the cliff, Thelma.This week our programming team dropped from 12 down to 4. Various volunteers couldn’t make the commitment, and other people who hoped to get course credit for the project couldn’t make that work. So now we have Karen, who is part of the CRL team and is also leading Programming, Jay, who is teaching the class as well as programming, Thanh, who is taking the class in place of a CS course, and Bert, who is the one volunteer who has managed to stay with us.
We’re still running tests on Torque, mostly trying to get animation and sound to synch up. It seems that Torque makes a lot of assumptions about what you’re going to name your animations, and what they’re going to do, and if you want to do anything else, you have to do some engine modification.So this week we’re trying to divide up tasks into the “easy” stuff that involves writing TorqueScript, versus the “hard” stuff that involves actually recompiling the engine. So far Jay has managed to compile successfully on the Mac, but Karen hasn’t managed to reproduce his results on her machine. Thanh and Bert have things running OK on the PC side.
January 22 - January 28
Now armed with a sample model and animations from the World team, and sample sounds from the Sound team (the one team whose work from the previous semester didn’t get totally trashed, because they were smart and backed things up…), we’re having our first go-round at actually putting real assets in the world. And again, Torque has made lots of assumptions. And you know what they say happens when you assume…
Right now our creatures are sort of gliding around in a silent checkerboard world. It could be very peaceful and Zen, but we’re supposed to be making a game about predator/prey here. However, we have started playing with the Camera controls, and have modded the engine to give us the ability to change camera views. Turns out the GarageGames site has downloadable mods for almost anything you’d want to do; it just requires a lot of searching and cross-referencing and patches upon patches.
Still no luck on a reliable Mac compilation; even Jay’s version has a weird problem, in which basically we’re stuck between the creature’s legs (traumatizing to us, as well as our 3rd grade audience) PC version is doing fine, however.
January 29 - February 4
Based on the mockup from GUI team, we are now beginning to deal with the trickiness of a context-sensitive interface in Torque. The problem is mapping 3d coordinates to 2d space. To put it simply: when you click the mouse on the screen, you’re sort of clicking on a “window” to the world of the game. You have to get the computer to figure out what object is closest to the surface of the “window” so that you know what the user is actually clicking on.
You know how artists used to trace images on to glass to get the 3d-to-2d translations right? Imagine getting a computer to do the same thing. You basically have to figure out how far away something is and move it “up” or “down” on the 2d version of the screen.
The point of this? We’re attempting to design the interface so that it “pops up” around wherever the user rolls over, kind of like “Black & White” (which is also probably closest to the original game idea we were doing in the Fall).
February 5 - February 11
The rollover idea from last week isn’t working so well, so we’re moving to clicks. The problem with the rollovers wasn’t just technical, but also aesthetic: every time you rolled over anything in the world, you’d get this context-popup that changed. So it was like a constant stream of flashing icons. Or it would have been, but we couldn’t get the mod to behave correctly. Also, it turns out that everything depends on collision meshes (the same things that are used to detect when something “hits” something else in 3d) so we have to send every file back to the World team. They are going to kill us.
In better news, World team provided us with a prototype of the desert itself, so we now have two creatures (Sanchez the lizard and Gerald the mammal) running around. Gerald’s looking good, since he is under player control, but Sanchez is sort of a spaz: he often flitters back and forth between two spots so quickly that he makes the screen look like it’s suffering from some weird flickering.
Also, we finally have begun to decipher sound cues, so we may be able to sync up footsteps accurately, which would be nice, since the Sound guys have actually made footsteps for every creature type and every environment type.
February 12 - February 18
Jay has declared this “Hell week” for the programmers, in the hopes that we’ll have time to actually do some tweaking before the presentation to the critics in 2 weeks. This is the presentation that makes up for the end-of-term presentation we didn’t have last term, so it’s everyone’s grades at stake. No pressure!
Karen and Thanh and Bert all have lots of other deadlines for their Computer Science classes, and Karen’s also stressing about Animation 4. Jay’s buying people lots of Starbucks, though, and trying to keep us going. Karen is working all nighters. Jay works the day shift, trying to figure out what is going on with the code. We still don’t have a good check-in/check-out system (CVS isn’t working for us) so we’re doing lots of emailing of files back and forth.
Thanh and Karen have managed to get the clicking interface working so that creatures are selectable, but it’s with a very “default” looking UI that is nothing like what the GUI team designed. So now Animation and GUI are probably going to kill us. Fortunately Will from the Sound team has been helping us with the sound programming issues, so he’s too busy helping us code to consider killing us. Yet.
February 19 - February 25
One week until the midterm, and Jay’s sick. He’s funny when he’s hopped up on DayQuil, but it’s not really helping us to get the code out the door. Bert has managed to implement a bunch more small code changes. Considering he’s not doing this for a grade or anything, he’s been amazingly productive. We need to buy him a puppy or something.
Unfortunately, all the Starbucks and puppies in the world won’t change the fact that we’re behind for our demo for next week. We now have three kinds of creatures in the world, although World team is still placing plants and creatures. Luckily Jay spent some time with the World editing tools and figured out how to use BBEdit (his favorite text editor) to do quick search-and-replaces and to merge multiple World files together.
Freakiest thing right now: because of a problem with collision meshes, the birds tend to run into each other and become scary two-headed monsters. Funniest thing right now: because of a problem with the “running away” code, Gerald tends to enjoy sniffing the butts of the predator birds, which confuses them and causes them to be unable to turn around to peck him to death… even the two-headed ones.
February 26 - March 4
Argh! The presentation is Tuesday, the same day as the Animation 4 midtertm! Half the class thought it was Friday, for some reason! So here we are, pulling multiple all nighters in a row. Karen hasn’t slept in three days, probably.
The night before the presentation, Jay came back to school and actually worked with the team for most of the night. Karen got to bed around 3:00am, and we had the presentation ready to go by 12:00 pm.
It went fairly well, considering. Yes, there are a ton of glitches, and yes, nobody’s stuff worked exactly right, but the critics were at least able to give us feedback on what worked and what didn’t work. The hardest thing about this is that everyone would like to see it be more of a “game”, but since it’s a psych experiment, we have to keep everything very controlled.
Jay and Karen designed a Powerpoint presentation to give to the CRL folks the next day, so even after our midterm was over, there still wasn’t a lot of sleeping going on. Thank goodness for Spring Break!
March 5 - March 11
Jay was supposed to go to Eugene, Oregon, to the GarageGames headquarters, to see what help we could get. They were having a seminar on their newer “Torque 2d” product, which Jay uses at his company. However, between the airfare cost and the fact that we really need help with the 3d stuff, he decided not to go, and instead he threw his own “Torque Boot Camp” for himself.
Karen took the time to catch up on Animation 4, and Thanh caught up on some sleep.
By the end of the week, Jay had a copy of the “Advanced” Torque book almost completely marked up, with all the errors fixed in the first 10 chapters, and a copy of the code that worked on the Macintosh correctly! He also had some direction for us as far as Artificial Intelligence coding. He also now needs a vacation.
Good news: A new Torque book is coming out in a few weeks – ironically, one which replaces a lot of the info which was taken down from the web when we started this project!
March 12 - March 18
And people thought John Kerry was a flipflopper! Now we’re back to the idea of the rollover icons again, as well as the more limited camera view. Technical limitations are bringing this on us. We’re beginning to feel like we should have designed this to be like a first-person shooter (FPS) game, since that is what Torque was designed for. Of course, Torque has been used for many other games that aren’t FPS-style, but they probably weren’t put together by a ragtag band of folks who don’t even have a working source server.
Speaking of which, Bert spent the break getting CVS (the source server) working for us. Unfortunately, it never seems to get all the files in synch, so we’re back to the old “READ ME” update routine. It stinks, but then again, that’s how Capstone goes: you make do with the tools you have.
Another big push this week, in hopes that we don’t have to do another set of all-nighters at end of term. Unlike previous Capstone projects, this one can’t go “into overtime” since our client wants to be able to use the product.
March 19 - March 25
Okay, the GUI people will probably kill us, but we have had to switch back to the clicking method for objects. The problem now is one of gameplay: if you click on a creature, you get its context menu, but if the creature moves particularly quickly, then by the time you click the “attack” icon, the creature will be out of range.
It has been suggested that we “freeze” the selected creature so you can choose to click on something, but this so far hasn’t been too successful. For one, the creature ends up looking like a fish (well, lizard) wriggling on the end of a hook. We’re looking into the idea of “auto-attacking” creatures instead.
Bert has presented us with some minimal AI, so now the creatures actually run around looking for members of their own species, in addition to chasing after the player (if predators) or running away from the player (if prey). It’s based on the swarming code from the book, which isn’t the best code for what we are doing, but it’s a heck of a lot better than all the random spazzy running from before.
March 26 - April 1
April Fools! This was another one of those weeks of two steps forward, three steps back. We got a new programmer, Phil, who is a professional programmer interested in games. He’s willing to put in at least a few hours a week, and he might help bring some order to our chaos. Unfortunately, the engine also started to break this week, with mysterious compile errors that didn’t even disappear when we backed out our changes.
On the other hand, at least now we have interface clicking working correctly so the GUI team can get started on their tutorial creation.
April 2 - April 8
More April Fools! GUI team really can’t start writing the tutorial until we have this first playable level done. Weren’t we supposed to be done with Level 1 at midterm, Level 2 this week, and Level 3 next week? Oy, scary. Fortunately Phil is definitely onboard, so our team is now up to 5 folks. One of the creatures from the Swamp world (which is looking beautiful already) is named Filbert, and two of our programmers are Phil and Bert. Coincidence? Yes, believe it or not!
The final has been set for April 28th, the last possible date for this class. Will we be awake enough to attend the Capstone reception and dinner afterwards? Only time will tell!
April 9 - April 15
The new Torque book arrived last week, and it's great stuff! Jay immediately rushed out and bought three more copies on top of the free one that the guys at GarageGames nicely sent us. We may have to take back a few of the things we've said about them under our breath when the engine keeps crashing impenetrably.
But, the engine keeps crashing in new and exciting ways, so I suspect the under-the-breath profanities will continue. However, heaps of praise on the author of "The Game Programmer's Guide to Torque". The book still has errors (what is it with Torque books and errors?) but it's a heck of a lot better than what we've been dealing with! Especially check out the reference materials on the CD, if you're a TorqueScript newbie.
What they REALLY need is a book on modding the engine, but there's probably issues of proprietary code around that or something.
At any rate, we now are back struggling with the GUI. We have decided that we should have named the graphic design group "Flatworlders" and the animation group "Roundworlders". And of course, our little programming group isn't even on the same planet. We're trying to get there, though.
Tried the easiest thing this week -- adding our custom splash screen -- and even THAT came with a boatload of assumptions that we didn't expect. So that's been backburnered until next week...
On the plus side, Karen and Thanh finally got clickable water working, so our creatures can have a drink -- even if we don't have time for one, ourselves.
Speaking of which, Gabe (animation team) and Jay are already planning the post-Capstone drink-a-thon...
April 16 - April 22
Slow but steady progress. We're losing Phil next Tuesday, four days before the final, so we're doing real cramming this week. He's made progress getting the creatures to behave better. The swarming algorithm we started out using has caused more problems than it's solved, so Phil's pretty much stripping it out character by character
and putting in our original finite state machine plan.
The catch is that we got so caught up with a lot of other details that the internal representations of health, thirst, and hunger aren't working entirely correctly. Here's where Jay's original notion of doing the whole game as a text-based simulatioin before
going to graphics might have been good. Actually, come to think of it, we sort of did that, using this C++ simulation that Jay had translated to ActionScript some time ago. But, neither C++ nor ActionScript really prepared us for the weirdnesses of TorqueScript.
We won't bore you with the details, for now. Let's just say progress has been made on all fronts, but we're still at the tip of the iceberg. We have decided that for the final we will show a completed "desert world", with video demos of the "swamp world" and "forest
world". Too bad about the swamp: everyone worked hard to get all the assets in place in time, but the integration just isn't going to happen. Still, the animation folks have got a kickass reel planned out for showing off the other worlds, so it's all going to LOOK
great, even if not everything works.