Skip to content

Latest commit

 

History

History
154 lines (99 loc) · 5.66 KB

README.md

File metadata and controls

154 lines (99 loc) · 5.66 KB
Raw

NeoMori

NeoMori is a summer project exploring contemporary software development and DevOps in a game development setting.

☀️ Read our blog post here! ☀️

NeoMori_Preview

Project goals

Game development has unique challenges which can make it difficult to adopt modern software development techniques and disciplines such as test driven development, automated software pipelines, etc.

NeoMori aims to explore and overcome those challenges and produce a comprehensive guide on how to do so for novice and veteran alike.

For a full list of challenges, check the roadmap.

About the game

It'd be hard to run a project on development practices in game development without doing any game development. Underlying the project is the development of NeoMori, a fast-paced stealth platformer where players avoid detection while navigating through various levels.

Installation

  1. Navigate to the GitHub Releases page or the itch.io page
  2. Download the latest release for your distribution
  3. Unzip the release to a chosen directory
  4. Follow instructions below for your distribution

Windows

  1. Run NeoMori.exe and enjoy!

Linux

  1. Grant execute permissions to the game: chmod +x NeoMori
  2. Run NeoMori and enjoy!

Mac

Fair warning, the Mac dist is a little finicky at present.

  1. Open your terminal in the directory you unzipped the release
  2. Run the following: 
    unzip NeoMori
ls -lr@
xattr -d -r com.apple.quarantine .
open GodotDevOps.app
  3. Enjoy!

Development

Workflow

  • Commits should be tied to an issue
    • Reference the issue in the commit messages: "WIP #3", "Fixes #3"
    • Release notes should be added in the commit body: "Fixes #3 > New Feature: Giant lasers have been added to the player's arsenal"
  • Code changes should happen on a branch
    • Name: Related issue number, lowercase, dash-separated 3-add-giant-lasers
  • Merging is done through a pull request

Task management

  • All development tasks should always have a corresponding issue
  • All work on the project should always be tied to an issue
  • The board is divided into 5 categories: Ungroomed, To Do, In Progress, Done and Scrapped
  • Issues are ordered by importance/priority

Ungroomed

Ungroomed issues tracks ideas, unrefined large scope issues or other work that is vaguely defined.

To Do

Issues in To Do have clearly defined definitions of done, a set of tasks that need to be finished before it can be considered done.

An issue should also take less than a full day to complete. Anything larger should be broken down into smaller issues.

For convenience's sake we allow "epics" to reside here as well. These are large issues used that help track progress of similarly-themed smaller issues.

In Progress

In Progress are issues currently being worked on.

As a rule of thumb, the amount of issues here shouldn't surpass the amount of project members at any given time. Essentially, a developer can't work on two things at once.

It is perfectly fine to move issues back and forth between To Do and In Progress.

If an issue is larger than expected it can be broken down into smaller issues and placed in To Do.

When an issue has all its definition of done marks checked, it can be merged in, closed and moved to Done.

Done

Issues in Done are done and stay done.

If an issue needs revisiting, a new issue is created rather than reopening the original issue.

Scrapped

Issues are moved to Scrapped when they are no longer part of the project's scope. They serve as a log of features once considered that didn't make the cut.

GitHub Actions

Build

The build workflow is triggered either on pull requests or when pushing to main.

It runs the unit tests, builds the game clients and archives them for testing.

Publish

The publish workflow is triggered on tag.

It takes the built clients from the build workflow and publishes them as a GitHub Release.

Creating a release

  1. Check out the commit you wish to release
    • Only works if the commit has a successful build on main
  2. Run .buildscripts/release.sh and follow the prompts
  3. Your commit should now be tagged with generated release notes
    • This will trigger the publish workflow, publishing the release

Project flow

The project as a whole loosely follows the following structure:

  • Game development continuously ongoing
  • Monday and Wednesday fikas and project discussion
  • Friday demos
  • During fikas and demos, we'll:
    • Find ways to improve our workflow, by either adding or removing processes/skills/tools
    • Book the time to hold some workshops/trainings to achieve those things
    • Where applicable, add them as isues to the board.

License

This project is licensed under the MIT license.