Inactive Combat

[aherber]

Cervator edit: Moved to Incubator, added header

Name: Combat Framework
Summary: Technical combat system that'll be able to support actual combat content
Scope: Engine
Current Goal: Design / Implementing/Testing Prototypes
Phase: Implementation
Curator: aherber
Related:

Hello everyone,

as i have have mentioned in my initial post i already started some work on combat. Since this element may very well change during the development and is also subject of possible mods im planning to keep things simple for the initial version. This version will (hopefully) more or less lay the technical foundation for the combat system and therefore will not cover any gameplay specific aspects.

The current State of implementation:

CombatSystem:

PhysicsSystem:
- add a mechanism to handle the Collision Detection for fast moving Objects to prevent them from tunneling through objects. (implemented works great so far),

HitDetectionSystem:
- decouples the Collision Detection from the Physicssystem (implmented)
- Prevents douple Detection of Hits between the frames.(implemented)
- stores the Detected Hits in a seperate Context that can be used by other Systems. (implemented)
ProjectileSystem:
- Physics and non Physics based projetiles. (implemented)
- Fligthpath may use bullet trajectory(velocity based rotation). (implemented)
- Projectiles may use ammunition or not (implemented)
- Projectiles may or may not be effected by Gravity.(implemented)
- Projectiles can be bounced of based on the hitnormal.(implemeneted)
- Projectile can be reflected based on their current rotation.(implemeneted)
- Projectiles can now pierce blocks. (implmented AND buggy )

 

[Immortius]

Hello everyone,
as i have have mentioned in my initial post i already started some work on combat. Since this element may very well change during the development and is also subject of possible mods im planning to keep things simple for the initial version. This version will (hopefully) more or less lay the technical foundation for the combat system and therefore will not cover any gameplay specific aspects. So this version will be more about collision detection then flying limbs and explosions . I have seen that you are using JBullet for Collision Detection in the TeraBullet Project. Are you planning on sticking with that libary ? And how detailed you think the collision detection shall be for the combat ?

As per the Physics Arc, I'm still in the process of integrating it. As for sticking with it... probably at least for the short to medium term. Maybe replacing it with Bullet proper in the future, although that would mean a lot of work wrapping Bullet. This suggests avoiding exposing jBullet directly to too much of the game though.

The particular features I'm aiming towards that will help combat are:

• Collider and Rigid Body components for entities. This will give entities something that can be raytraced against (and collided with)
• Collider enter/exit events and contents iteration, probably touch events too. This will allow colliders to be used as detectors and triggers for events (possibly a basis for your tracking system?)

 

[Cervator]

Other good stuff to look at getting out of the way: Adding "regions" of some sort. Spout already has that and it makes sense. Currently all geographically bound entities are in the same place - I figure at least some of them should eventually be split by region (size? static or dynamic? relation to possible multi-node servers down the road?). Should help cut down further on creature navigation / AI I figure.

Simple example tools for melee and ranged would be great

My personal long-term wishes for combat (which may be unrealistic / too niche, not sure) centers around a non-HP health system (body parts and status effects, more like DF than MC) and more of a focus on preparing units then minimally commanding them in combat (again, more like DF than FPS-style aim and shoot, you're the only center-piece that matters)

Shorter term it would certainly be easier just focusing on the player as the sole combatant vs environment (or PvP) using plain ole HP.

Also: Tag, you're a contributor!

 

[Immortius]

On regions, we have a bit of it in terms of active regions around the player(s), with chunks being loaded and unloaded as the players (and thus regions) move. We have nothing for entities or physics yet. For physics, in theory there could be separate physics worlds for disjoint regions, but the joining and separating of those regions (and all the physics objects in them) needs to be managed - and needs to be a little loose so a player can't cause it to happen every frame by hopping a chunk edge.

My concern with regions as Spout has them is that they are static and adjacent. Basing physics worlds on Spout regions means you have to come up with some complex solution regarding behaviour on the edges, where objects can fall across multiple physics worlds. Or more fundamentally, the benefit of disjoint physics worlds only exists if they are disjoint, which isn't the case with fixed, adjacent regions.

It is all a bit of a moot point at the moment though, as we only have one player and thus only one active region. Work would be better spent hibernating entities outside of the active region - when an entity hibernates its collider or rigid body should be removed from JBullet, thus effectively limiting the active physics objects to the relevant ones.

 

[aherber]

Thanks for the feedback.

Cervator The Idea for the Combatsystem sounds great. Needs some Meta infomation for the collision volumes to detect what Area of the body has been hit. Don't know if you could use the bone hierachy of the model for this.

Immortius I guess its a good idea to start with only with the active region around the Player. This actually is exactly what i had in mind for this System.

I was also thinking of implemeting a simple radar to debug the system ingame. This may also be useful for debugging other things when it comes to the interaction between the player and the entities if it makes sense. What do you think about that ?

 

[Cervator]

A radar? You mean like a mini-map of sorts? That sounds cool and useful

I don't know what the best way would be to implement regions, I just imagine we'll need them eventually

 

[Cervator]

Moved this to the Incubator to be an official worked feature - tagged you as curator, aherber !

Feel free to edit the header I added to your post with more detail / updates over time. Looking very much forward to seeing commits! I heartily encourage pushing to your personal repo on GitHub frequently so your code can be reviewed early and often, then just say when you'd like some integrated in (or make a pull request when ready) - and thanks again!

 

[Cervator]

Moved this to the Incubator to be an official worked feature - tagged you as curator, aherber !

Feel free to edit the header I added to your post with more detail / updates over time. Looking very much forward to seeing commits! I heartily encourage pushing to your personal repo on GitHub frequently so your code can be reviewed early and often, then just say when you'd like some integrated in (or make a pull request when ready) - and thanks again!

"Dumb" Rating, AlbireoX ? Et tu, Brute? *cry*

 

[AlbireoX]

"Dumb" Rating, AlbireoX ? Et tu, Brute? *cry*

Hehe, I was testing that out. I think we should get rid of those ratings; I don't like negativity.

 

[Cervator]

Hehe, I was testing that out. I think we should get rid of those ratings; I don't like negativity.

Agreed - I had considered axing them last night but... 3am

Incidentally - relevant to this thread's actual topic: https://github.com/MovingBlocks/Terasology/pull/280 - Immortius has some 3d wizardry in his branch that might also help targeting poor gooey with sword blows, but IIRC he doesn't have a sword yet. So, uh, don't bring a ray caster to a sword fight?

 

[aherber]

Cervator Yes, I think i have to start from scratch using the code from Immortius physics branch. I will make a fork and reimplement the Sword using the new physics-system. Just didnt had so much time till recently because of crunch time at work. Im sorry if this is mentioned somewhere else and this question may sound dump, but are there any regular (IRC) meetings for the discussion of the development besides the forum ?

 

[HeadClot]

Suggestion - Why not have a simplified Mount and blade combat system?

Attacks Example - Fists / Weapon / (?) Makeshift Weapon (?)

Left Swing = Move Mouse Left + Left Mouse Click
Right Swing = Move mouse Left + Left Mouse Click
Uppercut = Move Mouse Forward + Left Mouse Click
Jab or Thrust of a sword = Move mouse back + Left Mouse Click

Charged Attack = Hold Left Mouse button

Same as above just with the Right Mouse button.


I am really not sure how much programming effort would be needed to implement such combat system. But from my Limited experiences with java. It should just be input + call animation + Hit Detection = Attack

[Addendum]

Forgot to mention something here...

We could use this to our advantage game-play wise for "Smart and tough" enemies that take a group to take down.

Dragons, Minotaur, Cyclops, etc.

 

[Cervator]

Cervator Yes, I think i have to start from scratch using the code from Immortius physics branch. I will make a fork and reimplement the Sword using the new physics-system. Just didnt had so much time till recently because of crunch time at work. Im sorry if this is mentioned somewhere else and this question may sound dump, but are there any regular (IRC) meetings for the discussion of the development besides the forum ?

Sounds good! I might still try to pull your code to a temporary branch so we can make a demo combat branch

Meetings - I've suggested considering Saturday afternoons (EST) as a focus time for trying to make it on IRC, but we don't have any regular meetings. Discussions will pop up spontaneously quite frequently and we'll probably aim for monthly scheduled meetings on IRC for important topics.

HeadClot - "Mount and Blade" ? Interesting looking game, wish I had time to play that (and a hundred other things...), but I don't think a movement-based combat system would work well in a multi-player environment

GuildWars2 just manage to allow dodging - and they've spent how many millions on that?

I'd rather focus on a simulated system that moves from generic hit points to body part-based damage / status effects, like in DF - which likely won't even care about collisions beyond something getting hit and the rough height of the attack

 

[HeadClot]

Ok, sounds good

I am behind you guys 100% on this!

 

[Cervator]

Tested - looks good! And the physics stuff is ready to build on top of now

Want to update https://github.com/MovingBlocks/Terasology/pull/280 with new commits sometime or should we just close it and re-open when ready?

 

[aherber]

Cervator I think we should close it for now. Still working on the new Version.

 

[Cervator]

FYI aherber - another shipment of physics stuff from Immortius just went to MovingBlocks/develop including some stuff on targeting

 

[Immortius]

Basically now raytracing through BulletPhysics will pick up entities if they have a shape component and a rigid body component or trigger component. Also all the input events include the entity the player is currently targeting, whether block or otherwise - as long as that target is in the DEFAULT or WORLD collision group.

 

[aherber]

Immortius Hey im currently testing my Implemention for the Ranged Combat. I actually run into a Problem that may be familiar to you or anyone else who have been working with the Physics System. In Contrast to the Melee Combat where i am currently using Raytracing for the Collison Test i use Projectiles and the CollideEvent to check for collison between enties. This already works. The problem is that whenever i destroy an entity that had an collision the game crashes with the following stack trace:

Aug 11, 2012 435 PM org.terasology.game.Terasology main
Schwerwiegend: Uncaught Exception java.util.
NoSuchElementExceptiat java.util.AbstractList$Itr.next AbstractList.java64)
at org.terasology.physics.PhysicsSystem.update(PhysicsSystem.java:183)
at org.terasology.game.modes.StateSinglePlayer.update(StateSinglePlayer.java:223)
at org.terasology.game.TerasologyEngine.mainLoop(TerasologyEngine.java:424)
at org.terasology.game.TerasologyEngine.run(TerasologyEngine.java:134)
at org.terasology.game.Terasology.main(Terasology.java:44)
AL lib: ReleaseALC: 1 device not closed

From what i understand whenever an entity gets destroyed all its Component get removed too. Therefore i was assuming that those entities get removed from the Map(s)(Rigid Body, Triggers) within the Physics System Class. The
It seems to me that the Entity is still being iterated altough they no longer exists. The removeTrigger or removeRigid methods of the Physics Systen class do not get called before the error is raised. Therefore if think the itration and the removel and possible also the addition of new collision objects seems to be out of sync. What am i doing wrong ? Thanks in advance.

 

[Immortius]

Probably an issue with destroying physics objects in the middle of iterating physics objects, I'll have a look into it. The physics update loop should be intelligent enough to deal with this.

Are you using triggers or rigid bodies for the projectile?