Related: [[Unnamed Space Game]] # 2026-04-16 ISPO Development Progress ![[20260412-160734 - Cmder (cropped).png]] > ISPO (Independent Space Probe Operator) is a terminal-based space probe command-and-control simulator. The player operates robotic spacecraft exploring a fictional but physically consistent planetary system, writing command sequences, managing limited resources, and bringing back valuable science data. (Written 2026-07-25) Back in April, I watched the entire stream of the [[Artemis II]] mission, start to finish. Two-hundred and something hours. I slept when the crew slept, mostly. Afterward, I had an idea, and I was able to stay obsessed with it for about two days (in all fairness I had to travel, which broke my stream of attention). Actually, I had a few ideas during and after Artemis II. The first was [[Tomboolery - Self-hosted PLC and Instrumentation Simulator]]. The second was [[Procedra - Self-Hosted Procedures and Checklists]]. The third was [[Unnamed Space Game]], now called *ISPO: Independent Space Probe Operator*. I started with a prompt, and ended with 60% of a game. I don't know if I would say "I" made 60% of a game. I barely touched the actual code. I did all the prompting, the git version control, minor bugfixing, and running/playtesting. But I didn't do any programming. The core idea, structure (e.g., choosing Rust for the engine, a TUI for the UI, Lua for scripting, TOML for content declarations), requirements (e.g., first-class data-driven moddability) are mine; the results perhaps less so. I used Claude, but I didn't use Claude Code; I would prompt Claude to write code or a section of code, it would provide me with a zip of the files, and I would manually integrate them into my local git project. I used Sourcetree to interact with Git. I liked this semi-manual process. I did feel like I was "doing something" even while not typing a single line of code. I sat and thought about my prompts longer and avoided "yeah that sounds good, do that". I also copied my prompts and the responses into Obsidian (per [[Guidelines for Including AI-generated Content in Personal Writing|guidelines]]) for later review and usage elsewhere. What I'm left with, as of mid-July 2026, are the code from "Phases" 1-4 out of 10, a `README`, a `CLAUDE.MD` (of course), and several game design documents and development documents. Eventually, I can take the code and continue where I left off, either with Claude or another LLM, or I can restart the project from scratch with my saved prompts and the documents and see what an entirely new iteration of the project might look like. It runs. The game engine works, the time scaling works, the orbit and spacecraft movement math works (it looks correct according to the numbers, at least), and you can write sequences to control instruments or manipulate the craft. The "game" aspects are what's left: operator email (for missions), missions, completion criteria, spacecraft creation and selection, etc. It's definitely a minimum viable product with emphasis on "minimum". I've recently (read: today) gotten interested in [[NASA cFS]], so I might read more into that and see how I could change or restart ISPO to reflect a more realistic-looking spacecraft system simulation. Maybe ISPO 2.0 will require running cFS in a VM. ### Notes - [[Unnamed Space Game]] - [[ISPO Writing and Lore]] - [[ISPO Content Creation Guide]] - [[ISPO Design and Development Conversation Phase 1 and 2]] - [[ISPO Development Conversation Phase 3]] - [[ISPO Development Conversation Phase 4]] ### Documents - ISPO Lore Bible (17p) - ISPO GDD (Game Design Document) (45p) - ISPO Development Plan (21p) - ISPO Content Creation Guide (34p) - SPIM Style Guide (for the forthcoming Space Probe Information Manual, an in-universe guide for the player inspired by the FAR/AIM) (20p) ## Screenshots Anyway, here are some screenshots, taken 2026-04-12. >[!info]- Genesis > ![[20260412-071552 - Space_probe_control_game_design_-_Claude_—_Mozilla.png|597]] >[!info]- TUI Screens > > ![[20260412-060802 - Cmder.png]] > > ![[20260412-160734 - Cmder.png]] > > ![[20260412-160825 - Cmder.png]] > > ![[20260412-160852 - Cmder.png]] > > ![[20260412-160855 - Cmder.png]] > > ![[20260412-160858 - Cmder.png]] > > ![[20260412-160903 - Cmder.png]] > > ![[20260412-160907 - Cmder.png]] > > ![[20260412-160911 - Cmder.png]] > > ![[20260412-160915 - Cmder.png]] > > ![[20260412-160919 - Cmder.png]] > > ![[20260412-160923 - Cmder.png]] > > ![[20260412-160932 - Cmder.png]] > > ![[20260412-160957 - Cmder.png]] > > ![[20260412-161003 - Cmder.png]] > > ![[20260412-161048 - Cmder.png]] > > ![[20260412-161105 - Cmder.png]] >[!info]- Git History > ![[Pasted image 20260725224726.png]] ## File Structure ### Content Core game content and modded content would go here. ``` ispo/content/ │ system.toml │ ├───bodies │ keldara.toml │ lunara.toml │ pyreth.toml │ sorath.toml │ terrin.toml │ veska.toml │ ├───commands │ all_instruments.toml │ antenna.toml │ attitude.toml │ data.toml │ propulsion.toml │ transmitter.toml │ ├───instruments │ ir_spectrometer.toml │ magnetometer.toml │ mspec_imager.toml │ particle_detector.toml │ radar_altimeter.toml │ thermal_mapper.toml │ uv_spectrometer.toml │ ├───missions │ ltp_training.toml │ lunara_science_002.toml │ pyreth_orbit_001.toml │ ├───spacecraft │ ltp_bus.toml │ survey_bus_02.toml │ └───sponsors ari.toml helios_data_corp.toml ``` ### Scripts ISPL (Interplanetary Sequence Planning Language) scripts would go here. These are the scripts seen on page D10 above. ``` ispo/scripts/ │ escape_lunara.ispl │ first_light.ispl │ maneuver_test.ispl │ observation_pass.ispl ``` ### All The git repo folder structure looks like this. ``` ├───config ├───content │ ├───bodies │ ├───commands │ ├───instruments │ ├───missions │ ├───spacecraft │ └───sponsors ├───crates │ ├───ispo-content │ │ └───src │ ├───ispo-ispl │ │ └───src │ ├───ispo-scripting │ │ └───src │ ├───ispo-sim │ │ └───src │ │ ├───orbit │ │ └───subsystems │ └───ispo-tui │ └───src │ ├───displays │ └───widgets ├───docs ├───scripts ├───src └───target ``` ## On fatigue after pausing this project for just two days (Written 2026-04-15-ish) > Code used to be expensive. It took time to write out what was in your head onto the editor. It gave you a surface area to sense when a pattern was pushing back on you. You had space to and time to think through the way you built a class, a function, a comment. > It gated decisions through at an acceptable pace, a pace you could keep up with and balance to do your best work. > Today it feels like I make 10 of these white-board level decisions before my second cup of coffee. -- [The cost of code use to be a middleware for our brains. : ClaudeAI](https://old.reddit.com/r/ClaudeAI/comments/1smjbvq/the_cost_of_code_use_to_be_a_middleware_for_our/) I feel this comment strongly. I've taken a break from my unnamed space game for just two days (today is thursday, I last worked on it on monday; spent two days traveling). Coming back to it now, it feels foreign. Far away. I have an exact record of where I left off on Monday through the conversation history with Claude, but I don't have everything in my head that I did three days ago. There's so much I'd have to reload before I'd feel confident in resuming the development process with enough "opinions" that I'm not just pressing "continue" for each phase. Once I take my attention away from the project for more than a few hours or a day, I forget the mental flow I was in and the decisions or intentions I had that I didn't write down. I hate comparing language models and the human brain, but it feels like my brain's context has been reset and I'm starting a new mental context from scratch. *I* have to reread the game design document to remember all the details I used to have in my head just to be able to continue. So now I'm really considering starting completely over. I'll take some of the work product I made over last weekend, such as the design documents and the content files (the *data structures*), but I feel that to have as deep an understanding of the project as I did in the three days straight I worked on it, I have to spend more time myself re-reading the design docs and planning out the smaller things (see above) that in the first run were already taken care of by Claude. In looking at what I made in three days, three days ago, I now see how I want to do things differently, earlier. I've gone from "let me race through development to get the basic game complete" to "let me sit on the basics for a while and see where more detailed planning gets me." I have to recreate the mental model of what I wanted. I see my original writing at the top of this note ([[Unnamed Space Game]]), so I know I was thinking about it deeply at the time, but now... the mental model I had didn't get ingrained, because I only did half the work (thinking of the ideas and putting them into words) and left the other half to be completed by the language model in mere minutes (converting the ideas and words into the thousands of lines of code required to manifest the idea into a functioning program). I feel like it will be easier if I start a brand new Claude Project so it has no context of the first attempt to manifest the game. Then bring in parts of what's been created already as I refine them more closely than I did for the first try. I don't want to rely on Claude "knowing" the other parts of the development process, because it will "remember" them even more wrong, and I don't remember enough of the first try to recall what I noticed needed to be corrected and had sitting in my head. Example given: Reading back through the conversations, I read that there was a back and forth on whether ISPL should be implemented with a combinator-parser or a 'hand-written' parser. I'm sure at the time I considered the pros and cons of each, and possibly did some reading myself online before making a determination, but I don't remember it. Probably only a few minutes passed between the question asked and the answer given. I learned nothing from that. I remember my program translation class from eight years ago better than the application of that knowledge I used five days ago. I know absolutely nothing about how the math for orbital mechanics was implemented in the Rust code. I couldn't tell you a thing about it, because I didn't write it. I didn't even read it. I entered `cargo run`, it compiled, and it appeared to work as I expected. That's all I can say. (to be fair I meant it as a proof of concept and minium viable product, but still.)