Option 2: board game

Option 2: board game #

The second project option available to you consists in developing a video game with mechanics analogous to the ones of Might & Magic: Clash of Heroes or Legend of Solgard.

Students who choose this option you will be provided:

  • a basic graphical user interface (GUI) that they can reuse and/or customize,
  • examples during lectures that they may adapt to their project.

Requirements #

The minimal requirement to submit this project is a player vs player game playable on a single machine.

But of course, you are free to go further and add your own features. Among other possibilities, you could for instance:

  • implement new mechanics (e.g. a rock-paper-scissor logic for unit encounters, events that may affect the board, etc.),
  • make the game deterministic (i.e. eliminate randomness),
  • create units with specific behaviors,
  • implements scripted encounters (“boss fights”),
  • implement a story, character progression, etc.,
  • develop a player vs bot mode,
  • etc,

Note. If you choose the last options in the list above (player vs bot), then you may benefit from an algorithm seen in the chapter on recursion. Besides, if several groups choose this option, we may organize a competition between bots (provided that they play by the same rules).

Guidelines #

GUI #

The source code for the GUI can be cloned from GitHub. The project is designed so that:

  • you can develop a fully functional game (player vs player or player vs bot) by focusing exclusively on the backend (i.e. the mechanics of the game), without modifying the GUI.
  • backend and frontend are decoupled.

Communication between frontend and backend is specified via Java interfaces. It revolves around the notion of a game snapshot, which contains all the information needed to describe a state of the game (equivalently, you can think of a snapshot as a save state). In particular, snapshots are independent of a specific GUI.

For instance, a method is available that allows you to pass a snapshot to the GUI component. When you call this method, the snapshot will be drawn on screen, replacing the previous one (if any).

As input, your code receives the next action of the active player (for instance, delete the unit present on a specific tile). These are again specified by an interface. Your code should react accordingly: modify the current snapshot, and then send it the GUI component for display.

The README.md file (at the root of the project) contains a description of the different components and interfaces, as well as building instructions, and explains where your code could fit. Read it carefully before you start working on your project!

Note. You are of course free to modify the interfaces that come with the project. But this may require modifying the implementation of the GUI.

Disclaimer. By design, the project compromises performance for simplicity and modularity. This is not how a resource intensive game would be implemented.

More generally, this exercise is not meant to teach game development, but general-purpose programming and problem solving.