Skip to content

Latest commit

 

History

History
121 lines (80 loc) · 6.64 KB

docs_00_overview.md

File metadata and controls

121 lines (80 loc) · 6.64 KB

DOCS 00: documentation overview and scope

Doc links

Documentation page links:

About

  • this is mostly an overview with details on what the different sections do, it also includes some scope overview stuffs

Contents

Sub document briefs

[Back to contents]

  • look below, and behold that there exists things.

DOCS 01 : Concepts and some throwing around ideas

[Back to contents]

  • click here to goto [DOCS 01 : Conceptual]
  • initial research and thoughtables
  • can be actor identifying and the use case stuffs
  • will be the use case diagrams and sequence diagrams too
  • include the context model
  • mah haps the architecture

DOCS 02 : Requirements building the things and interactions

[Back to contents]

DOCS 03 : Detailed designs etc

[Back to contents]

DOCS 04 : Make the things

[Back to contents]

Development style notes

[Back to contents]

  • important spookers about the development process
  • previously within the conceptual doc:
    • a lot of the conceptual design notes already covers a lot of this, and this stage is kinda broadly skipped so far, but inclusions/exclusions as well as dependency matrix should first be made to highlight a realistic development plan and "attempt" to avoid complexity demon ruining the gamification of this art project

development iterations and conditions

  • conditions of development will be that this does not interfere with studies of repository maintainers and is meant as an artistic project
  • design aims of this project are that it facilitates exploration of different engineering practices, OpenGL as a frame work, and C++ as a language
  • as C++ is not taught as a primary language in the university that the creator of this project attends, there will be certain features that exist in C++ which are not an option in development for someone with more experience in java.
  • there will be times where development may be halted due to the restriction of chosen resources and ever the chance that development may be halted indefinitely with little warning.
  • whilst the project does have the potential to showcase certain talents, this will be an ongoing battle to avoid thinking about and to dodge it becoming too much about the showcasing and not enough about the art and creative drive/freedom that the medium presents the creator.
    • likely causes for project development death will be the aforementioned "showcasing", as too much attention can heighten unnecessary negative criticism, self-sabotage to avoid the spotlight, and over-estimation of abilities.
  • development will attempt to take an iterative approach but more likely will end up being "Near-sighted Spaghetti Demon" due to the concepts involved
  • were the creator patient and scheming enough, this could very easily be adapted to be a thesis project rather than a creative project, but that would cause similar concerns as before and likely assassinate motivation in working on it

notes on different terms

Gamification

  • wiki page about Gamification
  • but honestly we use this as the idea to cognitively turn this project into an artwork / game to be conquered so that the development is less likely to halt.
  • what if development were more gamified as to avoid the complexity demon and the engineering anti-fun monster

the engineering anti-fun monster

  • not sure if this is an existing idea, but a similar one to the complexity demon
  • to summarise, this is just the idea that some projects tend to get bogged down by engineering documentation and the overall intent for everything to be a new dotpoint on one's portfolio
  • sometimes, projects suffer by having them being made into mountains by the very strict and rigorous "anti-fun" of the engineering design process which makes all deviation from "the garden path", out to be an illegal, very serious criminal offense, and punishable by low grades on your design aspect of the learning and sentencing to some engineering jail house where you sit and think about the evil miss-deeds you've committed while other engineers frown at you if you ever make eye contact. Continuing this way until such time as you ascend to be an agile-shaman who makes immaculate documentation, regardless of if the project was a success.

the complexity demon