Isles of Ethor

In this cozy puzzle game, Players assume the role of Sky, a young adventurer set on a mission to reunite her home and the other islands in the land of Ethor. Once a bustling and thriving nation, the land of Ethor flourished with magic from a powerful entity known as the Mother Crystal; that is, until a catastrophic event known as the Fracture separated each island. But that was years ago, and the newer generations of Ethor haven’t known a life without the land being broken. Can you help Sky bring the Isles of Ethor back together? Or are they destined to be broken apart forever?

• Developed in Unity & C#
• Coded in JetBrains Rider
• Version Controlled through GitHub and GitKraken
• Managed progress & deliverables through GitHub Projects and Issues
• Built GitHub Actions Workflows for CI/CD processes to remotely test and deploy the game
  • Includes a custom-made MacOS workflow
• Created all 45 releases of the game and maintained the entire changelog with it

All 45 releases of the game were published with respect to the team’s semantic versioning rules. She also documented every single release in the repository’s changelog, which bridged the communication gap between engineering and the other less-technical departments. If there was a bug, confusion, or a design request, other teams could note the exact version that they were reviewing, rather than trying to play catch-up with the programmers. In tandem with these releases came the “Known Bugs for Engineering” document that she maintained.

While doubling in quality assurance, Nicole created this document that helped other teams communicate short-yet-specific grievances to the engineering team. Under each version heading, a suggestion would be documented and translated into our GitHub issues board where engineers can create semantically named branches (e.g., issue/15-player-stuck) that are linked to the issue number on the bug report log.

All new suggestions were prefixed with the word New, and all on-going issues were prefixed with Cont. after each subsequent release until the issue was resolved.

All 45 releases of the game were published with respect to the team’s semantic versioning rules. She also documented every single release in the repository’s changelog, which bridged the communication gap between engineering and the other less-technical departments. If there was a bug, confusion, or a design request, other teams could note the exact version that they were reviewing, rather than trying to play catch-up with the programmers. In tandem with these releases came the “Known Bugs for Engineering” document that she maintained.

While doubling in quality assurance, Nicole created this document that helped other teams communicate short-yet-specific grievances to the engineering team. Under each version heading, a suggestion would be documented and translated into our GitHub issues board where engineers can create semantically named branches (e.g., issue/15-player-stuck) that are linked to the issue number on the bug report log.

All new suggestions were prefixed with the word New, and all on-going issues were prefixed with Cont. after each subsequent release until the issue was resolved.