lxdesk

Crawford's work is worthy of study, as is the causation for why he experienced external failure. It embodies the "simulationist" aesthetic of game design: given enough modelled parameters, something emergent and interesting will happen. This was a trend of the 20th century: computers were new and interesting, and simulations did work when you asked them to solve physics problems and plan logistics. Why wouldn't it work for narrative?

But then you play the games, and they're all so opaque. You have no idea what's going on, and the responses to your actions are so hard to grasp. But if you do figure it out, the model usually collapses into a linear, repeatable strategy and the illusion of depth disappears. You can see this happening from the start, with Gossip. Instead of noticing that his game didn't communicate and looking for points of accessibility, he plunged further forward into computer modelling. The failure is one of verisimilitude: The model is similar to a grounded truth on paper, but it's uninteresting to behold because it doesn't lead to a coherent whole. It just reflects the designer's thoughts on "this is how the world should work", which is something that can be found in any comments section.

Often, when Crawford lectured, he would go into evo-psych theories to build his claims: that is, he was confident that the answers he already accepted about the world and society were the correct ones, and the games were a matter of illustration. He was likewise confident that a shooting game would be less thoughtful than a turn-based strategy game because the moment-to-moment decisions were less complex, and the goal should be to portray completeness in the details.

I think he's aware of some of this, but he's a stubborn guy.

I would put it into these three categories:

1. Assembly coding within a REPL. Forth supports "load-and-store" without the additional bookkeeping steps of assembly. Once the program works, it can be incrementally rewritten into the assembly if needed, or used to bootstrap something else. Historically this is probably the single biggest usage, because the language works as a blunt instrument for that within the standard wordsets. Lots of programs on the early micros shipped with code that was developed with Forth, but with the Forth interpreter discarded at the last step; and where there is novel hardware and novel applications, Forth tends to come up as the bootstrap.

2. Minimal-dependencies coding. For the same reason that it's a good bootstrapping tool, Forth ends up being portable by assuming nothing. While different Forth systems are all subtly incompatible, the runtime model is small enough to wrangle into doing what you want. Stack machine VMs basically are "Forth with more sandbox and less human-readability".

3. "Big ideas" coding. The "human-readable stack machine" aspect means it's a useful substrate for language design - being programmable, you can shift the imperative interpreter model in the direction of new syntax and new general-purpose data structures, while still retaining a way to drop all the way down to assembly - the biggest downside is that this doesn't let you easily introduce existing library code, so bootstrapping from within Forth would take a long time and you would most likely get stuck on trivial string processing. But Forth as the second of a two-step process where you "compile to Forth" using something more batteries-included is actually pretty reasonable as an alternative to generating a binary or designing an original VM.

You don't even have to look to geopolitical analogies. It's an everyday thing, all the way down to basic "exclusive club" gatekeeping.

There's a longstanding tendency across financial systems historically to use the law to bar access to the "real" products for various reasons that happen to favor the incumbent elite. Instead, if you get any access, it's the version mediated by a middleman of some kind. There is often a rationalization in play, but the effective control over societal outcomes is the same.

Want to found a disruptive company in 16th century Europe? You had better have a royal charter.

Maybe it's the 19th century and you have a great invention: "Patent fees for England alone amounted to £100-£120 ($585) or approximately four times per capita income in 1860." [0]

You're a laborer in 1900, and you've pooled a little nest egg you want to use to trade stocks? You can't afford the real stuff, so you will have to play in a bucket shop.

You're a middle-class Black person in the 1950's US and you want to own a home or start a business? Redlining ensures that you won't get a good deal or your neighborhood of choice, neither will you get a loan from the major banks(at least, not one on reasonable terms).

And so I have to conclude that the whole basis of the debt system is always subject to some form of gatekeeping, at some point, and that's what has drawn people back to precious metal exchange over centuries, despite its limits. We've been through a long period where debt worked really well, because our economies experienced industrial growth patterns and could coexist within a stable framework(some world wars and interventions notwithstanding). That does not mean it's better or forever.

The same kind of framework is in the process of being enforced in cryptocurrency; cypherpunk-friendly privacy coins that have some adherence to Bitcoin's original spirit like Monero or ZCash have been delisted from most exchanges through regulatory pressure, while defanged "blockchain economy" tokens have stones-throw availability and heavy promotion. Meanwhile a substantial number of token exchange services will play games with your ability to withdraw to keys you own.

But I think that's going to be about as hopeless an endeavor as stopping music piracy was; it's abundantly clear that we're headed towards a long term trend of breakdown in "trust me" debt economies and their model of operation, even if some of the leaks get plugged in the near term in the way that Spotify "solved" piracy[1]; what "trust me" now results in at Internet scale is increasingly sophisticated ransomware hacking. So, while debt and lending itself could still exist and be a rewarding venture, tokens lacking credible mechanisms to back their fundamental value and consensus are going to wash out.

(I also think the El Salvador plan is a stunt - a way of marketing the country with a side of personal benefit - albeit one that could become consequential in surprising, unpredictable ways, in the way Bitcoin has been generally.)

[0] https://eh.net/encyclopedia/an-economic-history-of-patent-in... [1] https://www.digitalmusicnews.com/2018/03/22/music-piracy-spo...

What he calls "world construction" involves the development of a rubric custom to the problem.

This creates a faster feedback loop inside of the larger, noisier one. Your feedback is now guided around the question of "what makes the rubric itself better?" This can be done on principle, with limited access to external information. Philosophical thinking is eminently suited to this style of problem, but it can be supplemented with short-term empirical studies that add some falsifying points and narrow your cone of uncertainty.

At the end you've generated a list of yes/no questions forming the rubric of whether the course of action is likely to succeed. It can be turned into a ranking score, or a pass-fail threshold.

If you're frustrated by the idea of just making it up on principle, that's a frustration with philosophy itself; it rarely "works" until you accept some pragmatic premises around what is "good" or "true". The point of having a large number of questions, using a wide variety of perspectives, is that they test the overall coherency of the premise. Something can work fine from one perspective, and then completely fail in another. When that happens, it's a good sign that you have more to improve.

It's quite an important life skill to practice. It's easy to go along with the crowd, but this is a way of breaking away from it.

Sounds like you may be getting close to an ideal result, at least for this project! :) Nice on the use of SQLite - I agree that it's right in the ballpark of usability if you're just occasionally editing or doing simple turn-taking.

When you create gameplay tests, one of the major limitations is in testing data. Many games end up with "playground" levels that validate the major game mechanics because they have no easier way of specifying what is, in essence, a data bug like "jump height is too short to cross gap". Now, of course you can engineer some kind of test, but it starts to become either a reiteration of the data (useless) or an AI programming problem that could be inverted into "give me the set of values that have solutions fitting these constraints" (which then isn't really a "test" but a redefinition of the medium, in the same way that a procedural level is a "solution" for a valid level).

It's this latter point that forms the basis of many of the "little languages". If you hardcode the constraints, then more of the data resides in a sweet spot by default and the runtime is dealing with less generality, so it also becomes easier to validate. One of my favorite examples of this is the light style language in Quake 1: https://quakewiki.org/wiki/lightstyle

It's just a short character string that sequences some brightness changes in a linear scale at a fixed rate. So it's "data," but it's not data encoded in something bulky like a bunch of floating point values. It's of precisely the granularity demanded by the problem, and much easier to edit as a result.

A short step up from that is something like MML: https://en.wikipedia.org/wiki/Music_Macro_Language - now there is a mostly-trivial parsing step involved, but again, it's "to the point" - it assumes features around scale and rhythm that allow it to be compact. You can actually do better than MML by encoding an assumption of "playing in key" and "key change" - then you can barf nearly any sequence of scale degrees into the keyboard and it'll be inoffensive, if not great music. Likewise, you could define rhythm in terms of rhythmic textures over time - sparse, held, arpeggiated, etc. - and so not really have to define the music note by note, making it easy to add new arrangements.

With AI, a similar thing can apply - define a tighter structure and the simpler thing falls out. A lot of game AI FSMs will follow a general pattern of "run this sequenced behavior unless something of a higher priority interrupts it". So encode the sequence, then hardcode the interruption modes, then figure out if they need to be parameterized into e.g. multiple sequences, if they need to retain a memory scratchpad and resume, etc. A lot of the headache of generalizing AI is in discovering needs for new scratchpads, if just to do something like a cooldown timer on a behavior or to retain a target destination. It means that your memory allocation per entity is dependent on how smart they have to be, which depends on the AI's program. It's not so bad if you are in something as dynamic as a Lisp, but problematic in the typical usages of ECS where part of the point is to systematize memory allocation.

With painting what you're looking for is a structuring metaphor for classes of images. Most systems of illustration have structuring metaphors of some kind specifically for defining proportions - they start with simple ratios and primitive shapes, and then use those as the construction lines for more detailed elements which subdivide the shapes again with another set of ratios. This is the conceptual basis of the common "6-8 heads of height" tip used in figure drawing - and there are systems of figure drawing which get really specific about what shapes to draw and how. If I encode such a system, I therefore have a method of automatic illustration that starts not with the actual "drawing" of anything, but with a proportion specification creating construction lines, which are then an input to a styling system that defines how to connect the lines or superimpose other shapes. Something I've been experimenting with to get those lines is a system that works by interpolation of coordinate transforms that aggregate a Cartesian and polar system together - e.g. I want to say "interpolate along this Cartesian grid, after it's been rotated 45 degrees". It can also perform interpolation between two entirely different coordinate systems(e.g. the same grid at two different scales). I haven't touched it in a while, but it generates interesting abstract animations, and I have a vision for turning that into a system for specifying character mannequins, textures, etc. Right now it's too complex to be a good one-liner system, but I could get there by building tighter abstractions on it in the same way as the music system.

My main thing this year has been a binary format that lets me break away from text encodings as the base medium, and instead have more precise, richer data types as the base cell type. This has gone through a lot of iteration to test various things I might want to encode and forms I could encode them in. The key thing I've hit on is to encode with a lot of "slack" in the system - each "cell" of data is 16 bytes; half of that is a header that contains information about how to render it, its ID in a listing of user named types, bitflags defined by the type, a "feature" value(an enumeration defined by the type), and a version field which could be used for various editing features. The other half is a value, which could be a 64-bit value, 8 bytes, a string fragment, etc. - the rendering information field indicates what it is in those general terms, but the definite meaning is named by the user type. The goal is to use this as a groundwork to define the little languages further - rather than relying on "just text" and sophisticated parsing, the parse is trivialized by being able to define richer symbols - and then I can provide more sophisticated editing and visualization more easily. Of course, I'm placing a bet on either having an general-purpose editor for it that's worthwhile, or being able to define custom editors that trivialize editing, neither of which might pan out; there's a case for either "just text" or "just spreadsheets" still beating my system. But I'd like to try it, since I think this way of structuring the bits is likely to be more long-run sustainable.

I've gone down roads similar to this. Long story short - the architecture solves for a lower priority class of problem, w/r to games, so it doesn't pay a great dividend, and you add a combination of boilerplate and dynamism that slows down development.

Your top issue in the runtime game loop is always with concurrency and synchronization logic - e.g. A spawns before B, if A's hitbox overlaps with B, is the first frame that a collision event occurs the frame of spawning or one frame after? That's the kind of issue that is hard to catch, occurs not often, and often has some kind of catastrophic impact if handled wrongly. But the actual effect of the event is usually a one-liner like "set a stun timer" - there is nothing to test with respect to the event itself! The perceived behavior is intimately coupled to when its processing occurs and when the effects are "felt" elsewhere in the loop - everything's tied to some kind of clock, whether it's the CPU clock, the rendered frame, turn-taking, or an abstracted timer. These kinds of bugs are a matter of bad specification, rather than bad implementation, so they resist automated testing mightily.

The most straightforward solution is, failing pure functions, to write more inline code(there is a John Carmack posting on inline code that I often use as a reference point). Enforce a static order of events as often as possible. Then debugging is always a matter of "does A happen before B?" It's there in the source code, and you don't need tooling to spot the issue.

The other part of this is, how do you load and initialize the scene? And that's a data problem that does call for more complex dependency management - but again, most games will aim to solve it statically in the build process of the game's assets, and reduce the amount of game state being serialized to save games, reducing the complexity surface of everything related to saves(versioning, corruption, etc). With a roguelike there is more of an impetus to build a lot of dynamic assets(dungeon maps, item placements etc.) which leads to a larger serialization footprint. But ultimately the focus of all of this is on getting the data to a place where you can bring it back up and run queries on it, and that's the kind of thing where you could theoretically use SQLite and have a very flexible runtime data model with a robust query system - but fully exploiting it wouldn't have the level of performance that's expected for a game.

Now, where can your system make sense? Where the game loop is actually dynamic in its function - i.e. modding APIs. But this tends to be a thing you approach gradually and grudgingly, because modders aren't any better at solving concurrency bugs and they are less incentivized to play nice with other mods, so they will always default to hacking in something that stomps the state, creating intermittent race conditions. So in practice you are likely to just have specific feature points where an API can exist(e.g. add a new "on hit" behavior that conditionally changes the one-liner), and those might impose some generalized concurrency logic.

The other thing that might help is to have a language that actually understands that you want to do this decoupling and has the tooling built in to do constraint logic programming and enforce the "musts" and "cannots" at source level. I don't know of a language that really addresses this well for the use case of game loops - it entails having a whole general-purpose language already and then also this other feature. Big project.

I've been taking the approach instead of aiming to develop "little languages" that compose well for certain kinds of features - e.g. instead of programming a finite state machine by hand for each type of NPC, devise a subcategory of state machines that I could describe as a one-liner, with chunks of fixed-function behavior and a bit of programmability. Instead of a universal graphics system, have various programmable painter systems that can manipulate cursors or selections to describe an image. The concurrency stays mostly static, but the little languages drive the dynamic behavior, and because they are small, they are easy to provide some tooling for.

Implement a MIDI 1.0 sequencer and get it to play back SMF files with a sine wave synth - you can have it output a WAV file, or learn an API to do realtime rendering. It's not a large spec, there are lots of old documents on how the protocol functions in practice, and then once you start getting it working you'll get results instantly(lots of SMF files around to test with) but will want more features, better synthesis; complications start to arise and you will then pick up a lot of knowledge by doing.

Here's an example: Cash decentralizes credit.

"Cash and carry" grocery outlets were a 20th century innovation. [0] Before that, the norm was to have a line of credit with the business, and in many cases, to accept their terms for delivery. Cash transactions anonymize, since settlement is done at the counter. You don't have to assess the buyer, you just need to verify the bills and change are real.

However, that isn't the entire story. While there were businesses using cash before this, they faced difficulties with accounting, supply logistics, and other elements that made it hard to conceive of something like a "supermarket", carrying a vast variety and quantity of goods on a daily basis. So then we have to look at all the pieces that fell into place to make it possible.

The automobile decentralized access to mobility, making carry-away a real possibility for more people, and thus making it possible to apply cash-and-carry in more places. Supporting elements like cash registers and refrigeration were becoming mature enough to support new forms of retail and allow more parts of the transaction to be delegated to local outlets and low-wage employees. The inter-war years really saw a whole set of technological innovations that were used in combinations to propel social changes and different categories of business(e.g. fast food), many of them decentralized in some respects but centralized in others - supermarket chains, as opposed to local markets.

These are the kinds of changes that are hardest to assess in full; when you decentralize one thing, centralization is "squeezed" into other parts of the economy, it seems. The obvious example for this phenomenon is Amazon, leveraging an apparently decentralizing mechanism(online retail - premised on an internet with sufficient bandwidth and security to list goods and take payments) into becoming the world's largest retailer. So it's centralized on one axis, but decentralized on others - a buyer no longer has to go to a particular physical location to purchase something, when all of it can be delivered to the doorstep.

[0] https://en.wikipedia.org/wiki/Cash_and_carry_(wholesale)

I think the probable reversal of the cycle is:

1. Towns revise their taxation and zoning laws so that more classes of business are permitted in residences. They also start issuing more forms of local credit(the technical means to do so are only getting better), excluding big-box participation and restarting the cycle of capital accumulation locally.

2. Costs are lower and incentives are now aligned for more small businesses to survive in marginal areas.

3. Big-box stores increasingly become commodified and unbundled, themselves; the shift from Main Street to Wal-Mart to Amazon is one of the warehouse turning into a store and then back into a warehouse. The services of shipping logistics and delivery become less of a centralized process. Now the local businesses are using the big-box to their benefit.

The reason why Wal-Mart succeeds is ultimately premised on policies that let capital centralize itself according to a national and global framework. But that's only one way of "seeing" the economy, since following that policy, as we know, creates a mix of expensive star cities and dying no-hope towns. It's improbable that the future will simply be a restatement of the post-1970 trends, given what we know about history - something will change.

Use value is easy to assign to an NFT post-facto. That hasn't been really done in the current market(which is, of course, in the midst of a bubble), but:

* Tokens can become tickets to events

* Tokens can become options on commissioned work

* Tokens can become signs of membership

Because the token is guaranteed to be unique, and you can track ownership, there's a fluidity to this that lets you do away with contractual mechanisms. You can reuse the same tokens many times or announce that it will expire(for your use case).

Edit: And platforms can't really own it if it's on a public chain, too. You just copy the chain(see: BinancePunks copying CryptoPunks). So there's that.

Speculation is enabling to non-coercive frameworks. If I say a token has a use value that I will use to supply goods and services, you may want to acquire that token. If I can also control issuance and supply of that token, then, short of direct threats of violence or enslavement, you must negotiate with me or with a marketplace.

Most of the ill in the world has something to do with gatekeeping replacing speculative activity.

Godot doesn't expose inheritance to scripting AFAIK; it's strictly a convenience used internally to describe the core nodes. When you script Godot to make complex entities, it's through composition of arbitrary nodes in arbitrary hierarchies, often encapsulated as scenes. References are mostly done by relative path, and the scripting language has sugar to make this a convenient process.

So, yeah, try it. It's the best system I've encountered for the general-purpose use-case, and I've designed a fair few myself.

It's a fantasy to think that authoritarian governments actually succeed at this. Every one of them ends up with an underground market despite tremendous repression. Even literal prisons have one. At best, such governments have flare-ups of the condition where they murder in great numbers for a time to send everyone into terror, but in time they tire of it and calm down. The market pops right back up like a weed.

The analogy you should be looking at is the printing press, because it broadened the scope of such markets; what a person of higher literacy communicates is illegible to the lower. And such is true of a system of account that renders a larger scope of transactions illegible. The possession of great wealth itself is a concept that assumes a top-down vision of value; the phenomenon of being robbed for cryptocurrency is mostly reflective of the new being imitative of the old. But if they're all tokens, and anyone can make them - well, then, that means we increasingly don't have a man at the top. If the scrip you pay your police doesn't buy them anything at the market, they aren't going to be very motivated to take out fingernails for you.

If VS Code is an endpoint to incremental improvements in text editing, then the next big thing that appears will involve a revolutionary approach.

The kind of issue I see this thread getting at is what I call the "terrarium problem", which is, to make a whole software ecosystem like a language environment or API mechanisms bounded by a standard, one has to build a sufficiently large terrarium for it and maintain that. The largest, most flexible terrariums we use as developers tend to be operating system standards, browser standards, Internet protocols, etc.; in the case of Forth it's defined by the bootstrapping process, since the bootstrapping code can present a Forth that is near the hardware, or one that is embedded alongside another language environment like Lua. It is even relatively straightforward to have a Forth that generates Lua source code, which the Lua interpreter can then apply its own checks to and evaluate efficiently.

Extensibility by itself doesn't solve the terrarium problem because it doesn't define any standard, so there isn't anything to build on. When presented with extensibility, you still build the terrarium, it's just a customized one, and if you do it ground-up like Forth, you can potentially build it smaller and simpler. But in the end you still have a terrarium with assumed boundaries.

This has led me away from Forth-the-language in the last few months to explore the terrarium problem further, and I hit on the idea of treating this as an organizational issue solved at the level of the core UX. If the problem is defining boundaries in software, we should have better ways of doing that. At first I considered this in terms of selection - selection being one of the pillars of structured programming, and many of our improvements taking the form of easier selection metaphors. This gradually led me to explore the idea of document editing with a binder and sticky notes metaphor, with a supplemental compiler process taking the resulting complex, layered documents and processing them into a linear form for consumption. The presumption is that if I present a rich set of tools for defining types of divisions and groupings defined skeumorphically - pages, bins, tape, wire, guides, stickies, overlays - and then add a bit of labelling and indirection on top, a powerful "thinking tool" should emerge where the organization is easy and the compilation system makes it easy to query and traverse it in a customized way.

If I can finish designing it.

To me stoicism is helpful in the sense of the advice one gets in jujitsu: If taking one grip on something isn't getting you the leverage you want, don't grip it harder, let go and take a different grip.

Stoicism can't help if you're just getting traumatized, but a lot of "I feel awful about the world generally" sentiment boils down to having a tense grip on one's worldview, a rigid set of norms leading to the judgment that it is all wrong and terrible and thus to a kind of flagellatory self-harm. Nature as a whole, on the other hand, is indifferent - the "is" instead of the "ought". We learn many oughts when we're young, but they all deserve examination.

I can see one avenue in which GPT-3 might be quite disruptive, and that is in reinventing our software development processes. For example, if it can be purposed into something that reliably converts source code between programming languages, then there is no longer any moat in library code and bindings beyond the prompt development; PL development will accordingly accelerate. And the same goes for tasks like developing tests, static checks, optimizations, user interfaces, import/export and so forth.

In this scenario, software itself commoditizes to a greater degree. Perhaps not to the point where the AI is a Star Trek computer, but transitionally towards that. And that means that software businesses increasingly become commission shops that pump out AI-built programs on demand, while software services built on platform lock-in get threatened by cheap data export and format conversion tools.

Most of stress injury derives from the "time under tension" component which is not necessarily a matter of key travel distance. In this case it's a combination of switch mechanism and keycaps. Flat and light keycaps have less force at rest than tall, heavy keycaps. A higher resting force means the needed activation force is lower. In both cases, the switch is governing how much force is needed in total, and whether there's a "tactile bump" indicating activation before the switch bottoms out completely.

When the switch bottoms out, it's like your fingers have hit a wall: this is the norm with most membrane switch designs, and with linear mechanical switches, which are usually light. With tactile and clicky switches, the concept is to reduce bottoming out by indicating the activation with heavier force partway through the downstroke. A pairing of heavy keycaps and heavy tactile switches is often considered satisfying for typists because then the heft of the switch has been balanced out; a light tap will fling the key down past the tactile bump and spring it up without the same degree of muscle activation as a linear switch. And it is possible to have "too heavy" keycaps for the switch, which simply won't work(always activated).

With the key height, as well, what will matter is tension at rest, which will depend on overall posture. In theory you move the keyboard down if the keys are taller.

Neat fact: I learned the other week that this exact format(first, last, number of characters in between) is how old Forths compressed the word encoding. It has a very low collision rate.

Networked games touch on a number of general challenges with distributed computation:

1 Logical clocks used for synchronization. The clocks aren't literally synchronized, but the events taking place across multiple clocks(at least one per connection, and maybe more if concurrency within the client is accounted for) are all logged to an eventually-consistent timeline. How that consistency is enforced is where the trade-offs come in.

2. The closer the featureset resembles shared memory, the worse the experience is. Item duplication bugs were a common occurrence for so long because they express shared memory ownership in a fairly direct manifestation, and it takes a few roundtrips to verify ownership. Saying "I shot you", in contrast, is just sending a message, and can usually coexist with other messages.

3. Consensus algorithms that are governed by nominally human inputs and perceptions. Input manipulation and ESP tools are typical entry points for cheating. When we say "you cheated at this game", we're talking about an attack on consensus.

The thing that I think more could be done of is to ignore the notion of really playing "simultaneously", since we're already using logical clocks, and to focus instead on performance capture and reproduction with AI. The thing that we want out of the experience, generally, is better signal-to-noise, and that isn't had just by lowering the ping times and exhaustively tracking all the data, but by distilling player behavior into pertinent factors and then recreating them in approximation. We're already doing it, but our expectations force the reconstruction to stay close to real-time, which means consensus is constantly being disrupted by anomalous behaviors.

If we looked instead towards trying to create a bot that can accurately match each player's observed unique playstyle, it becomes easier to make "dream matches" that provide a rich signal for players of all types and skill levels. But current bots never throw that much effort into quality, hence their poor reputation as computer opponents persists.

Let's put it this way. Trans people are researching the topic of sex and gender through active self-experimentation. They are claiming empiricism, and their direct experience makes them credible experts. They have produced facts backing their empirical claims, and certain of these claims are further backed up by other sources. You are wandering in, denying both facts and expertise and treating it as if it were crackpot theory, a simple matter of "believe whatever you want".

Now, denial of a factual argument is not hate in and of itself, but denying it on the premise of assigning no credit to the messenger, cherry-picking the weakest arguments and calling it "relativism" can be hateful, because it is indicative of a reality that is actively impeding the investigation of truth.

I say, go back to basics - literally. There are still many "games BASIC" languages around. Some are attached to or reproduce retrocomputing environments like QB64, FreeBASIC and BASIC8(plus a plethora of modern BASICs that target old platforms, like Altirra BASIC, BasiEgaXorz, batari Basic), some are pretty modernized like Cerberus X and AOZ Studio. The thing they all have in common is that they get the tooling and deployment challenges out of the way pretty quickly, and they abstract out enough functionality into APIs that you can start doing flashy things quickly.

For writing a GUI app, look to Python and TK or wx. Those are not too awful to get started with(well, TK particularly, wx is cluttered with boilerplate). Or for a form-editor approach, Lazarus - the current open-source successor to the Pascal lineage.

ECS is useful for real-time, but it means that you are rolling your own query logic. This is fine for the runtime of game engines because they generally aren't dealing with that many data types(for the very most complex AAA games, perhaps a few hundred components) and the queries used at runtime are simple and tend to demand optimization at the data structure level.

If your purpose is an editing tool you may want to reconsider. Editing changes the goal in a very substantial way and the complexity of your queries goes way up, which is where SQL syntax absolutely shines.

That conflates the use of the schema with the use of the format features. You can, in fact, use your custom in-memory structures and then "slurp it out" to BLOB when you're ready to save.

Data mining is an old gamedev worry. Nobody who's been doing it for a while particularly cares. If the game is remotely popular, data mining will happen. Disassembly to find the decrypt function is a talent possessed by many, many people who have the reverse-engineering bug. If you then obfuscate the code, you have made things interesting and then increasingly talented people will try to have a go at it. If you combine a changing obfuscating technique with updates, you can slow down community possession of the game with respect to modding etc., and Minecraft worked that way in its beta phases. But it's really all a question of your purpose at that point.

If you haven't already, I suggest cruising through TCRF: https://tcrf.net/The_Cutting_Room_Floor

You need an idea to pursue. The idea cannot be a simple myth about changing the world in some way, it has to be somehow more intrinsically engaging to you.

Studying some philosophy can help - not for getting the idea, but for usefully evaluating it after you get it.

Personal work goes into a sync folder organized by year.

References are organized by media type, then by general subject, then (usually) by author. I mark up filenames with tags so that I have some options for tracking down stuff with file search.

When I want to collect references for a project they get copied out.

What I've noticed is that the organization ought to reflect the mind, and the mind doesn't run on Internet Time. You probably aren't a professional librarian archiving the whole world's knowledge, but rather a person who is using curation to say "this is what I like" and create a quick-access space for self-exploration. If you go too general in your organizational patterns, if you archive too much or archive unseen works, you won't use it. You might as well run off to a search engine in that case. So it has to be more of a gradual-phases accumulation.

The most recent change is that I started copying more, because I'm aiming not to data-hoard and with current capacities it's hard to fill up the drive with references without falling into hoarding.

I've come to believe that the confounding factors in whether dietary ideas "work" are micronutrients and the gut biome, and these are still really unexplored areas of medicine.

If you have a deficiency of, say, magnesium - that won't be fixed by eating more meat or less sugar, but it might give you strange cravings or bad moods. And if you have a gut that is working inefficiently, it might not adapt well to a high fat diet. And this translates into "bad and good diets", because eating differently reduces the symptoms.

But if your body is generally taking in things efficiently, its macronutrient requirements are going to be mostly proportional to your energy use, and then you can have relatively more protein or relatively more carbs without many ill effects.

So IMHO a decent starting place for dietary change is not really diet itself, but to take a multivitamin, start intermittent fasting, and to get some daily light, full-body exercise. These things start up the flywheel of reducing ongoing deficiencies and increasing selective pressure on the gut.

I think I understand this one. I would restate it as "Powerful static type systems usually encode more constraints than you can easily reason about." And that's good(it catches your errors) and bad(you start to fight the compiler instead of solving the problem).

With simpler, more gradual designs like what are in Typescript or Haxe or even static, native-code languages like D, you have more escape hatches available, so you can iterate on the specification a few times and get code running quickly but also aim to make it tighter over time.

1. Do not set a goal that involves conquering the world, saving the world, or attaining personal glory. These goals have internal contradictions that will lead you away from doing good work.

2. Find a theme and follow the theme to set the goal. This can come from your personal philosophy and inclinations, from something you observe in nature, or by remixing an existing idea.

3. To help find the theme, keep a diary and try to build up a personal library of references. (Do not try to hoard data. Do tight curation.)