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!