need help with adding new propulsion component.

Discuss the future of Warzone 2100 with us.
themousemaster
Regular
Regular
Posts: 600
Joined: 10 Nov 2006, 16:54

Re: need help with adding new propulsion component.

Post by themousemaster » 07 Dec 2006, 14:45

Watermelon wrote: if you are referring to 'hit sides',it's already done for units(droids) 6 sides:FRONT REAR LEFT RIGHT TOP BOTTOM,now all bodies have equal amount of armor on all sides.

fps's such as Half-Life 1,2 are very newbie friendly,the learning curve is relatively short compare to the complex system of wz,that's why they became more popular to wz/other RTS's imo.


Actually, I beleive the reason games like HL are more popular than WZ is because of its genre, not its ease of play.

Your average video gamer is a teenager.

Teenagers like action.

Therefore, games with constant high-action attract greater numbers of the average player base.

...

Well, that, and in games like WZ you can't run up to, spraypaint, and then teabag a beaten opponent...


User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: need help with adding new propulsion component.

Post by kage » 07 Dec 2006, 23:33

Solitaire wrote: How the hell did I manage to start that?! :-[
every action requires a brutal and opposite reaction.
Solitaire wrote: Err... the point I was trying to make is that multi-turrets will cause problems as they will need quite a bit of rebalancing to make them effective yet balanced; this will probably break balance with older mods, and many (well, probably all!) of my gameplay ideas are closely interlinked so we might be getting ourselves into a rut if we allow multiturrets outside of a mod. All that can be done is to add the facility, unless we want to add ALL of the new features in, which will make the game a lot better and hopefully get around some major balance issues still in WZ while making the game a lot more interesting, but would almost certainly break compatibility with LOTS of stuff. Kind of a nasty dilemma that...
agreed. even now it needs deliberate balance, since it something along the lines of "multi-turreted vehicles cost 3x as much but only have 4/3 the health" -- if this is true, then the only 2 reasons that a multi-turreted vehicle could be more useful than 3 single turreted equivalent is if either you put a high-veterancy crew in the multiturreted vehicle (3x rate of fire), or if the battle was far too congested (too many tanks getting in the way of each other), though, if cyborgs were to have multiple weapons, this would not apply to them since they can't get "bunched up" (i think the designers deliberately made it this way to encourage use of cyborgs... to bad they're not useful enough in general, though).
Solitaire wrote: I do NOT want "WZ Simulatorz" outside of a separate mod because that kinda thing derailed a major HW2 mod - not least because it ended up becoming a freaking simulator! My ideas were all created by an urge to add a tiny bit more realism and a fair bit of fresh new interest to WZ, and I'm not the only person who wants multiturrets and I'm not the only one who knows that would open all sorts of cans of worms with balance. Thus the idea of grading weapons came into being, killing two birds with one stone (it would also finally kill stuff like the old Bug-Hover-Hellstorm/Plasma/Scourge/Archie rushing bs), and without using restrictions based on tech level. Also, adding big units to fall in line with the Dragon is an old idea too, and would either need multiturrets or really big guns or BOTH judging from what was said about the Dragon years ago to really make a difference. Yes, the Dragon was a missed opportunity, but at the time there was no way to expand on the concept. There is now. But its damn hard to say whether its all better off as a mod or as a Warzone Revolution. Either way it'd need code support.
i never played hw2, nor the mod in question, so i don't know what you're talking about, though, i do agree, any gameplay changes should be restricted to new mods, or redesigns of old mods. gameplay changes to the original campaign i am okay with as long as the following holds true:
  • any new features that affect gameplay must require a complete rebalance of the campaign: it's really best to complete a lot of features, then rebalance all at once.
  • all features that affect gameplay in a noticable way must be turned off by default - perhaps there could be some "engine-features.txt" data file in the mod detailing what the engine should and shouldn't deal with. an example of a mod that doesn't need to be turned off would be watermelon's directionally-signifigant armor feature if it defaults to a divisor of 1 for all sides (or the equivalent based on its implementation), in which case the feature is in effect at all times, but has no effect unless explicitly designed into the mod. an example of a mod that doesn't really affect gameplay is the new weapon ballistics system: i didn't even notice it was there until the beta campaign, at which time shooting at enemy tanks behind buildings hit the buildings first (then i subsequently forgot about it until it was recently mentioned to me).
  • most importantly in my mind is that, while the campaign is perhaps the best way to showcase the dev projects features, and that it should follow a similar upgrade path to the game, the campaign should always be available in original (i'm talking about the campaign as existed in 1.10, or whatever was released to us) and unmodified form (as far as the content, not the mod package format) if the user wants it -- even if i'm the only one who'll host it (which i'll happily do), it should be publically accessible, and the name for any "retooled" campaign should be something like "the resurrection campaign" or something that logically links to the dev project. beyond that, efforts should be taken to make sure that the engine is always capable of playing the original campaign in a "gameplay unfettered" way, though, of course, with shiny new graphics.
Solitaire wrote: Ultra-realistic tank sims do seem somewhat less popular than Half-Life 2 for some odd reason... ;D
i attribute that to players wondering why pressing 'w' makes them simultaneously move forward and turn right, until they read the manual and realize there are seperate controls for each tred. then they get pissed trying to hit an enemy tank at a km's distance while driving over building rubble (think of trying to scope in on an enemy with a rifle while doing "jumping jacks"). suffice it to say, if you could engage in "urban improvement" (don't like a stop sign? drive over it... is the enemy on the other side of a building? just drive through it), or if players actually found out why the tank corps refers to infantry as "crunchies", tank simulators would quickly regain popularity -- unfortunately they don't spend much time on graphics or those kinds of physics, and wouldn't think to make a game that would be rated "mature".
Watermelon wrote: fps's such as Half-Life 1,2 are very newbie friendly,the learning curve is relatively short compare to the complex system of wz,that's why they became more popular to wz/other RTS's imo.
agreed. it's somewhat sad that the gaming industry is now taking the stance of "how can we dumb down our games to make them more playable to the average gamer?"
themousemaster wrote: Actually, I beleive the reason games like HL are more popular than WZ is because of its genre, not its ease of play.

Your average video gamer is a teenager.

Teenagers like action.

Therefore, games with constant high-action attract greater numbers of the average player base.
i'm agreeing with everyone on this topic, i guess. yeah. since more teenagers are getting into fps games than any other, the industry is making more fps games than any other, to the point where talking to a random gamer can get really pathetic really fast:

me: "so, you said you play a lot of UT2004, right?"
gamer: "hell yeah!"
me: "do you play anything else?"
gamer: "well, sometimes i play counter strike 'n sh*t"
me: "ah... do you play any rts?"
gamer: "huh?"
me: "'real time strategy'..."
gamer: "oh, yeah, i play battlefield 2"

then you got the other side that plays mmorpg's and nothing else. i miss the old days when a game was either a good game or a bad game, and gamers played "games", not "fps games" or "rpg's" or "rts games" -- you'll find so much of the gamer "elite" has no familiarity even with the basic genre acronyms. it's pretty much just the indie gamer community that is still pulling around any honor in the "i'll make something fun to play" area -- almost all publishers have fallen into "fun? sh*t... i don't care! this stuff sells" policy.
themousemaster wrote: Well, that, and in games like WZ you can't run up to, spraypaint, and then teabag a beaten opponent...
you should be a sociologist, master: you've figured it out perfectly.
[/quote]
Watermelon wrote:
  • support for faster projectiles: projectiles in warzone are fairly slow in regards to reality, though artillery is more or less on track, as are some missiles.
doable via weapon.txt.
reason i mentioned it is because there was a bug, and quite possibly still is, where if you give a vehicle a speed greater than, i think 700, or a projectile a speed faster than (i can't remember the value), really wierd things start to happen - the game doesn't crash or anything like that, but the behavior isn't predictable after that point.
Watermelon wrote:
  • angle of attack signifigance: hitting a piece of armor at highly suplemental angle (125 degrees 180 degrees) will be ineffective against vehicles with heavy armor, regardless of type of weapon.
should be done via 'top armor' checks.
not quite sure what you mean by "top armor" -- to clarify better (whether or not it was needed), i mean to say, in a situation as shown in the image below, damage, if any, would be would negligable, as almost all projectiles are designed specifically to deliver damage to something struck head-on (or nearly so) by the tip - the armor would have scorch marks at best from the projectile if it managed to explode, but no signifigant damage (at best a very small dent).

Image
Watermelon wrote:
  • maps would have to be about 5x larger to be effective for this style of gameplay, and most weapon ranges would have to be modified (the current heavy-cannon range in warzone is about the effective range of a real-world m-16... enough said).
not sure how to do this
this is definitely the hardest thing to do, or at least one of them, but really modern tanks can fire further than the length of most of the larger warzone maps on a side -- tanks are often used as artillery, sometimes automated, where the computer systems on a tank will receive fire orders, and without any interaction from the operators inside (and often much to their confusion), 10 tanks within area of a given target might automatically all swivel their turrets and fire at that target, with time delays on each tank's firing so that all shells will reach the target at the exact same time. modern warfare just doesn't happen in such small areas, and warzone is a game that basis itself on "precollapse" (modern) technology.

for a more realistic scope, look at following:

new heavy cannon range = archangel arty range
new archangel arty range = ( archangel arty range ) / ( old heavy cannon range ) * (archangel arty range)

now you're getting something more online with real-world ranges, though, of course heavy cannon, being mostly a direct fire weapon would still be limited to firing within sight range (if somehow it could see across to the other side of the map, it could try to take shots at an enemy there - after 10 minutes trying to hit a moving enemy with a skilled crew, it might get lucky)
Watermelon wrote:
  • the hit/miss system would have to be replaced with a ballistic flight path/collision detection system - this would make it so you couldn't shoot "through" units as is presently possible in warzone, in addition to having numerous other benefits.
done not really ballistic with trajectory,but it does have collision now(no more flying through building/units)
okay, yeah. come to think of it at one point i did notice that. question is though: does it also collide with units that might be in the path of the projectile (like trying to hit a target in the middle of an enemy group, and striking those units on the perimeter instead)? also, does it collide with terrain?
Watermelon wrote: [*]since the weapons would be realistically deadly, ai would have to be adapted - low rank units would be stupid, and would stand still to take a shot, higher rank tank/vehicle crews be smarter, and would always stay mobile, trying to keep their strongest armor towards the enemy. tank battles would take about as long as they do now, if not longer, because, to avoid that "single shell of death", most tanks would be constantly manuevering: not only would the gunners have to hit a moving target at .5 - 1 km range from a moving vehicle, and would have to do so as their sights shake all over the place (since the tank would be moving over terrain generally more bumpy than pavement). so it's a lot of shooting with eventual lucky hits. having to lead enemy targets based on each vehicles speed, direction, and relative altitudes would be extremely difficult. vets get better at manuevering and aiming.
target prediction is sort of working,not sure about the AI.
i'm pretty sure that the ai doesn't do that kind of manuevering. beyond that, the current ai scripts should really take the position more of "strategic control" -- where to send groups of units and what to have them attack, never where to put individual units exactly, as that should really be dependent on the veterancy of a unit (units with more experience should be more "stupid" than ones with a lot of experience -- "green" units would get frustrated and opt to stop so they can line up a shot, even though this is often a pretty bad idea).

still haven't had time to look at the code - have been dealing with real life and, especially, this jury duty thing that's coming up. i'll have to get into the code though, and see exactly what you mean by "target prediction" -- ideally, you'd code from the standpoint of "i am the gunner, this is what i see" instead of "that's the tank that's shooting"... so "accuracy" is no longer really a stat, and before a weapon is fired, it's orientation is not determined from the standpoint of "that's where the shell will land" but instead it should be "this is where the gunner is aiming".
Watermelon wrote: need to add a field engineering truck/ammo truck to do rearming,limited ammo could probably be done via weapons.txt,maybe scavanger model/animation can be used as infantry/person workaround.
yeah. don't worry about infantry workarounds -- if they can be used effectively in the game, eventually you'll find that some nice models come forward. when facing vehicle weaponry, infantry do die just as fast as you see in the campaign, though if they're behind any sort of cover, that's not an issue -- if somehow we could make a way for infantry to be able to "peek out" from behind a rock - making them able to shoot without being any more likely to hit, it would really make up for their easy ability to die (when they're in the open, they're dead. if they're hiding and using cover, machinegun fire, their biggest threat, is very ineffective). this combined with some sub-ai that makes them move to use cover whenever possible, and difficulty for them to be seen without the aid of a sensor unit that has near line-of-sight on them (unless they are in the open, in which case they are easily seen). something else: vehicles should not target individual infantry if possible if they have rapid fire weaponry: that is, if there's a group of 10 infantry and you have a machinegun, you don't shoot at one until they die and then move onto the next: you create a sweeping arc of fire past them, counting on a single bullet as being enough to, at the very least, disorient the soldier it hits, then sweeping back to finish off the survivors of the first barrage. if we have infantry, i'd be interested in implementing this (i could look to 3d modelling software to see how they do automatic path creation and then create some kind of ai-aim-pathing algorithm that shoots in a sweeping pattern against a group of infantry in the same general direction -- if the engine has already truely switched over to collision detection and abandoned the hit/miss percentile system completely, this would work quite well, and would have a nice in-game effect).

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: need help with adding new propulsion component.

Post by DevUrandom » 08 Dec 2006, 00:05

I wanted to say something more, but after reading these long posts I forgot about it. :(
What I remember is:
Intention is to support the original 1.10 gamestyle via a mod. If someone wants that style of game, he can do a mod and I will include it... Eg. "The oldschool mod". :)

My idea to the "engine-features.txt": Make the mods be able to disable features they don't want via selecting a ruleset in an init-script. This way the oldschool mod could disable everything past the 1.10 ruleset. If no ruleset is selected, the default ruleset is implicitly selected, which includes most of the features.
(If someone knows SMAC: My idea is similar to the ruleset selection when starting a game.)

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: need help with adding new propulsion component.

Post by kage » 08 Dec 2006, 00:20

DevUrandom wrote: I wanted to say something more, but after reading these long posts I forgot about it. :(
What I remember is:
Intention is to support the original 1.10 gamestyle via a mod. If someone wants that style of game, he can do a mod and I will include it... Eg. "The oldschool mod". :)

My idea to the "engine-features.txt": Make the mods be able to disable features they don't want via selecting a ruleset in an init-script. This way the oldschool mod could disable everything past the 1.10 ruleset. If no ruleset is selected, the default ruleset is implicitly selected, which includes most of the features.
(If someone knows SMAC: My idea is similar to the ruleset selection when starting a game.)
okay, all i ask is that original campaign gameplay be preserved: it it needs to have each feature explicitly disabled instead of implicitly disabled, that's not much effort -- i was only citing the opposite approach because of all the other mini-mods and larger mods out there.

once features roll in, i'd be happy to repackage the "oldschool campaign" mod to have them disabled, while at the same time trying to get a good idea of what sort of stat changes any new gameplay changes (whatever they might be) would require so as to best encourage use of strategic and, moreover, tactical thought.

a thought i just had: something like "the pumpkin mod" might work well, or something else that is indicative of its original creators.

yes, and i've played alpha centauri way too much -- that is a good thought, especially when dealing with starting multiplayer games, though there is the issue that each gameplay-altering feature often would require stat changes, since the stats were originally tweaked specifically for the gameplay supported for the engine.

that said, we could either have "feature mods" that multiply or transforms stats arbitrarily when turned on or off, with different features meshing their transformations together mathematically -- that might or might not work - in either case, without stat changes to back up a feature, you really do run into a case where "flipping the switch" not only turns off the light, but also makes it harder to aim at the stuff you want to shoot (that's the cause and effect type chaining stuff that would happen here without good planning and forethought).

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: need help with adding new propulsion component.

Post by Watermelon » 08 Dec 2006, 08:15

some changes such as projectiles are irrevervible,because they changed the functions significantly.Other features that have 'data dependency' like multiple turret,armor 'sides' can be disabled easily by modifying body.txt.(setting weaponSlot to 1 and give equal amount of armor to all sides).

giving a tank the range of archangel will probably hurt the gameplay,5x - 10x range increase should be a blend of realistic and playable imo.

there is not many detailed objects on wz that can be used by infantry as 'shelter',maybe making them go prone is better approach.

i think wz does have unfinished component(turret,propulsion) damage system,i'll see if i can fix/finish it.
tasks postponed until the trunk is relatively stable again.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: need help with adding new propulsion component.

Post by DevUrandom » 08 Dec 2006, 10:55

Ray based collision system...

The current collision system might work badly if the projectiles get too fast or the PC is too slow.
It would simply warp through everything, check if it collides at it's current position and warp further, because it is not anymore near anything...

Somewhere I read about ray based collision, where you cast a ray from the current position to the next and check if the ray hits anything. If it does you know you have to impact somewhere between your current and your next position.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: need help with adding new propulsion component.

Post by kage » 08 Dec 2006, 17:01

Watermelon wrote: giving a tank the range of archangel will probably hurt the gameplay,5x - 10x range increase should be a blend of realistic and playable imo.
even though they have that range, they can still only shoot at stuff they can see, and tanks generally don't have large bay windows, so in the majority of cases, if we followed through, we'd limit the sight range of tanks and other heavy vehicles so they'd see less -- it'd change gameplay a little, but by making tanks less effective.

another example: if i gave you a rifle (no scope) with a high muzzle velocity and low-drag ammunition, sure, if you aimed up enough, you might be able to get that bullet to hit the ground somewhere 7 km away in a given direction, but it's pretty doubtful you'd be able to hit anything reliably beyond 400 m, and that's if you're good -- same thing with tanks.
Watermelon wrote: there is not many detailed objects on wz that can be used by infantry as 'shelter',maybe making them go prone is better approach.
good thought: going prone is extremely effective if the terrain is even slightly uneven. one thing is that you never want to take it for granted though - if someone is pointing a 50 caliber machinegun at you from 20 m away, you're screwed all the same, prone or not (at much greater distances, though, you're very hard to see if you're wearing camoflauge), and if you're hiding behind a pillar of rocks, there's nothing to stop someone from driving around from behind and catching you in the crossfire.
DevUrandom wrote: Ray based collision system...

The current collision system might work badly if the projectiles get too fast or the PC is too slow.
It would simply warp through everything, check if it collides at it's current position and warp further, because it is not anymore near anything...

Somewhere I read about ray based collision, where you cast a ray from the current position to the next and check if the ray hits anything. If it does you know you have to impact somewhere between your current and your next position.
that's a pretty good optimization: lots of games do a tick-by-tick "see if the projectile is actually in another object, which is lots of calculations per second, and indeed, the reasons why a lot of games let you shoot through walls with certain kinds of weapons. ray based (and other kinds of collision detection) make it impossible for the speed of a projectile to affect the accuracy of the detection, and if implemented properly, can allow you to figure out the collisions that might occur over the course of the next, say, 10 ticks really quickly, making it so you don't have to touch collision detection for that projectile until 10 ticks later. this kind of problem solving in programming is very much worth it, but requires a lot of fore-thought (you can't rush through programming it), and more than often can give you headaches trying to figure it all out.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: need help with adding new propulsion component.

Post by DevUrandom » 09 Dec 2006, 13:40

Ray based collisions: OGRE seems to be able to do such ray casts easily...

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: need help with adding new propulsion component.

Post by kage » 10 Dec 2006, 01:05

DevUrandom wrote: Ray based collisions: OGRE seems to be able to do such ray casts easily...
ray casting collision detection has been in use since the late 90s -- almost everything nowadays uses that in some combination with "is this even anywhere near anything else" checks, including all the apis which provide any kind of collision detection.

what you do is don't raycast one object's mesh against another (as raycasting would seem to indicate) -- you do raycast one bounding box against another, and it's not even really raycasting usually (that's just what it looks like you when try to describe it) -- often enough it's a "stretch each moving object's bounding box so that the leading edge of the bounding box exists wherever it would be at whatever future tick you want to check up until"  (you can do multiple ticks at once by making "future tick" > "current tick + 1" ), and see if the bounding boxes of any plausible types intersect your time-warped new bounding box (you wouldn't check against other projectiles, for example, unless you had some kind of anti-missile missiles, or something like that), and if something does intersect, you move each colliding object to be where they would be at that point in time, and do a more accurate poly-to-poly collision check.

if you want it, i can make a diagram of this stuff.

User avatar
lav_coyote25
Professional
Professional
Posts: 3434
Joined: 08 Aug 2006, 23:18

Re: need help with adding new propulsion component.

Post by lav_coyote25 » 10 Dec 2006, 05:31

holy smokes!!!!  documentation!!  wow :o
‎"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: need help with adding new propulsion component.

Post by DevUrandom » 10 Dec 2006, 12:58

I think in one of the older Game Programming Gems (<4, I don't have those) it is asl o described. (If someone wants to read it up.)

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: need help with adding new propulsion component.

Post by kage » 10 Dec 2006, 14:00

DevUrandom wrote: I think in one of the older Game Programming Gems (<4, I don't have those) it is asl o described. (If someone wants to read it up.)
i think game gems 2 specifically teaches that. they've probably left it out of newer copies since game gems is often more of a "tips in addition to what you're already learning" type book, and everyone teaches event queue'ing now

Post Reply