New version

After nearly a month of hard work, I have finally released version 1.2.0 of Spaceships.

The main focus of this release was having it actually possible to win the game. Previously there wasn’t any goal in the game with the scoring system just keeping track of the number of kills each player has. This can be used to get an idea of who’s doing better in the game, but with no clear objective, the game isn’t too fun.

This release solves this problem with the creation of a very flexible scoring system to support many different types of games.

I also implemented many other features, many of which were required by the scoring system but some of them make things nicer to play with.

Version 1.2.x and 1.1.x of the game are incompatible with each other, but future 1.2.x versions after 1.2.0 are planned to still be compatible.

Scoring system

Now for the details of the scoring system. The scoring system consists of multiple parts: the controller, the win condition and the elimination condition.

The score controller configures exactly how the score of each player increases. By default this is set to the original behaviour of increasing by one for each kill. The score can now also be configured to change the player’s score when they die, occupy a certain part of the world, or periodically by a constant amount for all players. The exact positive or negative change in score can be changed for each of these scoring events.

The win condition is used to end the game and have one player, no players, multiple players or all players be the winner. The elimination condition is used to remove players from the game where they cannot respawn until the game ends.

Both win and elimination conditions are specified the same way and are dependent only on the scores of each player and the time on the timer.

Here are some examples of win conditions:

  • First player to a score of N.
  • Player with the largest score by time T.
  • Player with the largest score by time T, but allow waiting after time T if there’s a tie.
  • Last player with their score greater than zero (in this system, the scores would decrease over time, possible after each death).

Chat and commands

One important requirement is for the server to be able to tell the players which of them won the game.

There were many ways I could do this. I could’ve created a simple protocol that only allows one-way communication from the server to the client. However, in-game chat was a feature I was wanting to eventually implement, so I decided to create a more flexible system and get in-game chat as a bonus feature. A special case of this in-game chat is automatic messages sent by the server to the players, which can include information about who won the game.

I also implemented commands as well. These commands are for switching to and from spectator mode (a new feature mentioned later) and allowing the game to start early. One of these commands provides the player to voluntarily weaken themselves, known as underpowering.

Here’s what this chat looks like: Screenshot showing the new chat.

Underpowering

If you’re a skilled player and are playing with other players who are newer to the game, you most likely will win nearly all the time. That isn’t fun for you as you don’t get a challenge, and even less fun for the other players.

This release has added the ability for players to underpower themselves to make the game fairer.

Underpowering is done with the underpower (aliased to up) command which can allow players to decrease their speed, reload, regeneration rate and bullet damage. For more information about this, see the documentation or run help up while in the game (open the command window by pressing ‘/’).

Lobby

To give players a break between games, I created the lobby which disables scoring and players can use that as a time to relax or chat with each other.

By default the lobby is disabled but it can be enabled in the server config.

Spectator mode

Now players can connect to the server as a spectator without actually joining the game. This can be used for players who want to watch but are too lazy to play, but my intention with this change is to allow the elimination of players in some game modes. For example, the survival config (will be discussed later) has players who lose all their lives eliminated from the game. When this happens, they are put into spectator mode to watch the remaining players.

Players can choose to join the game as a spectator through a checkbox in the GUI. While playing in the game, players can voluntarily become a spectator by running the spectate command and (if the server allows it) then join again by running play. While spectating, a player can press ‘F’ to toggle between freely moving and following another player.

Here’s a screenshot showing a player in spectator mode: Screenshot showing spectator mode

Timer

When in the lobby there’s now a timer in the top-right corner displaying how much time is left before the game starts. This timer can also be available while playing the game depending on the server configuration. This timer can indicate how much time is remaining before the game ends, or how long it has been since the game started.

New configs

I have created two new server configs for this release, survival.ron and occupation.ron.

Survival

In this server config, each player has five lives (displayed in the score) and they are eliminated when they lose all their lives.

Occupation

This server config implements a radically different game mode to how things previously were.

This server config only works with two players which are spawned at fixed locations in their bases located on opposite sides of the world. Players increase their score by occupying the opposing player’s base, which is simply going to their base and having their score increase five times per second (after the first second of occupation). The winner is the player with the highest score after five minutes. If two players have the same score by then, the game continues until that changes.

Here’s a screenshot of the base of the red player in this game mode: Screenshot showing base of red player.

Changelog

Here is an incomplete list of everything that has changed since version 1.1.1.

Major changes

  • New scoring system.
  • Chat, commands as well as a status line.
  • Underpowering.
  • Spectator mode.
  • Lobby system.
  • Timer.
  • New configs: occupation.ron and survival.ron.

Minor changes

  • Addition of events.player_powerup_spawn_separation_radius. This allows prevention (by default) of players spawning too close to powerups and vice versa. This prevents confusion with players suddenly getting a powerup effect.
  • Using linefeed instead of rustyline (because of a bug in the latter).
  • Removed vi mode (switch to linefeed which doesn’t support it).
  • Reduced extreme jitter that can happen in rare scenarios (bug in bulk update acknowledgement).
  • Using a crosshair cursor while playing the game, as well as grab cursors while freely moving in spectator mode (to indicate that you can drag the camera).
  • Slight change to thrust and damage powerup particles. These probably aren’t noticeable.
  • When there are no scores shown, the “Scores” text is removed.
  • PlayerReset and ClearItems world events added.
  • Removal of effect zone min_time field.
  • Colour of blue player changed.

Bug fixes

  • Now the server no longer hangs when the terminal is resized too much (bug with rustyline).
  • Fixed bug when clients can panic if a player leaves very quickly after being hit by a bullet.
  • Other visual bugs related to players leaving and new players joining quickly after.
  • Now when the window’s height is very small, the ammo status text is rendered properly.
  • Stars are now spawned correctly when the window aspect ratio rapidly changes (such as toggling fullscreen).
  • Preventing the ammo status window’s borders from being visible if the mouse is over it when clicking on the play button. This resulted in a weird visual bug.
  • When a player dies while in an effect zone, the effect is now removed when they respawn.
  • Error message updated on unknown request to include correct supported versions.
  • Animations are now (closer to being) the same on all frame rates.
  • Spawn radius actually specifies the spawn radius rather than diameter.