Devlog 11

---

Ferris’s Game of Life (FGOL) v0.2.0 is now released!
Check it out here: https://github.com/Polycarbohydrate/FGOL/releases/tag/v0.2.0

What is new?

• First of all, Ferris, is now in banners that surround text in the CLI!
• These banners surround important pieces of messages or menus. Text that is used for input will be displayed regularly.
• Taking into account many of the suggestions from the first ship, I added presets!
• There are 5 presets with this ship, and I plan to add more, which you can select to skip the hassle of setting up the simulation. These 5 were ones I found interesting and were fun to watch on the CLI.
• Additionally, you may notice that there are more menus now. In order to accomodate the many changes while keeping the user experience friendly, I decided to use menus instead of forcing you to follow a setup process. You are able to customize the simulation however you want!
• You are now able to add, remove, and view existing cells before you start the simulation!
• You can still edit the speed of the simulation, and choose the grid size you want.
• New settings include choosing when to stop the simulation (if you have an infinite loop) and stopping the simulation once cells move off of the screen.

---

Technical changes:

• To make the code readable and better to edit (i don’t think a 1000 line file with repetitive text is good), I added banners.rs, which holds all of the banner/text content. Other files use the content by calling functions within banner.rs. This makes it so I can see more logic than text, which is more important with debugging.
• I added the type SettingsExport to hold all of the information I import into cli_display.rs. This was a suggestion from cargo clippy.
• As always, all code is linted using cargo clippy and formatted using cargo-fmt.
• All files besides core.rs were modified to accomodate changes. input.rs was changed the most.
• All platform binaries are still a modest file size (~100kb)

---

Before releasing, I tested for formatting, bad input, and tried to fix everything. I something doesn’t look right, or you encounter a bug/error. Create an issue on the GitHub so I can quickly fix it.

---

Future plans:
Ship this release.
Work on more features
Transition to web-version.

---

Video demo:

Devlog 10

---

Minor changes today

I didn’t spend much time today working on this project becuase I have some real world stuff to work on.

---

Changes:

• I added 2 more presets to the code for a total of 5 presets.
• Added some additional code comments for better code understanding

---

I did some research on a pause feature that I saw in one of the reviewer’s feedback. It is hard to implement an easy to use pause, as I want to keep the CLI std lib only - no external creates.

I may drop that feature or implement it stupidly in the future. Ill do some more research on it in the future.

---

I added 2 additional issues for future features I want in the CLI.

Both have to do with detecting a simulation loop.

---

I have also decided that the CLI should remain independent with no external crates.

Devlog 9

---

Made some improvemets/additions to the CLI today based on some of my own discoveries and feedback from the first ship.

Thank you to everyone who voted on my first ship ever! I looked throught the feedback and appreciate the support. I also appreciate the constructive feedback. I took it into consideration and applied changes.

Major Changes

• Biggest change was the addition of preset templates. You can now choose between inputting your own cells through coordinates, or by just selecting a preset template which has hardcoded values for cells and everything else.
• This was done by adding presets.rs which is mainly for the hardcoded values to be fetched and stored. Additionally inputs.rs was updated and overhauled with more functions to be more readable and easier to edit.
• main.rs was changed to accomodate the changes in input.rs and presets.rs
• core.rs and cli_display.rs were not changed

---

Bug fixes

• Inputting a negative number in the first step of the custom setup process would not have proper program execution. I fixed by checking for negative numbers

---

Personal changes

• The program now has a dedicated exit and loops after a generation dies so you can keep on testing!
• Phrasing in one of the prompts in inputs.rs was changed to be more clear.

---

Additional thoughts:
I will fix up the CLI a bit more and add a few more features before moving on to TUI development. The release of the TUI will be my second ship. Eventually I plan to have this project with a GUI, TUI, CLI, and a web version.

Since I am planning for the CLI to be used on low-end devices, I am going to limit the file size to 1 MB. That is 1 MB across all platform binaries.

Someone suggested adding a pause feature. I am currently looking into implementing that.

Tldr: I will continue fixing up the CLI and adding features.

Have a wonderful day.

Devlog 8

---

This will likely be the last devlog before my first ship.

File changes:

• cli_display.rs: Removed hardcoded grid constants and added new input parameters for grid size. Experimented with different grid spacing but settled on a dot and space to one emoji (”. “).
• inputs.rs: Added a new section for grid size selection. There are four choices for selection: Small, Medium, Large, and Custom. I had a little bug with Custom not properly working but that was quickly fixed.
• main.rs: modified to accomodate variable and parameter changes of the 2 files above.

---

• I checked error handling and the spacing of text as well. Everything should be properly handled
• cargo-fmt & cargo clippy ran.
• Fixed the old bug of inverted y cells; the problem was because of the way I collected line renders (I rendered the bottom of the grid up, but my string concatenation pushed the bottom lines to the top). To solve I just reversed the loop for the rows (y-value).
• Plenty of comments
• In the video attached, at 200ms per frame there is no screen stutter. The new way of displaying frames seems to be good.

---

Future:

• After this I will update my project GitHub ReadMe and add binaries for Windows, Linux, and MacOS. Then I will add the playable link here.
• After shipping, if the project passes, I will clean up the code and make the game replayable after all cell dies.
• Next major modification would to progress to a TUI then a GUI with additional features.
• Lots of ideas for this one!

---

Other:

• Self contained Rust, no external crates.
• Q: Why not GUI? A: I see lots of people on this platform have a GUI. However they are using an easy to use game engine, web render, and/or easy to use applications. Rust is mainly for backend and using Rust for frontend is a pain in the butt. I would have to learn eframe/egui and how to work with web-assembly and convert my code to be compiled that way. A TUI would be my next step. If the TUI works, I may consider an infinite grid project milestone and/or then proceed to do a Rust-based GUI.

---

• Attached is the cell pattern known as “diehard”. It contains 7 initial starting cells and goes all the way to generation 129 before dying exacting on generation 130.

---

Feedback is welcome!

Devlog 7

I didn’t change much during this time. However, I redid the printing to that it prints the frame at once instead of one line at a time so there is less stuttering and screen movement. I spent the majority of the time trying to use eframe and wasm but I had a hard time figuring it out. Additionally to just compile and test my code I had to compile 225+ packages every time which took a long time and if I decided to use wasm, it would be even more packages…

Next step is to see if I need to fix the location of the delay (speed) and then ship. After ship, I will use an external crate for the TUI. then if the tui goes well maybe an online thing as well.

Majority of projects here are using a framework that is high level for frontend development. Using Rust for frontend is a pain :(

---

I added another video with the famous 7-cell 120+ generation ‘diehard’ to show the cli. I think there is less stutter now (i think the stutter at the end would be reduced if my terminal was not as big).

Feedback is welcome!

Devlog 6

---

File changes (additions, removals, modification)

• modification: tui.rs/cli_display.rs -> renamed tui.rs to cli_display.rs to be more accurate since I am not building a TUI-based display/application

---

Non-code changes

• In Cargo.toml, I changed the package name to FGOL instead of the generic testing name I had before. This will now reflect on compilation.

---

Code changes

• main.rs: I refactored usage of tui.rs to the new file name. I also added a stop to the program that checks if the cells HashSet is empty. If it is, then the program prints the last empty grid frame and notifies the user before stopping.
• core.rs: No changes.
• inputs.rs: Major modification to the code in here. Made the input process look nicer, tested the display spacing (including after error messages), overhauled to ask the number of cells that way it is less repetitive if a user wants to add more cells. Added a seperate function to clean the file up a bit (still have some work to do; I don’t think its very readable). Added the crab emoji as the banner for Ferris.
• cli_display.rs: Changed the cell char to the crab emoji as the banner for Ferris 🦀.

---

Other

• Everything is formatted to cargo-fmt & cargo clippy
• No errors or warnings during compilation.
• Error handling was tested and the printed lines have spacing to look nice.
• No external crates or packages; it is entirely self-contained.

---

Future

• I may ship like this (as a binary) to see what feedback I may get.
• If my ship passes I will continue and make a GUI and learn an external crates for that.
• For testing and playing, I think a web UI is the best. A binary application is not the best (and unnecessary). I will see what my time looks like and maybe I will convert to an actual UI on the web before shipping or find another solution. Otherwise I will compile the .exe myself and host on the GitHub.

---

Feedback is welcome!

GH: https://github.com/Polycarbohydrate/ferris-s-game-of-life

Devlog 5

---

Big changes were made today!

• main.rs completed
• core.rs completed
• input.rs completed
• tui.rs completed

By completed I mean that the program is functional (albeit, not pretty).

Program is formatted to cargo-fmt and only one cargo clippy warning is left for me to address.

---

The next step is for me to fix a bug that causes the points to be inverted when plotted (positive y becomes negative y).

I also have to figure out the clippy warning which is stumping me (warning on an if-then-else statement). This should not take long.

The output is stretched due to the uneven spacing of chars in the terminal. THis will have to be addressed in the future by redesign or switching to a GUI framework (likely eframe/egui).

I also need to streamline the user input section and make it easier.

I will upload to GitHub soon. I also applied for access to hackclub.app to host it for testing.

One thing I will note is that the code currently has no outside crates/dependencies and is entirely self-contained.

---

I have attached a video of the program running. The low quality is from it being cropped from my VSCode terminal…sorry :(

Suggestions/feedback is welcome!

Devlog 4

Big improvements today! I finished the core algorithm and completed the first version of the inputs that a user can provide. I restructured the project with:

• main.rs (the file that brings everything together)
• inputs.rs (user input stored and returned to main.rs)
• core.rs (takes info from inputs.rs to calculate the next generation of cells)
• tui.rs (im progress; probably the hardest part. I am thinking of doing a gui using egui/eframe. If I don’t I will likely implement a grid in the terminal using a limited space (probably 100 x 100 cells for the initial version)

Very good progress so far. Only thing I need to do that is important is display the cells.

Today I had an insight to switch the initial state to a simple vertical 3 cell stack. This was to make it easier to debug since the next generations are periodic and my code should show alternating points. The simplified conditions allowed me to figure out the proper algorithm structure:

1. Find dead cells.
2. Calculate new alive cells.
3. Remove the original dead cells.
4. Generation complete

Previously I was checking AND removing dead cells before finding the next generation’s alive cells.

The next step is to reorganize my code, verify the results, and then convert to a GUI or TUI.

Decided on data type usage (HashSet mainly for storage of cells, and HashMap to convert dead cells to alive cells.) I am sure it is very unoptimized right now. There is a big bug which I will have to fix later.

Today I started working on a simple game of Conway’s Game of Life. I started coding in Rust. It will be my first ever project/game of this sort and hopefully it will be fun!