Select Page

Dungeons of Doom Gone Wild!

Initially started as a coursework from the first year of university. It started as a text based game where you would have to navigate through a map, collect sufficient gold and exit. We then created GUI, for which I used the MVC design. Also multi-thread server - client model is used with a chat. I have gone over and ahead the course specification and implemented an bot that solves the game as efficiently as it can, using Dijkstra's algorithm and dynamic memory allocation to store all the information collected about the labyrinth.
Sample Game Map

Sample Map of the game. Maps are loaded as text files of this format instead of hardcoding them in game. Maps are loaded by the server, the clients do not need to have them to play them.

Dungeons of Doom is a coursework for the first year of Computer Science students in the University of Bath. It is implemented in Java 1.7. The commands that the game logic recognizes are:

  • MOVE N
  • MOVE S
  • MOVE E
  • MOVE W
  • LOOK
  • PICKUP

N,S,E,W stand for cardinal points in which you can move. LOOK prints a 5×5 view in the map surrounding the player. PICKUP picks up the gold (if there is any underneath) and then prints the remaining gold to win the game.

In the LOOK print, ‘.’ is empty, ‘E’ is exit, ‘G’ is gold, ‘#’ is wall and ‘X’ is out of bounds.

In the case of GUI, on button press the client sends the string to the server, which then generates the reply in the gamelogic and the processed result is returned to the client where the string is processed and displayed on the GUI accordingly.

 

DoD Client 1

Example from in game GUI, as seen from Client 1.

Example from server view

Example as seen from server view (zoomed in image)

DoD Client 2

Example as seen from Client 2

Example Server view before players connect

Example server view in the map, before players connect.

This video illustrates how the bot interprets the game and an example of a solution. The spawn position in the map is random, and the size of the map also is unknown. This means that the bot needs to generate local coordinates, its spawn being 0,0 and with each step record its new current coordinate, the minimum and maximum it has seen (both positive and negative coordinates from spawn) in order to be able to recognize when it needs to allocate more memory space. It keeps an internal map of what’s the next move it needs to take in order to reach any of the places in the map, and then depending on the X,Y it decides to go to, it reads the according direction memory location in the array and executes the move.