seanfxyz/assembler_exemplar

An educational computer chip design game.

assembler_exemplar's Issues

Add a "Main" scene.

This scene could be called "Main", "Game", "Application", "Root" or something like that. It will be an over-arching control scene that contains an instance of our MainMenu, and would manage transitions by instancing the ChipDesigner, and possibly by activating loading screens or transition animations. I think it should have a Control Node as its root.

Update documentation from Programmer's Manual

Currently, the Programmer's Manual word doc corrects a lot of inaccuracies in the documentation files located in the docs/ folder. These files should be updated from the Programmer's Manual.

Design save file format.

Pick a License

I like the GPL v3 License, because making it Free Software means others can play with and learn from our code, while being a copyleft license prevents others from re-packaging our code and selling it as proprietary software. Licensing the code that way wouldn't keep us from making proprietary locked-down versions for educators later on, though.

Create a scene representing a "dummy" chip, meaning no inputs or outputs, and get it to do the following:

1. Be "draggable" i.e. movable with the mouse.
2. Snap to a grid. This tutorial may be useful.

This scene can then form the basis for other chip scenes.

Delete chips placed on Canvas

Maybe using a "right click" action on the chip/wire?

Implementations to be completed

Create "Input" and "Output"

Create scenes corresponding to the initial input(s) and output(s) for the Chip Designer.

Design chip/wire ID scheme.

In our JSON-based save and recovery data formats, the ID values for chips and wires must be strings. We need to figure out how we can generate unique ID values for each chip and wire that is added to a given solution.

It's probably fine for IDs to overlap within a save, but not within a solution.

Ideally, we could start with single-character IDs which grow if too many chips are added.

I think the URL-safe version (just to avoid future problems with integration of some sort of web-app) of the standard base-64 character set would be a good place to start for this. We can have each chip in-engine have an ID that's just an integer. When a new chip or wire is created, we increment the highest known ID by one and use that as the new component's ID. Meanwhile, the JSON representation would use the same integer, but encoded in a base-64 string.

Design recovery data/file format.

This will be the format for data that we save to a file continuously, line-by-line, for each modification the player makes to the chip. I'm thinking it will be JSON data, like the save file format, but with each line forming a single JSON object describing an operation on the chip.

When we load a save file, we can check for a recovery file. If it exists, we would then apply each operation specified in the recovery data, updating the data structure generated from the save file.

Implement ChipIO Singleton.

This is basically just a GDScript file full of dictionaries that map combined inputs to arrays of outputs. See here for more info.

Automate ChipIO dictionary production.

We should be able to automate the creation/population of the dictionaries in ChipIO in one of two ways I can think of:

1. Create scripts in Python, Perl, or whatever language to write out the dictionaries in GDScript syntax for us.
2. Add code in ChipIO that generate these dictionaries when the application starts.

I would lean toward option #1, since it lightens the startup load on our application, meaning less waiting for the users.

I think we should keep the scripts out of the src/ directory, since they don't need to bulk up the Godot project's contents. Maybe put them in a util/ folder in the repo root.