TUXDB - LINUX GAMING AGGREGATE
by NuSuey
NEWSFEED
▪️ GAMES
▪️ STEAM DECK ▪️ DEALS ▪️ CROWDFUNDING ▪️ COMMUNITY
tuxdb.com logo
Support tuxDB on Patreon
Currently supported by 9 awesome people!

🌟 Special thanks to our amazing supporters:


✨ $10 Tier: [Geeks Love Detail]
🌈 $5 Tier: [Arch Toasty][Benedikt][David Martínez Martí]

Steam ImageSteam ImageSteam ImageSteam ImageSteam ImageSteam Image
Cold Take #7 - Jumpjets and Jumplegs

Jumping is old, going back to the early days of Complete Annihilation, which predates Zero-K. It is also a very stable mechanic, to the point where a player from 15 years ago would not see the difference just from using it. In part this is due to its simplicity: just give a unit which can jump a jump order, and it will jump to the location once it is in range. But it is also because surprisingly little has changed. So why write an article about jumping? Well, while there have been a few changes, each one reveals a further refinement in the design of Zero-K. Even more revealing are the ways that jumping has deliberately stayed the same, in the face of potential changes. So here are four mini-articles on the how, what, where, and legs(?) of jumping.

Which units jump?


Perhaps the most important aspect of any ability is the types of units that can use it. Jump is one of the many abilities associated with a particular factory, in this case the Jumpbot factory, but in an unusual way. Other factories with a unique movement ability, such as the Hovercraft Platform or Spider Factory, have that ability on all of their units, whereas only about half the Jumpbots jump. This makes Jumpbots more like Cloakbots or Shieldbots, which each only have a few cloaked or shielded units. Furthermore, the Shieldbots' Dirtbag jumps, as well as the Recon Commander, and the largest unit in the game - the Detriment. This smattering of jumping is also similar to cloaking and shields. To see why Jumpbots ended up like this we have to go back to CA, since only commanders and Detriment have gained jumping since then. Jump was an ability exclusive to the Core faction, to mirror Arm's exclusive access to all-terrain spiders. Each faction had two tiers of bot factories, with a few all-terrain options in the higher tier factory. Placeholder and Firewalker, two non-jumping Jumpbots, did not exist at the time, and Moderator existed in the skirmisher role, but with a different weapon. Technically we could have let Moderator jump, its role stopped us.
Jumping is not just a way to move around the map, it is also a tactical ability that bestows a burst of speed. So a jumping skirmisher violates Quant's Rule, since skirmishers are meant to be weak to fast units that negate their range advantage. Jumping is as an excellent escape tool that negates this weakness, so Moderator was not given the ability to jump. Firewalker is non-jumping for the same reason, and also because dislodging artillery from awkward cliffs sounds very annoying. Spiderbots lack true artillery for the same reason. In addition to violating Quant's Rule, using jumping skirmishers also sounds tedious. Jumping with a short ranged unit is a game of risk, reward, and sudden retreats, while jumping with a skirmisher sounds like game of routinely retreating when enemies get too near. Such a thing feels like it could be automated, which also comes into conflict with the idea of fighting your opponent, not the UI. We considered creating a combined jump and spider factory while CA was being merged into one faction to create Zero-K. The goal was to create a fleshed-out all-terrain factory, and on paper it worked quite well. The only spiders at the time were Flea, Venom, Recluse and Crab, which fill the scout, riot and skirmisher roles, which leaves the raider, assault and anti-heavy roles to be filled by Pyro, Jack and Skuttle. However, this idea did not make it beyond prototyping, and instead we settled on the Jumpbot and Spiderbot factories we have today. I do not recall the exact process behind the decision, but here are some likely factors.
  • Jumping is a sudden bursts of speed, while spiders can constantly dance around cliffs. These are distinct styles so should be in different factories to let the distinctiveness flourish.
  • The combined factory would be too full, and too flexible, with all the units it could contain.
  • It would be tricky to find new homes for all the non-jumpers and non-spiders that we wanted to keep from the rest of the bot factories.
  • Having two factions that can play very hilly maps, or areas of maps, seems much better for diversity.
  • Jugglenaut and Crab would fight over the role of the factory's signature unit.
The solution was to add Hermit and Tarantula to flesh out the spiders, and make Widow all-terrain. Redback was added later to let Venom move more towards a raider role. As for the Jumpbots, they are essentially the old CA tier 2 Core bot factory, with a few new units added later. As for why there are no new jumping units, that goes back to the Zero-K approach to uniqueness. Many sci-fi strategy games use a weapon-chassis approach to unit design, where units can be boiled down to a combination of weapon and movement types. Sometimes there is even an in-game unit designer to make this breakdown explicit. Zero-K can be viewed through the lens of chassis and weapons, but there are so many holes in the matrix, and extra subtleties on top, that doing so is of limited use. Zero-K units aim to be more distinctive than combinations of weapon and chassis, and adding more jumping units for existing roles would work against that. Besides, jumping is primarilly a Jumpbot feature, and there are plenty of mechanics to build other factories around.

Jump physics


Jumping is surprisingly non-physical for a game with unit cannons and Lobsters. A jumping unit follows a set trajectory until it either dies or lands on a building, so unless that happens, it is guaranteed to end up safely on the ground. Its trajectory is calculated at the start of the jump, although the jump will be blocked if it would pass through terrain. This is all very deliberate, to the point where an impulse-based alternative was written by the developer xponen was not adopted. This new system used dynamically scripted physical forces to launch and guide units through the air, then slow them down at the other end to avoid taking fall damage. It was essentially a simplified and automated Kerbal Space Program. The impulse-based system was rejected for the unreliability inherent in its design. The goal of the system was to give units full physics while jumping, which meant that sufficient incoming fire could knock them off-course. Jumping multiple units was particularly risky since they would bump into each other mid-air, and even a slight course adjustment could lead to a unit bouncing away, down a cliff, and into a puddle. But how is this distinct from Lobster lob, which was added much later? Lobster picks up units and physically throws them in a direction, with the only nod to safety being temporary fall damage immunity.
The difference between Lobster and jumping lies in their centrality. Lobster is a somewhat niche midgame support unit, while many jumping units, particularly Pyro and Constable, are built from the very start of the game. As such, jumping has to be much more reliable. A Lobster causing part of an army to bounce down a cliff is recoverable, and to some extent it is the price of using Lobster. Armies are large enough by that point for things to average out. An early Pyro failing to jump up a cliff, or a constructor becoming stuck, would feel really bad and could be game deciding. The general principle here is that, if you want to build a faction around a mechanic, it had better be reliable. People have to be able to trust their units' basic abilities, since taking even a slim risk of complete failure into account is too taxing. On the other hand, tactics that appear later in the game can afford to have a bit more risk. There are more options later in the game, so using any particular one is more opt-in, and there are more ways to mitigate risk. As for the unused impulse-based jump code, there is a happy ending. Amphibious floating was originally implemented in the same way as jumping, with a set trajectory. This leaves a lot to be desired, and I could see xponen trying to get more physics into the game, so I suggested that the impulse jump tech be used for floating. This worked great since units bobbing around and bouncing off each other is a great feature for floating, and it cannot fail in the same ways as jumping. Floating is much better for it, and the impulse jump code still exists in the repository, so a modder could even pick it up for use in a game with a different set of goals.

What are jumplegs?


The lack of interaction between jumping and the rest of physics has a few weird effects. Units can jump from anywhere to anywhere, provided it is in 2D range, which includes flying through the sky after being launched from a unit cannon. Such units just follow their calculated trajectory, so turn sharply and float towards the ground. I remember launching Pyros across Victoria Crater almost as soon as Newton was implemented. However, there have been a few problems. Skuttle is a cloaking, jumping, bomb, which made it a particularly powerful unit to launch. Imagine the Sky Jacks of today, except they are cloaked and 1-shot their target. The best theoretical counter was positioning Hercules, or any other high-flying gunship, above anything important to decloak the Skuttle, and spamming Pickets. This was far too expensive, arduous, and silly, so we considered ways to nerf the tactic. Removing cloak was not an option since Skuttle needs to cloak while jumping for its mundane uses, so instead we removed its ability to jump mid-air. Thus the distinction between jumplegs and jumpjets was born.
A unit with jumplegs can jump, but not from mid-air. Skuttle was given jumplegs, along with some other units that looked like they use legs to jump. Notably, Pyro and Jack were given jumpjets, so retained their utility in unit launchers. This reflects the broader design philosophy of trying to retain as many of the creative combinations of mechanics as possible. It would have been easy to remove mid-air jumping entirely, but instead we surgically patched out the bits that would clearly break the game. Besides, jumping from anywhere has synergy with Placeholder, and saving units that are knocked off cliffs by enemy fire is cool. Splitting jets and legs also let us make jet break cloaking. This had to happen eventually, but was blocked by Skuttle needing to cloak, since the smoke and fire emitted by jumpjets ignore cloaking. Effects like these can be seen by players, but not their units, which gives players extra information. This leads to a form of fighting the UI where players want to tell their units to shoot at the mysterious smoke, but cannot. In these cases we either removed the effect while cloaking or make the effect decloak, to bring player knowledge in line with unit knowledge. The former is applied to damaged-unit smoke, which is suppressed for cloaked units for this very reason, but would look silly when applied to jets. The latter, decloaking the unit, was initially why units decloak when they take damage, since projectiles exploding mid-air is suspicious.
The existing jumpers were split into jets and legs on aesthetic ground. Basically, if a unit already had leg animations, then it was given leg mechanics. This was particularly good for units with a wind-up animation, since the animation caused them to actually stop mid-air to do their animation, which was too cartoony even for Zero-K. Detriment jump, which was added later, has a wind-up animation and a rocket jet, so mechanically it has jets and legs. It decloaks when it jumps and cannot jump mid-air. Recon Commanders was hit the hardest by the addition of jumpjet decloaking, since it can equip a personal cloak module. I recall this being a desirable change at the time though, as cloak made the commanders a bit too slippery. Jugglenaut and Detriment also decloak when they land, since their impacts create a visible explosion.

Where can units jump?


The question of where units should be able to jump is a tricky one, since both extremes lead to frustration. Highly restrictive jumping will cause units to annoyingly refuse orders that the "should" be able to carry out, unrestricted jumping results in players unintentionally ordering their units to become stuck on impassible terrain. The current system is as follows.
  • Units cannot jump onto terrain that is too steep, since they would become stuck.
  • Units can jump onto structures, however, the jump ends when they hit the structure.
  • Units can jump into water, provided the terrain under the water is not too steep.
  • Units cannot jump out of the water, except Detriment and commanders, since they are amphibious.
These rules work surprisingly well, and have been tweaked over the years. Originally units could jump out of water but not onto structures. Jumping onto structures used to be impossible. The issue with allowing it is that a jump trajectory would let units clip completely into structures, making them impervious to enemy fire. However, this had to be solved, since being unable to jump at structures felt like too much of an arbitrary limitation. Jacks were looking silly milling around the bases of terraformed turrets, and a Singularity Reactor in a hole should be more vulnerable to jumpers, not less. So we let jump target structures, but interrupt it as soon as the unit hits the structure. This lets Jacks jump up to get a few hits on a turret on a spire before bouncing back down, limiting its damage output by its jump recharge. Interrupting a jump when it hits a structure leaves units at the mercy of physics, so they could bounce off the structure and fall down a cliff, but I do not recall any complaints. Perhaps it is because such a jump is a deliberate decision, and one that rarely has to be taken early in the game. People naturally give jump orders on open terrain, when it is available. The bouncing is also much more restrained than full impulse-based jump, since the jump is always interrupted very close to the destination. It also used to be possible to jump out of the water, and there was even the idea of making jumping units fully amphibious. Jack could already be used amphibiously since melee weapons fire underwater. However, the idea of giving jump a small amount of underwater utility was dropped because it was too tedious. Babysitting units across the sea by chaining jump was a form of fighting the UI, which we resolved by removing the possibility. The idea of full amphibious movement was dropped because jump already bypasses cliffs, so if it bypassed large bodies of water, then there would be too few ways to make a hard barrier against it.
Units can jump into water because it seems like something they should be able to do, and there are more upsides than downsides. Sometimes it is worth saving a Jack or Jugglenaut by telling it to jump into the sea. Rescuing such units is just a matter of a little terraform, to give them a small platform of dry land to jump from. In theory these units can jump in any direction, so it stands to reason that they should jump into the sea if it is to their advantage to spend some time stuck underwater. Jumping into the water accidentally is bad, but water is visually distinct enough to make this very rare. There would be times when units would want to jump onto terrain that is too steep, where they would be stuck until they jump out again. However, terrain steepness is harder to make out than water, no matter how clearly it is shown, and there are far fewer advantages, since the main purpose of water is to block projectiles. Ability restrictions are about balancing the feel of units being able to freely use their abilities against the risks of each application. A niche use for an ability that has a high risk of being accidentally misused is not worth allowing.

Distilling some principles


Hopefully that was a useful insight into some aspects of jump design. Most of these articles involve dredging the principles out of my subconscious, which means at the outset I am not entirely sure how the concepts will be carved up. So I would like to take a moment to summarise a few of the new ones we saw.
  • Jank Escalation - Mechanics that are central to some core set of units need to be reliable, so players can trust them. More niche mechanics, or those that show up later in the game, can have more risk involved. So jumping is reliable while Lobster is not.
  • Disciplined Physics - Physics is great, but is should not be used at the expense of other considerations. Zero-K does not set out to apply the maximum level of physical simulation so usability often takes precedence, as mentioned in Physics vs. Formulas.
  • Surgical Excision - Interactions that would break the game should be removed without affecting related mechanics that have not yet been shown to be broken. Doing so would hinder the creative toolbox feel of the systems. So Pyro can still jump mid-air.
  • Practical Verisimilitude - Units should feel like they are free to use their abilities in ways that make sense within the game world as it is presented. But units with no restrictions can be told to do very stupid things, so applications with low utility and a high risk of misuse are restricted. So units can jump into the sea, but not onto steep terrain.
Of course, we also saw a few ways to use Quant's Rule and Not Fighting The UI, but they are going to show up everywhere and already have their own articles. Perhaps it is time to start a glossary. Index of Cold Takes


[ 2024-02-24 23:45:57 CET ] [ Original post ]

Zero-K
Zero-K Team Developer
Zero-K Team Publisher
2018-04-27 Release
Game News Posts: 63
🎹🖱️Keyboard + Mouse
Very Positive (3733 reviews)

Commander wanted! Construct giant robots, build an army of a thousand Fleas. Move mountains if needed. Bury the enemy at all cost!
  • Traditional real time strategy with physically simulated units and projectiles.
  • 100+ varied units with abilities including terrain manipulation, cloaking and jumpjets.
  • 70+ mission galaxy-spanning campaign to be enjoyed solo or co-op with friends.
  • Challenging, (non-cheating) skirmish AI and survival mode.
  • Multiplayer 1v1 - 16v16, FFA, coop. ladders, replays, spectators and tournaments.
  • PlanetWars - A multiplayer online campaign planned to start in May.
  • Really free, no paid advantages, no unfair multiplayer.

Fully Utilized Physics


Simulated unit and projectile physics is used to a level rarely found in a strategy game.
  • Use small nimble units to dodge slow moving projectiles.
  • Hide behind hills that block weapon fire, line of sight and radar.
  • Toss units across the map with gravity guns.
  • Transport a battleship to a hilltop - for greater views and gun range.

Manipulate the Terrain


The terrain itself is an ever-changing part of the battlefield.
  • Wreck the battlefield with craters that bog down enemy tanks.
  • Dig canals to bring your navy inland for a submarine-in-a-desert strike.
  • Build ramps, bridges, entire fortress if you wish.
  • Burn your portrait into continental crust using the planetary energy chisel.

Singleplayer Campaign and Challenging AI


Enjoy many hours of single player and coop fun with our campaign, wide selection of non-cheating AIs and a survival mode against an alien horde.
  • Explore the galaxy and discover technologies in our singleplayer campaign.
  • Face a challenging AI that is neither brain-dead nor a clairvoyant cheater.
  • Have some coop fun with friends, surviving waves of chicken-monsters.
  • Cloaking? Resurrection? Tough choices customizing your commander.

Casual and Competitive Multiplayer


Zero-K was built for multiplayer from the start, this is where you can end up being hooked for a decade.
  • Enjoying epic scale combat? Join our 16v16 team battles!
  • Looking for a common goal? Fight AIs or waves of chicken-monsters.
  • Prefer dancing on a razor's edge? Play 1v1 in ladder and tournaments.
  • Comebacks, betrayals, emotions always running high in FFA.
  • Want to fight for a bigger cause? Join PlanetWars, a competitive online campaign with web-game strategic elements, diplomacy and backstabbing (currently on hiatus pending an overhaul).

Power to the People


We are RTS players at heart, we work for nobody. We gave ourselves the tools we always wanted to have in a game.
  • Do what you want. No limits to camera, queue or level of control.
  • Paint a shape, any shape, and units will move to assume your formation.
  • Construction priorities let your builders work more efficiently.
  • Don't want to be tied down managing every unit movement? Order units to smartly kite, strafe or zig zag bullets.

Plenty of Stuff to Explore (and Explode)


Zero-K is a long term project and it shows, millions hours of proper multiplayer testing and dozens of people contributing ever expanding content.
  • Learn to use all of our 100+ units and play on hundreds of maps.
  • Invent the next mad team-tactics to shock enemies and make allies laugh.
  • Combine cloaking, teleports, shields, jumpjets, EMP, napalm, gravity guns, black hole launchers, mind control and self-replication.
  • Tiny flea swarm that clings to walls?
  • Jumping "cans" with steam-spike?
  • Buoys that hide under water to ambush ships?
  • Mechs that spew fire and enjoy being tossed from air transports?
  • Carrier with cute helicopters?
  • Jumping Jugglenaut with dual wielding gravity guns?
  • Meet them in Zero-K!

MINIMAL SETUP
  • OS: Ubuntu 13.04 or equivalent
  • Processor: 2.0 GHz dual core CPU with SSE (Intel Core 2 Duo or equivalent)Memory: 4 GB RAM
  • Memory: 4 GB RAM
  • Graphics: 512 MB graphics card with OpenGL 3 support (GeForce 8800 or equivalent)
  • Storage: 6 GB available spaceAdditional Notes: 64bit only. Big Picture mode is not supported
RECOMMENDED SETUP
  • OS: Ubuntu 17.10 or equivalent
  • Processor: 3.0 GHz quad core CPU (Intel Core i5 or equivalent)Memory: 8 GB RAM
  • Memory: 8 GB RAM
  • Graphics: 2048 MB graphics card with OpenGL 3 support (high GT 500 series or equivalent)Network: Broadband Internet connection
  • Storage: 8 GB available spaceAdditional Notes: 64bit only. Big Picture mode is not supported
GAMEBILLET

[ 6132 ]

1.69$ (15%)
11.82$ (41%)
16.00$ (60%)
15.00$ (50%)
13.99$ (30%)
16.96$ (15%)
11.53$ (54%)
8.39$ (16%)
2.50$ (75%)
16.00$ (60%)
5.34$ (82%)
11.24$ (25%)
11.04$ (15%)
18.39$ (8%)
12.42$ (17%)
3.79$ (81%)
12.99$ (35%)
8.69$ (13%)
0.90$ (91%)
6.22$ (79%)
17.59$ (12%)
7.44$ (50%)
16.79$ (16%)
3.35$ (16%)
8.86$ (70%)
8.79$ (20%)
13.79$ (8%)
3.00$ (70%)
25.19$ (16%)
8.00$ (60%)
GAMERSGATE

[ 2625 ]

5.31$ (79%)
5.52$ (82%)
21.59$ (46%)
3.0$ (80%)
9.66$ (68%)
9.0$ (70%)
15.0$ (70%)
1.28$ (74%)
4.35$ (56%)
17.99$ (28%)
0.75$ (81%)
5.7$ (81%)
1.88$ (62%)
0.45$ (85%)
20.99$ (40%)
3.0$ (85%)
9.9$ (67%)
5.0$ (75%)
7.5$ (75%)
5.1$ (66%)
7.88$ (77%)
5.5$ (75%)
1.9$ (81%)
2.0$ (80%)
7.5$ (75%)
5.22$ (74%)
8.99$ (55%)
3.0$ (62%)
1.67$ (83%)
2.0$ (90%)

FANATICAL BUNDLES

Time left:

8 days, 23 hours, 57 minutes


Time left:

14 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

11 days, 23 hours, 57 minutes


Time left:

36 days, 23 hours, 57 minutes


Time left:

16 days, 23 hours, 57 minutes


Time left:

8 days, 23 hours, 57 minutes


Time left:

43 days, 23 hours, 57 minutes


Time left:

32 days, 23 hours, 57 minutes


Time left:

29 days, 23 hours, 57 minutes


Time left:

37 days, 23 hours, 57 minutes


Time left:

39 days, 23 hours, 57 minutes


HUMBLE BUNDLES

Time left:

3 days, 17 hours, 57 minutes


Time left:

17 days, 17 hours, 57 minutes

by buying games/dlcs from affiliate links you are supporting tuxDB
🔴 LIVE