The Animal Farm

June 29th, 2008

Personal Agile Extension

Pushing back my personal agile development by a week, since I didn’t find myself doing any personal development. Bunch of little excuses, but it comes down to me not having wanted to spend my evenings doing programming in lieu of other things. So let’s pretend I didn’t write that last post and say it starts this Monday instead.

I’ve found myself getting all girly over the apartment I’m moving into this week. Shopping around for furniture, wondering about decorations, that sort of thing. I’m focusing on thrift stores mostly, which unfortunately have this nasty habit of closing before 6, leaving me pressed for time after I leave work. I wanted to go out and purchase a ton of stuff en masse - at the very least a bed, TV stand, couch, and computer desk - but it looks like I may be picking things up gradually. Still, I’m excited.

He called me Mr. Glass.

June 28th, 2008

Good Game Design 2

Contuing where my last post on the topic left off.

(7)Short-term goals - there’s a reason the level structure still exists today, and it’s not because removing it is technically infeasible. People like tangible short-term goals. Finishing a level is about as tangible and short-term as you can get. Killing the next boss, getting the next weapon, wrapping up this chase scene, getting out of this infested desert. Most games manage this naturally.

(8)Timers are weak motivators - very few games can pull off time limits. The original Mario had a time limit. Did you notice it? Probably only a couple of times, when it came in like a surprise jerk and killed your plumber. It didn’t belong. Elebits had a timer, and when you lost you wasted maybe fifteen minutes. To my mind, fifteen minutes is not an insignificant amount of time when repetition is involved. If you want to push a player along, find something to actually push them, don’t kill them based on some arbitrary clock.

(9)Saving is the player’s option, not yours - a player should have the option to stop the game at any time, period. There are games that differentiate between saving (marking a spot to return to when you die) and suspending (allowing the player to stop the game and return later at the same point), which is an acceptable alternative so long as save points are well distributed. To my mind, if a player has to repeat anything more than a five minute segment of gameplay for whatever reason - even the player’s own failure - there’s a problem. While we’re on this topic, autosave shouldn’t be an extra feature; its absence should be considered a flaw.

(10)Mazes suck - they just do. I don’t care what genre of game, what kind of environment, what mood, whatever. Levels should never contain more than a handful of branches that are easily distinguishable. The player should never, ever be forced to wander around in circles trying to remember which door leads where. I’m talking to you, Star Ocean.

(11)Depth is good - I was talking with a friend a good many years ago about why Devil May Cry 2 sucked, and one of the major reasons was that it lacked the depth of Devil May Cry 1. Less player customization, less stuff to purchase, fewer options in general. Dumbing down a game is never beneficial. If there’s a problem and you think the game is becoming too complex, keep the same level of control but expose it in different ways.

Again, there’s more, but I’ll defer that for another time.

Everyone will be pleased.

June 28th, 2008


Just watched Unbreakable with Samuel L and Bruce Willis, and I’m not sure how I feel.

It’s basically the opposite of the Hulk. It’s entirely origin story, there’s practically no action, and there’s much more emphasis on character development. This isn’t bad, of course, but I feel the distinction is rather well-timed.

It’s a slow movie but not poorly paced. It wouldn’t have been good if it were any longer, but I think its length was just right. The characters are mostly believable if not completely forgettable; Sam was top knotch, but otherwise nobody stands out.

It’s an M. Night movie from back when he still believed in a big twist, and he delivers here. Although it was easy to see the twist coming, it was still good. I think there’s more story there during and afterward, but we’ll probably never see it.

There’s really not a lot to say here and even less if I want to avoid spoiling the ending. This is probably a bad sign, but I would say the movie is at least worth one watch, perhaps two.

This is the point where we shake hands.

June 28th, 2008

So Sorry

Lately I’ve been either at work or hanging out with Morgan. The free time I had to write a post I instead spent playing Final Fantasy Tactics.

Brian’s downtime seems far more ambitious than mine, with personal agile and other game design-based posts. I just haven’t really gotten into programming for fun in a really long time, possibly a year or so now. It isn’t that I don’t want to program for fun, sometimes at work I’ll be doing something and randomly think of how I could use a similar portion of code for my own purposes. But the big problem is I can’t split up my time between gaming and making games, I just like em both to much to split focus. Playing games have been winning most rounds though.

My WoW time has been reduced to possibly an instance run on Sunday or Monday, IE only 3 hours of play a week. It is a little depressing really, since I still love the game a lot, but I can’t bring myself to sit in front of a meeting stone from 9:45 to 10:30 waiting for the rest of the raid to show up, an hour late. Seems like an awful waste of time. A select few people from my guild (me and 9 others) are forming a dedicated 10-man raid group to attempt to conquer some content that we have been road-blocked on since it came out, really. I am really excited about this for 3 reasons:

1) The 9 other people are never late to raids, they are the cream of the crop,
2) This raid instance is really fun to me, and
3) I really enjoy WoW and this’ll give me a new goal.

That last one is important, I believe that WoW is only fun for me when I have goals in mind. I have two categories of these goals, short and long term. The short term are usually getting some reputation done, or gaining a level or two. Those are more for an instance of playtime, and don’t span more than a few days. The long term ones are the annoying ones that involve mostly gear. When I started WoW-Vanilla, my goal was to get to 60 and collect the first end-game set. They then introduced a mostly solo and small-group series of really hard quests to upgrade the first end-game set, provided you had the set to upgrade. That was my goal, and it kept me occupied until November or December. The XPac came out in January the following year, it was perfect. This time, however my initial goals were met to early and the guild’s general purpose moved to more advanced things, things I wanted to do but never thought I would. It was fun, but it adds a lot more stress to gameplay when you rely on 24 other people to not only be on time, but also not be retarded.

Viva Pinata DS comes out early September, I am really excited.

I recently bought Guitar Hero: On Tour and FFTA2 for the DS. The former has had a half hour of playtime and the latter has had none at all. FFT for PSP is taking up most of my time. I’ll give reviews of those two eventually.

Ricky and I first listened to the You Look Nice Today podcast on our way to visit Morgan in Arlington. It is a really funny and clever podcast that is really about 3 guys coming out with ideas to make money to keep the podcast going. They have several tangents that they go on, but all are funny. I highly recommend listening to it if you need something for your morning commute.



June 27th, 2008

Good Game Design

Thinking about qualities that contribute to good games. What I’ll say won’t apply to every game, but I’m trying to be specific here, since I absolutely despise the “everything depends” mantra that is found in most design books.

(1)Constant rewards - practically every good game throws out a host of different rewards for progressing. A new weapon is the most obvious, as is common every couple of levels in an FPS or action-adventure game. RPG’s give new abilities every few levels and a host of different items for doing different things, especially MMO’s. Unlockables, of course - new courses or characters. Megaman gives a new toy every level. So does Zelda. Devil May Cry, Ninja Gaiden, Chrono Trigger, Quake, Half-Life, Smash. It’s hard to find a good game that doesn’t constantly give the player something new to play with.

(2)Uniform play experience - games that constantly try to deviate from their core strengths typically introduce irritation rather than enjoyable variation. Enjoy the Gummi Ship in Kingdom Hearts 1? Didn’t think so (was much better in Kingdom Hearts 2 though). How about playing characters other than Sonic in the 3D sonic games? It’s important to recognize when a break in the core mechanics hurts more than helps and cut those features. God of War 1 did this - the Icarus-style flying stuff simply wasn’t ready from prime-time, so they deferred it to God of War 2 for greater effect.

(3)Mini-games - I absolutely despise sandbox games, but games with a healthy number of completely optional side events very often stumble upon some gem. Final Fantasy 7 had a slew of fun minigames. Final Fantasy 8 had a fantastic card game. Legend of the Mystical Ninja was a shining example: it had tons of awesome mini-games that were practically better than the game itself.

(4)Avoid boring gimmicks - I’ll lay it on the line right now, Super Paper Mario for the Wii was a miserable gimmick. The introduction of the 2D->3D transformation added very, very little to the actual gameplay but inspired the constant flipping of the world to search for little trinkets, sucking down time and fun in the process. But then, it’s a Wii game, a system composed of practically 70% gimmicks. I can only think of a handful of games where the Wii-mote helps gameplay, and a ton more where it might help in theory but in practice it’s clunky. The Nintendo DS was a system built entirely on gimmick; it was only when developers started nigh-ignoring the top screen and limiting stylus control did the good games start coming out.

(5)Put the strongest material first - first impressions are everything. It’s just no good to put a boring tutorial level as the introduction to the game. As an anecdote, most of the RPG’s lately that have started out boring, I’ve had a hard time picking up after two hours of play.

(6)Dark is boring - next-gen seems to be defined by dark brown worlds. Unless there’s something genuinely imaginative about the world, the darker the world gets, the less interesting the details become. I refuse to play a WW2 game without bright blue skies. Team Fortress 2 is fantastic and also very bright and cartoony. By contrast, the cold tones of Hellgate: London quickly became tiresome.

That’s all for now. More to come later.

Train kept-a rollin’.

June 26th, 2008

Hulk Smash

Well, I thought the new Hulk movie was pretty good.

It was basically everything I expected. Minimal character development, cheesy comic book-esque dialog, and crazy action. I was pleasantly surprised to see them practically discard the ‘origin story’ that superhero movies are so fond of rehashing - so much so that fully 70% of Iron Man involved building a suit. They move straight into the action, and let’s face it, action is the only place a movie named The Hulk could ever possibly be competent.

There’s plenty of fan service here, even to the mostly uninitiated comic reader. From Stan Lee’s appearance to a restaurant named Stanley’s to crossovers from Iron Man. More interesting to me, though, was the content taken from the Ultimate Destruction game by Radical. It’s very possible that I’m not familiar with all (or any) of Hulk’s signature moves from the comic, and I don’t want to spoil anything, but there’s a bit in the final battle that definitely reminded me pleasantly of the game.

What the Hulk tries to do it does well, and what it wouldn’t do well it doesn’t even try. Edward Norton’s character gets maybe fifteen lines. Accomplished actor that he is, even he couldn’t make Bruce Banner more interesting than a giant green thing throwing a forklift. The love story is tacked on, but then, it’s a superhero movie. Luckily it doesn’t consume a great deal of screen time.

In the gamut of superhero movies, I would place this one fairly highly. It’s no Spiderman. I enjoyed it more than Iron Man, but I seem to be in the rare minority that thought Iron Man was rubbish. I enjoyed it more than Batman Begins too, but I’m also fairly opinionated regarding that camera shaking extravaganza. Easily better than Fantastic Four or Daredevil or Superman Returns. Really, I think the only way this movie could have been better is if it, well, were about a more interesting character.


June 26th, 2008

Signal/Slots versus Monolothic Message Handlers

Some time ago I made a post on GameDev talking about my old message passing scheme - a big monolithic Singleton that sat squarely in the middle of practically every subsystem and passed messages back and forth. I was trying to get away from Singletonitis and wondered if there was a better message passing scheme. Someone I had previously identified as a rather talented engineer quickly brought up signals/slots - delegates, essentially - as a more type-safe, more decoupling, easier-to-handle alternative.

I accepted it because, well, I’ve grown a remarkable distaste for Singletons, signals/slots have become first-class citizens in C# in the form of events, and this guy is way smarter than I. Lately, though, I’ve been reevaluating the choice in my head.

The problem, as I see it, is that it does exactly what I wanted it to - decentralizes the mssage passing scheme. Which was great in my head, but leaves certain pragmatic difficulties. For instance, there’s no easy way (that I know of) to keep a log of all events fired, unless of course you implement it yourself in every event firing routine. With a centralized scheme, you can practically get this for free. This is both a boon and a curse during debugging - the log is great in theory and can give useful insight into program flow, but it really doesn’t measure up to a stack trace when something goes terribly wrong, the stack trace being largely meaningless when there are a bunch of events flowing through a central system.

The real benefit to having the system centralized - and what I think is an extremely strong argument - is directly related to logging and when I say the name you might not notice a semantic difference: recording. Assuming you’re running your game at a fixed time step (something I am a strong supporter of), if you have a record of the events that get fired during game execution and during what ‘tick’ they get fired at, you can play that record back later for pretty easy gameplay recording. That right there is an invaluable tool for debugging along with implementing an instant-replay system or a quick demo mode (ala the intro to Quake before you actually started playing). I don’t know how nicely this plays with multicore/multiprocessor systems; I think it might be more complicated but still functional.

There’s another benefit that I’m still up in the air about. With signals/slots, you’re essentially confined to the happy world of type safety. Make a function of a certain type, bind it, no problem. But what about data-driven games? What if you want to provide support for firing events in a script that were hitherto unheard of and listening for them in another script? A centralized system can be designed to pretty easily facilitate this; it can still be done with signals/slots, but it’s a bit more awkward. But, again, at that point you’re leaving the happy world of type safety, which I think might be more important than trying to “design for everything.”

So in summary, I still haven’t made a firm decision. I’ll probably go with signals/slots because they’re the more “preferred” way to do this from what I can tell, but it’d be great to get some feedback.

Think about how stupid the average person is, and then remember that half of them are dumber than that.

June 20th, 2008

Personal Agile, Week 1

It’s time I invested effort in my personal projects. To that end, I’ve decide to adhere to an agile-ish (not strictly agile, but good enough for me) development cycle where I setup short sprint cycles with clear, tangible goals that are not especially forward-looking. My sprints will last a single week, and at the end of each cycle I’ll do a wrap-up and before each cycle I’ll do a sprint startup. Technically, my sprints will begin on Monday and end on Sunday, but I’m going to go ahead and write about the first sprint now.

The goals for this first sprint follow:
*Setup a component-based entity system with a few baseline components.
*Take a first pass at an entity modeling tool that exports entity schemas to XML.
*Write a rough Renderer class that will draw sprites to the screen.
*Create a Sprite component and test it via creating an entity that has it and adding the entity to the world to see if it draws.

All this is C# and XNA, which has some facilities that will help me (a decent form editor, built-in XML support, extremely simple windowing/rendering code). My focus is more on fast development/iteration than raw performance, and I’m not shooting for any 3D, though the flexibility to expand to that later would be nice. I’m going to try to keep my tools as user-friendly and intuitive as possible (no Blender here), but they won’t be completely productized - if non-intrusive bugs are present, they may stay that way for a while as I develop other areas.

This is my first week, so I honestly don’t know how realistic those goals are. I’m coming home fairly drained some nights, and I”m not sure how much more programming I’ll want to do, but if my experiences at EA are any indication I think I’ll still have some energy throughout the week for my personal projects.

As long as two people are left on the planet, at the end of the day, someone is going to want someone dead.

June 20th, 2008

Performance Tuning

Before graduating, Zach and I wrote one of the slowest, most horribly jerky graphics programs in the world for a class. It was a very basic scene with some animating MD3 models, terrain, some trees, and a ton of custom materials/shaders. We didn’t think aggressive optimization would be necessary given the small number of objects in our scene, but it turns out we were straight-up wrong. I’m not going to show this program off, because it was very poorly written, but I’ve been musing about ways to make it faster. Here are some thoughts:

Culling: We didn’t cull anything. Stupid, I know, but we thought that with the small number of objects in our scene that it wouldn’t make a huge impact. Of course, most of our slowdown came from rendering things which weren’t even on screen. The meshes all should’ve had bounding boxes (or spheres) checked against the view frustum. The terrain should’ve been broken into smaller chunks that could be individually culled (but not too small - there comes a point when the cost of culling can outweigh the cost of rendering).

LOD: We had a fairly large scene, and at any given time only a few things would be close enough to need full visual quality. We didn’t really have any tools to generate lower LOD meshes (we were using free resources off the internet and had no modeling experience), but we should have explored something. Terrain LOD maybe, but most terrain LOD techniques are too CPU-intensive and it becomes faster just to shove the high-quality data into the graphics card and render that or pregenerate lower LOD chunks and store those on the GPU. I did a healthy bit of reading on clipmaps, but they felt too unwieldy to me. Mesh LOD, however, could’ve really boosted our performance.

Hardware animation: I made a rough pass at hardware morphing (since MD3 uses vertex tweening, not skeletal animation), but it worked wonkily the way I had things initially setup so I ditched it. The animation definitely wasn’t a bottleneck, but still, it might have had a little impact. Meanwhile, a couple nights ago I was laying around and worked out how to do skeletal animation on the GPU. It’s a pretty commonly-known technique (there was a GDNet post on it today), but I hadn’t ever given it thought.

Nothing revolutionary in that list, but still things that I think could’ve made a huge difference. I won’t lie - there’s little to no chance I’ll go back and revise the program. My current personal ambitions are dedicated more toward general design than performance optimizations, and the projects I have tossing around in my head are all 2D. But still, stuff to think about.

The difference being that one’s a profession and the other is mental sickness.

June 18th, 2008

Two Screens in One

Nobody told me certain Dell widescreen monitors supported picture-in-picture (PIP) and could essentially act as a TV. That’s magnificent! I had a dev kit hooked up and showing in a small window at the bottom right of the screen while I developed on the main window. In related news, I’ve discovered my TV does not support PIP, which is rather unfortunate considering other nearly identical models from the same company do.

I’ve given Summon Night an honest two and a half hours, and I’m ready to talk about it. Are you ready to listen? I’ll start with the story thus far, because it’s simple to talk about - it’s rubbish. Simple, uninspired, bland. It brings nothing new to the table and doesn’t have the common decency to rob from games that do what it does better. Of course, I’m early in, so there’s still time to shine, but awaiting that is like hoping my carpet will do something impressive before I’m finished with it.

Gameplay wise it’s pretty standard hack-n-slash, essentially a cartoony Diablo. Skill trees, a small party, summoning beasts to help. It could definitely benefit from some multiplayer, but no luck. Touch controls are clunky; my commands are repeatedly ignored, and the gestures for special attacks can sometimes take a few tries before registering.

Aesthetically, meh. The art is pretty and vibrant, but not terribly compelling. The music has its catchy moments but is ultimately forgettable.

Overall, I kind of hoped for more. I’ll definitely be continuing the game until it loses my interests or better alternatives are released, and if things change I’ll update my stance, but so far I’m unimpressed.

While we’re talking about video games, has anyone checked out the upcoming release schedules? I might as well sell my Wii back, it’s not getting anything in the foreseeable future. Bunch of shovelware, which is a trend Nintendo set with the N64 so really I only have myself to blame. The DS only fares a little better. PS3 is a no-go, but the PSP may get a purchase come September when the Star Ocean remakes hit. The XBox is the only system really earning its keep - I see a lot coming all the way through November that I want to play. Most recent of which is Operation Darkness, which drops next week.