Real Time Worms
From Worms Knowledge Base
Real Time is a hotly debated subject in Worms, with many players being against the idea for a variety of reasons. This page serves to discuss some of those reasons.
- 1 Problems and solutions for Real Time Worms (RTW)
- 1.1 Real Time Worms would be chaotic
- 1.2 What if a player kept shooting you, and you couldn't get up to fire back?
- 1.3 How would health be managed? It would be too annoying if you had to wait for it to be deducted every time you got shot
- 1.4 Airstrikes would be too easy to use - it would just be "Click 'n' Kill"
- 1.5 Offline multiplayer would be impossible
- 1.6 How would you control a whole team of Worms at once?
- 1.7 It would be too easy to just hide and let the other players kill each other
- 1.8 AI players would not be able to cope with Real Time
- 1.9 Wormnet would be less sociable - in-game chatting would be occasional at best
- 1.10 What would happen if two weapons collided with each other?
- 2 Clones of the Real Time Worms Concept
Problems and solutions for Real Time Worms (RTW)
Real Time Worms would be chaotic
Sure enough, if you took a random scheme from Worms Armageddon and put it into a Real Time situation, it would be chaos. With unlimited bazookas, you could fire away continuously until there was nothing left to fire at.
But a RTW game can avoid this outcome with a good set of restrictions and limitations. A player is not going to unleash wave after wave of bazooka shells in random directions knowing he only has half a dozen left - that would be a waste of his firepower, and put him at a disadvantage. Instead, that player is going to spend more time planning his moves, and carefully aiming to make sure he gets the most out of his limited supply. Limit all the weapons in this way, and it becomes clear that RTW need not be as chaotic as one might think. Players will spend more time planning, moving, and aiming, and less time firing. Rather than a five-minute frag-fest, games could be as strategic as the turn-based equivalent. Combinations and use of weapons, rather than the shear number of them, would be of far more importance.
What's more, the degree of chaos likely to emerge in any one game can be directly controlled by the game host. Give the players very few weapons, and they will take their time to make sure every shot counts. Boost the ammunition numbers however, and the players will be less concerned about running out, and more prepared to use their weapons recklessly.
This solution has a potential flaw, though: limit every weapon, and there's a possibility of every player running out of weapons, and the game coming to a standstill. One solution is to have a plentiful supply of crates, the other solution is to have reinforcement weapons beamed straight to your team's stockpile at regular time intervals. Either of these could lead to inventory abuse by sealing off an area of the map, hiding, and stocking up on weapons indefinitely, but a simple restriction on the total number of weapons in a team's inventory at any one time would prevent getting hold of a Full Wormage stockpile.
What if a player kept shooting you, and you couldn't get up to fire back?
As above, a simple restriction would solve the problem. A small delay (or 'cooldown') of 4–5 seconds between weapon usage would prevent a player from releasing a quick succession of mortars or a stream of uzi rounds. this would give any stricken victim time to either escape, or pull out a gun and fire back. That worm would then himself have to escape, before the opponents delay expired allowing him to shoot again. This would add to the strategy, as there would no longer be the option of running into an enemy-infested area and letting all hell loose. Nor would there be the simple "face-off until somebody dies" situation, as each player might have chance to escape and save his worm's life.
This 'delay' could vary between weapons, to account for their potential abuse. A bazooka might have a delay of three seconds for example, while a pigeon would have a much greater delay. Then there are delays between switching weapons, which gets a little more complicated. You wouldn't want to wait several seconds to use a teleport after dropping a dynamite, for example. Non-hostile tools and utilities should have little or no delay, depending on what they are.
How would health be managed? It would be too annoying if you had to wait for it to be deducted every time you got shot
Health could be deducted instantly and players' control of worms never lost. The health display is another matter. It may get in the way if it hung above your worm's head all the time, and the 'floating' deduction notices that occur when you lose health would be too frequent in a real time game, especially if you were shot with a minigun and lost health in packets of 5. The floating deduction boxes could be ditched, and replaced with just one health display which reduces in value every time you are shot. That display could be made semi-transparent, so that it can be seen but also does not get in the way too much.
Alternatively, the health display could be stuck in the corner of the screen, but this would make playing the game tedious if you had look in the corner constantly to keep an eye on your worm's health. But this situation could be improved by a visual cue - namely the one already present which makes your worm appear sick under 30pts of health. This would enable you to make a very quick judgement of how susceptible your worm is to being killed.
Airstrikes would be too easy to use - it would just be "Click 'n' Kill"
As it is, they would be far too easy. Target a worm walking along an open bit of ground, and the enemy player would barely have enough time to react to the incoming missiles, let alone escape. Put a delay of a few seconds on the time it takes for the bomber to get there, though, and you not only give the enemy a chance, but a little more strategy is required to get the shot right.
Target the worm directly, and by the time the missiles arrive the worm will have moved out of the way. Use some clever thinking, and you can predict where the worm will be next and target there instead. Using this method, "Click 'n' Kill" is no longer an issue for airstrike usage.
Offline multiplayer would be impossible
That's to be expected - it would be impractical to have several people crowded around one keyboard, especially given the large number of keyboard commands assigned to Worms. But this would only put it in the same situation as many other real time multiplayer games. LAN would still be an option, anyway.
How would you control a whole team of Worms at once?
This is perhaps the most complex issue for Real Time Worms, and there are a number of possible solutions.
The first is to have just one Worm in the game at any one time. The Worm could have a number of 'lives', so when he dies he could respawn and fight again until all those lives expire. For a relatively more realistic approach, his death could be followed by the arrival of your second team member by parachute or teleport. When he dies, your third team member could be drafted in, and so on, until your entire team is killed.
Alternatively, your whole team could be made present on the battlefield. This would be a bit unmanageable with eight worms, but four would be suitable depending upon the situation of the game. You could only control one worm at once, but pressing Tab would instantly (without need of getting out a Select Worm utility) switch control to the next worm in your team. This may get difficult to handle if two urgent situations arise simultaneously, especially in the more chaotic games. But if you deem one worm to be safe for a few minutes, then you have time to switch to another and take control of another situation. Teleporting any 'spare worms' to a bunker and using one as a front-line fighter would probably be the safest strategy.
Thirdly, a mixture of the two ideas could prove most popular. Having two or three worms on the terrain at once should be fairly easy to manage. And should one die, it could be replaced with your next team member so you would always have two or three worms at once.
A fourth idea involves giving each worm a set time in which to be active, much like turn time. As soon as this time expires, you are automatically switched to the next worm in your team and given the same turn time in which to act. (A "weapons per turn" restriction could also be introduced with this idea, to replace the "weapon delay" idea mentioned above). This would prevent the "spare worms in a bunker" strategy which might be seen as an unsporting tactic, but it would probably also make the game frustarting to play, as you would not be able to switch to other worms in times of need.
Finally, having a 2v2 or 3v3 game and letting friends take control of the other team members would have a similar effect to the whole team being controlled simultaneously. It also brings in player co-operation, which would boost gameplay and strategy, as does any team game.
It would be too easy to just hide and let the other players kill each other
This tactic - darksiding, as it's known - happens in almost every real time game, and even happens in turn based Worms as it is. The only way to avoid such tactics is to ensure there are only two factions, i.e. one vs one or two vs two. Besides, if darksiding would be so advantageous, then all players would do it.
AI players would not be able to cope with Real Time
This is another difficult issue for Real Time Worms. More precisely, it is the constant terrain deformation which AI could not cope with. In Turn Based Worms, the AI player has a few seconds before its turn to scan the shape of the terrain and then calculate trajectories and movements. But as soon as the terrain changes, it needs to calculate it all again. On a constantly changing terrain, the AI would never have chance to fire.
But this doesn't quite rule out Single Player campaigns. Simply use indestructible maps for missions, and the AI need not re-consider the shape of the terrain (but would need to consider the locations of worms and objects). It would however severely limit Single Player campaigns to have terrain undeformable all the time.
Could AI be improved enough to cope better with a changing terrain? Perhaps the AI should just ignore the most recent changes to the terrain - it probably won't affect his shot.
If not, then the game would be restricted to online gameplay.
Wormnet would be less sociable - in-game chatting would be occasional at best
In most Real Time Games, chatting is restricted to one line, which gets sent to all players and then disappears shortly after. If Worms retained the Page Down chat box the game would probably be more sociable than other real time games, as chat messages would be stored and players wouldn't 'forget' what another player said, so a reply is more likely. But that's something which could be done in any game.
Worms has always been a sociable game, and it is the time to chat, created by a turn-based format, that makes it so. Real Time would certainly reduce this important part of Worms gameplay, unless it was a particularly slow-paced game. Chat-promoting features could also be introduced, such as an ability for a player to request "Cease Fire", which other players may or may not comply with. It would be a useful feature if a player needs to leave his computer, but would also make time for chatting, plotting, or harassing.
What would happen if two weapons collided with each other?
As it stands, weapons pass through each other. This can be tested in WWP using the multiple weapon usage mode. Such collisions in Real Time would be rare, but would add an interesting strategic element of blocking your opponent's shots with your own. However, programming a whole bunch of complex physics just to make it a little bit more realistic is probably not worth the hassle, so if anything they would have to be simple.
Clones of the Real Time Worms Concept
Liero gives us a good taste of what Real Time Worms might be like, although many use it as an example of why RTW shouldn't be made. After a few hours of playing it, it's not hard to see why.
The weapon system is confusing at first, although this might have more to do with being used to the Worms weapon system. On it's own, Liero's weapon system is a unique and cunning approach to the problem of selecting weapons, although it does severely restrict the number of weapons you can have in the game.
Chaos is Liero's downfall. For a start, the weapon ammunition is infinite, so there's just no point in not firing a weapon: you've got nothing to lose. As a result the game arena is chock-a-block with weapon fire, and not just weapon fire that quickly dies away. Some of the weapons linger about for several seconds, bouncing off walls and dropping what seems to be hundreds of pixel-sized bombs. They do little or no damage, which is just as well because they're almost unavoidable. All they seem to do is clutter the screen up. Most of the weapons are clusters, covering huge areas and being completely random. So you don't even really have to aim: just get the general direction right and you're almost guaranteed a hit. Again this is just as well, because the worms move too fast for any pinpoint accuracy weapons to be of any use (often the reason why worms are moving about so fast is not because they are walking or jumping but because they are being knocked about by an endless firework display of ammunition!).
The only restriction which works against chaos is the delay on using the weapons. After using so much ammo on a particular weapon, you have to wait for it to charge back up. But this time is far too short - if it were longer there would be more hesitancy in using a weapon, and more aiming to get it right. This wouldn't completely solve the problem - ammo limits and fewer clusters should be priority - but it would be a promising step forward.
Although the Liero Community Website shows evidence of a map editor, the default maps leave much to the imagination. The terrain starts off completely filled in, bar a few holes where your worms are spawned. After a few minutes of weapon fire however, half the terrain is gone and a giant cavern has formed; usually at the bottom of the map if gravity has its way. A lack of water is disappointing, but not surprising when you realise how little time it takes for the battle to excavate a giant trench all the way to the very bottom of the map.
Hopefully, things will improve with Liero 2 (see community website). The project was abandoned by Liero's creators but many fan groups have taken up the task. No mention yet as to whether the chaotic behaviour of the game will be addressed though.
Soldat is not really comparible to Real Time Worms, but comparisons are often made. Soldat is a graphically superior 2D real time shoot 'em up. The only thing it has in common with Worms is that it is 2D, has a variety of weapons (mostly guns) and the occasional crate. Other than that it is completely different - no deformable terrain, no transport utilities, and not much in the way of explosives. While fun and well-made, the game hardly offers much for the idea of Real Time Worms.
Taking most of its ideas from Liero rather than Worms, this game could easily have been better. The game is very buggy, and controls are not just difficult to get to grips with but difficult to use full stop. It's as if the keyboard commands change over time. Sometimes you wonder whether you really are in control of your worms - random movements and random shots seem to be commonplace. The worm sprites, which appear to have been drawn in a 3D program and then converted to a static picture, don't fit into the rest of the graphics at all. The game may be detailed but the graphics don't match.
But for game that was made entirely by two teenagers, it's an impressive effort.
- needs commentary - feel free to play the game and review it here
Project X Realtime (discontinued)
Project X, which is being developed by Entuser, once had a task to include the Real Time Worms feature. However, after some days of work, the development was dropped. This was due to various factors which prevented the release, mainly the lack of motivation. As said by Entuser, it may not be renewed until Project X 1.0. The only PX revision which had RTW enabled was given to a restricted group of testers, had hundreds of bugs and worked only under Windows XP (or lower) and 220.127.116.11.