-
Notifications
You must be signed in to change notification settings - Fork 1
MDM Log
MDM stands for "Method for Design Materialization." This is a way for us to track our progress across the project and better understand how our designs have progressed. This is accomplished through the timeline below, separated by key dates that highlight our work, including presentations, artist statements/journals, and pull requests.
For further exploration of each Pull Request, which by far was our primary documentation for the MDM (as demonstrated below), please view the closed Pull Request section of our repository here. These can also be found under the "Pull requests" tab along the top. This will provide a much more in-depth timeline that includes approvals, as well as a visual of the individual files we altered during the Pull Request. This is completely optional.
All dates are within the year 2025.
Our early work encompasses work to better prepare us for our project proposal on January 29th. Much of it is initialization of the project, adding in early assets, and overall testing. Much of the documentation is also for testing purposes or is lacking for initialization reasons.
Aden | 1 commit
The initial setup for the entire project.
Aden | 1 commit
Testing if repo works.
Tate | 1 commit
Contains text mesh pro and the Articy plugin, Tested by Aden
Dear Dr. Scheiding, I am writing this commit because I am scared. Scared that it will break the project, scared that I am not a good Untiy developer, and most scared that I am being dumb and overthinking it.
Tate | 1 commit
added a basic 3d movement script. Access in movement scene.
Probably should not be a direct transform call, but handled by the player movement component. Oh well.
Dear Dr. Scheiding, I chose this movement option because it is what popped up when I looked for a simple 3d movement script for Unity. We are trying to recreate the fixed camera found in PlayStation games like final fantasy, resident evil, and silent hill. Off topic: do you like sparkling water? I do. I am a big Topo Chico fan. Please let me know!
With love, Tate
Aden review: This is really neat code work. I'll make sure to build off of this.
Aden comment: Tetsing comment for MDM purposes. (Documentation assignment for the course).
Aden | 2 commits
This provides a very initial description of the project for viewers while linking to a more in-depth overview in the wiki pages.
Commit 2: Fixed the link to the Home wiki page.
Tate comment: thanks for doing this aden! 😄
Aden | 1 commit
I reorganized a few files and created a handful of folders we will potentially need. Organization/specific directories create multiple, multiple merge conflicts, so I am trying to get ahead of that.
For the town testing, I created a scene and imported some Final Fantasy 9 background images that I will use to test player movement through towns. I hope to test scene transitions, camera movement, player movement vertically, and player resizing.
Tate review: Wow this is a super cool first step!!!!
Tate | 1 commit
The character now turns to the direction they are walking, and there is now a interactable rectangle that turns green if you press space around it.
I am very tired right now. There was a bug with the new movement where it kept going after the button was pressed. I found the solution two hours ago. I did not realize that I had fixed it till 15 mins ago. I am happy that it works. That is all I have to say.
Tate comment: also a sprint is bound to the escape key
Aden | 3 commits
Commit 1: We want some scenes/areas to be long/tall, so I updated our PlayerMovement script to include camera movement alongside the player's. The camera is clamped so it does not go past the boundaries of the screen, and the player remains centered if they turn back from being past the camera boundaries so that the design can remain consistent. I have also started changing these boundaries regarding what plane (scene/area) the player is on. This will be expanded in the future once I get to test it more accurately following scene/area transitions.
Commit 2: We are going to have different planes/areas that the player will traverse within a single town, so I created a test for this. It involves trigger points and empty objects representing camera and player shots, which practically just teleports both onto the correlated empty object when the player collides with the correlated trigger point.
Commit 3: As previously referenced, this is an expanded tracking method for tracking plane numbers, so the PlayerMovement script can track what plane/area the player is currently on. This plane number will then be used to specify the camera's boundaries for that specific plane/area, which is already used for the 1st plane/area.
Tate comment: I think that this will work