11-20-04The Stranger's Wrath code is possibly the most stable and robust game code base ever; certainly it's by far the most stable I've ever seen. On the entire project, we've only had two persistent nasty crash bugs - one was from Granny (a licensed library), and another is from XACT (the XBox audio library). Both of those libraries fail to follow our guidelines of being self-checking, input-validating, etc. For example, XACT will simply crash any time you play sounds with an index out of bounds, which can happen easily due to people have different revisions of the content. It's been extremely important for us to have this level of stability. We are able to take the development build and deliver it as a fully stable milestone in about 1 days' notice. Generally the bad bugs we have to fix are "stop playthrough" bugs, not crash bugs, and quite often the "stop playthrough" is just a design issue, that eg. this door doesn't open so you can't move on. We had to deliver numerous demos to publishers, to MS, to EA, to press, and it was all reasonably easy because we could go from full development to a stable build so quickly. In fact, it encouraged some practices I wasn't too fond of - the design team would frequently work on demos until the day before delivery, so we only got one day of content lock to test & fix code. In the past I've always wanted closer to a week of content lock to make sure we get a stable build.
I would discourage all programmers from relying on repro for bugs. I don't use repros unless it's a strange bug or needs a specific case to test, etc. Generally I try to fix bugs just by looking at the code. When someone describes a bug to me, I think of where in the code that problem could be caused, then I simply go and look at that part of the code. You can look at that code and see how it might break, and 99% of the time you can spot the bug just by looking and making sure it's robust. Even if you don't spot the bug, if you have a good idea where it is, you just add some more asserts and self-checks and logs in that part of the code, and hopefully those will trip in the future and give you more information, and they can stay there to make sure the code seems strong. Another thing that I emphasize is to look at how the bug happened and try to prevent that from happening in the future. Look at the buggy code - how did that get in? Was it reviewed? Did both people involved actually understand that bit of code? Did they talk to the original author? Did they test it? Did they have good asserts checking the code? I try to not only fix the bug, but also fix the behavior that made the bug. Sure, sometimes you just have mistakes that make bugs and everyone was doing the right thing, but that's actually rare compared to bugs made from someone trying to be too fast or sloppy (often me). Repro is sort of a crutch for bugs. I don't like to fix the code for one specific repro case - I like to make the code bulletproof for all possible break cases.
It's funny to me that we (Oddworld) and Bungie use the absolute opposite coding styles, and yet the result is extremely similar. We use heavy C++, dynamic allocation, multiple inheritance, STL. They use almost straight C, macros, function pointers instead of inheritance, no dynamic allocation at all, etc. In the end, we both push the XBox very hard, running the GPU to the limit, using all the 64 megs of RAM to the fullest. I know they don't believe that we use the hardware or memory optimally (in reality, we do stall on L2 cache misses because of our polymorphism, but that's maybe 3% of CPU time lost), and we don't believe they can possibly develop rapidly and robustly, but probably we're both wrong. However, our situations are very different, and I can't imagine their style would work here. We've had to hack in crazy new features on a daily basis; if I want to make some types of objects support some new interface, I can just define that interface and dynamic_cast to it at the query point; I don't have to push my crazy feature up to the base class.
11-20-04The testing we've gotten from EA has been really terrible. We've not gotten a single decent focus test or play test from them. When we ask them for play test feedback, they have some exec assigned to the project play the game and send us notes. Uh, thanks, but no thanks - have you guys ever made a video game before? Have you ever heard of getting people in the target demographic to play the game, maybe tape video of them? Of course, Oddworld also failed to do it themselves. So, we're left with our own play-throughs to tweak the game. I think we've done a decent job, but it's hard to tell, because we're also so jilted from playing the game for the last 3 years, there might be really major flaws that a new eye would perceive that we don't see. Our bug test has been pretty poor too; I don't know what the deal is, but the testers seem really junior. They enter bugs without decent repro steps; when we question them about it repeatedly, they wind up completely changing the repro steps and describing a totally other bug. They also have failed to find all sorts of major bugs, which we had to find and enter ourselves. In fact, here we are a few days from Beta, and we're still finding major bugs in house and they're not finding much of anything significant. I don't know if EA test sucks in general, or if we've just been given the "C team" because we're not one of EA's darlings at the moment.
11-17-04In the development of Stranger's Wrath, we had various people on the team who really wanted to make a shooter, so they tried to push that on the game, we had people who wanted to make an RPG, so they pushed that on the game. We had basically no one actually looking at the cool strong unique elements of the game and trying to make them richer. Probably the strongest unique element in the game is the 3rd person fast run and ramming. It wound up being not really a major element because it wasn't played up. Things that would have jazzed it up - hold a button to lower your head which prevents you from turning but makes your ram blow guys to pieces; the ram should create fear in guys who see it coming - some just panic and stand still, others dive out of the way, etc; make your 1st person weapons more complementary to ramming, eg. a freeze shot, a slow-down shot, etc.; make other ramming and anti-ramming enemies, like a Matador boss who side-steps you, other enemies that are very fast and ram, like a goat-demon.
Some really cool scenarious with the fast run & ram might have been: a chase - some giant guy that you can't kill chases after you; you just have to run away, ala the big rock in Raiders of the Lost Ark; chasing down enemies who are fleeing (we did get some of this) or a carriage hijacking or something - in a big level, a carriage is speeding away with the outlaw boss in it, you have to run up along side it, while his goons on top shoot at you; you can ram it and bump it, you have to get up to speed with it and try to jump in. In general, the enemy could've had fast vehicle you have to run along side of.
Often when I suggest ideas, the designers say "I didn't think that was possible in the engine". Well, it probably isn't, but it easily could have been. Engine features are made based on what's needed for the game. The design has to be done (considering the schedule) based on what will work, not what does work.
11-16-04We were originally scheduled to ship about a year before we actually are. There's certainly no good reason why we didn't make that date, but various things came up, like having to make demos and sign a new publisher, and the fact that we had no game design or designers for the whole first year of dev. Oh well, minor issues. Anyway, shipping at the wrong date really screws up development. If I had known our actual ship date, we would have done things very differently - better renderer (with dynamic lighting), better physics (maybe a real licensed physics engine), better tools, better animation system & pipeline, etc. - all those things were cut to make the original ship date. For the whole last half of development (18 months) we were in the mode of "we have to ship in two months", and that deadline was continually moved back. Well, if you only have two months to go, you have to be in feature freeze, so we had lots of problems with pipeline, etc. that we couldn't fix. The result was that everyone was working less efficiently than they needed to. When you know your real schedule you can do proper planning - heavy tools work in the first 25%, finish the engine by the next 25%, finish the features in the next 25%, and polish in the last 25%.
11-16-04I would have loved to have taken the "Live Ammo" concept to the extreme - everything in the "Stranger's Wrath" universe could be alive. There are some famous scifi artists who do this, I forget their names. Anyhoo, the cars are animals, tanks are turtles (for their armor, of course), instead of a boat you ride like a loch ness monster, your crossbow is a living creature, everything is wet and soft and shiny and slithering and alive. The live ammo could talk to you all the time, run around on your body, steer through the air, etc.
11-16-04I hate "Just Too Late" algorithms on a deep moral level. The so-called "Just in Time" compiling is really JTL. If it was really JIT, it would be ready to go when I need it. Instead, I ask the app to run, and then I have to wait while JIT does its thing, then I get to go. That's sort of like if you asked a nurse in an operating room for a scalpel, and she goes, "oh, I've got it just in time, let me go get it from the supply cabinet" - No! That's Just Too Late! It looks to me like Halo 2's paging is JTL. Resources request residency when they are used, which means they don't actually become resident until after they're needed. The worst case for this kind of thing is when the camera is jumping all over the places, the resources you need keep changing, and the paging can never catch up with what's actually needed. We try to do all our paging with a true "JIT" system, which means they become resident just in time before they are needed, so the user never actually sees them non-resident. To do this you need good foreknowledge of what will be needed, which is generally pretty easy in gameplay because the user can only run around coherently - you can't teleport to arbitrary random spots, so I know what's near you and what direction you're going and I can anticipate the needed resources. In cinematics it's really easy, because the whole thing is hard-coded, you can compute exactly what's needed at what time and store a timeline track of when things should page in and out.
11-15-04"Oddworld : Stranger's Wrath" stories - we have great big seamless levels. The state of the whole world is persistent, so if you drop a coin somewhere in the game, then play for hours and go back to it, the coin is still there. In the shipping game, the levels are pretty linear. We imagined them as being more like an RPG, with exploration, and big wild spaces, spawning persistent enemies you could kill for money and resources. We have towns, but we imagined big towns like hubs for the levels. You could stock up in town, talk to people, then go out on missions, go back to town and stock up, finish the mission, etc. We still have some of that, but not much.
We have various different character types and races. In the shipping game, they basically never mix. We originally planned on mixing them, and wrote most of the code for that. Part of the original vision was a sort of play of the races and their interaction - like, you have the oppressed races and their oppressors, you have rednecks and city folk, and they sort of interact and mix and talk to each other and you can interact with them and manipulate their reactions, etc. Most of the races are in the shipping game, and they have their character and whatnot, but they don't interact.
With a lot of features we had a sort of chicken/egg problem. We'd sort of do a feature, like supporting moving collision and animated objects. I always imagined levels where there were giant gears and pistons and you could run around on them - avoid getting smashed yourself, and knock your enemies into getting smashed. Nobody ever implemented anything like this and there was no call from design to improve the "moving collision" code, so we didn't work on it. The result was the code is rather sketchy and unpolished, because it just wasn't a priority. The design guys tend to try to use what works and exists, so they never used moving collision much. This is why coherent direction and cross-department vision is so important, you need someone in design who knows what's useful and what's not, and you need someone in code who knows what can be done and what can't, and they need to get together and agree; then the game needs to be designed based on the features that will exist, not the features that do exist.
Everything takes us 5X longer than most game devs, because every feature has to be extremely polished. A game like GTA:SA could never be done here - their controls suck, it glitches like crazy, but they have tons of features. We would take one of their features and spend years tweaking and polishing it. Obviously GTA:SA is very successful, but I find it intolerable to play. I think the optimal game dev model is somewhere in between, but much closer to GTA. Basically polish doesn't matter much except on the player controls. The game should be responsive and solid so far as controls are concerned, but if it looks like crap, glitches, pops, the animations are terrible, no one cares (well, the average consumer doesn't care), and it's a waste of dev time. In a way, that makes me sad, because I have a very high quality standard and like to work on solid product, but it just doesn't pay in the marketplace.
11-15-04"Oddworld : Stranger's Wrath" is almost done. I think it's a very good game. Not nearly as good as it could have been, not as good as Halo 2 or Half Life 2 (probably, we'll see), and of course we're just talking about the single player, they have great multiplayer and we have none, but still one of the better single player experiences in the last year. Our lovely friends at EA are doing almost zero marketting for us, so I thought I'd do some here -
Clearly the semi-innovative thing about it is the 1st to 3rd person gameplay. This is the first game I know of that has a really fully functional 1st person shooter and a 3rd person platformer/melee/driving put together, and quite seamless and smooth where you can switch back & forth and it feels good and natural. You actually switch in combat to do various moves, unlike some games where you move in 3rd and snipe in 1st, etc. The 1st and 3rd are also actually different, it's not like Heretic or Everquest or something where you can use either view, but the 3rd person is really just 1st person on a stick behind the axis of rotation.
In 1st person, the game is basically a shooter, but the weapons are a bit quirky. Many of the weapons are not basic damage weapons, they're tools for manipulating the enemies, and you can combine them in sequences for "combos". One of the basic combos is just to freeze a guy with bees so you can lay a thudslug or boombat on him. Another common one is to skunk a mob then drop a boombat in the middle of them. There are also lots of environmental traps that you can make use of; there's lots of knocking guys through glass to their death, things like that.
In 3rd person, the game is like a platformer/adventure/driving/melee game. Here, you are fast, very fast, and control sort of like a car or motorcycle (actually the controls morph from standard walking at low speed to more like a car at high speed). You can ram and meelee. One move few people know is that if you jump before you ram a guy, you keep your velocity and go through him - very useful.
One of my favorite things about the game is the twist. I won't give it away (we've asked all the press to keep it a secret), but part way through, there's a big story twist. That's pretty standard in movies and games, but there's a difference - the play actually changes a lot as well. Unlike most games where you get a story twist, or play as the enemy, and the gameplay is basically identical, here the whole feel of the gameplay changes a lot, the pacing changes. It's a cinematic thing, there's a shift and suddenly the feel is different for the 3rd act building to the climax. In the beginning, you're a bounty hunter, in the end?
11-14-04Halo 2's first level (tutorial) is pretty horrible. It's ugly, the play is nothing that wasn't in Halo 1, it really doesn't sell the game. After that, the game gets much better. This is such a huge and common mistake - for them, it's okay because they have such hype they don't need to sell new players, and people will get past the beginning. For most games, like mine, if the first level is bad, no one will play farther. I think our tutorial now is actually pretty good so far as tutorials go. It's not as good as Sly Cooper or Halo 1, which both do the right thing - put you straight into gameplay, and introduce the controls gradually over the duration of the first gameplay level, as you need them.
Halo 2 actually reminds me a lot of "Colony Wars". That was a great game! Great music, story, voice acting, and beautiful graphics.
11-14-04Wow, Halo 2 is really good. This is the first video game I've played till 3 AM in a long time. The first level looks like shit, but after that the graphics are mostly beautiful. Sometimes the shaders and lighting are just fantastic; I wouldn't say they were super realistic, but they're very beautiful. The gameplay is rather monotonous, it is pretty much the same thing the whole time - take cover, shoot, reload, repeat. The vehicles are ok, but I hate the way they do the controls like a 1st person cam; I'd rather have cars that drive like cars, not like strafing people. The flying vehicles really feel bad/weird to me with those darn controls. The cinematics are amazing; the graphical quality in the cines is awesome (if you ignore the horrible LOD and paging pops!); the basic renderer doesn't impress me as much as all the custom anims and effects and fancy background and matte work that they did for the cines. In general the level design is very good and the integration of the story and the levels is very smooth, coherent, solid.
11-13-04I saw a tiny bit of that history of Video Games thing on PBS; I think maybe it's old, but it was ok. In one bit, Jason Rubin is talking about why video games are great. He says something like - "In real life, I'll never be on a pro sports team, I'll never be able to drive a Formula 1 car, but with video games I can do those things, and that's what makes video games great" (he chooses not to say "in real life, I'll never get the pleasure of running around with a machine gun and spraying bullets into other mens' heads"). Anyway, that's all well and good, but I find it incredibly boring and sad. I don't want video games that let me do things other humans do - I want video games that let me do things no man has ever done! Let me drive a car 1000 miles an hour through the cities of the moon, then take a swim in the oceans of mercury (the metal, not the planet), let me grow enormous and consume the stars, or grow small and fight bacteria. I'm sick of all this real world sim shit.
11-10-04I think one of the big mistakes people in game dev make is they put their best programmers on core engine technology, like rendering or networking, etc. Yes, that stuff is important, but once it's reasonably good, the user can't really feel the difference between good and great renderer programming. On the other hand, things like controls, camera, motion, input, latency, animation, these things provide direct feedback to the play experience, and even small improvements can make a big difference in the sensation of quality. Those are the things that really make a game feel polished and good, that make it like a Nintendo or Naughty Dog game - clean, responsive, pleasant to interface with.
Engine coding is fun because the technology is challenging, the algorithms are interesting. It's frustrating because an engine in itself doesn't show up on the screen - you need people to use it well, which rarely happens. Gameplay coding is fun because you can do features all alone and get cool results in the actual game. Gameplay coding is frustrating because you do 3 features that are cut for every 1 that's used, and you have to spend tons of time polishing silly little features and eventualities that the player will never notice.
11-9-04Halo 2 is out; I haven't seen it yet, but I see Halo 2 as sort a quiet insult to us game developers. Any game company that's half competent should be able to make Halo 2. This is not intended as an insult to Bungie, I have much respect for them, they're one of the best studios around, but basically Halo 2 is not very innovative in terms of gameplay or technology. Sure, some of their tech is fancy, but not in a way that's really important to the quality of the game. Yes, the gameplay is well polished, but it's just a shooter, they don't do anything that hasn't been done many times before. And yet, it's one of the best games of the year, and almost no other game company could make a game as good. This isn't so much because Halo 2 is so good - Halo 2 is the level of quality any game could be - it's because all other games are so *bad*. Bungie gets their priorities right - improve the things that will make the experience better (the networking, the match-making, the basic controls), and not other things. They make time for actual focus ("usability") testing, which almost no other game dev does. On the other hand, I'm not sure how they do it, because all the stories I've heard about development at Bungie sound just as F'ed up as anywhere else - stories of ridiculous gameplay features that they try that don't make it into the shipping game, stories of going off on pointless tangents, only to scramble back to your core gameplay (cut levels) at the last minute and kick out a game.
11-8-04I used to hate Tony Dungy when he was coach of the Bucs. He's kind of a quiet guy, and I hate quiet coaches; I like in-your-face, yelling, angry coaches, like Bill Cowher and Bill Parcells. But, these days, I have lots of respect for Tony. He went into Indianapolis, and he saw the talent he had there, and he didn't force his style of football on them, he went with what the team had to offer. The worst coaches are the ones who bring a "system" and try to put it in place regardless of the team they have. The best coaches look at their talent and devise a way to win with those people. Tony Dungy went from a defense-first, no-score team, to a super scoring team with no defense, and I respect that.
11-8-04Businesses are all shit-sucking scamming bastards. Sports Illustrated gave me a free subscription, and now they're using semi-illegal schemes to make it hard for me to cancel, by making it difficult and time-consuming. The fucking city of SLO gave me the most ridiculous parking ticket ever for crossing the lines in parking spot (at the end of a row, when other cars were already shifted) - the ticket was for $30, it was upheld on appeal, and now to fight it further I have to pay a court processing fee of $25. My damn bank charges me $3 for an ATM withdrawal from any other bank, even though it's free for them.
11-8-04I'm doing my damndest to ensure that all the little horrible things are right in our game - the load times are quick, the GUI's are ergonomic, the frame rate is solid, the latency is low, the game is responsive and nice to the user. These are some of the most important things in games, but producers will never give you time to work on them, and directors & publishers will happilly sacrifice them in exchange for some unneeded feature.
Non-skippable cinematics are just an insult to the player. It tells the player "we don't give a damn what you want to do, we're going to force you to sit there and watch this". There's nothing else like it in media - if I watch TV, I can change the channel - can you imagine a show that prevented you from changing the channel away? I would never watch that show. Can you imagine a DVD that turns off your skip and fast-forward? It's my DVD player, in my house, I'll skip if I want to. (in fact DVD's do have those non-skippable intros which are infuriating). With a book or magazine, you can turn the page any time you want; if the story gets boring, you can jump ahead, but you can also go back if you want. A game is not a movie in a theatre, it's an interactive experience that the user is creating for themselves, they should be allowed to craft that experience for themselves. Now, some people take that too far and ruin the game - the game universe should still have a rule set and logic, and even if people want to do things outside of that, they can't, but they can try (eg. the player might want to drive a future mech tank in your fantasy RPG, don't let them!). You see, that's part of the content, which the game developer should control, the user should be in control of the medium, the mechanism for viewing the content.
11-7-04One of the basic important things in management is to correctly identify the people who are doing well and those who are not. If management goes around praising people who are actually doing a bad job, and chastizing those who are really doing the work, that not only pisses off the people who are doing the work, it creates a bad atmosphere for the entire team - they see that good work is not rewarded. Usually when this happens, the people who are incorrectly rewarded are friends of management, or charismatic, or liars who take credit for others' work, etc.
11-7-04It would be fun to work on a 3d engine that's all physically accurate lighting. So far as I know, such a thing has never been done, and is even rarely done in pre-rendered CG. We still can't do realtime radiosity, so we have to hack the rendering equation in various ways. One thing we can simulate quite well now is a semi-static environment, where the radiosity effects are precomputed in various ways and the direct lighting effects are evaluated in real time in various ways. The main flaws with these approaches are that the dynamic objects don't interact with the render equation well, eg. they don't contribute to the radiosity solution correctly, and the less static the world is, the less correct the lighting can be. The biggest thing for physically accurate lighting in 3d hardware is floating point buffers; this lets you capture the massive differences in brightness between lit and unlit areas. You of course then need an exposure function to simulate the aperture of the eye or a camera.
11-7-04A good director should be able to see the game with the eyes of someone who's never seen it before. Often there's some major feature or character which it seems horrible to cut - but that's just because we've been through the development of that thing, and it seems important to us; if someone saw the game and never knew that thing was supposed to be there, they would have no idea something was missing. It's such a simple point, but everyone gets it wrong; the game should not be directed based on what you the developer think would be cool, but by what a typical player who didn't make the game would feel was missing or would actually perceive as improving the game.
11-7-04The parable of the painter. There once was a painter; he wanted to do great masterworks of oil, but he struggled in that world, and took to painting houses. Still, he strove to be the greatest house painter that ever was. He saw the other house painters - using spray guns and cheap paint, and he thought their work denigrated the art of house painting. And so, he tried to prove himself on every job. He would go into the house, survey it, but the houses were never right - too old, the walls too small, the materials too cheap - what sort of canvas was that for his work? With many complaints, he would get to work. The painter would carefully remove all the furniture, strip the old paint, usually he would find some bad plaster and tear it out and replace it - perhaps the ridge of a stud was poking through, he'd try to smooth it out. Weeks into the job, the home owners would be nagging him, and he would say - if you want quality, this is the time you have to take. So, he would start on the undercoats. He would lay perfect, even white undercoats; usually there would be an imperfection or two, so he'd lay another coat. But by this time the homeowner was always at wits end - "we need our house back!" they'd cry, and tell him to finish in a day or get out. Panic! The painter would work fast, throwing the paint up on the wall any way he could - the special paint that was supposed to mix for three hours - no time for that. When he was done the paint was in goopy smears all over, an uneven ugly job, and he was despondent - "cursed homeowners" he'd think "didn't give me enough time for the job". Finally, despite his many mediocre jobs, the painter found a perfect client (for he had some esteem among the bourgeois, more for his attitude than his work) - "give my house the best paint job anyone has ever seen - and you can have six months to do it". Oh happy day for our painter! He surveyed the house and emptied it, and began to study the walls, taking color samples of the lawn, the roof, the furniture. He ordered special custom paints, and planned. Weeks went by and he planned and re-planned, and finally started to improve the walls - we need spackle here, all this drywall here has to be replaced, there's a leaky pipe here, the mortar in these brings isn't perfect - soon he was tearing up the house improving the walls, trying to make the perfect canvas for his work. Another month went by and the homeowner returned to see the house in shambles - "what are you doing?" he cried, and hired a crew to fix the walls. He threatened to fire the painter, but the painter convinced him "just give me another chance, I'll wrap it up". The painter started on the base coats; he was working along, doing coat after coat, making the perfect even white; he was most of the way through, then he noticed the white at the end wasn't the same as the white at the beginning! He was taking so long, the base coat was discoloring in the air, so each day's work was slightly different. That would never do! He stripped it all off, and started over; this time he applied a first coat to the whole house, then a second coat, then a third, so it was all even. Another month past, and he began the color. He started painting, but after a few days of looking at the color, he realized it wasn't perfect for the house. So, he mixed a new one, ordered it, and had to wait for it to come. He started again with the new one, he was content, working along. Then, one day, he visited a friend and saw his work - he was painting with gold flake, and holographic colors, and everyone was talking about it. Damn! thought the painter - this is a new standard, my work can't compete, I have to be on this level. So he stripped his work again and ordered this new high-tech paint. He began painting with it, but it clumped and ran; he didn't know the technique, and his base coat was the wrong type! But then the homeowner arrived - the six months were up - "show me my amazing home!" he bellowed. The painter was aghast, he stalled the owner and ran to the home and tried to throw the paint on the walls again, but it just made splashes and blobs and a horrible mess, even worse than any of his previous jobs where he didn't have enough time to perfect them. The moral is - parables are stupid.
11-4-04Game difficulty has a form of relativity. If you are in a car looking at another car, and you both keep speeding up, you don't feel fast - you feel like you are still. In our game (Stranger) at the moment, we introduce a new set of harder enemies, and we give the player upgraded weapons at exactly the same time. The result is that the difficulty doesn't change at all, it feels just the same as before. Good games will typically introduce the harder enemies before they give you upgraded ammo. This gives you a chance to perceive that they are harder, to go "whoa, that guy is tough". Then you get more powerful yourself, and difficulty comes back to the sweet spot. RPG's all are built on this principle - you go into a new area, and it's really tough at first, then you start to level up, at some point it probably becomes pretty easy as you are now more powerful, then you go to the next area and the process happens again. The difficulty oscillated up and down across the sweet spot, which gives you the perception of movement, of getting more powerful.
A related note is that for difficulty to remain in the sweet spot (I've been assuming you know about the sweet spot - the spot where it's challenging, but not frustrating, where it takes a little while to beat, but not too long), for difficult to remain in the sweet spot as you play, it must ramp up over the course of the game. The reason is that the player is getting better at the game. If you don't give them harder challenges, they don't really have a chance to experience the fact that they're getting better. Some of the old jumping platforms were really good at this ramp. The later levels would have just felt impossible at first, but if you actually play through the whole game to them, they feel fine.
11-3-04I'm trying not to even think about the election. I want to pretend it didn't happen. My overall feeling is of disgust, not just for Bush and his cronies, but for the people who voted for him. I'm totally disappointed in America. How can you all be so blind? How can you let yourself be lied to and manipulated? This bastard has taken the deaths of Americans on 9/11 and twisted it and lied about it as a way to seize power and do all manner of unbelievable unreasonable things.
- ► 2014 (48)
- ► 2013 (87)
- ► 2012 (134)
- ► 2011 (237)
- ► 2010 (310)
- ► 2009 (362)
- ► 2008 (697)
- ► 2007 (394)
- ► 2006 (654)
- ► 2005 (696)
- 11-21-04 - 1
- 11-20-04 - 4
- 11-20-04 - 3
- 11-20-04 - 2
- 11-20-04 - 1
- 11-17-04 - 1
- 11-16-04 - 3
- 11-16-04 - 2
- 11-16-04 - 1
- 11-15-04 - 2
- 11-15-04 - 1
- 11-14-04 - 2
- 11-14-04 - 1
- 11-13-04 - 1
- 11-10-04 - 1
- 11-9-04 - 1
- 11-8-04 - 4
- 11-8-04 - 3
- 11-8-04 - 2
- 11-8-04 - 1
- 11-7-04 - 5
- 11-7-04 - 4
- 11-7-04 - 3
- 11-7-04 - 2
- 11-7-04 - 1
- 11-4-04 - 1
- 11-3-04 - 1
- ▼ November (27)
- ► 2003 (74)