Game Development Community

dev|Pro Game Development Curriculum

Plan for Ted Southard

by Ted Southard · 11/25/2004 (7:51 am) · 9 comments

Okay, so I can finally loot the bots in my game! It's a great feeling, though for some reason, they get back up when I start looting them and do a run animation(they probably want to hang on to their stuff). Other than that, it's rather nice.

Working with the database for transferring items was a lot easier than I thought it would be. I had this whole complicated function to copy the item from one spot in the inventory record to the other, and then clear out the former spot, and then it hit me: Why not just change the ID of the "owner" of that inventory record? So, viola, looting just changes that one bit, and it instantly shows up in your inventory the next time you scroll around. Finesse dictates that there be the obligatory refresh function for both inventory and loot being displayed, but everything else is in place, and I just need to get a right-click on world objects working to make it fit in with gameplay completely. Here's a shot of looting a bot in all it's glory(the box around the bot is from the Click n Pick resource while I think of a better selection cursor for the game):

www.DigitalFlux.com/miscstuff/looting.jpg
The rest of the GUI is coming along nicely, and I just finished the artwork for the skill GUI, to be followed by the rest of the functionality today through the end of the week. Basically, you can click on one of the named categories of skills, and then scroll through them on the right hand side. This makes it more manageable, seeing that there's 120+ skills in the game. The GUI also makes it possible to expand categories if that need arises:

www.DigitalFlux.com/miscstuff/skillgui.jpg
Now, I've been thinking about the AI lately, and the Artificial Emotion(AE) part in particular. I found a list of 500+ complex emotions on a website a few weeks back, and was only able to narrow it down to about 175. A second round of narrowing would probably bring it down to about 100 or maybe even less, but that being said, it's still too many.

I'm keeping the low-level bots in the game with rules-based AI, for the obvious reason that I don't want to swamp the server with trying to figure out if a rat is feeling wistful at that particular moment. But in the interests of being "light" on network bandwidth, I'm going to take a chainsaw to the AIPlayer class and start cutting out things I don't need. I'll have to do that with the Player class as well, since there's quite a bit that's not going to be getting used(no projectile collision testing, since damage is done via dice rolls, etc). In it's place should be very thin classes that are generic, affording very little services that the server-side scripts won't provide. Or functions that take a "type" variable to decide what kind of AI to apply to that function(ie, rats won't worry about improvising weapons or using healthpacks, whereas high level bots query emotional states and communicate with other bots to do flanking maneuvers and small unit tactics).

KISS rules in this area: Keep It Simple, Stupid. So now that I have my bot in, and he can fight(kinda), there's two things that need to be done: Divide the layers of AI so that I know which rulesets go to whom(as well as other features), and then set up the "action queue" for combat, where the player can click on different attacks and actions, and they enter a queue to be used when the combat timers allow. A monitoring function needs to be written for that in order to see if any "combinations" are successfully performed, and award points for it accordingly.

And lastly, time is rapidly approaching where I need to make a decision on whether or not to split up the Skill Point system. On one hand, it makes sense to keep things simple. On the other, that system is bland and allows people to increase some skills by performing irrelevent acts (like increasing your mechanic skills by killing wild beasts). So, if I go with the seperate Skill Point categories, I'll need to think of as few as possible.

The idea I was playing with was to have something like the skill categories, as well as a "General" category that allowed for a limited overlapping of Skill Points, so that players are not completely boxed in when they get Skill Points. It should be easy enough to follow, as the accumulated Skill Points will be displayed as the player switches categories in the Skill GUI, and thus knows what they can spend(and they can also spend it on the fly, since there are no "levels" in the game).

It's not as simple as other systems, but one of the goals of my game is to get players to role-play naturally, so the rules and gameplay have to accomodate that end organically. If it doesn't do so from the ground up, then the game won't stand a chance of being a true RPG... Much like the current crop of persistent worlds, which are more like MMOFPS' than MMORPG's...

About the author

Started with indie games over a decade ago, and now creates tools and tech for games. Currently working as a contractor for startups and game studios.


#1
11/25/2004 (9:07 am)
Ted, I love this. I emailed you with a proposal. Let me know.
#2
11/25/2004 (9:24 am)
Haven't received it yet, however, I don't have the resources to work on anyone else's game right now. A "technology trade" might be different if it's mutually beneficial...
#3
11/25/2004 (8:56 pm)
Hey Ted,
It's Buddy from IS Games......
Looks like you're making great progress....

I was reading the part about the skill points.... i was wondering... if they were kept in a database..... if you created a datablock and it contained X number of digits, you could easily combine points for a single action and split it among different skill sets...

Not quite sure how to explain what i was thinking.... I thought of it while i was setting some file attributes in FreeBSD.... where you use 3 digits, but are able to set permissions for ownership, read/write.... etc.....

This would let you easily setup both main and sub categories....

Say you did a task.... and it had a task Id of.... 1350.... this could in theory let me split points among 2-3-4 categories.... cat 1000, cat 300, cat 50 ..... thn the next set of number could be a % split or a hard number....

using this you could send a simple string of numbers and then apply them accordingly using a simple Left$(), Mid$(), Right$() type of decoding via sql query and dump it straight to the database.

Example:
Skill completed - Kill Object with bow/arrow.... completion would send string X 1300100250 .... which could then be decoded as ... (1300 ... 1000=Weapon Skill ... 300=Markmanship Skill) .... (100250... 100=Weapon Skill Points .... 250=Marksmanship Skill Points)
or whatever numbers you assigned to the skill sets...... as long as you had a set string length... then you could just pad with 0's when needed...

Then again I may just be talking complete nonsense :)
#4
11/26/2004 (1:06 am)
Phat Lewt (Just kidding). But seriously that's fantastic work.
#5
11/26/2004 (1:26 am)
Ted, getting rid of the player physics and shadows would give you a significant speed boost for lots of bots. Disabling collision or flagging out any type of detection would work well too..

Basically, raycast down for position, do a bit of stock animation on different states (state machine for animations) and youre set.

Personally, I'd start a new from gamebase for this if you are really trying to keep it "light".
#6
11/26/2004 (5:46 am)
@Phil: You're probably right about that, since it's a huge task to start taking things out than starting anew.

@Buddy: That's a great idea, and it would save space in the DB as well(I need to think more creatively along those lines, since the DB is going to be huge.
#7
11/26/2004 (6:57 pm)
Ted, you might also want to check out the RTSUnit code, it does basically what you're asking for in terms of stripping down Player. As Phil says, you could also derive from GameBase and re-implement the animation stuff you want. Not trying to just sell you on the RTS kit, it's just that both deriving from player and stripping stuff or deriving from GameBase and re-implementing stuff can be a pain. The RTSUnit already provides an out-of-the-box solution that's awfully close to what you're looking for. Still, even with RTSUnit, you'd have to re-enable some animation stuff, and decide exactly what you'd want to do with collision, but it should be less work than going straight from GameBase.

Anyway, interesting stuff. :)
#8
11/27/2004 (9:26 am)
That's an awesome idea, and worth the $50 just saving the time and effort alone. Hopefully it will play well with the much older(at least 1.2) TGE that I'm working with.
#9
11/29/2004 (6:09 pm)
Awsome stuff, I'll look be looking forward to this. I'm a huge fan of RPGs. I wish you luck.

-Jase