FreeOrion

Forums for the FreeOrion project
It is currently Sun Dec 17, 2017 3:51 pm

All times are UTC




Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: Combat
PostPosted: Fri Jan 17, 2014 5:22 pm 
Offline
Space Kraken
User avatar

Joined: Mon Jan 06, 2014 3:33 pm
Posts: 101
eleazar wrote:
It seems to be there's a lot of interest in adding new features to combat to make it less one-dimensional:


Seems like other understand what 1dim here means but me has a Question: does it means that it is actually implemented into sequential processed Code resp written as litereal Sequence of SRC Code, literal represented Result of Combat or does it address any spartial Dimension like ignoring x,y,z, and see instead Radius r only or does it relates to KISS?

MoO did offer interactive SpaceCombat (remind zooosh when enterered StarSys with any SCSM Sites on Planets inspiring to try first Retreat) while same Time Auto-Battle-Option reduced that Matter to a one-click-Issue due to Matter was that simple resp Automatism-Logic effective that Player-Interaction did not offer any ROI to Success but RISK to make an Error causing increased Loses. Fazit: as seenable MoO did obviously Battle in 2dim/planar Space simulating and would have there been any AutoAutoBattleOption and Battles' Result listed inside TurnOverMessages sequentially then Matter of Combat would have been that that Model is 2D, View 1D while Option to set ChkBox for Control would even be 0-Dimensional. So did MCV and Num of spartial Dims help to specify Matter of SpaceCombat in MoO as FO's spurious Ancestor.

So my brief Question is what N of Ndim of MCV Aspects get used for FO's SpaceCombat Implementation and what N's are aimed for? IF MoO did TB like resp more precise if SoaceCombat was like Chess with Turns each Side did multi-unit-moves per Turn but Sides sequentially, what means Players p1,p2 did SEQ p1:3 units move, p2:2 units move, p1: ... IF FO did adapt that same Way I would advice as Improvement to change that per Turn even multiple Players p1,p2,p3 can do simultan do Planning of Moves and Turn exec them as Instruction parallel while these can fail due to InterActions what means a Unit u1 moving to any spec Position does that finally just as DustCloud due to unexpected InterCeption from eg stealth/cloacked Units. That thought as more sophiticated SpaceCombat-GameStyle inclusvie Unit-AI resp SpaceCombat-Commander-AI doing that for AI-Player enable Game to make with MCV Spec like known from MoO - latter refered due to still dont know how FO solve that Matter. FZI: if that M of MCV gets advanced enough it could ROI to Players if supported by sophisticated CV joined inside G (GUI) make that interesting for Players to play here that MicroManagment Part manually - but Proposal does not exact that while for Debugging and Implementation-Issues would profite from. (why does that model suck for AI? let me view how it performs or try manual control of Options to see if me get it done better to identify Problem - but CVG just for Development Issues - disabled for Release .. if that's your Opinion about). So dont ask for VCG in Release-Isssues but ask for Model and propose Enhancements.



In Context of Model there is boring plain Game for KDE named ... KSpaceDuell,http://kde.org/applications/games/kspaceduel/ where to Duelists orbit around Planet and can accellerate to manipulate their Orbit and thus effect their relative Postions while have to omit ballistic Orbits ... even that is RT we could think of HighLevel-Commands to select Maneuvers which define Trajectories that aim for new Orbits.

Eg Init-Orbit is circular and User draw another circular Orbit and Code figure out Maneuver to cause Trajectory that would lead to that Orbit -- eg in maaaany Turns or SubTurns .... eg 3 or 300 what means while Unit maneuvers for new Trajectory into new stable Orbit (we dont want it do impact ballistically so we need any new Orbit and therefore may select new Orbit while can change final Orbit on InterimStates and no no we cant - have wait to get first in 10 Turns to previous selected Orbit before can try another).

You may wonder what that may ROI in MicroManaging for Player but that is a Point I OMIT to address here in first Order while I focus here like explained the Developers to do as TestPlayers substitute GameLogic to deal with Orbits automatized resp check out what Options Ship-AI/FleetCommander-AI has and how to use them, the Developers would know that Way faster than write Code like for parking Car in PArkingLot and wonder what the Problem is. Developers as DriveTrainers or AI have to have a SteerWheel in the Hand to check out interactively what the Problem is if it concerns not to AI but their own Idea how it should behave.

Best Way to get XP is playing that incredible cool.. http://kde.org/applications/games/kspaceduel/

before the Players getting TimeSpace (or is it same like SpaceTime?) to delay any Decision about if Players can later do it manually or ca not - I dont care here - but for sure Developers would have to do learn how to deal with that clearly different planar Model and gain XP how to deal with that new Space and its Constraints. You may play that KDE Game for first to get instantly XP with, while you may find that it is lesser intuitive to deal with via plain Control like switch on MainDrive for 60 Seconds and 50% Thrust after turned SpaceCraft into special Direction. Plain said: if you have to press Arrows to head the Ship and fire the RocketEngines for dv then Orbital Maneuvers are more challenging than defining new stable Orbits and select Trajectory for InterOrbit-Transit and you want either Orbit to stay there or Hyperbel to leave Planet but surely omit Parabolic Trajectories which mean to impact if not disintegrate by thermal OverLoad due to Friction in the Planets Atmosphere if Planet have one.

Stop thinking both that either that does not matter due to its just mean planar Map does just spin - better think it static and let Planet spin instead - or think opposite it does matter for sure but imply so many difficult Possibilities for Maneauvers you dont get mastered to deal totally completely with your Code - you dont have to! You need mainly to implement Orbit, even SubSet is sufficient like Circular Orbits, plain Maneuver like Spiral Trajectory what means SpaceCraft does ONLY accellerate tangential to concerning circular Orbit per Position and then you will already get planar SpaceBattleField with odd new Behavior that remove most of the Beams from the Water in MoO were implement.

Brief Points are:
a) it behave different!
b) it matters!
c) you can deal with! (see KSpaceCombat).
d) there exist simple Maneauvers to change between different Orbits (eliptical - covers circular)

When I assume you did implement it first Time working fro Celestrical Mechanic means with ballistic Orbit resp elliptical Orbit on MassCenter that collidate with Planet Surface, but Init and Interface allow just change between circular Orbits, plain Commands like: define CMDs like keep Orbit by Drift with fredom for Orientation of SpaceShip to aim at other Ships to shot Salve at them Way of ancient Asteroids or CMD move into other Orbit which require for Phases of firing Engines according Orientation and thus can onyl shot Opponent, if his stupid Trajectory let him pass your Cannons .. eat StarDust - CodeMonkey! Well, got exaggerated somewhat imaging first Encounter with new Model. It surely Way of we encountered unexpexted Issues we have to analyse better to understand better the Problem before we can engineer a better Solution - the Impact-on-UTurn-Phenomen is more complex than XP with Parking Lots hints - we are working on that Matter Day and Night and try next to fly U-Turn in Down-Loop-Style instead up Up-Load as did before. (My Advice is to break first hardly to increase that Way the SpaceGrip :D)

Well, we can do better, but I like a good Commnication Style :)

First plain Point with Idea of DogFight: Your SpaceCraft sc1 is next to Opponents sc2 and you want to get a good ShotPosition. What are you doing intuitively? You consider to decellerate sc1 to get slower than sc2 and thus get behind. First Surprise: you get indeed slower but that causes your Orbit to get smaller Radius and thus your Orbit is shorter and effectivey get before your Opponent - that looks bad! Reverse do you accellerate your Orbit get higher and thus you get after sc2.

Now consider that: you kick Brake heavily (I mean decellerate for short Period of Time aLot) which means that while being at Postion on HighOrbit Altitude HO the according Orbit is deeper, I call it MediumOrbit here. Consider Matter of ballistic Throw eg with Catapult: you put a Boulder onto, cut Rope and it does, AirFriction not respected here, mean that there is a tangential SpeedCompound dx/dt=dvx which is constant till impact moving the Boulder forwar and another dy/dt=dvy which behave like inverse to free Fall and let Boulder moving up - fall him up to Point where its dvy get Zero and it return there falling down. Now we observe Matter from MO and see up there sc1 start due to breaking fall down to MO and ariving MO with maximal Speed dvy pass MO downwards like shot it ith Catapult from MO downwards. We would see same Issue like before but to other Side: sc1 decellerate in dvy till that Point, assigned toLowOrbit LO, where it changed all dvy into dvx and return fall back upwards this Time towards MO and pass again MO with maximal dvy. Due to there is no Friction sc1 would like a sinodial Curve alternate between Orbits LO..HO with MO in the Middle. Due to dvy gets that Way always converted into +/- dxy what means that sc1 has higher dvx on LO than on MO and HO that effective Trajectory looks like sc1 fly Cycles around the center at MO between the upper and lower ReturnPoint while that Center orbit on MO.

That Behavior is rather surprising, I call that Kind of Trajectory Holo-Orbit, due to that Center does not have to containt any MassCenter of relevant Mass and therefore sc1 orbits around nothing but empty Space (empty as well as empty Space exist - there may be Millions of Electrons, Particles etc - in Respect of Volume and Mass quasi nothing, call it next just Vacuum).

I would for first just implement just circular Orbit but not as Circle x*x+y*y=r*r but Way of Iteration of small Trajectory Segments by calculating new VectorSet of Orbit per each Segment, and gen Circular Orbit as VectorSet that explains where Object is and what Direction with what Speed moves and that means to be the Orbit as next VectorSet from Iteration may look totally different but concerns to same Orbit. You could think that adds unneccessary Complexity to Code but it does not for real but the Opposite. Due to Iter-Step map physical Issue properly to Code while if you use Appraoch with Cycle-Equation resp and want to add next arbitrary Ellipses by other Class/Type and then again a Class HomannTransferOrbit HTO to pass between these Orbits you have to forge whole Day a Square into a different Cycle due to you did not take a Cycle like you needed and then quickly give up to add more real exisiting Complexitiy of Code while the Approach with VectorSet and Iteration can do that all with a single Class and just another Class of ManeuverControlCodes like fire Engines for 60 Seconds, orientate Ship into that Direction and fire Engines again and then got new circular Orbit - or ballistical - depends on previous States and DriveControl-Instructions here unspeced Parameters. Issue is: 20 special CutDevices as Classes and Types and Need for TypeCasts or do it via Trajectory and enable Wheel hard SteerBoard for other Meanings.

Yet last Example for another basic Maneuver: IIRC Homann-Maneuver
sc1 is distant from Planet #3 on its Orbit around Star and Navigator want to get quickly and economical to analog Orbit of Planet #2 eg from Earth to Venus. It does here neither matter here if central MassCenter is a Star or Planet nor if there are the aimed Orbit contains a Planet or just empty Space aside of close Distance to heavy MassObjects their Gravity Environment matters of course in Aspects of orbit there or impact there - but we assume that there are locally no Planets while the Orbit itself concernss to a Planet's own Orbit around CentralStar.

You can fly to opposited Position of Earth on Earth-Start-Orbit orbiting same Orbit what means between that Position on same Orbit like Earth and its Position a direct Line would mean that you can never see Earth due to the CentralStar is between. (well you could perhaps due to that Orbit is not circular adn thus the OrbitalSpeed vary depending from vary Distance to Star while Star is at one of two FocalPoints of elliptic Orbit, so the Line may not always not pass the CentralStart - see that as irrelevant Detail for Context - brief Point is on opposited Position is no Planet and thus no GravityCenter to respect.

Assume Example is with Planet as MassCenter with a Moon and we go just from LowOrbit to Moon-Orbit but at other Side of Planet then Moon-Side. If you worry how to factor in Moon that is simple resp already done as Model via the Vector-Thing for Trajectory and you have just to calc Effects from Planet an Moon on SpaceCraft independent and plain accumulate their Effects vectorial: (a,b)+(c,d)=(a+c,b+d) and for Matter of Control resp Maneuver consider the LagrangePoints, which represent special Properties as if you know to move there, you got Kind of stable quasi-static ParkingLot in PerSpective from Earth and Moon and can use same ManeuverType to enter Gravity-dominated Environment of the other Celestrial.

Alternative without PitStop at Lagrange is the Transit-8 used for Apollo Project, which pass same Lagrange but with higher Speed. You may find ManiFold of different T8Trajectories T8Ts but all pass on L1 why you can from there also use them all from L1 with no additional Costs for Fuel). While in LEO a SpaceCraft hast about dv=30km/s and have to get that from Launch, T8Ts are about dv=0.5km/s and thus means SC passes very slowly there and PitStop almost for free .. um rather cheap.

My Advce to do first is drop Idea that there is just Planet Earth and next giant Moon and between is a Lot Vacuum but take a Look on Gravity-Map with Lagrange- and Pascal-Points (L4,L5 .. well, was Pascal who calculated and discover them, I do not have to take Terminology other defined, my is at least good, L-Points and P-Points diff cleary in their Properties with diff ROI/Use and simplify Comm). When you see such a Map try to understand that SpaceCraft have to have a special Trajectory which does not cause SC to stay at Position but let it move without DriveAction from SC to fly thatLine you see there. Consider Kind of circular Orbit just rather bended to look like that. Consider neighbored Lines to require same DeltaV to change from one to the other Trajectory and see small dV means a Lot change there, inparticular for L1.

Aimed Result for that Advice is to get Kind of Idea that there exist special Positions you can use fine with Space InfraStructure like place a SpacePort resp Base there eg to patrol or defend from there any attacking Player. That means that with a heavy Moon that SpaceBattleField gets more interesting for Players to do his Defense manually. I would start with simpler Things while Iter of Trajectory by Time-Sections is just first Step all like ballistic impact, elliptic Orbit etc while Meanings to allow HighLEvel-Navigation inside is second Stage and it does not matter if final Result is below euphoric Expections like dont get this or that Matter dealed for Navigation and GUI what in worst Case would eg mean Field can just do elliptical, hyperbol and parabol Trajectories and change between them but that does still include a Lot of more Options than move Ships like Figures on a Chess Board.

Remind in that Scope that plain KDE Game noted above dealed that Matter even for RT what means SRC is GPL and not that difficult like it may seem as you do not have to Newton's Work to discover Law of Gravity but can find a Lot of Documents and Sources in the Internet. So it is mainly not about Challenge but Intention if you do not care if you need 6 or 24 Month to get it working. Me would like to have KSpaceCombat (or what its Name was) TB combined with MoO BattleField-Options aside of Drift while would like to see drawn Trajectories to see immediately what Trajectory Ship(s) have and what next Trajectory would be from next Maneuver-Instruction inclusvie POS for Turn.

You dont to calculate the according Ellipsis but the Trajectory instead what means you dont call drawEllipsis(geom) but drawDot(trajectory.nextPos(dt=+4)). So does Time t does btw concern to 7th Member of Orbit-Data while other 3 contains x,y,z (or x,y for planar) and dx,dy,dz (resp dx,dy) representing Speed and Direction while dx/dt=ddx aka Accelleration gets calculated for Gravity and Drives per Moment and via dt=period_of_time temporal Resolution calculate ddx*dt effective Change for dx and anaog dy,dz (new Speed) and via dx*dt effective new Position while do not expect to calculate it really preciseley but just any Kind of limit precisely bt precisely enough that SpaceCraft does not orbit in Shape of a TriAngle and as we are not deal with Matter that Game SpaceCraft has to fly that Course for real we do not have to care if it would for real not orbit 50km above Moon but imapct as it does not but orbit 50km high. Plain Point is we do not face same Need for Quality than professional Software in that Scope.

_________________
Pure Cyan harms PhotoReceptors doubtless - even half Portion appears mysterious.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group