May I suggest considering a different era of warfare than the Sword and Shield era? How about a DF style game with musket and cannon type combat? Such a change would be far more able to get the most out of any sort of bullet physics simulation than arrows and axes. Or maybe include both eras, and have the ability to research up to the later style of combat.
Inactive Combat
- Thread starter aherber
- Start date
Hmm, Steampunk references an era that ends right before 1880, before WW1 and after the American War Between the States. During this era of war line/set piece battles were falling out of favor. Indeed, during the War Between the States, the first half was fought via colonial era type line battles (excepting for the greater range of a rifle-musket of that era VS. the smoothbore of the previous one), which then devolved into WW1 style trench warfare during the latter half of the war. If I were to design a tech tree, I probably would start right before the pike and musket era, back when mounted knights in armor could still be protected from primitive blunderbusses by their steel armor, and end it right at the end of the line battle era, with rifle-muskets, rifled muzzle-loading cannon, steam locomotives, and buoyant airships as the landmark apex technologies. All in all, during the game you would be researching from medieval punk, into steampunk. Of course, I will defer to the fine gentleman who is heading the framework design, but I just wanted to contribute some ideas/suggestions.
If you're that familiar with Steampunk and assorted historic eras you'd be welcome to flesh out those ideas further. We really haven't gone a whole lot beyond "Hey Steampunk seems cool and would fit well with mechanics and such!" - some ideas on the line-ups (and a potential nature/genetics gone wild parallel in Untrue Tao) possible and how they could fit in well with the theorized setting (how do you start as a player in the world and how do you craft/advance?) would be nice 
Probably best to do so in a separate thread, however, since this one is primarily about the architectural foundation (code) of the combat framework, not so much its in-game technology specifics (content). There are a couple lore threads in the Incubator you could add to if you like!
http://forum.movingblocks.net/threads/lore-recent-history-overview.580/
http://forum.movingblocks.net/threads/lore.574/
(In addition to the world theme thread I linked earlier)
Probably best to do so in a separate thread, however, since this one is primarily about the architectural foundation (code) of the combat framework, not so much its in-game technology specifics (content). There are a couple lore threads in the Incubator you could add to if you like!
http://forum.movingblocks.net/threads/lore-recent-history-overview.580/
http://forum.movingblocks.net/threads/lore.574/
(In addition to the world theme thread I linked earlier)
Ranged Combat Prototye:
- This is an expirement for the Ranged Combat. It can be best described as a First Peron Realtime Worms. Projectile Weapons , like the Bow, can be charged by holding the Button . On Release the Projectiles is fired. The bigger the charge is the more Force is added to the Projectile.
Whats good about it:
Introducing the Charging mechanism into Combat:
- Adds time as a dynamic Resource into the Combat.
- Makes it a lot more Skill based to hit something.
- This can be used for all sort of things. It can be used to determine the size , number ,damage, range ect. of Projectiles.
Whats problematic:
Walking the thin line between Fun and Frustration.
- Makes it a lot more Skill based to hit something.
- Maybe to hectic in certain Gameplay Situation. Melee Combat based Characters could jump around like crazy and make it nearly impossible or at least really hard to hit.
- Maybe only practical in round based games like worms and may only be fun in 2d based games.
This list will be continued.
I have implemented a working Prototype. Still needs some polish but its working. I will push the prototype as soon as possible to my repository so everyone who is interrested can have a look and try it out. If it turns out that its not worth to further go into that direction, i will scrap it and take the experience i earned from it into the next prototype.
Thanks for your feedback.
- This is an expirement for the Ranged Combat. It can be best described as a First Peron Realtime Worms. Projectile Weapons , like the Bow, can be charged by holding the Button . On Release the Projectiles is fired. The bigger the charge is the more Force is added to the Projectile.
Whats good about it:
Introducing the Charging mechanism into Combat:
- Adds time as a dynamic Resource into the Combat.
- Makes it a lot more Skill based to hit something.
- This can be used for all sort of things. It can be used to determine the size , number ,damage, range ect. of Projectiles.
Whats problematic:
Walking the thin line between Fun and Frustration.
- Makes it a lot more Skill based to hit something.
- Maybe to hectic in certain Gameplay Situation. Melee Combat based Characters could jump around like crazy and make it nearly impossible or at least really hard to hit.
- Maybe only practical in round based games like worms and may only be fun in 2d based games.
This list will be continued.
I have implemented a working Prototype. Still needs some polish but its working. I will push the prototype as soon as possible to my repository so everyone who is interrested can have a look and try it out. If it turns out that its not worth to further go into that direction, i will scrap it and take the experience i earned from it into the next prototype.
Thanks for your feedback.
Looking forward to it!
I figure if nothing else we can have the player be more of a commander or a sneaky type than the primary combatant. Up close in melee range you probably would resort to melee weaponry or even commands to creatures to help push back attackers. Less up close and personal combat would probably help lag as well.
I figure if nothing else we can have the player be more of a commander or a sneaky type than the primary combatant. Up close in melee range you probably would resort to melee weaponry or even commands to creatures to help push back attackers. Less up close and personal combat would probably help lag as well.
if area effects is included in projectiles( like explosions), then no Melee guy is going to jump away from it. area effects can be also used to ease hiting target that way you don't need to hit target, just hit near enough.
Of course adding too much area effect would overpower bows(and such) and make game unbalanced. And I like idea of extremely acurate shooting, which is sensitive.
Of course adding too much area effect would overpower bows(and such) and make game unbalanced. And I like idea of extremely acurate shooting, which is sensitive.
Finally a new Version of the Combat System is finished !!!.
You can find it in my current reposistory under https://github.com/aherber/Terasology. Its still buggy right now. I dont want to make a pull request before i haven't updated everything to the current state of development.
If you want to test it you have to do the following. Start a new Game with the mod Combat Gamplay and the Portal mod activated. Get the 3 Bow items from your chest in your Inventory. Place one or more Portal Blocks in your world. If you want to use your bow now the Model of the projectile is not rendered. This Problem only occurs after placing one or more portal blocks in your world. In order to fix this you have to leave and reload your world. Now everything works fine and the projectile are rendered correctly. I dont know whats the reason for this error.
Projectiles also collide with billborded Blocks like Grass and Flowers because they are using the same collsiongroup as normal blocks (world). I may solve this problem by getting rid of the riggid body component completyly and only consider the triggerComponent for the collsion handling of projectiles and check if the colliding block is penetrable or not.
The other posibilty would be to introduce a new collisionGroup for passable blocks like grass and flowers to distinguish them from solid blocks.
Anyway just shoot the gelcubes that are spawning from the portal blocks. The damage of the arrows kill them with one hit. Because there is currently no death animation for the gelcubes i added a tempory one. The Gelcube become a dynamic rigged collsinon object and is pushed around. This may look funny. This is just a temporary solution and works as a "tell" that the gelcubes have been hit and died.
Whats new:
A Bow with reflecting arrows, that are fired in a straigth line and not beeing influenced by gravity.
A Bow with piercing arrows that fly in a parabolic path and stick to any block that is hit.
A Bow with bouncing arrows that fly in a parabolic path and bounce of blocks.
Be careful you can hit yourself with your own arrows at the moment.
Well i hope you have fun with it. If you run into any problems just let me know.
You can find it in my current reposistory under https://github.com/aherber/Terasology. Its still buggy right now. I dont want to make a pull request before i haven't updated everything to the current state of development.
If you want to test it you have to do the following. Start a new Game with the mod Combat Gamplay and the Portal mod activated. Get the 3 Bow items from your chest in your Inventory. Place one or more Portal Blocks in your world. If you want to use your bow now the Model of the projectile is not rendered. This Problem only occurs after placing one or more portal blocks in your world. In order to fix this you have to leave and reload your world. Now everything works fine and the projectile are rendered correctly. I dont know whats the reason for this error.
Projectiles also collide with billborded Blocks like Grass and Flowers because they are using the same collsiongroup as normal blocks (world). I may solve this problem by getting rid of the riggid body component completyly and only consider the triggerComponent for the collsion handling of projectiles and check if the colliding block is penetrable or not.
The other posibilty would be to introduce a new collisionGroup for passable blocks like grass and flowers to distinguish them from solid blocks.
Anyway just shoot the gelcubes that are spawning from the portal blocks. The damage of the arrows kill them with one hit. Because there is currently no death animation for the gelcubes i added a tempory one. The Gelcube become a dynamic rigged collsinon object and is pushed around. This may look funny. This is just a temporary solution and works as a "tell" that the gelcubes have been hit and died.
Whats new:
A Bow with reflecting arrows, that are fired in a straigth line and not beeing influenced by gravity.
A Bow with piercing arrows that fly in a parabolic path and stick to any block that is hit.
A Bow with bouncing arrows that fly in a parabolic path and bounce of blocks.
Be careful you can hit yourself with your own arrows at the moment.
Well i hope you have fun with it. If you run into any problems just let me know.
Awesome!
The bows certainly do the job of knocking over gelcubes, clever "death animation" by the way, however the projectiles are not visible for me even after returning to the main menu and reloading the world
I can affect the miniion monkeyheads as well with the bows although I'm not really sure what happens. I can't get to the real neat factor of the bows though since I can't see the projectiles differ. Sad!
It is possibly some of the bugs would be fixed or at least easier to deal with if you did indeed do the upgrade to latest. Your branch is almost two months behind, so you're missing out on a ton of stuff, perhaps most interestingly the Oreons who come complete with full models and even real animations, including attack animations - maybe they could be encouraged to develop the ability to shoot arrows with their attack command, in the direction they happen to be facing
Some of the Oreon stuff is mentioned in later pages of the miniion thread and put together by Maternal
and overdhose
Edit: Forgot to mention that I didn't spot any logged errors related to projectiles and such, although the game did seem to hard-crash once. One alternative to pulling the latest from develop might be going straight to looking at getting combat up to speed by basing it on the multiplayer branch instead since that changes some stuff combat would need to adjust for anyway. Immortius might have an idea if that's premature or potentially useful.
The bows certainly do the job of knocking over gelcubes, clever "death animation" by the way, however the projectiles are not visible for me even after returning to the main menu and reloading the world
I can affect the miniion monkeyheads as well with the bows although I'm not really sure what happens. I can't get to the real neat factor of the bows though since I can't see the projectiles differ. Sad!
It is possibly some of the bugs would be fixed or at least easier to deal with if you did indeed do the upgrade to latest. Your branch is almost two months behind, so you're missing out on a ton of stuff, perhaps most interestingly the Oreons who come complete with full models and even real animations, including attack animations - maybe they could be encouraged to develop the ability to shoot arrows with their attack command, in the direction they happen to be facing
Some of the Oreon stuff is mentioned in later pages of the miniion thread and put together by Maternal
and overdhose
Edit: Forgot to mention that I didn't spot any logged errors related to projectiles and such, although the game did seem to hard-crash once. One alternative to pulling the latest from develop might be going straight to looking at getting combat up to speed by basing it on the multiplayer branch instead since that changes some stuff combat would need to adjust for anyway. Immortius might have an idea if that's premature or potentially useful.
I don't see any arrows/projectiles either, but the rest works fine
Anyways, I like the physics based deatch animation, that feels "right" in the world. Maybe we should prefer a physics based splatter effect or something rather than "static" death animations?
Anyways, I like the physics based deatch animation, that feels "right" in the world. Maybe we should prefer a physics based splatter effect or something rather than "static" death animations?
I'd be all over that
I additionally like the idea of segmented models where limbs and such can fall off with damage, although maybe more in a cartoony fashion than a gore'ish one
Hey everyone. Thanks for your feedback. I will fix the remaining problems and have a closer look at the rendering problem. Maybe i have to check my projectile model again or replace it with another one. I hope it only takes me till next weekend to get everything updated. I planned to do that last weekend but i got a cold and spent a lot of time in bed instead of coding. Hope you dont mind to much. I will try to get my code up to date as soon as possible. Cervator, @Skaldanar At the moment the physic based death animation is rather static. I do not consider the hit direction or the hitvelocity for example , but this is a simple thing to add. If you like to have a physic based death animation, i will have a closer into it.
Yep! I can see the "arrow" now and all three bows work great
Hilarious to fire ricochet arrows in a small cave
Bouncy arrows are fun for how they maintain direction after bouncing, so they'll wiggle away into the sky like fish
Nicely done!
Edit: Built in the Jenkins highlight branch + published as a preview to FB
Hilarious to fire ricochet arrows in a small cave
Bouncy arrows are fun for how they maintain direction after bouncing, so they'll wiggle away into the sky like fish
Nicely done!
Edit: Built in the Jenkins highlight branch + published as a preview to FB
Just a little update. I implemented the math to check from which direction the Entity has been hit. (above,below, right,left, front, behind ). Im using the hitposition , the position of the Entity and its current rotation.
Im working on some examples like critical hits if an Entity is hit in the back to show how this could be used in the game .
I can also determine how much to the left or rigth (or any other direction) an entity has been hit . This could be used to define "Hitareas". This is actually also the reason i decided to implement this. I really want to find out how far i can go with this before thinking about more complicated solutions to determine wheter the the shoulder the arm the hand or a finger has been hit. At the moment i hope that my current solution is sufficient for this but im optimistic. Its now after 3 am here and im really tired. I will now get some sleep. I post more information about this if im not feeling like a zombie. I just wanted everybody to know what im currently working on.
Im working on some examples like critical hits if an Entity is hit in the back
to show how this could be used in the game .I can also determine how much to the left or rigth (or any other direction) an entity has been hit . This could be used to define "Hitareas". This is actually also the reason i decided to implement this. I really want to find out how far i can go with this before thinking about more complicated solutions to determine wheter the the shoulder the arm the hand or a finger has been hit. At the moment i hope that my current solution is sufficient for this but im optimistic
. Its now after 3 am here and im really tired. I will now get some sleep. I post more information about this if im not feeling like a zombie. I just wanted everybody to know what im currently working on.
Woo, functional directional damage? That sounds awesome! Need this on GitHub in a mergeable state already
Keep up the good work and don't leave us hanging too long between updates, we worry that the ninjas have got to you
Keep up the good work and don't leave us hanging too long between updates, we worry that the ninjas have got to you
Immortius Cervator I had a closer look into the md5 Mesh format. I tried to get my head around how to dynamically create the Collsionvolume-Tree based on the vertices of each bone but i think a more elegant solution would be if the collsion volumes are defined in a seprate mesh (Im aware that thecurrent version of the md5Loader doesn't support multiple meshes ). In my opinion the best solution would be to use a seperate md5 file that defines the collision mesh for the models. This way the colision volume can be reused by several models. The creator of a modell can also decide how complex the collsion volume needs to be. The collsionvolumens can also be scaled if the bonesize differ between different models as long as the extents of the collisionvolumes are similar. I just wanted to know what you think about this idea. Thanks in advance.