A thing I dreamt up to help me keep pace with my creative whims in the realm of 3D networked video games.
Probably not ready for anyone else to use.
Stands on the shoulders of open-source giants. Currently this list includes THREE.js, ECSY, CANNON.js (actually, the active ECMAScript fork, cannon-es) etc.
Designed to be friendly with FP rendering engines (e.g. React). See src/render/EntityRenderConnector.ts
click here for documentation and API reference materials
Note: Physics, if desired, can be wired up using @react-three/cannon
within react-three-fiber
components.
PS: Until #124 is merged I recommend using my fork of @react-three/cannon.
These steps need to be performed whenever you make changes:
- Write awesome code in the
src
directory. - Build (clean, lint, and transpile):
npm run build
- Create unit tests in the
test
directory. - Verify code coverage:
npm run cover:check
- Commit your changes using
git add
andgit cz
- Push to GitHub using
git push
and wait for the CI builds to complete.
Note: This project uses automated changelog generation as long as you follow Conventional Commits, which is made simple through the included Commitizen CLI.
Follow these steps to update the NPM package:
- Perform all development workflow steps including pushing to GitHub in order to verify the CI builds. You don't want to publish a broken package!
- Check to see if this qualifies as a major, minor, or patch release:
npm run changelog:unreleased
- Bump the NPM version following Semantic Versioning by using one of these approaches:
- Specify major, minor, or patch and let NPM bump it:
npm version [major | minor | patch] -m "chore(release): Bump version to %s."
- Explicitly provide the version number such as 1.0.0:
npm version 1.0.0 -m "chore(release): Bump version to %s."
- Specify major, minor, or patch and let NPM bump it:
- The push to GitHub is automated, so wait for the CI builds to finish.
- Publish the new version to NPMJS:
npm publish
- Create a fork on GitHub
- Use the Suggested Development Workflow
- Create a GitHub pull request from your fork
Alternatively, (though less awesomely):
- Create an issue on GitHub
- Describe the issue in as much detail as possible. This makes up for not going the pull request route.
- What happened
- What did you expect
- What browser/OS versions were you using
- What have you tried to fix
- @chriswells0
- the fantastic Typescript node package template used as a starting point