BattleFTP

BattleFTP (Battle for the Point) is a text-based RPG game built in Haskell. The player will be able to create characters of various classes and races, and engage in combat with AI-generated opponents.

Overall description

Here are some top-level modules that the project will need to contain.

• Game (suggested) is the overall game module that manages the others. It will be the one producing the main executable.
  • Need some world traversal mechanics, an end goal.
• Unit manages all information related to playable as well as AI-generated units.
  • Possible actions: Attack, Defend, Flee, Wait, what else?
  • Should there be separate modules for AI and UI units? Or should they be submodules of the unit module?
• Equipment manages information related to equipment, weaponry and armor that one may carry.
  • Have standard "template" of equipment for the user to pick from?
• Combat manages the mechanics involved with hostile encounters, such as forming parties, managing actions and their order, managing in-combat unit health and buffs.
  • List of possible actions determined by user attributes, health, location, equipment, enemy type.
  • How do we handle "deaths"?
• Event manages the different events in the game. Is this needed? How does it interact with Combat? Is a whole combat one event? What other events might we have?
• AI is responsible for the management of enemy behavior.
  • Maybe rename to AILogic?
  • Will need to determine actions based on "enemy" attributes.
  • Will be nice to have difficulty levels.
• UI is responsible for user interaction, showing progress to the user and receiving input.
• State is responsible maintaining, storing and retrieving the game state.
• Environment (suggested) manages the different environments in the game world.

Developer Information

File Structure

All source code is contained within the folder called src.

You all have a basic file for your module, named after the module. If you need to create submodules, place them in a folder named after your module. For example, if Unit was to have a module called Unit.Party, then you would create a folder called Unit and in it create a file called Party.hs.

Overall Project Compilation

To compile the overall project, run: make exec from the root BattleFTP directory. This creates interface files within the src folder, and an executable battleftp in the root BattleFTP directory. You can execute that file, and thus run the program, via ./battleftp.

The main file for the project is src/BattleFTP.hs. By default it imports the Game module, but you may possibly find a need to import more. It contains a main function that currently does nothing. The Game team will need to change this function so that it calls a corresponding function in the Game module.

Documentation

To generate documentation, run: make doc from the root BattleFTP directory.

Commit Workflow

As we are all contributing to the same project, it will be important to avoid conflicting too much with each other. Therefore we will follow some rules:

1. Each team should create a branch, named after their team name. You should ONLY make commits to this branch. We will discuss in a few moments how to keep the branch in sync with the master branch.
2. Each team should only commit to the files for which they are responsible. This would be the main file (e.g. Unit.hs for the unit team) as well as any submodule files in the Unit folder.
3. If you need something added to another team's files, you must communicate with them to initiate this change, and they would be responsible for generating that commit.
4. Every now and then you will be sharing your changes by making a pull request onto the main branch, and you will be updating your branch with the changes from other teams' pull requests. We will discuss how to do this in the next two subsections.

There are typically two tasks that you would need to perform:

Update team branch with master changes

Every now and then you would need to incorporate changes that the other teams have made to your branch. These changes are typically incorporated into the master branch. What you need to do therefore is update your team branch with the current status in the master branch. You would do this as follows:

• In GitKraken, make sure you use the Pull pulldown menu, and use the "Pull (fast-forward only)" option. If that option gives you any conflicts, then you should talk to me, because it means something has gone wrong.
• Make sure your team's local branch is the current branch. Its name should show up near the top of the GitKraken window. If it does not, then you can right-click the branch in the tree list, and choose the Checkout option.
• Right-click on the master branch, and choose: "Rebase your team's branch onto master"
• This should not cause any conflicts. If it does, talk to me about it.
• You must now force-push your branch onto GitHub. Right-click the branch and choose "Push". A popup will show up at the top of the screen, with a Force Push option in red. Choose that option on that popup and the next one. This is a somewhat destructive option as it completely changes the remote version of the branch, but since it is only your branch and noone else is supposed to be using it, this is OK.
• You have now updated your team's branch with changes from the master branch.

Submit your changes to the master branch via a pull request

When you have changes to share with the other groups, you will need to create a pull request. A pull request basically signals to the project maintainer (me in this instance) that your team wants to commit their changes to the master branch. The pull request is a formal mechanism for doing that, and it offers a possibility for discussing these changes before adding them. Here are the main steps you would need to follow:

• Make sure your branch has incorporated the latest changes from the master branch, as discussed in the previous paragraph, including force-pushing your updated team branch to GitHub.
• Right-click on your branch, and choose the option to Create a Pull Request.
• In the resulting popup, you should see your team's branch selected on the left part, and you should choose the master branch on the right part if it is not already selected.
• You should provide a brief title for your pull request, succinctly describing what you are adding. Use the larger box area for a longer description.
• Click the Create Pull Request button.
• Now your pull request has been created, and you can view it on GitHub on the Pull Requests tab.
• It will be up to me to merge this request into the master branch.
• If many pull requests arrive at more or less the same time, then I will have to merge one first, and I may have to ask the other teams to synchronize their branches first before I can merge their requests.