mark/sota
Archived
2
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases 1 Wiki Activity
year 2.1 integrated project monorepository
This repository has been archived on 2024-08-16. You can view files and clone it, but cannot push or open issues or pull requests.
44 commits 1 branch 1 tag 10 GiB
yaml 97.8%
json 1.9%
C# 0.2%
Go to file
sippy-thinks 2ad1927eb6 modelling: created walls
2024-07-27 22:32:07 +08:00
Design design(rl logo): update + export 2024-07-23 20:09:18 +08:00
Documentation docs: init STLD_GDD 2024-07-25 18:25:29 +08:00
Modelling modelling: created walls 2024-07-27 22:32:07 +08:00
RunningLateGame game: update unity editor version to 2022.3.38f1 2024-07-23 10:21:18 +08:00
.gitattributes meta: add base files 2024-07-11 03:26:27 +08:00
.gitignore meta: ignore oldstep 2024-07-22 16:33:45 +08:00
LICENCE.0BSD docs: add readme + licences 2024-07-11 16:25:59 +08:00
LICENCE.UNSPLASH docs: add readme + licences 2024-07-11 16:25:59 +08:00
README.md docs: add HDB floorplan 2024-07-23 16:38:20 +08:00
sidestepper.py tooling: faster repo dupe + std elapsed string gen 2024-07-27 02:28:57 +08:00
sync.py tooling: faster repo dupe + std elapsed string gen 2024-07-27 02:28:57 +08:00

README.md

sota staircase Horizontal Logo

The sota staircase Mono-repository

Primary Repository: https://forge.joshwel.co/mark/sota
Submission Mirror: https://github.com/markjoshwel/sota

Name Primary Role Secondary Role Forge GitHub
mark creative and technical director senior programmer @mark @markjoshwel
ryan programmer generalist @ryan @sc0rch-thinks
sai lead 3d artist quality checker @sai-thinks @sippy-thinks

Handbook

on 3D Modelling (Maya, Blender, ZBrush, etc.)

Lead Sai

design-as-in-modelling your assets with modularity in mind, anything that can be modular should be modular

design-as-in-look should be checked with the group

structure your files similarly:

Modelling
├── Sources
│   ├── <Asset Name>.blend
│   └── <Asset Name> (Maya Project Directory)
│       ├── ...
│       └── workspace.mel
├── Textures
│   └── <Asset Name>
│       ├── *.png
│       └── ...
├── Modulars
│   ├── <Asset Name>_lowpoly
│   └── <Asset Name>_highpoly
└── Heroes
    ├── <Asset Name>_lowpoly
    │   └── *.fbx
    └── <Asset Name>_highpoly

on Graphic and UI/UX Design

Lead Mark

and then send it to mark for approval (●'◡'●)

anything that can be saved locally (including figma files, btw) should be saved locally, and then pushed to the forge under Design/

organise as you wish but make sure it's logical

on Game Development

Lead Mark

  1. make changes

  2. make sure the language checker isn't nagging you
    (spelling and grammatical errors)

  3. make sure intellisense isn't nagging you
    (variable/class naming conventions, etc.)

  4. reformat using rider's Reformat and Cleanup Code function, using the Built-in: Full Cleanup profile

    example

  5. push to the forge, or branch off and make a pull request if there are conflicts

on Game and Level Design

Lead kinda everyone more so mark

for this, discuss with the group; either through the telegram group or through an issue on the forge

on Documentation (for All Modules)

Lead kinda everyone more so mark

source files (.docx, .fig, etc.) should be in the respective modules' directory, and then exported as .pdfs to Documentation/*.pdf

on Repository Syncing

Wizard Mark

Syncing to GitHub via ReStepper

instructions:

python sync.py

if it screams at you, fix them
if it breaks, refer to the resident "wizard"

for what the script does, see the script itself: sync.py

Advanced Usage

you probably don't need to ever use these :p

the following environment variables can be set:

  • SOTA_SIDESTEP_MAX_WORKERS
    how many workers to use for repository duplication, default is how many cpu threads are available

the following command line arguments can be used:

  • --skipsotaignoregen
    skips generating a .sotaignore file, useful if you know you've already generated one beforehand

  • --test
    does everything except actually pushing to GitHub

there's more, but god forbid you need to use them unless you're changing the script, search for argv in the script if you're comfortable with dragons

SideStepper and the .sotaignore file

the .sotaignore file is a file that tells the sync script what to ignore when syncing to GitHub, and should be in the root of the repository

it is automatically generated by the sync script and should not be manually edited unless there's a file we want to exclude

any file over 100MB is automatically added when running ReStepper (the sync script) or SideStepper (the script that generates the .sotaignore file)

to manually generate this without syncing, run:

python sidestepper.py

we may or may not want to add the contents of the .sotaignore file to the .gitignore but that's probably better off as a case-by-case basis type thing

for what the script does, see the script itself: sidestepper.py

Advanced Usage

you probably don't need to ever use these :p

the following environment variables can be set:

  • SOTA_SIDESTEP_CHUNK_SIZE
    how many files to chunk for file finding, default is 16

  • SOTA_SIDESTEP_MAX_WORKERS
    how many workers to use for file finding, default is how many cpu threads are available

  • SOTA_SIDESTEP_PARALLEL
    whether to use multiprocessing for large file finding, default is false

    hilariously, it's ~4-5x slower than single-threaded file finding, but the option is still present because it was made before the fourth implementation of the large file finding algorithm (now called SideStepper because names are fun, sue me)

the following command line arguments can be used:

  • --parallel
    same behaviour as setting the SOTA_SIDESTEP_PARALLEL environment variable

Licence and Credits

"NP resources" hereby refers to resources provided by Ngee Ann Polytechnic (NP) for use in student work during the course of our study

  1. software source code

    software source code, unless otherwise stated, is licenced under the 0BSD licence. for more information, see LICENCE.0BSD

    considering how many YouTube tutorials were used on ryan's end, I doubt we extensively used NP resources

  2. models made with "extensive use of NP resources":

    specifically, coming from or in part has had the following software and/or services involved:

    • Autodesk Maya
    • Adobe Substance 3D
      • Substance 3D Modeler
      • Substance 3D Sampler
      • Substance 3D Designer
      • Substance 3D Painter
      • Substance 3D Stager
      • Substance 3D Assets

    would have all rights reserved, unless otherwise stated

    (i mean mr q said this already lol)

    the only exception to this is if the model was made in blender and doesn't touch substance painter, in which it falls under the modified unsplash licence noted below

  3. whatever is left

    everything else, from assets to documentation, unless otherwise stated, is licenced under a modified unsplash licence. for more information, see LICENCE.UNSPLASH

    disclaimer: the creative lead (mark) has been using adobe software even before enrolling into np, so whether it is "extensive use" is fair game lol

    (also yea I don't really have a better example than my eae portfolio oops)

Third-party Licences

exceptions to the above licences are as follows:

Template:

- (Asset/Work Name) by (Author Name): (Licence Name)
  `directory path, file path or glob pattern`

Example:

  • Frogman by Frog Creator: Standard Unity Asset Store EULA (Extension Asset)
    Assets/Characters/Frogman

comma-separate multiple licences, and use code blocks if you need to list multiple files/directories/patterns