Workflows
| Team | Deck Builders | Tournament Prose | Bread and Butter | |
|---|---|---|---|---|
| Scrum Master | Emmett | Z | Drew | |
| Cath | Nash | Dave | ||
| Aidan | Graham | Cara | ||
| Sinéad | AJ | James | ||
| Dara | Joy | Micky | ||
| Nena | Nick | |||
This is a one month project development project, January 2023.
| Start | End | Notes | ||
|---|---|---|---|---|
| Project Planning Meeting | 28th Dec | project vision | ||
| Sprint 1: | 1st Jan | 5th Jan | research and experimentation | |
| Sprint 2: | 6th Jan | 12th Jan | development begins | |
| Sprint 3: | 13th Jan | 19th Jan | ||
| Sprint 4: | 20th Jan | 26th Jan | ||
| Sprint 5: | 27th Jan | 31st Jan | end of development | |
| Sprint X: | Feb 1st | maintenance and publishing |
How to change/add items to the main branch on Github
- Clone repository, make and checkout branch.
- Make changes, commit the change to your branch. Repeat until feature completed
- Changes might be made by others while you work on your feature. Merge the main branch into your branch and resolve any conflicts.
- When conflicts are cleared, make a pull request, explaining your changes. Post in discord that you are waiting for review.
- When your pull request is reviewed, check that there are no new conflicts since you posted your pull request. If nothing new, complete merge.
- Ensure main branch runs after merge, close your branch and pull request, then open a new branch for your next feature and repeat above.
The idea of Quality Assurance (QA) here is to check things on a high level before any code is written. The goal here is to check that the functions and layout of the planned features make sense from a user perspective and stay in line with the game's vision.
This is open for all members as it is mainly a group discussion. The functional checks here would include logic checks. Like checking that game cards don’t make people over-powered too easily, or that enemy health-pools make things unwinnable, but this also covers the likes of U.I. in menus, game play and much more.
Each feature card where the result is something executable, should have test cases linked to it which check the possible scenarios that can happen with that feature.
Ideally, the tests should be written before or during development to confirm what is and is not in scope When that feature passes testing it can be merged to the master branch once approved in review. (Continuous Integration)
We have a master branch with feature branches. When a feature is added to the master branch, as a system health check there should be a Regression test of the most common areas, as well as areas in which the newly added feature interacts with (eg. update to deck animation does not affect the maths of the shuffling mechanic)
For ease, tests can be written in Google Sheets and the link is shared in the GitHub task. The format would be like this:
| Test Case Name | Has Been Tested | ||
|---|---|---|---|
| Action 1 | Result 1 | YES/NO | |
| Action 2 | Result 2 | YES/NO |
With testing features and whole system checks, extra areas of checking include Exploratory tests and Bug Bashes.
- In a time box going through the system and interacting in a way that will try to cause or highlight possible issues.
-
This is a group activity where in a time box, all parties use the system as intended. This can highlight issues across multiple devices and different actions.
-
This boils down to a closed beta with the developers as the play community.
-
Going forward, it's best to have two terms.
-
When something goes wrong with a feature in development we call that an “Issue”, and a comment will be left on the card with details of the issue as well as a direct message to the developer dealing with the card.
-
For problems found on the master branch label them as “Bugs”. For Bugs, a card should be created in GitHub with details and a @All message will be added to the general channel in Discord.
The main repository is 100% open to the world, and anything added there will be visible to anyone who wants to look. Your current/future employer, your mother and even complete strangers. Keep that in mind as you work on this project. We are a group of friends working together, but this is a loosely professional environment.
With our open-source nature, you can use this as an item on your portfolio, and as proof of work well done. Of course that also means we are a bit open to plagiarism and being scraped. We are in the process of deciding on our license, which will set out fair rules for use of our software. This is about as secure as the open side of our project can realistically be.
That said there may be assets we do not want available to the web as a whole, but do want to make use of in the final distribution of our game. For these, we will adopt a two repository system.
- Open Source:
- Closed Source: (If you are not a member of the team this link won't work, sorry!)
The Public Repository must be fully compilable at all times!
This will be difficult to manage with files that may or may not be missing. Public cannot be dependent on private to run. If you are adding a file to the private repository, it is your job to make an equivalent "stub" in the public repo. No file should exist in private, without a placeholder in public.
Assets without placeholders will not be used in the game
- File names must be the same
- Folder Structure must match between assets folder in public repo, and the private repo.
- General file structure should be the same, it should have the same file type, image dimensions, etc.
- The replacement should be appropriate to the games theme. An image shouldn't be replaced with a white box for example.
- Placeholders should be our files, or be files we have the right to use commercially. Don't use google images and nab the first result.
This will by it's nature mean git is a bit more complicated to use. You'll need to manage two repositories. I'll put example images in from git-hub desktop in drop downs for reference
- Clone the public repository
- Clone the private repository
- Find the local folder on your file system that the public repo is stored on.
- Clone the private repository into the folder assets_closed_source_assets of the public repository.
- Adding an asset.
- Make a branch of both repositories.
- Add a file to the appropriate folder of the private repo
- Add a stub file to the equivalent folder within the assets folder of the public repo
- commit and push both repositories
- create a pull request into main for both repositories.
- Developers need to do everything Asset Creators do to clone the repositories.
- An asset retrieval method will need to be made.
- If private assets are available, they'll be used first. We'll fallback to public repo.
- Try to never hard code an asset like a texture or audio.
- The main branch of the public repo is protected from direct merge.
- This is not the case for the private repo.
- Make sure to still use the same best practices and use pull requests and branches whenever you are merging to main.
- Two repositories means we will need to be diligent to keep them in sync.
Scripts must be written in this format to be readable by the game. Make a copy of the template. Write your script, give it a name like script_1.xml, and put it into the assets/writing/dialogue folder, then make a pull request.
If you want to keep your writing closed source, put it in the closed source repo, but be sure to have a placeholder in public.
<?xml version="1.0" encoding="UTF-8"?>
<!-- _______________________________________________________________________________________________________________ -->
<!-- this is a comment, it does nothing when read by the game -->
<!--
I'll use them to explain the template.
You can use them to suggest things to devs, or just as notes.
You can remove all of these when writing your own if you like, just copy this template, and give it a new name.
-->
<!-- How this template works -->
<!--
A dialogue is a collections of characters, locations and a script
Think of it as a cutscene which interrupts gameplay, and does not go back to gameplay until it finishes.
-->
<!--
First you declare which characters will be used in this dialogue, then what locations will be used.
Characters are defined in characters.xml, a separate file. You can set their color, sprite, and animations there.
Same deal for locations in locations.xml
-->
<!--
A script is a collection of shots which will be included in this script.
A shot is a collection of lines, followed by a set of responses.
lines will be played sequentially, and the player will the be presented with options.
options are a list of responses, or a dialogue_end tag. They may contain text, but they must always either contain either:
an id for the next shot (whichs allows for decision trees)
or a dialogue_end tag (which exits the dialogue)
-->
<!-- _______________________________________________________________________________________________________________ -->
<dialogue>
<characters_present>
<character id="" default_pos=""/> <!-- The id from characters.xml -->
</characters_present>
<locations_present>
<location id=""/> <!-- The id from locations.xml -->
</locations_present>
<!-- _______________________________________________________________________________________________________________ -->
<dialogue_script>
<shot id="" location_id="">
<lines> <!-- you can have any number of lines in a shot, they will be played sequentially -->
<line character_id="" animation_id=""> <!-- Set which character is speaking, -->
<override_pos> mid </override_pos> <!-- Where the character appears on screen: left / mid / right -->
<text> </text> <!-- The text that appears on screen for this line -->
</line>
</lines>
<options> <!-- these might be dialogue responses, or choices in how to proceed in the dungeon -->
<!-- you can have any number of options in a shot, but keep it to a reasonable number for presentations sake and for your own sanity in keeping track of shot trees. 1-4 is ideal -->
<option>
<text> </text>
<next_shot_id> </next_shot_id> <!-- The next shot to be played after this -->
</option>
<option>
<text> </text>
<dialogue_end end_var=""/> <!-- a flag to end the current dialogue. Includes an attribtue variable to pass data forward into gameplay, for example to decide next battle -->
</option>
</options>
</shot>
<shot id="" location_id="">
<line character_id="">
<override_pos> left </override_pos>
<text> </text>
</line>
<options>
<dialogue_end end_var=""/>
</options>
</shot>
</dialogue_script>
</dialogue>
<!-- _______________________________________________________________________________________________________________ -->
Characters must be defined in the format outlined below. They must be added to the existing file. You should not add a new character file. Add a <character> node to the file, ensuring the same formatting. Fill in all fields. Make a pull request, your character will be available for use in scripts.
<?xml version="1.0" encoding="UTF-8"?>
<!--
This file is used to define all character attributes as they will be used in dialogues.
There should only be one copy of this file, which contains the definitions of all characters in the game.
-->
<characters>
<character id="char_1"> <!-- Every character should have a unique ID following this pattern, char_name -->
<name>testName</name> <!-- character name to be displayed in game -->
<font>testFont</font> <!-- a reference to the font asset for this character -->
<color>#FFFFFF</color> <!-- a hex value for the colour representing this character -->
<sprite>test.png</sprite> <!-- a reference to the sprite asset for this character -->
<default_animation>anim_test1</default_animation>
<animations>
<animation id="anim_1"/> <!-- reference to in game animations -->
</animations>
</character>
<character id="char_2"> <!-- Every character should have a unique ID following this pattern, char_name -->
<name>testName</name> <!-- character name to be displayed in game -->
<font>testFont</font> <!-- a reference to the font asset for this character -->
<color>#FFFFFF</color> <!-- a hex value for the colour representing this character -->
<sprite>test.png</sprite> <!-- a reference to the sprite asset for this character -->
<default_animation>anim_test2</default_animation>
<animations>
<animation id="anim_2"/> <!-- reference to in game animations -->
</animations>
</character>
</characters>
All locations should be added to the existing file, do not add new files. Make a <location> node, endure you fill in all fields and match formatting. Make a pull request, and your location will be available to use in scripts once merged.
<?xml version="1.0" encoding="UTF-8"?>
<scene_locations>
<location id="loc_1"> <!-- Every character should have a unique ID following this pattern, loc_name -->
<name>testName</name> <!-- location name to be displayed in game -->
<image>test.png</image> <!-- Background image, an asset name -->
<animations>
<animation id=""/> <!-- A reference to the animation that should be played over this scene -->
</animations>
</location>
</scene_locations>