Vacations End
Vacations end
Four Weeks of Acceleration
4 weeks of unbridled vacation time. I am amazed at how far the project has come in so short a time.
At the beginning of the vacation I foresaw months of continued rewriting of old to new note format as well as massive restructuring of the entire vault.
Well, after starting to trust Codex to actually just manage the vault and files directly, my expectations have been blown so far out of the water, that we have basically taken flight.
The project is so strongly managed now that even Claude has almost nothing bad to say about the state and progress of the framework.
Every single day it seems like we still manage to turn a new discovery into even more strength for the framework. A single question from Codex can spark ideas that manifest into a new stronger direction. We have managed to pump lots of safety and security into the inner workings, make the scaffolds for a framework that manages most things automatically as safely and securely as possible, without harassing the devs or admins.
Almost 2,200 Questions
About a week ago we started refining the framework details by having Codex ask questions and we are now almost 2200 questions in. These questions have sparked small and large discussions and reframing along the way, allowing us to formulate better, smarter and faster logic ways for NPC's to think and reason. Hopefully allowing us to let devs just point NPC's in a direction with a simple instruction and they handle all the hard logic surrounding the logistics of making things happen.
One Command, Many Decisions
An example could be a plugin that just gives the base commander of the Soldiers faction a simple command:
"Attack <player's> base"
And the NPC acting as commander at the current time (because all NPC's will be individuals with their own sets of skills and abilities and intelligence and experiences shaping them), will make all the necessary decisions on what will be needed to actually, potentially complete an attack on that base. We wont need to define the amount of soldiers that will be sent, we wont need to define kits or vehicles or anything else. That simple command is all that is needed. The commander will probably rely on their skills and send out a scout to survey the target base, determine defences from observations, determine how many players/defenders there might be. Who are known associates of the owner? What amount of explosives might need to be brought? When should they be brought? How many soldiers should be committed to the attack?
Knowledge Has to Be Earned
The ONLY bit of "non-newtonian physics" that will be exerted here is that the commander will "know" when the owning or residing players are online, so they will not just attack a players base, if they are not online. But all other information is based on what the base commander actually knows through the Rumours and Intel system at the given time; which might require him to send out a scout, if he "feels" like he needs more intel before committing a force to act. This system is designed to limit knowledge, so neither players nor NPC's actually have any information they did not actively learn. However they disseminate and learn this information automatically simply by osmosis (being near other NPC's/players), so noone actively needs to select to exchange information. But they do need to go out into the world to learn something new.
Designing Through Events and Minigames
We also vastly expanded the potential Events and Minigames with more than 120 potentials, not because we intend to actually create all those events or minigames, but because we will need to discuss HOW we could create them, so we can learn what they would be needed of the framework infrastructure in order to actually create them. Because that is how we will prepare the functions that will allow creating inventive minigames and events with much simpler coding than current plugins.
The aim is that devs should just make decisions on what should happen, not have to design all the minutiae of the functionalities that enable the events/games to work. Similarly to the "attack x base".
Interfaces That Build Themselves
The admin menus are also defined to autopopulate the UI's, so when devs create plugins with settings and such, they just need to define the proper metadata to menu attributes/settings, and that basically tells the plugin admin UI what to place where, so the dev doesn't need to worry about creating admin UI or commands. I'm trying to do away with the chat commands and manifest everything Admin related into context dependent ingame menus as well as a more fleshy and powerful webinterface for admins and players.
Compacting the logic
A rather interesting discussion also spawned a concept that might be an even larger speed boost for our framework, that we had not even conceived of earlier. The plugin logic might actually be possible to "mix and match" their code around to make the framework do less work, by analyzing what the plugins do (e.g. by using the desired metadata devs should add), so the types of logic and work they do can be compacted into doing many less runthroughs. If 20 plugins ask for the same types of data for the same players, why do that question 20 times x players when it can be done 1 time x players instead?
Privacy by Framework
Insanity also forced me to think about integrating GDPR into the framework, so players can contest how and where their information is stored and whether it is stored. They will lose functionality, if they dont want the framework to process their data (player Steam ID is also personally identifiable information, so subject to GDPR). And that will be full framework enforced. If a player asks the ADC (our primary central web interface for both admins and players) to have their information purged from all servers they have ever been on, the framework will facilitate that as issuing a case to the local frameworks, but the local admins must review and fulfill the request or provide a lawful reason for retaining specific data, since its local processing remains their legal responsibility.
By facilitating this, the framework allows players to see which servers have not enacted the deletion, so they can contact the relevant server owner directly. Any resulting legal dispute falls outside the frameworkâs responsibility. SteamID ban records are not automatically purged. Bans remain untouched.
Admin Power and Player Evidence
We also had thoughts about admins and their power hungry selves. So the framework will include a case system to handle disputes. But since the framework actually collects and collates a whole lot of activity data, it will actually have gameplay-evidence for why players gets banned and admins need to define, with evidence, why they enforce a ban. Players can protest and cases (if local framework admin allows) can be sent into ADC to let unrelated and randomly chosen other admins act as judges based on the gathered evidence. All identifying data is redacted, so the random admins can judge the case simply on the merits of the evidence and case data.
Local admins can still ignore the case judgment, but at least the player will have this remarked on their case that the local admin chose to go against impartial judgment. Cases are stored "globally" and players have access to their own case data, so they can review what they supposedly did wrong with the framework gathered evidence; not just rely on whatever admin had a bad day and banned them for whatever reason.
Numbers Inside, Language at the Edges
Logging security has been strengthened and made faster by reducing the amount of human readable data processed. Log files may look just like a bunch of coded data, because numbers are faster to process. So log viewers are required for humans to understand what the logs contain, but that is just faster and better for the framework. Basically the entire framework will be built around these design methods. Using ID's and numbers wherever possible. Only at human level interfaces are "translations" needed. So devs can create plugins using "language", but once the plugins are compiled, they will basically just be processing numbers, not strings. An NPC's long ass conversation? Pulled out of the plugin and stored in a file, replaced with just an ID. Allows the processor to just handle "A123" as the conversation, rather than "And I really wanted to tell you this long ass story about how I stubbed my pinky this morning. Let me tell you the ways it hurt!" Now multiply that with the multitudes of other types of strings and text, that will no longer need to be converted or carted around inside the logical processes and processing. They are basically not needed until they egress into the game engine.
A Soundtrack for the Work
I also gave Codex access to Spotify, as my music choices had gone a little stale. I tend to find the same 50 pieces of music, so it is refreshing letting Codex pick out a song now and again, and add it to a playlist it has free reign over.
And finally AI is getting even smarter
I let Codex fix all the missing headlines from my blogs. God, I am really lazy! But Codex is just faster and better at it anyway! I did not let Codex change any wording and it actually double-checked its own work by making a backup, adding the headlines, then removing them again and verifying the result up against the backup! Without me asking it to! AI sure has progressed a lot over just the past half a year!
Half a year ago you would not have seen me letting AI manipulate this project's files directly!
I worked a lot with Gemini through longer periods of time and I constantly had to keep a very short leash on the work it did. That is why I manually copy/pasted all the text we changed between browser to the project files. Codex (ChatGPT) just managed to prove it can be trusted to actually do the work well. It however has been instructed to make backups often, and it does! But they are very rarely needed.