Blog for abc at GarageGames.com

CMPS80k: "The Three Princes" (final project)

abc — 2006-03-15T10:00:06+00:00

30mb zip
other games from this class

I would put up screenshots, but the game doesn't look very good in screenshots. It looks *okay* in motion, and it has pretty good sound. More on that in a bit.

Postmortem: The Three Princes

Intro

Our initial concept for "The Three Princes" was "cartoon adventure," the cartoon part mainly because it let us get away with a simple art style. The "adventure" part we had to waffle about on for quite a while; the game is basically non-violent, since most of the time you're running away from stuff and you don't have any direct means of attack, but otherwise it resembles games like the Zelda series. That wasn't a problem; I had experience doing this type of game, so I knew it was possible. The problem was what came after.

Building a World or building a Story?

After we came up with the most general ideas behind our game, that it was a cartoon adventure, and that it was basically non-violent, we had to delve into details. There were a few other "nos" in there, some of which, like "no boss fights," eroded with the original envisionment when the challenges they presented had to be dealt with; of the three worlds in the game, I can only claim that the first one really does what we wanted, and even then, it has no side-quests, secrets, or easter eggs, making it a fairly barebones environment.

The problem came when we got to storyline. We became overly fixated on the plot of the game, and this led to a cascade of other problems. Spending so much time on the story meant that we had a lot of dialogue, and so one team member became a dialogue writer for the remainder of the project. But we also found that so dialogue cut up into little text boxes became a chore to read. For the intro to the game, we improved the situation by adding some additional scenes to visualize events. For the remainder, we cut what we could, but there wasn't time to do any more. We were chained to the story. And even then, we slowly let the literary elements of the story slip, eventually cutting the climax of the game into a cliffhanger.

Focus on story meant disfocus on gameplay elements. There was no formal design document. We split the three worlds of the game amongst ourselves, and came up with some general overviews, but the actual implementation was all up to me. Nobody else was designing the puzzles, enemy behavior, and order of events, and saying directly, "let's do it exactly like this." So I had the task of implementing some fairly unclear visions, and was for the most part playing "design troubleshooter" the entire way through; the results are predictably uneven. In general I tried to make the puzzles too easy and not too hard, but with little tweak time, there wasn't much I could do about making *good* puzzles, so there are only a few and the reliance was mostly on reusable enemies for challenge, which was also a terrible thing to go in blind on, but I think I managed through it acceptably.

Content

Content was a huge challenge. The dialogue writer did a decent, but not exciting job of telling the story; there are many errors both in the script and my implementation of it, but time was the main issue in fixing it. I did all of the music with Psycle and free VSTs, and I have to say that that was my favorite part of the project. I liked doing it and I liked most of the results. If people come back to this game, it will probably be because of the music.

The main issue was sprites. Our third member, the one that wasn't me and wasn't the dialogue writer, was in theory a sprite artist. He was, unfortunately, more of a "do-nothing artist" and it took some willpower not to blow up in his face. He made content, but not a lot, and most of it was poor. Either he did drawings that showed an obvious lack of effort(the player sprite, which I mentioned in my previous going-crazy-post here, was probably the most egregrious of these), or he found photos and cut and paste or shrank them down - sometimes doing so acceptably, as with most of the phone sprites, but other times resulting in backgrounds that looked "good enough" at first and on each closer inspection became more and more infuriating - one of them even still had the watermark!

So why didn't I come down on him? The problem was that I didn't feel like I was in a position to say "this is total crap, start over" without the support of my other partner, and I didn't get time with him alone and looking closely at the stuff so that he would agree until very near the end of the project. We made our complaints clear the day the project was due, and he claimed to regret being so sloppy after the fact. I guess I can believe him, but whether or not he meant it, what I felt had to be done during development was to make graphics myself -- quickly. I did what I could. It's too bad people tend to judge games by their looks, because this one could really do with an overhaul.

Testing

The morning the game was due, I finally implemented the dialogue, the last area, and some of the last characters. I had time to test and fix bugs from all of these new things once. The results: Poorly formatted dialogue, an "error if you go backwards" bug in the last area, and a character who asks for money, successfully checks for the existence of the money, but does not actually subtract the requested amount. Also, rocks that were meant to shoot up in the air but instead merely blast downwards at high speed. Sigh. I'd fix them, but I'm ready to move on.

Presentation

On the same day the game was due, we got to present it. Half the class(the other half goes Wednesday) got five minutes apiece to present on one of four screens running in the room. So I also got to see the other games. It felt very much like I was at an expo or something as each screen fought for our attention. Most were unexciting; a few were neat. My friend Nick with the neat physics/universe engine had his Ninja Olympics game running. There was a photographer there who shot about a zillion pictures of that. So I asked Nick, "How did your game turn out?" since I remembered noticing that his original concept with multiple gameplay sequences got cut down to just snowboarding as he realized how hard doing gameplay was. My game has snowboarding too, it's just not nearly as cool looking. But from what I saw, even the final result was cut down. The gameplay, in his own words, consisted of "move as slow as you possibly can while doing a zillion tricks in the air." It all made me feel better about my own game.

Anyway, when we went up, we used the computer sitting in the Media Services desk to run the game. This was a mistake; we should have brought along a laptop, as the computer was underpowered for the task. It took something like two minutes to load; once in-game, we were treated to slowdown, and lots of flickering and white areas because there wasn't enough memory in the machine to hold the overworld portion properly. Also, I could barely hear that music I so liked over the din of the class and the other games most of the time, perhaps in part because the speaker system got split amongst the games, but also because I got the impression that the volume on that machine was turned down.

Still, people were reasonably impressed and asked questions about the game. So I guess the presentation went well anyway! (but I doubt the photographer took any pictures of the flickering, white, slowed-down morass)

Summary

The last three-and-a-half weeks were at times painful to live through, but also constituted an extremely informative learning experience, one that bore strong resemblances to anecdotes I've read from inside the industry. I found that I wouldn't have had half as much game to show if it weren't for a weekend deadline extension, because so much content work was crammed into the end. Our decision to build to a story had many consequences, mostly negative for the total game. Skills really make the difference in what you can do - long, hard work is just a consequence of having a lot of skills and little time to use them. And most college students aren't game developers. Overall, I think this game was a success - perhaps not critically or commercially, given that it looks and feels more like an overextended prototype than a shipping release. But the core of what we were going for remains present.

Oh, and we got off to a slightly late start because my teammates, being students first and developers second, didn't want to actually think about the project until a little while before our concept document was due. We could have done something even larger had I convinced them to start some work early on, but I think that might have been a disaster simply because I wouldn't know the challenges ahead.

Here's the thing that's most important: it's a lesson I already knew and know a little better now. You can think you know something, you can "learn" it. Then, later, you get some experience, and you learn it much better and more thoroughly. Still later, you REALLY LEARN IT, PERIOD. I went from "learning" game development to learning game development by doing this project. It was big enough to challenge me properly. Going from learn to LEARN is going to be some years in the making; I know that now. But you always have to be naive first, and gain the real knowledge from the challenges you face.

crunching

abc — 2006-03-07T11:22:15+00:00

My game design class is coming to its close as I enter the final week of development and try to pull this thing together into presentable shape. The last two weeks have been hectic and it looks like the last one will be the most so....good luck self. I'd put up a picture but a lot of sites are being funky for me this evening, so image hosting is unavailable.

With very little debate, our team settled on a "cartoon adventure" idea to start off of. The rest of the design process was chiselling down....carving out the story, the "musts" and "shouldn'ts" of gameplay, the characters, and slowly getting down to individual pieces. We started out with some ambitious concepts and managed to preserve a bunch of them, but as time progressed I noticed how we more-or-less brushed away some of these concepts in favor of solving the nitty-gritty basics. At various stages of the design process we were all helpful...but it's in the implementation that I'm seeing the real differences.
For better or for worse I've done the vast majority of the implementation work because I have the largest skillset. I've worked with the "Game Maker" program and know most of its ideosyncracies already, so I did the gameplay coding. I composed every one of the 17 and counting BGM loops and made up the sound effects. I put together a working version of the entire first third of the game by myself. For this week I'm getting to a stage that I've been somewhat dreading for the whole project, as it is reliant on the rest of the team. One member has been doing paper level design and dialogue. The other has done sprites and made "could-work" mockups of levels using Game Maker's tools.

The dialogue is good. The paper levels seem OK. It's the sprites and the mockups that are going to give me an aneurysm because they clearly aren't up to the same standard that I set with what I already made. Take the main character, for starters. He follows a "smiley-face-with-limbs" character design, which I would think would be easy enough to get right, and yet, somehow, he manages to be MESSED UP. The problems are manyfold: An asymmetrical, unclean mouse outline, downsized from an enormous resolution to 32x32 and left uncleaned, with legs that are thin and set too far apart, hands too blocky and high, left UNANIMATED, and with the forward/backward and left/right versions made at DIFFERENT SCALES.

I started trying to fix it, and then finally decided to redo the character entirely. Keeping that sprite would have been embarassing - nobody would take it seriously. I gently hinted when I first saw it that it could do with a revision, but this appears to be the best I'll get.

Similarly, the level mockups are done in a style that can best be described as "Windows 3.1 gaming," built to a lilliputian scale and generally consisting of some border made from a repeated sprite, a seamless repeated texture for the background, and a bunch of sprite rips for objects inside the room. They're not ALL that bad, and a few of the sprites based on photos look fairly decent, but the only way I think I can manage to have some pride about the working set for these later areas is by thinking "this stuff comes later in the game! We can hook them at the start and then get away with this bullshit in the middle!"

Oh, and none of his resources are given names. The whole time he was showing them to us he was clicking haphazardly five or six times in a row to try to pull up the right room.

With respect to the final project, this is a terrible class to be "just a student taking it for credit" in. It's also a terrible class to be a "hardcore developer" in. The former gets pushed to do grunt work without any preparatory instruction and the results are predictably abysmal; meanwhile, the latter gets held back by the former.

Words...don't come easy

abc — 2006-02-17T06:53:54+00:00

My class teammates and I went with a completely new idea since I last posted, and good progress has been made. It looks like we've designed out a pretty deep narrative game, and it won't take sophisticated AI either. We started out by saying that it would be a cartoon adventure, and then started subtracting elements we didn't want - no platformer, no "boss fight," no explosions(this is a stipulation imposed only because we get extra points for it...it's hard to make absolutely nothing explode in a game), and once we had enough things subtracted, only then did we start adding in things like branching plot, puzzles, character abilities, etc. This evening while finishing up the concept document to turn in tomorrow, we started adding some literary elements. It'll take a good deal of work to really flesh things out on that front, but I think already we've done about as much as any commercial game has done, and we're keeping the gameplay simple, but not dumb or unrelated.

One of the issues I see us running into in adding literary elements is that while those elements are meant to describe something about humankind, the player is imposing their own subtext through their actions. So when we draw parallels through e.g. naming and characterization, they can only be brought so far and they won't feel consistent if the player deliberately makes a character do goofy things. If you do very much branching, it quickly becomes a higher order of complexity from linear writing, so it doesn't let you spray ideas all over and expect to easily tie them up later.

Common examples: The PC can't be a hero if the player is allowed to slaughter innocents. Neither can the PC be particularly tragic if the player is defeating everything in sight instantly. What really has to be done is to get away from those kinds of archetypes, I think, and invent new ones that can directly describe the player. Specific traits that are presented as options work well: Greed. Lust. Jealousy. Arrogance. Shyness. (although no video game player is shy if the game can be reset) And the outcomes of these decisions are what can bring meaning into the story. All too often games are overly realistic and logical, for example: help out person, you get stuff. Sure, it makes sense to do that, and the player gets some reward so that it's satisfying. But it's about as meaningful as being told to take out the trash or do the dishes and it doesn't do anything for plot advancement. Why not have an errand as a reason to...

...put the PC in a position to see/hear some event?
...develop some of the PC's traits as percieved by the world/characters? "nobody will notice if I..."
...introduce some theme or plot device that can later be followed up on? "we need to raise money to help ...."

This has been done before to some extent, but I think this is the kind of stuff I think this game is really aiming to break ground on, to have a non-dull world experience and to make everything tie in with everything in a way that can say something reasonably profound. We've deliberately made it a short game and easy to do assets for. Three weeks...but it looks like all of us are ready to put in the effort :)

School project....getting ugly

abc — 2006-02-09T04:52:52+00:00

So, as the final project in our game design class, we have to make a video game. So we also have to propose the concept. We turn in the proposal a week from next Friday and have about a month from now to finish the completed game. My teammates have dragged their feet the whole way; they don't seem to want to spend any extra time on the class like I do. But we that we should meet today and figure out what our game will be.

So, I go off and I come up with this fairly ambitious thing: a 2d side-view action-adventure with strong plot similarities to the first Die Hard movie; in this one, the terrorists take over a nuclear missile silo, plotting to launch the missile and start a war(or maybe some other similar bad thing), and as the chief security officer you try to stop them before it's too late. The main focus of the game is to make it a "simulation" of the attack, rather than a linearly-scripted game, so that it feels alive and dynamic - still cutscenes to add drama could also be added in by dressing up with costumes, taking photos and subtitling them. After coming up with this idea, I do about five pages of sketches and notes and start implementing some of the most challenging parts of the game: the pathfinding routine and world model. Although we're recommended Game Maker and have spent many lectures on learning to use it, I get annoyed at the scripting syntax after about an hour and turn to my default of Python, and it unsurprisingly turns out to be a much faster tool for me. Today I got some work on the actor model(sensing and reacting to events) started.

So then I talk to the other two guys during/after class. They both go "uhh, I didn't come up with anything." And they hold reservations on my idea too; on feasability, on how similar in theme it seems to so many games, and on how easily they can understand it since, as I'm envisioning it, it's not really a clone of anything in *particular*, but it uses some well-known gameplay elements in slightly unusual ways. They would feel far more comfortable with a clone, of course. The three of us don't actually have a meeting, because the guy that set it up runs off after class apparently forgetting our meeting, so I only got to talk to that one briefly. But I show the other one the progress I've already made and he just sits there like an emotionless lump. "If we go forward with this you're going to do most of the work," he warns. (this is in reference to my using Python)

I guess I will do most of the work because I don't think they'll come up with anything at all. As partners, they seem absolutely depressing at the moment. They have no sense of time constraints or enthusiasm for making anything. I think I can get them a little more hyped up once I have things moving around on the screen, but it looks like it'll be a long four weeks either way. They don't appear to have any skills to speak of(they certainly aren't advertising it), so I don't know what they can do if they do managed to get stoked about the whole thing.

An interesting side note: Myself and Nic(the guy I mentioned in a previous entry with the awesome physics engine) are, as far as we know, the only ones of a handful - like three or four groups of two/three in a class of 170 - trying to do a non-Game Maker project. We also coincidentally happened to structure both our games (in gameplay, not thematically) on the blueprint of old Dynamix titles. He's doing something like "David Wolf: Secret Agent" because it suits his engine. I'm doing something like "Project: Firestart" because...well, I dunno, but nobody's really touched that design yet, so far as I know. And it's a good one to work off of, and I'm twisting things around to add a little to it. So there :)

"Tara"

abc — 2006-01-26T05:14:21+00:00

So, I've been taking this game design class. It's been a great class; the lecture this particular day included a student demo of Guitar Hero, an overview of rules and how they relate to emergence vs. progression(we're generally following the outline of Jesper Juul's half-real), and turning in non-video design projects. I also got 100% on my analysis of M.U.L.E., though 100% wasn't an uncommon score.

After the class I got to talk with this one guy on his long-term dream game project, and I think I might stick with him, since I don't have a dream game at the moment. It's ridiculously ambitious but he's already spent two years on it, and he's amenable both to spending literally decades of time on it and to pare things down and make compromises at regular intervals so that a sellable product might be made; he's taking a very rational, level-headed approach to it, and because of this I can actually see some reasonable business plan made out of it.

The gist of it is that he wants to, by the end, do one of those "do-anything" kitchen-sink games, in a sci-fi setting, making it massively multiplayer and moddable. That's not really the part I care about, since it's too pie-in-the-sky to be made anytime soon. What he already has *done* is very interesting and different from what most of the industry does. He's a physicist, so he's made his own rigid-body simulations, Newtonian dynamics, etc., and to make the content-creation process of planets and starships managable he's created and integrated a large variety of classes for terrain creation - heightmaps, rooms, poly-soup meshes, etc., and is in the process of building toolsets for them. He's avoided implementing graphical features beyond some texturing and lighting with OpenGL, and his main focus right now is to finish a human figure simulation.

Given the evidence he's shown me, he has indeed done the work he's claimed to, and is talented enough to continue leading the coding work. And he feels that he spends too much time doing art assets right now. Previously in this blog I noted how I was at a sort of crossroads in what skills I could pick up, and I was thinking to start leaning towards artwork. That it would let me fit into a needed role on this project would be a happy coincidence.

At the very least, it'll be good practice. I might start putting up some images here in the near future.

The unknown's scary.

abc — 2006-01-15T01:53:46+00:00

This is a big "think about career" post. As tends to happen when I start another quarter of school, my productivity for any sort of long-term project temporarily stops until about two or three weeks in when I get into the swing of things again. This is OK with me, it's a good break and I get some time to think about the long-term future.

The main thing I'm worried about, I suppose, is that my production skills aren't really strong in any one particular area. I do some drawing, and I do some tracked music, and I do some programming. It's sufficent to make a certain quality of game, something 2d that doesn't try too hard to be fast-moving or shiny. So in theory, I could strike off on my own and try making something to sell immediately, but right now I don't feel comfortable starting a business the moment I graduate, or while still in college for that matter. Plus what I can do with those skills is more likely to drive the games I make towards the casual end of the market, which is getting quite intense right now.

So the alternative is to get employed. Which brings up the skills problem again. The reason I took the time working on each of these different areas was to be self-sufficient in producing my own designs. I like the design part, but it's also the position that requires the smallest amount of manpower since it's not about implementation. But after a certain point my interest in the production aspects drops. Finding any sort of foothold in the development market looks like it will be very challenging from this starting point.

This QCS project of mine which I've been logging in previous plans is intended in part as a portfolio-builder exercise, but I keep getting the nagging feeling that it might put emphasis on the wrong parts of my skillset - building this thing into something resembling a working product has been mainly a tremendous programming challenge. I don't doubt that some people will be enthusiastic about it, and the end(or rather the beginning) is in sight, if still a bit too distant to make me want to crunch the rest of the way. But nonetheless I worry that it won't be enough to get me into a position somewhere, some place where I can work on games without having to worry as much about income or sanity.

I've still got about another year-and-a-half to work things out, at least.

Passive v. active interaction

abc — 2006-01-08T02:01:39+00:00

So over my winter break I got to be around my older brother a while. He's a grad student and he's decided to(among other quirks) avoid keeping a computer set up in his apartment because it interferes with his studies. So when he's back home he tends to soak up as much gaming as he can. Usually he ends up getting "stuck" on one title until the vacation's over. The object of his addiction, on this particular occasion, was Cute Knight from Hanako Games, a Princess-Maker-esque life sim. We decided to buy it together - I tired of it after a few days; my brother, on the other hand, kept going until he left.

My rationale for quitting was "I've experienced all the gameplay. There won't be any new career paths or items. The only thing left is more endings, but they won't be substantially different to play through, so it's not worth it even if I miss out on a few things."

His rationale for continuing was "I haven't seen all the endings yet and I don't know exactly how to reach all of them. This is a problem I want to solve."

The reason I make this contrast is that it brings back the question of what a player wants out of the game experience. I felt that because the gameplay aspects of the story had essentially been solved, I was done and playing further was like playing more games of Tic-tac-toe. What intrigued me most was the demo - there were lots of options but you were given only limited time to try to execute them. In the full game, I realized almost immediately that there's enough time that it feels like the game world "collapses" towards the end - you just pick a potential ending and work towards it - so it starts feeling very rich and open and later ends up being heavily constrained once you narrow down the goals. This was something my brother really enjoyed, I think, while I considered it uninteresting.

Then I thought to myself this evening, looking at some other article, "this really does reflect on both me and him. He likes sitting there ten hours a day solving well-understood problems. I prefer wandering around and observing things and possibly making some non-obvious connection between them." Gamer psychology has been done to varying degrees before, but this was a real-world example of it. The question it raises for me is, how can I design a game that interests me in some way other than being a simple problem-solving exercise? This is what I usually find myself faulting games on - game experiences are hardly ever "passively interactive." And when they are it's usually as an interlude or endgame case, not as the core experience. I think this is the question I've been wanting to ask myself but couldn't decipher previously.

QCS Progress Report #5345235

abc — 2005-12-23T03:35:10+00:00

I haven't updated on QCS recently. But it's all going well. I've been filling out editing functionality....now you can create new Things, rename them, delete them, edit some(not all yet) of their properties...and today and yesterday was spent reblocking the code so that it actually uses seperate files now. One of the things about Python is that it doesn't really force you to use lots of seperate files until you want to, but making the change generally means a lot of minor breaking and fixing of things. So there's some inertia against doing it, but I finally set to it because editing a huge source file is aesthetically unfun and if I want other people to actually contemplate developing, I'll have to keep such things sane.

While I'm at it, spirit of the holidays and such, I'll point everyone to a pre-pre-not-very-official-unfinished-release download:
people.ucsc.edu/~jhofmann/qcs.rar

It's just the Python source, so you have to have all dependencies(Python, PIL, Pygame) to run it. Start it from qcs.py, or possibly(if your install is set up right) run.bat. It's set up so that you only see the test gameplay: Arrow keys move, 'a' key brings up the attack cursor(space selects your target), 'q' quits. To see the other stuff I've done, you can uncomment the two commented things at the end of qcs.py. Like I said, pre-pre-not-very-official. It still doesn't look like much of anything because it's not yet to the point where any substantial content pipeline can exist - I haven't even put in load and saves for the editor bits that are done. It'll get there.

You can also see the mission statement, which I think I've made too complex, and the readme file that has nothing to read.

Monday Dec 12 19:08

abc — 2005-12-12T19:08:50+00:00

Ludum Dare 7

I did an entry for the Ludum Dare 48 hour gamedev competition :) It was fun and I was unusually productive for the duration, even when factoring my long breaks.

http://ludumdare.com/wiki/index.cgi/JamesHofmannFinal
This is the final version.

http://ludumdare.com/wiki/index.cgi/JamesHofmann
This is the during-development log.

Now, the postmortem.

My first thought is that I think I really hit on a good puzzle game idea with this one; had there been more time to flesh it out it would probably have crack-like addictive properties. I had an overnight period to think about the concept(Friday evening before I went to bed, I found out the theme - "growth") and start turning it into a design. My thought process was something like this:

1. I want something growth-related, and I need to keep it simple because I wanted to use C++/SDL and I've never tried using that development environment before. A puzzle game seemed likely since the algorithms and data structures needed are usually fairly simple.
2. I always wanted a version of Tetris where you could "build to infinity." That just seems like a really cool concept to me. When part 1 came along the idea fit pretty well. (this was the lucky break for me) I considered a few other angles for tower-building, but the Tetris-like one seemed the best. That reduced the design challenge to a matter of retrofitting some interesting new gameplay onto the falling block concept.
3. I turned to the real world to come up with possibilities for gameplay. The main one was "how could I make the player build in a fashion that is reminiscent of the real world?" I considered how in skyscrapers, the girders are stacked first in a set of verticals and then horizontals, and how they are first put into place by crane and then welded by the workers. These ideas cumulated in the main gameplay element, the nail and combo-building. In the final game, you try to arrange the girders in a way that favors horizontal direction, because when the nail piece appears and hits a girder it spreads your combo first horizontally and then downwards - the girder arrangement becomes important because it will always follow their contours.
4. Once I had this down, the remaining problem - which I couldn't quite solve - was how to maintain some challenge and tension, since you don't lose through piece placement. I settled on a points-target/time-limit scheme to encourage the player to build both quickly *and* effectively. However, testing reveals that most rounds are finished in one fell swoop with a screen-filling combo, and increasing speed or efficiency becomes very difficult after a certain point; I can consistently reach round 7 and then die there.

Overall, the design was good, and simple, as I wanted - very important for LD48. Thinking back on it I believe the challenge issue could be resolved by replacing the fixed 2-minute time limit with a more flexible one that adds time as you gain points. With that and more tweaking on the piece selection(including corner blocks would change the outcome of most combos significantly) it would probably be a fine game.

The implementation was crufty but went surprisingly well. I could get away with really simplistic ways of doing things(almost all the data was stored in C++ namespaces, or just plain global variables). I had a crash bug that I never figured out, but oh well. Given the time I had the production values were OK, but not quite as good as some other entries. All that remains is to vote and see how I do :)

Sunday Dec 4 22:38

abc — 2005-12-04T22:38:22+00:00

The Movies, QCS

Last week I had a case of foodborne illness and that, as well as it being the week before finals, slowed me down a lot. But I did come across something cool that hasn't seen much press attention(yet): short films made with The Movies. They are small in filesize(very low-quality WMV format, usually only a few mb), are 2-7 minutes long, and the ones that get rated highly - especially those that include voice acting - actually work as decent cinema. I think the sheer *quantity* of work, with these short films being posted every couple of minutes right now, consititutes a major breakthrough in the accessability of machinima...indeed, there seem to be so many releases that no one viewer can hope to keep up. This is definitely ranking among the most interesting phenomena I've seen online :)

QCS-wise, building in scripting is something I've flipped back to waiting on again, even though I was feeling pretty gung-ho about it last week; not only is it difficult, working on it takes away time that I could spend crafting gameplay-important items that are more readily accessable(like simple built-in AI programs and actions-with-tests-prequisite). I also keep thinking that I should make (or adapt from other people's projects) my own pixeling tool for tiles because I'm never happy using most graphics programs for that purpose; they lack certain features like actually showing the tiling as you're working, or using portable formats, or allowing keyboard cursor control instead of straining one's mouse hand trying to keep it steady; these things can be real showstoppers IMHO. Either way I haven't been getting very much "real" work done on the project, but with the winter break ahead perhaps I can make up for it.