Game Water-Wars

Water-Wars

FailWhaleBrigade is proud to present: Water-Wars

A game we, a team of three people, implemented for a course at university.
The game idea was to clone “Towerfall”, a fast paced multiplayer shooting/platforming game. For a more creative touch, this game was supossed to feature under-water and over-water areas where your movement is drastically different, when moving from one to the other. Mermaids fight to become the princess and are shooting at each other with bubbles.

However, since this course should take about 75 hours per person we had to reduce our core product. Unfortunately, we had to forget about the underwater idea, since it would have required a lot of additional animations and effort regarding the physics.

Experiences

It was a very explorative process, we evaluated multiple technologies regarding graphics, error handling, sound, image loading, serialisation, networking and threading techniques.
If someone is interested, we can publish our results of this explorative phase.

Since this was supposed to be a full blown project, where we experimented with a lot of technologies, we depend on a lot a packages. However, it feels like it takes less time to compile than Haskell-IDE-Engine!

We attach our presentation from the end of the course, which provides more information: Water-Wars presentation.

The Game

The game is a lot slower than its spiritual role-model. At some point we added more emphasis to it and reduced the bullet speed as well as the interval of time you can shoot bullets. The result is a surprisingly challenging game. Although an arbitrary amount of players is supported, the standard map is best for 2-3 players due to size limitation.

The entire artwork has been created by @VeryMilkyJoe!

Here are some pictures:

Loading the game, when the server is not online:

Alone in the world with the server:

Playing online with friends and winning:

Important note, to mute the music start the client with the flag -q

Feature list

  • Connect to a server
  • Play in fullscreen mode with sound or without
  • Play different maps which can be created usind text files
  • Wait for more players to join the server before starting the game
  • Restart a game when the winner has been established
  • Monitor performance via ekg

Features almost done

  • Reconnect on unexpected disconnects
  • Decoration on the map such as the manta, umbrella, coral, … (done in principle, final touch is missing)
  • Volume regulation

Features planned but never implemented

  • Underwater physics
  • Different game modes
  • Map editor for everyone
  • Power-ups

What we were happy about

We learned a lot about Haskell development. What we liked:

  • Haskell-ci
    • Great to introduce travis to the project
  • mtl
    • For @fendor and @VeryMilkyJoe, this was the first time we used mtl to improve readability.
  • extensible-effects
    • @power-fungus loves algebraic libraries, so it was only logical to introduce a library that is complicated and confuses the rest of the team! However, this is one of the reasons we love Haskell, you can learn something new every day!
  • Gloss
    • It has never been easier to implement a game almost from scratch.
  • Language Extensions
    • We have a lot of them and some are not neccessary, but we still like our language extensions.

What we were not so happy about

We are far from being completely satisfied with our work. There is technical debt and there are practical concerns. Here, we list things we would want to improve, if we get the time.

  • Princesses with different colours
    • Not clear if we can do this automatically or have to draw each princess with a different colour.
  • Websockets
    • Websockets are not the right technology, but it was the easiest one to integrate.
  • Binary serialization
    • We use automatic derivation of the cereal package, which means that the serialisation may depend on the ghc version with which it has been compiled. This feature had to be rushed since we noticed on the day of the presentation (don’t tell that to our professor) that the performance of the previous serialisation method (Read, Show instance) was terrible.
  • Gloss
    • Gloss is not suitable for cool effects like 3d lighting and does not offer any functionality to implement a user interface, such as a menu, server list or similar.
    • Due to the nature of the game, it may be sensible to move to a browser implementation for the client.
  • Logging
    • At the time of writing the game, @fendor failed to find a logging library that fit the bill. That’s why sometimes there are too many log messages, but at the same time they do not offer enough information to really debug what went wrong.
  • Synchronization
    • There is hardly any or only an implicit one.
  • UI scaling
    • Not implemented.

Final résumé

It was a great project and we are all proud of the result!

8 Likes

Excellent! I still have to try it, but first bug report:

f@x60s:/tmp/water-wars$ cabal new-build all
When using configuration(s) from /tmp/water-wars/cabal.project, the following errors occurred:
The package directory '.' does not contain any .cabal file.
The package directory './client' does not contain any .cabal file.
The package directory './server' does not contain any .cabal file.

Probably a few .cabal files were not committed to the git tree. It can be easily worked around with hpack.

1 Like

Played it!
It is always nice to see a haskell game released and even more nice to have good documentation and a presentation to explain design choices! Well done!

1 Like

Thank you! This project used to be a stack project and we didn’t notice that the cabal files had been generated all the time! should be fixed now!

1 Like