Tales of the Rampant Coyote
Adventures in Indie Gaming!


(  RSS Feed! | Games! | Forums! )

Thursday, May 24, 2007
 
Frayed Knights Dev Diary: Mocking (Up) Conversations
Greetings, true believers... to another chapter in the saga of making an indie RPG for the PC, Frayed Knights. This week is about more quick & dirty development of prototype #1 - trying to get semi-functional stubs of all the game elements thrown together in this "evolutionary prototype" and begin iterating on it.

Movement Revisited
This week I continued work on the control system, and came to realize that what I posted last week is just not going to work. In particular, the problem arises when one is turning towards an interactive object or character... like the image to the right (which was also posted in the forums earlier this week). In this state, with the elf on the edge of the screen (though we could really afford to slim her collision volume down a bit), we have a very tough time turning left. If the elf was very tall, it would be impossible to turn left.

Back to the drawing board. Maybe...

What it comes down to is that either completely separate mouse buttons will have to be used for movement versus clicking on interactive elements, or interactive buttons will have to be added to the screen to control movement (outside of optional key controls). Or both. Or neither, and I scrap the whole system for a new one. One of the central design elements I'm trying to maintain is that the game must be completely playable using ONLY the mouse. Keyboard controls should be strictly optional. And I want to do it without cluttering up the UI too much.

We All Need... Someone... We Can Click On...
To create interactive objects in 3D space, there are a couple of different approaches you can take (that I'm familiar with, at least). The first is to project the mouse cursor into some 3D location in the scene, and then run a collision ray through the scene to the 3D cursor and see what it collides with. If it's with an interactive object, then you signal the client in some way to let it know that there's something "clickable" beneath the cursor. The advantage of this method is that it allows occluding objects to block access to interactive objects very naturally - a closed door will block you from clicking on the character behind it. The downside is that the projection of the mouse cursor into 3D space isn't very exact - as it only has 2D coordinates. So you can end up with some strangeness unless the cursor is ALWAYS centered due to perspective, where the player thinks he should be able to click on something, but the game thinks otherwise.

Another way to try this, if you don't have too many interactive objects within range, is to collect them in a list and to "unproject" them and their collision boundaries into 2D space, gathering their real screen-space positions. This has the advantage of more exact results (as exact as the collision volume boundaries get, at least) for clicking on the objects, but you lose collision information for intervening, non-interactive objects.

A hybrid approach would be to perform the second check, and then project the cursor out at the distance of the candidate object, and then perform the 3D collision check to make sure it still connects as a "sanity check".

There is probably a better technique than the above, but those are the ones I'm familiar with.

I'm currently using method #2, with plans to integrate the hybrid "sanity check" approach later on. What this gives us now is a good foundation for our evolutionary prototype. Hopefully I've designed it so the behavior can be easily expanded upon (or completely overhauled) later with few problems.

Oh! It's a Text-Based RPG!
One of my projects this week was to get the basic interface for conversations working. I'm doing some weird stuff with conversations that might not work.

What typical RPGs (think Bioware's RPGs, here) do with a "conversation tree" system is actually similar to how I'm handling interactions with objects... sort of a text-based sub-game. Anybody who has created a Neverwinter Nights module and used a conversation to simulate actions not normally allowed in the game (like swimming across a river, or climbing a rope) knows exactly how and why to treat things this way. While it isn't as immersive as actually seeing the actions play out graphically on the screen, it allows a lot more freedom in designing interesting situations.

Talk To Me...
For actual conversations, I'm doing something a little different. I'm not going to go into much detail right now, because I want to be able to talk about it when I'm actually implementing the nuts and bolts of it about a month or so from now.

From a pure interface perspective, it isn't too far removed from a traditional conversation tree system. You have several choices. The NPC responds to your choices with some canned statement (though it may be modified on-the-fly, which will really limit my ability to localize this game). You get new choices. This continues until you or the NPC end the conversation. The big difference is how the choices are made available, and how the NPC responds. The difference is that these are not statically related... NPC response A doesn't automatically lead to player choices B,C, and D. It all depends upon what events have occured in the game, the NPC's relationship with the Frayed Knights, and the collected social skills and feats of the party members.

So instead of delivering a static script, an NPC may be of value to speak with at any time in the game. Spending time and effort to befriend an NPC isn't going to be effort wasted beyond the one quest the NPC is assigned to - they will continue to be of value throughout the game.

At least, that's how it all plays out in my head. So when I click on the responses generically labeled "Response1" and "Response2" in the conversation menu, I'm actually envisioning this really cool, complex dialog. My imagination is so much easier to program than a computer game... Actually getting it to work involves many factors including inheritance and knowledge tables and heirarchies and risk / reward factors and stuff.

Soon...


(Vaguely) related posts where I pretend I know what I'm talking about
* RPG Conversation System Redesign
* Non-Combat RPG: A Fool's Errand?
* Frayed Knights Dev Diary: Getting Around In the World
* The RPG Commandments
* Prototyping Means Sucking Less Sooner


Read or Post Comments on the Forum

Labels: , ,



Did you enjoy this post? Feel free to share it: del.icio.us | Digg it | Furl | reddit | Yahoo MyWeb



Links to this post:

Create a Link



<< Home

Powered by Blogger