Stance-based combat

[George]

Hmm, final thought before I go to sleep. I'm going to plan to store all game content as XML, unless we find a need for more efficiency. That includes all weapon specs, stance specs, armor specs, characters, monsters, and text relating to all of the above. Actually, to really generalize the system, I may not store any text in with the game content, and instead store just a resource identifier of some kind. Then, the identifier could be translated by the telnet proxy into a string (using it's own XML files), by the 2d client into an image, and by the 3d client into a model or animation.

[George]

That would make implementation a lot easier for sure. I though of that a few time. I am not sure whey I didn't pick that instead, most likely it's because I am conditioned to think in turns of stats, skills, abilities, etc.

Separate skills vs attributes is the traditional way of doing things because the early pencil and paper RPGs didn't have skills; they were stapled on later and never really integrated. Also, pencil and paper (and other CRPGs) have character advancement systems that restrict the ability to increase attributes more than they restrict skills. If you're playing semi-realistically, its reasonable to say that a person's natural ability is bounded by racial limits, while you can alway train a skill higher. I prefer the simplicity of skills-only for my system, but attribute may match your vision for your system better.

Oh, yeah, have you thought about race? I'm just ignoring it for now (at most it will be an aesthetic thing in my system).

[Peijen]

Oh, yeah, have you thought about race? I'm just ignoring it for now (at most it will be an aesthetic thing in my system).

At one point I was thinking about using shapeshift skill, but for now it's just some kind of humaniod.

[Jonathan]

I still think strength should just be another skill, not attribute. Same with general accuracy (Dex), spell power (Int/Wis/Cha/whatever).

I am not against this idea, put out some example.

Guild Wars. Strength is an attribute. So is Swordsmanship.

Elementalist attributes:

• Air Magic
• Earth Magic
• Fire Magic
• Water Magic
• Energy Storage

Warrior attributes:

• Axe Mastery
• Hammer Mastery
• Strength
• Swordsmanship
• Tactics

Each attribute can have an effect just by itself. So each point of Strength gives you 1% armor penetration. Each point of Energy Storage gives you 3 additional energy. Also, most skills have a variable effect or duration. The effect or duration is determined by an attribute. Blinding Flash is a skill which blinds for 3-9 seconds and its linked attribute is Air Magic. The duration scales linearly in that range with increased Air Magic. Finally, certain skills do not have a linked attribute and thus do not have any variability. Flurry increases your attack rate for 5 seconds but decreases your damage, and nothing will change those numbers.

So, basically, GW skills are "feats" and GW attributes are either "skills" or "stats" in CMUd. (And most RPGs.)

[George]

Peijen, what do you know about Managed Extensions for C++? Visual Studio's help claims that if I use it with the CLR, the resulting code can be run on any CPU/OS that supports the runtime. I'll probably still try C#, but it would be nice to be able to fall back to C++ occasionally if I run into problems.

[Peijen]

Peijen, what do you know about Managed Extensions for C++? Visual Studio's help claims that if I use it with the CLR, the resulting code can be run on any CPU/OS that supports the runtime. I'll probably still try C#, but it would be nice to be able to fall back to C++ occasionally if I run into problems.

Not too much, supposely if you use pure C++ and compile it with VS.NET you can compile your code into a .net library, libraries made this way is marked as unsafe. Or you can use Managed C++ and only .net classes.

Personally I won't touch Managed C++. Look up C++/CLI. It's cleaner language (relative to Managed C++ that is), and a ECMA standard. Allows better mixing between standard C++ and C++/CLI.

[George]

The portion of the concept document dealing with the main game framework (mostly sequencing) is committed to the repository. It contains a lot of stuff I've been thinking about all along but never put in writing.

Tomorrow, I must sped less time writing about crafting (which I don't really care about) and more time writing about combat to try to get this done.

[Jonathan]

http://www.godwars2.com/combat.php

This is similar, though your idea is definitely different.

[George]

An interesting concept, but not one I'd enjoy playing. Way too much input required, and presumeably very quickly. I don't want to make ten keystrokes for one attack.

One of my goals for my system is to push as much of the real-time aspect of combat onto the game engine, freeing the player to make tactical decisions rather than micromanaging their character's every swing. My system has a lot of complexity under the hood--interactions between armor, stance, weapon, and character--but from the player's perspective, it's just a kind of loose rock, paper, scissors. Once you start combat, all you have to worry about is shifting stance to counter your opponent's stance changes. Spell casting and item use is still twitchy, but I'm starting to wonder if some kind of stance-like AI would make sense to micromanage your casting as well. Probably a good thing to push onto the client.

[George]

Ok, I got my first meaningful (i.e., not Hello World) test program compiled this morning. My program creates two characters who act as directed by AI objects, choose actions based on their activities, and use the timeline to schedule their actions. Unfortunately, they have no awareness of one another and no way to interact. But the scheduling and action generation infrastructure is almost complete, save for thread-safety and canceling in-progress actions.

I'm not using any of Peijen's interfaces or code yet. I have one completely new interface defined (ITimeline) and I have independent versions of ICommand and ICharacter that I need to merge into Game.Framework.

My goal for tomorrow is to implement enough of the world object and attack command/activity/action to allow the characters to perceive, attack, and kill one another. Sledgehammer-wielding kobolds is a still a way off since I don't think I'm even going to try to support inventory for quite a while.

[George]

Ok, new checkin. Still don't have perception working (there's debris of a hack I tried this morning scattered through the code). But basic attack works as long as the test driver issues the command manually and hard codes the target. The command is translated into an activity and actions correctly, and the attack is able to lookup the target when it occurs. Prototype damage and death code allows the attack to kill a character and the attacker will dequeue the attack when this happens.

Perception and cleanup tomorrow. A lot of infrastructure is pretty ugly and few casts are performed safely. Still aiming for creatures to detect one another's presence and start whomping each other.

[George]

Ok, perception didn't go well, so I gave up and went with a horrible set of hacks. Doesn't matter too much for now; I accomplished my goals for the first milestone. I entitle this version "Joe and Bob vs 200 Berzerk Kobolds". It's pretty much what it sounds like. Joe, Bob, and 200 Berzerk Kobolds are spawned. They recognize one anothers existance, and the berzerk kobolds randomly attack targets (including each other). Now since I haven't implemented inventory, Joe and Bob have no weapons or armor. But, hey, they can greet the kobolds, say "ow", and die. That's something.

On my last run, Bob died in 2.6 seconds but Joe lasted almost 25 seconds. I didn't let it run long enough to see who came out on top, but I was down to 5 kobolds after 30 seconds.

[Peijen]

Damn, now I am behind. I got star wars KOTOR yesterday... for research yeah... Probably won't be getting much done code wise this week hehe.

[George]

I spent WAY too much time this weekend coding.

I think the next step has to be unifying my interfaces with yours. There's a lot of the architecture that I just guessed at, and my guesses probably don't match the way you want to do it. So, I probably won't write any more code for a little while. Instead, I'll try to document what I expect from the interfaces and which parts I expect to have to implement myself.

[Peijen]

After reading through 5 mb of "Hello, Kobold X" I don't think the random number generator is working to well. The damage reads like

4
4
4
4
4
4
3
3
3
3
3
2
2
2
1
1
1
1
1

We might need to find a better random number generator, but I guess that doesn't matter at this point.

[George]

I was convinced it was broken when I ran with only a couple kobolds and it gave exactly the same results twice in a row. But since it changed on the third run, I had guessed it was just a fluke. I'm not sure I seeded the generator, but the documentation said it autoseeded itself with the time.

And yes, the console output from the 200 kobold case was a bit extreme. Most of it was there to prove stuff worked with fewer kobolds and I didn't take it out before expanding it. I certainly didn't actually read most of it. I just skipped through to try to find out when Joe died.

[Jason]

I just skipped through to try to find out when Joe died.

So should be the motd.

But that's really way too mean without context.

[quantus]

I just skipped through to try to find out when Joe died.

Code: Select all

Joe: It's the legendary Black Beast of aaauuugh!
*Joe is eaten by the Black Beast*

[Peijen]

I made a Game.Util library that uses Mesenner Twister implementation (I have no fucking idea what that is). There is a Random class that's marked static.

To generate a integer number call Game.Util.Random.Roll(sides, count). The library I used have few more functions we can add wrapper functions as needs arise.

I also created a IProvider interface for object creation. It will probably change around alot as I make changes to the code, but this should make CMUd more pluggable.