About this blog
Rolling fast and loose with C#, XNA, and AI
Entries in this blog
So I'm taking a quick break from MFAI, since it's Christmas break and all. I decided to vacation on some DirectX and good old fashioned C++. I have reached two conclusions, one being DirectX 9 is weird, and the other is that 3D game development is exponentially harder than 2D.
I'm pretty fluent in OpenGL, I did the went through the whole 'make a vertex/fragment shaded, LOD enabled terrain engine' phase. My experience with OpenGL was good, it's a very straightforward API, I'd even venture to call it elegant. Now I'm trying DirectX, and it's a bit tricker. First, I was all sorts of puzzled with their flexible vertex format and what not, but then I found out about multiple vertex streams and vertex declarations. Those happen to be closer to the way OpenGL deals with things, so that was nice. I'm still not used to all the vertex buffer locking though. Makes me wonder what DX10 is like, I've heard good things.
On another note, 2D game development is so much easier to deal with than 3D. That extra third dimension adds tons more to deal with. Frustum culling is building and checking against 6 planes, instead of just a square. The content problem is even bigger with 3D (textured models vs. 2D sprites). 3D model animation is many times more complicated than animating sprites (not to mention loading in the damn models). And that's not even the half of it - the list goes on. I had forgotten why I dealt primarily in two dimensions, and now I remember why. 3D game development is definitely more of a challenge, but I think I'm up for it.
My current project, MFAI, is a game of royal overthrow. You must interact with and manipulate townspeople into being your friend or enemy so that they do your biding. In this way you weasel your way into a position to overthrow/depose/kill the king. One of the ways in the game (and in real life!) to interact with and build relationships with people is through conversation. Naturally, today's topic is conversation and dialog for NPCs.
In general, talking to NPCs in games sucks. At its worst, NPCs say the exact same thing over and over; if you're lucky, it changes based on trigger events in the game's world. Other games have NPCs who cycle through phrases, and others allow you to navigate through a conversation tree, although it's always the same reply given my input. While these NPC conversation solutions usually work for the most part in the game they're in, they won't work in MFAI. MFAI involves a lot of AI interaction, and the player will quickly tire of hearing the same phrase repeated over and over (although, if any of you have played games with some exceptional NPC conversational features, let me know, I'd like to check them out).
I'm endowing my NPCs with a bit more dynamic and life-like conversational skills. My NPCs are going to talk to each other, have more choices in what they say and decide when they are going to say it. Consequently, the player will have these same choices when dealing the with NPCs.
I've set up a conversational graph. Each node represents a phrase and is linked to other nodes as appropriate. Each link has a weight, depending on whether the phrase is 'aggressive' or 'friendly'. To being a conversation, an NPC picks a starting node, something like "Hello" or "Yo!". The responding NPC would take this node and search its links to find nodes like "How are you?" or "What's up?". The first NPC then takes that node, searches the links, and chooses a phrase. Node selection is based on the link weighting and how the NPCs feel about each other. If the NPCs hate each other, they're more likely to pick nodes with 'aggressive' links. Every conversation is a traversal through the conversational tree, and every traversal can be different. This way NPCs talk to each other fairly naturally and will have different conversations depending on how they feel about each other.
So far, I've got the above system implemented. NPCs will talk, traverse the tree, and look like they're holding a conversation. The player can also engage in conversation, the node selection being handled by the player himself. The results look very ghetto due to minimal effort spent on the interface, so I don't have any screenies or videos to show yet.
The next step in the conversational system are context sensitive phrases. I'm planning for NPCs to be able to ask each other about their relationships ("How do you feel about me the Player/Paul/George?") or events ("Hear that Paul/George/the Player killed such and such").
Content has always been one of the biggest roadblocks to any game idea I've ever wanted to do. I spend more time on art than I do on the code, and the art still isn't all that great or complete. In my last game, we had to produce somewhere around 200 frames of animation, and it was no small task.
As some astute readers noticed, we indeed used clay for the art in our previous project. We choose clay over hand drawn animation because it's easier to manipulate a clay model than to redraw frames of animation by hand. And for side, front, and back animations, all we had to do was rotate the clay model, instead of draw a whole new set of frames.
Our process started by taking pictures of the model performing an animation (in this case running (we animated the players legs and arms separately)), each frame at 3 different angles, front, back, and side:
Then we cropped them into a rough grid:
Then we cleaned these images up (in Gimp, bleh!), alpha-ed out all the extra parts, arranged them in a uniform grid, and loaded them into the game. This wasn't a "bad" set up, but it was time consuming. Here's a quick video we made about midway through development, showcasing player animation, among other things: ">Watch Here
The problem we ran into was that for every new thing we wanted the player to be able to do, for every new enemy, for everything that moved, we had to whip out the clay and animate a crapload more frames. You'll notice the player doesn't have an attack animation, we just ran out of time. Adding an attack animation would have been another 48 frames of animation (8 frames for the front, back, and side, and doubled because the player could be standing still OR running while attacking).
Now considering my current project MFAI, we could easily run into this content issue again. My design calls for dozens of NPCs walking around, interacting, talking, punching, hugging, running, and so on. This amounts to a huge number of frames of animation. Multiply that by how many different looking NPCs I want - men, women, girls, boys, fat people, thin people - and we've got an art workload that is overwhelming.
What I've decided to implement is a sort of super basic skeletal animation system in 2D. I define a skeleton made up of 'nodes' (head, body, left hand, right hand, etc), then animations that can be applied to that skeleton's nodes. The animations themselves are just key points that outline a path for that node. To animate a run cycle, I would just define a path for the left foot and the right foot, a path that looked like a walk cycle.
In this way, I can write one skeleton and one set of animations that can be used by every NPC in the game. Additionally, I can play multiple animations on a skeleton at once. So I could composite animations easily and without any extra work (like that running and attack example).
The trade off here is in visual quality, but the pay off is in saved time. Instead of animating 10000 frames of animation, I can just set up a skeleton, a few sets of animation, and every different looking NPC in the game is fully animated.
I've whipped up an initial implementation of the system. The animations are crude, and the art is even cruder, but this should convey the idea: ">Watch Here
Next up is some walking, talking NPCs. I've got a few NPC conversation ideas I want to try out so that their conversations sound natural and they don't say the same things over and over again.
I've been working with C# and XNA for the past few months, primarily 2D. I've got a hot and sexy 2D engine, sweet collision management, xml based game data, it's slick and clean and runs on the Xbox 360 as well as windows. My roommate and I used it to complete what amounted to a complete game, proving the 2D engine is viable. Some screenshots:
One of the problem I tend to have with my games is that I spend a lot of time on snazzy tech, but don't have the time and energy to work in inspired, innovative gameplay. However, I don't have that excuse anymore, since the tech is "done". It's now time to start on a clever, fun, innovative game.
The concept of this new project is simple: You play as a citizen of a medieval town, to win you must dispose of the king. The fun comes in the many ways this can be accomplished. This medieval town won't be the kind you see in typical games. The NPCs won't walk around aimlessly, saying the same thing over and over, generally nothing more than talkative scenery. The citizens of our medieval town will have feelings, develop relationships with other NPCs, their actions driven by their desires. As a player, you must interact with these townspeople, making friends and enemies, working your way into a position where you can dispose of the king. Depending on how you live your life in the game, there can be many, many ways to win.
This journal will track the progress of this new project, which I'm from now on going to refer to as MFAI and serve to keep me on track as I progress along. Expect screen shots soon, maybe some chatty NPCs.