Document what you did in Week 5

[ikarth]

As you do things in week 5, post a short write-up with link to the issue where you wrote about it.

If you learned something, did some research, or anything else that isn't code, please write about that too! The idea is to document what we've learned and where we learned it from.

[ikarth]

Added Tracery to the project (run pip install -r requirements.txt or pip install tracery).

Refactored the module organization (#107). Please check to see if this broke anything that I missed!

Updated the way that asset paths work (#71). The scripts now use the Python module functionality to load assets. This requires asset folders to include (empty) __init__.py files in each folder, but allows it to use Python's modules to find the assets without messing around with file paths directly.

Fixed collision map generator (the byte order was reversed from what GBStudio uses) and uses it to output the collision maps to the generated project. #99.

Took Tammy's comments in the generator and turned them into docstrings #104.

Started work on a scene library (#110, #117). We need a large pool of scenes for the program synthesis to use, plus the properties of those scenes. Properties are a future problem.

Added Credits file (#120). Add your name!

I'm currently working on adding an interpreter for importing gbstudio project files and using them as scene templates (#119). That way we can use GBStudio as the primary tool for making new scenes for the scene library. Right now I'm working on importing scripts and altering them where needed for the templates (variable arguments, connections, etc.).

As part of this, I altered the way that methodCreator.py works so that it handles nested scripts with children better. And has description strings and comments and some other nice things.

[sachitaKashyap19]

This week I worked on completing my Maze Generator and pushing the code out to GitHub. Rather than utilizing an maze generation algorithm that I found online, I tried to create my own algorithm to generate a maze that splits up the 31 by 31 grid into four quadrants. The first step was making sure any blocks placed down would not collide with each other. I achieved this by creating a 2d array with a length of 31, and putting in a zero for each index. The basic idea I was trying to achieve is once a block is placed down, that coordinate gets fed into the array and changes the x coordinate and y coordinate in the array from a 0 to a 1. A 1 means the space is occupied, while a 0 means it is free. Using this method, I can check every block to make sure wherever it is placed, the X and Y coordinates are free in the grid. I also had to debug lots of out-of-bounds errors, which I dealt with by allowing blocks to go either down or to the left in the first quadrant so they would not get built outside of the 31 by 31 space provided. I used respective restrictions for the other 3 quadrants. To generate lots of rows of blocks to emulate a maze, I looped the code 20 times, which created somewhat of a maze. I found that generating a traditional maze is actually quite difficult, because computers do not understand the logical sense of pathways or symmetry. Coding out each and every design element of the maze taught me a lot about python’s capabilities and limitations, which I think will help me as I code new projects in the future.

[mittalanika]

During the fifth week, I assigned myself to a new issue in which I would create a storyline game with generative grammars. In order to learn about generative grammars, I read a research report called “Generative Grammar: A Report on Research” by Frank J. Zidonis.

[vijayak1]

This week I mainly played games on itch.io and tried looking into their GB files to see how certain games were made. For example, this game that's more mission oriented and to see how their booleans for assessing mission completion worked. I worked on my appearing and disappearing sprites issue and ran into the blip where I realized I didn't really understand my goal, so that carried into the next week.