Intro to programming in Odin
prerequisites how do computers work computer memory model representing things with bits
hello world what everything means syntax
statements and expressions declaring variables math operations expressions evaluate to a value
basic variable types int, float, enum
control flow if statements for loops switch statement
basic types 2 struct, array
pointers not as hard as people like to make them out to be The main concern is in considering where and for how long data can be accessed validly. With a well-structured program, many of the common difficulties people have with pointers can be relatively easily avoided. You really do not need to manipulate pointers directly very often if your memory allocations are organized in an intelligent manner. In my opinion, most of the problems that many people have with pointers comes from not having a very firm grasp of how memory works And the issues that they have with pointers are not really issues with pointers per se, they are issues with memory allocation and memory access.
procedures/functions declaration syntax passing parmeters by value, by reference return values
scopes
identifiers must be unique within a scope
data scopes (structs)
blocks, procedures, files, modules
best practices
limit scope as much as possible
prefer explicit parameterization
using libraries and modules importing libraries namespaces APIs sounds more complicated than it is the public-facing functions that a user calls in order to interface with a library basically just an agreement between the user of the library and its author that function signatures remain consistent between versions of a library many libraries like to hide much or all of the implementation, exposing only the outermost layer of functionality to the user directly. While there are good reasons to do this, you probably don't want to get bogged down in worrying about this sort of thing when newly learning to program.
the best way to learn is by doing from here, should be able to continue on to the game programming series would be valuable to use the concepts introduced so far to solve some more trivial problems simple programs taking some user input, processing it, and printing results to the screen as a beginner, it is actually very good to try writing even the most basic functions yourself, instead of using those provided by standard libraries
the language we are using similar to C lots of skills will transfer easier to get a development environment set up offers some modern quality-of-life features
the games we are making pong, zelda, mario
prerequisite knowledge basic programming knowledge
motivation for creating this tutotial
Pong rendering a rectangle moving the rectangle moving a rectangle every update moving the rectangle when the player presses a key collision detection checking if two rectangles are overlapping swept collisions
Zelda tilemaps, tilesheets rendering from an image converting in-game units to rendering (pixel) units programming basic entities
Mario player physics scrolling a camera
Environment Setup Installing Visual Studio required for linking by the Odin compiler Installing Odin adding the compiler to your system path Use whatever text editor you wish If you're coming to this with little or no prior programming experience, I would recommend starting as simple as possible. Use a very simple text editor like NotePad++ If you want to have some syntax highlighting, use VSCode and install the Odin Language Extension. The debugging experience for Odin in VSCode is not very good, but I have yet to require more from the relatively small projects I have built in the language so far. I personally have been using Focus as my primary text editor lately, and using VSCode for casual debugging.
Setting up an IMGUI
This will allow us to fiddle with variables in our game in real time without needing to change the source code or reload values from a configuration file.
Need to replace the SDL2 DLL that is provided with Odin's vendor libraries to a more recent version.
IMGUI needs access to a particular rendering function in order to work.
level design of mario 1 is only decent
Save states allow you to completely disengage from the actual mechanics of the game.
Why does the game have coins? Why does it display a score for you?
If you die, and you have limited lives, then you'll be motivated to explore levels more, break blocks, collect coins, all of the things that actually make the game. If you go for score, you have to learn how to actually control your player with finesse, threading between enemies, getting chains of bounces, lining up enemies on screen to take out with a koopa shell. All of these things have a fun sort of kinetic energy to them, but you miss out on all of that if you use save states because you never felt motivated by death.
He basically only engages with the basic player physics.
The way he describes playing through levels is completely reckless.
Run full speed through the level and try to react to everything in an instant And then with each iteration, getting a bit better
And of course, he can afford to do this because he isn't worried about running out of lives.
I partially blame speedrunning for people engaging with games in this manner.
You're not actually developing a depep understanding of the game, you're just memorizing the bare minimum required to get past whatever stopped you last time. And you're often not even developing an actual strategy for reliably overcoming an obstacle, you are merely brute forcing your way through things, getting past a hammer bro on a lucky break because he didn't throw a hammer this time.
people want to acheive the feeling of mastery without doing the actual work required to become good at something
By contrast to speedrunning, high score attempts actually engage with games ona deeper level
speedrunning prioritizes speed over litereally everything
getting a high score requires you to balance multiple different concerns that factor into this multi-faceted thing called score.
ability to pace oncself and to be consistent is an entirely different thing from simply having the ability to get past an obstacle a single time.
Mario 2
you figure out where the mushroom locations are naturally if you use the potions for their other purpose: finding coins for the roulette But if you never die, you'll never be motivated to figure out wtf is goin on in the game
having no idea what the cherries do for the entirety of the game, just sad goes to show that he was not actaully paying attention to what he was doing
you can fly over the level swith the tanooki suit, but you can also use it to, once again, find secrets that will help you to make it further into the game. Because, once again, you're actually not engaging with the game's design. You've missed it on such a fundamental level that when the game gives you a tool that aids in survival, you're like, what do I need this for? Because you don't feel threatened by slipping up and making a mistake.
In the autoscrollers, he's just sitting around waiting on the screen to move. Most of the autoscrollers in this game are actually very dense.
It's reasonable to stop caring about the star coins because they don't actually serve a gameplay purpose that is extrinsic to themselves.
One fo the things that I will concede is that there definitely was a degradation of the basic mechanics of SMB1 starting with SMW, and then seriously so in the NSMB series It's because death became less of an issue that coins became irrelevant. (NSMB2 is the perfect example) There were certain things that became conventions of a "Mario" game, and those things eventually became hollow and meaningless as the game changed around them.
need to go more in depth on tilemap collision and rendering
show the code for this
What do we store in each tile?
tiles stored in a flat array
map from 2d position of criticla points into the flat 1d array
given the index of the tile, we get the tile id and perform a lookup to get extra info for this tile. We don't want to store a duplicate of the same info in every tile, so using the id like this makes out tilemap much more compact in memory.
When we get to Super Mario Bros, our tile structure is going to contain more than just hte tile ID, since we will need to store information that is specific to each instance of a tile.
get_tile_render_info() This procedure acts as an interface between the tilemap system and the rendering system, to a degree. We can change the criteria that determine how a specific tile gets rendered without needing to change the rendering code itself. When designing an interface between multiple systems, we need to consider what information is required for a particular piece of code to do its job. And that data makes up the interface between those parts. Each of the two separate parts should not have to be directly concerned with how The rendering system should not have to be concerned with exactly how the tilemap system determines what tile render info to pass to the render syustem. As long as the rendering system is taking the information it is given and operating on it properly, it is fulfilling its job. If the rendering system is given bad data byt the tilemap system, then we can fix the tilemap system without needing to change anything about the implementation of the rendering system.
Just as get_tile_render_info acts as an interface for the rendering system, get_tile_info acts as an interface for the gameplay code.
Lead Sheets namesake contain only the bare minimum required in order to play a piece main melody require the one playing to imrovise, add harmony and accompaniment on top
the basic scipts that describe the movement of objects in the level
the music engine analyzes the syntax tree to determine certain musical elements
probably not going to determine the melody, but it could
have yet to decide what exactly how expressions in the syntax tree will map to certain musical elements
define the literal semantic meaning of the level
relevant to randomization
Instruments my pretentious name for the entities in a level are actually associated with an instrument in the music engine most likely interactions with the entity should alter the playing of the corresponding instrument in the music
accompaniment of Instruments and Lead Sheets creates "harmony"
Elements which are composed, vs those which are arranged
need to dig up my musings on primitve vs decorative mechanics and connect those concepts here
also see if I ever wrote anything down about comparing the design processes of soemthing like rain world to a precision platformer like the end is nigh
the composition of a level, or an element of a level is in the crafting of its particular semantic meaning
most games are built around decorative mechanics, arrangements of those mechanics certain arrangements can bring out a different, sort of emergent semantic meaning in the level
but this still feels very different to the way in which primitive mechanics compose with one another
its all sort of a sliding scale, really maybe just a question of orthogonality? some things compose more fully with other things
Extreme examples to help make the difference clear
movement components are very primitive
movement patterns compose basically effortlessly and are infinitely stackable because we can literally just add the offset together but as we add more components of movement, or when those movement components are based on more complex expressions, then movement becomes less intuitive and we need more visual aids in order to track it some functions are not suitable for the movement of objects because they have discontinuities
these are primitively composable because we don't need to define the ways in which each component interacts with another they are based on fundamental mathematical axioms
entities are very non-primitive
we need to code all individual interactions between entities could have some sort of component/attribute system that allows us to more easily define classes of interactions, and then create entities that combine those attributes/interactions in different ways e.g. entity has "on_fire" or "spiky_top" or etc flags that define behaviour. individual interactions must still be defined manually by the programmer/designer so then the entities are made up of more primitive components, but they themselves are not primitive objects within our game
much of the below uses the end is nigh as example
when used well, decorative mechanics can accentuate the primitive mechanics of the game enemies require the player to approach some piece of level geometry in a particular way agon floating over a pit, forcing a low jump or some articulation during the jump provide an excuse for motion only really justify themselves as ferals but the presence of the later permutation probably justifies the presence of the earlier permutation, helps build intuition, not seeing something totally new oftentimes, this can be accomplished using only level geometry, but that is often less interesting hoast, float, slag having things be entities conveys intent, because only living things have intentions and sometimes, the reactive nature of certain entities means their contribution cannot be concisely or intuitively modelled using only the geometry fo the level paraslag you have to do this little fakeout thing in order to get them out of your way like that little thing people do in soccer has this cool aspect of sticking to whatever surface he is on underutilized in the game [note to self: paraslag with angled tilemaps wil be cool, would be good to have ones that operate on a timer rather than reacting to player]
hard to capture intent in level geometry alone
for many types of motion, we don't really need an excuse
we come from a long tradition of moving platforms suspended in the air for no particular reason
but reactivity tends to warrant explanation
thwomps
tein still does this in the machine using gears/eyes in the walls
these are a more generic version of paraslags or thwomps
slag is just a moving spike, literally nothing more to that but it is more aesthetically pleasing
chargers are like slags, but bring in that element of intent speed up when you get on their level, bro (game grumps)
floast and hoast can be replaced with tiles/springs in most situations with minimal to no changes to the semantics of the level basically springs with spikes on the sides, that don't bounce you as high but they justify their inclusion aesthetically, as they provide a believable excuse to have floating/moving springs now the game just has seemingly sentient springs anyhow, but at least in principle, you get the idea...
there is also this thing of how bouncing on an enemy repeatedly requires you to control your jumps and position constantly, and to anticipate coming obstacles more, lining yourself up in both the x and y axes
the gaspers are basically hoasts, but introduce gas the gas is fantastic as a primitive mechanic because it does two very fundamental things at once 1. partition space into areas of safety and areas of danger 2. introduce a time constraint on the player's navigation of the level
prevent player from taking a breather in certain places
creates a flow of tension/relief within a level
maybe talk about celeste design talk thing?
both of these things are things that the base level layout can already accomplish (with 2 but's)
but not statically, usually. the level will require some kind of motion (or, like in celeste, the way in which the player interacts with the environment needs to have this quality built into it)
or, through other mechanics like crumbling blocks
which of course compose with the gas in cool ways
e.g. one time use platform to get out of the gas
but the gas does these two things in a way that is orthogonal to the base layout of the level
the gaspers, like the hoasts or floats are merely an aesthetic excuse to get the semantics we want in a way that is pleasing to the senses games are fundamentally full of this the form of an entity needs to match its function, we wouldn't make a water enemy that shoots fireballs and melts the ground he walks on, would be nonsensical
we already have lone gas clouds, which don't really need much explanation but since gaspers provide a source for the gas, we can have more dynamic gas clouds, meaning the partitioning of space I mentioned above now has this element of changing with time
the idea of how you partition space and all the implications of that limitations imposed on mobility within that space snooker, meta level, taking advantage of the implications of such a simple fact
toast is a bit different, but also hard to design levels around the level geometry then becomes a way of accentuating the movement of the hoast, rather than the other way around levels built for the hoast tend to either have highly generic or highly constrained layouts, very little middle ground in the highly generic ones, probably lots of toasts, player probably is in a very reactive state, has a lot of mobility, trying to navigate a chaotic situation and just get a foothold to get by in the highly specific ones, likely only one or two (maybe more, depends on how intricately the designer can weave together the timing of their jumps to produce something interesting) player's movement is highly constrained because he is focused on guiding the movement of the toasts, one misstep will probably result in a failure state, success depends on memorization, figuring out how to manipulate the hoasts into doing what you want
I'm not a big fan of having failure states for a level in a platformer, especially a precision platformer the player should die immediately upon reaching a failure state so that they can quickly try again these failure states can be ambiguous, player may not know that they needed a certain platform in order to reach the end It is ok to have a failure state which does necessarily kill the player, so long as it is completely unambiguous that such a state is a failure state and that the player can quickly restart e.g. player must conserve breakable blocks for a return route. If they fail to do so on the first try it is immediately obvious what the mistake was and how to correct it just something to be wary of. like all things, need to know the rules before you break them, need to have a good reason to break them
the binding of isaac is full of decorative mechanics synergies don't just happen naturally some do, but most don't in fact, some items can destroy a synergy because it doesn't consider the elemental attributes that your tears have acquired actually has basically no primitive mechanics hence why people use platinum god its just not really that kind of game favors memorization over intuition constant surprise, but never an "aha" moment navigating a complex system of bespoke interactions, based on knowing how to capitalize on opportunity how do you keep a game like this interesting? randomization helps, because it plays on novelty in the same way that finding a new item does even then, eventaually its all just the same thing but in different permutations so just throw more items and enemies on top! not trying to rag on this game, I've spent countless hours playing it is in fact a very fun game but also not very fulfilling, tbh I guess I'd be that steam review that says thumbs down at 6000 hours if anything, like terraria, I'm probably just salty that I didnt spend my time doing something more productive
n++ based on very few mechanics creating as many arrangements of those mechanics as possible but unfortunately those base mechanics are really not that interesting because all of the mechanics other than the player's movement are essentially decorative mechanics subtly different articulations of the same ideas played over and over increases in the amount of technical skill required to beat levels, but levels do not change in the kind of challenges presented definitely quantity over quality very much a speedrunning type of mindset
syntax vs semantics of game design rewatching jon blows talk to refresh for writing on this "semantics is what the player doesnt know before playing the level that they now know after playing it" - or something like that
disagree, but I get the sentiment
may be confusing the semantics of what the level is saying versus how the level is received/interpreted by the player and the meaning that it creates in the player's mind
what is said versus what is communicated? not quite
many ways of saying the same thing but using different words (constant semantics, varied syntax)
many ways of inspiring the same understanding in the second person, by communicating different semantics
I think his understand of the semantics of a thing here are focused on the perspective of the player
what is said versus what is heard? closer...
I would say "what is communicated vs what is understood", but communication I think implies an accordance between what is intended to be understood and what is actually understood
hence why communication must be tailored towards
two people speaking different languages cannot communicate, but that doesn't mean that the words they are speaking do not have meaning (semantics)
maaybe:
syntax : form
semantics : meaning
communication : mutual understanding
I gues this is what people call dynamical meaning or something
this is the most important part of a level and the best levels are created with the intention of creating this type of meaning in the mind of the player
this is all about putting the player in the correct position to come to this meaning on their own
communicated through the constraints placed on the player (level geometry, placement of entities, etc.)
providing a place with some give that the player will naturally press on, leading them down a path to understanding
present the problem, subtle hint towards the solution
hints in the layout of the puzzle itself, builds on previous understanding (context in space, and in time)
designing a game is all about setting up a system with some rules, and then experimenting with the interactions of those rules, and then finding the best way to present the elements of the game in such a way that a player will intuit/understand the same interactions that the designer saw
new understandings are hard to come across
and they may be something too abstract to be generated in the way the Jon proposes, at least withthe current technology that we have in the AI space
not to say that this is not a worthwhile subject of inquiry, just that I don't have any idea how to approach things at that level yet and I think we haven't really even gotten past the syntax barrier yet
communication can really only happen between minds because it is that accordance of understanding that I spoke of above
so i am not convinced that we can even accomplish communication here per se
for example,
if an artist paints a picture, they can communicate ideas to the observer
but I don't think an AI is communicating an idea to the observer of something it generates
it may be inspiring some new understanding in the observer, but I wouldn't say its communicating that understanding.
in either case, what we care about in the game randomization case is that some new understanding is being generated in the player, with relative consistency
new understandings can be "mined" for by procedurally creating new arrangements and compositions
creating these arrangements and compositions from a semantic level first is something I plan to explore further
I am optimistic that this will produce much better results than the typical methods of generating levels
and once again, I'm not really convinced that generating levels semantically has been done before.
I agree with Jon that its' almost always just done at the syntax level, even if we have slightly different conceptions of what that means.
the deeper that a game's mechanics are, the more interesting nuances of an idea can be expressed or understood
I actually anticipate that producing basic compositions that are interesting will be much easier than producing arrangements that properly accentuate those compositions
e.g. we can easily generate tons of movement components that are
for a human, the design process flows from understanding to semantics to syntax
but as an observer, the process flows in the other direction
you can get some really interesting meaning and understanding out of randomized content in some games, but you often have to wade thorugh a lot of crap as well
there also is a balancing act between making things interesting and making things playable, these are often inversely correlated, (TODO: revist notes on tein randomization)
less crap to wade through also means less exceptionally good stuff
like shrinking the width of a bell curve
most players would rather have something relatively decent, but unexceptional in randomization rather than something that covers a wider range of quality but brings in more really cool stuff
a lot of work in the design space of randomization seems to be more oriented towards just moving the center of this bell curve upwards, rather than working to widen the curve (and compensate for that) or to fundamentally rethink the mode of generating new content
good design requires having a very strong idea of what parts of a level are actually core, and what parts are accidental for certain types of games, removing as much of the accidental as possible is part of the process of refinind the game's design but for a platformer, the accidental portions can actually be just as critical to the fun-ness of the game as the core ideas sometimes it is better to give the player some room just to bebop around and enjoy the basic movement, and this is harder to do if every single part of the game is too tightly designed. now, even in these more accidental or loosely-designed sections, we actually have an opportunity to bring in more purposeful design in the sense that we can have more subtle or overlapping ideas going on at the same time. if you are an observant designer, you can actually take certain accidental elements and then orient those towards smaller, emergent purposes maybe there's one little ledge or slope that you recognize as an opportunity to perform a trick, well as the designer, you've got the opportunity to modify the level just a bit to bring out that opportunity further if this is done in subtle enough ways, players may not even assume that such choices were purposeful it's more like stumbling across strangely-shaped stump in the woods and thinking, hey that would make a great chair, not realizing that someone had been there 20 years before, recognized that some potential, and had carved the stump to make it better suited to the purpose
Need to write up pages for more recent projects
It has been sort of a running theme of my projects in Jai to lean heavily on the type info system to do some more dynamic things. But this should definitely not be mistaken for an urge to make Jai more like dynamically typed languages.
I think all of these sort of dynamic features are very useful when kept at the edge, so-to-speak.
Lead Sheets
Lead Sheets are designed to be simple both in usage and implementation.
Like my GON, Data Packer, and Jai-Dyncall modules, Lead Sheets lean heavily on Jai's type info
Dyncall bindings for Jai
Using the Jai bindings generator is very straightforward, and one can use any of the
In addition to the direct bindings, I wanted to provide a much nicer interface to the user.
This is currently still a work in progress because as I have used the bindings more in other projects, I have developed a need to use the library in a more granular way.
But still, the wrapper functions are starting to converge back into a nice, simple interface over time.
Data Packer
Sort of a technical follow-up to my GON parser, in that it is also for parsing and serializing files. However, it's a bit more complex since it works with binary data.
Also leans heavily on Jai's type info.
GON
written several implementations of a GON Parser
The intial version was an in-situ parser which produced a flat array of nodes for each field, object, or array in a file.
The resulting array is sort of a pseudo-DOM which the user can navigate via the size and count attributes on object and array nodes.
While the parser is very fast at producing this initial array of nodes, the user must still parse over the nodes in order to actually extract the data they need.
This is sort of the perenial problem of formats like XML or JSON; even if the initial parsing process of converting text to a DOM representation is very fast, there is still going to be a need for a second step of parsing that pulls information out of the DOM into strongly-typed objects.
And this second stage of parsing is probably much slower and messier than the intial stage.
In the latest version, I've moved back to using a sort of DOM structure, which allows for references between nodes.
The motivation for this came from a desire to be able to better define tile and entity templates for a game I am working on, which require references between instances for certain funcitonality.
While it was certainly possible to work around the limitations of the completely SAX-style parser, it felt worthwhile to just re-implement the parser in such a way that the workarounds would not be necessary.
Certainly, there is still some argument to be made in favor of the SAX-style parser over the DOM-style parser in terms of simplicity and speed, but the DOM-style parser undeniably provides more flexibility.
In the future, I plan to implement some limited expression parsing in the GON format through integration with my Lead Sheets module.
While this may seem yet more extraneous to some, I find it very useful to be able to define certain values off of other values or use simple calculations.
jhtml
HTML templating engine in Jai.
I started this project because I wanted to simply include html from one file into another file directly, and for some reason there does not seem to be a straightforward way to do this in 2024.
This engine allows the user to write Jai code directly into their HTML files. These template files will be loaded during compilation and used to generate Jai code that renders the template.
For now, I am using this as a static site generator.
I have not yet gotten around to writing a server that will actually render and serve these page, but in theory it should not be hard to do.
Autumn Collage
The Autumn Collage attempts to create a new experience for discovering music through visual art.
A collage of icons are presented to the user to select from, and each icon is associated with a hand-picked song recommendation.
Once the user has made their selections, they can explore their music recommendations and listen to previews of each song via Spotify embeds.
This project was written in C/C++, and compiled to Web Assembly with Emscripten.
From a technical perspective, there's not too much going on here. This is a basic SDL application running in your browser.
As Emscripten is currently the easiest way to get this done, that's what I used for my first foray into WASM.
But, I would certainly like to get away from it in the future if possible.
I would have probably used Jai for this project were it not for the fact that Jai cannot currently target 32-bit platforms.
And, as most bowsers do not support 64-bit WASM just yet, this essentially makes Jai WASM a no-go.
Although, I've heard grumblings that perhaps this might change in the near future.
If Jai WASM soon becomes feasible I would definitely consider rewriting this project in the future.
Mooviz
testing ground for using lead sheets for movement components in my game
also want to explore new ways of creating music and visuals through code
Enhancing GON with Lead Sheets
I wanted to be able to write some simple expressions in my data files, and since I've already got this nice little modular scripting language, why not just incorporate that? So I did. It's a bit weird in how parsing trades back and forth between the GON structure and expression parsing, but it works relatively cleanly and keeps the two modules working mostly separately.
The other little piece that was interesting here is how field references were implemented. This is probably also not the cleanest solution, but it is relatively simple.
Basically, before typechecking a node's value expression, I just walk the nodes of the expression and search for the specific prefix operators that are used for field references (&, $ and *), then pull the operand for that operation, which must be an identifier, and look up that identifier as a field path.
I then manually replace the node for the operation with the resolved field reference, and typecheck / evaluate the expression as per usual.
Again, not exaclty elegant, but it is pretty simple.
I could have just used a custom directive, but currently those are syntactically limited to the form #identifier, and I didn't want something so verbose here.
Ideally, we would be able to insert some compile-time operator directly into the script's context as a sort of mix of operator overloading and directives, but I will need to do some internal refactoring in Lead Sheets in order to make that work.
JR Mapper (or, the horrors of corporate programming)
Java refused to compile my program because of a capitalization difference between my filename and the name of the class declared in the file.
Now, when Intellij decided to give me grammar corrections on a comment, I just about lost it. This was the final straw. I do not want my IDE to complain about
The lack of normal enums is an absolute fail. What is the point of a Java enum? seems like it's trying to accomplish some more object oriented way of implementing a lookup table
Java gripes:
no by-value structures, even for extremely simple types
makes initialization much more painful and error-prone, requires a lot of additional null-checking that has no reason to exist.
forced OOP actually makes program structure more convoluted
certain things are simply preference, like where certain pieces of code are lexically located with respect to one another.
for example, in Lead Sheets I have all of my Node structures in one file, and then separate files for parsing, typechecking, and evaluation.
Typechecking and evaluation are both just organized as single procedures typecheck_node() and evaluate_node respectively, which takes the base node type and internally switches on the Node type tag to jump to each subtype's case.
This keeps all of the typechecking code in one place, so that you can see the logic for several different node types on your screen at the same time.
Another benefit of using a switch case here instead of using dynamic dispatch through an overloaded method is that we can have the common case before and after the switch statement, and we don't have to then factor that out to some common preamble/postamble method on the base class, which then needs to be called in all subclasses overridden methods.
in the JR mapper, each node subclass needs to implement its own typecheck and evaluate methods, which means that if I want to make a change to the typechecking which concerns all node types, I need to either find a way to put that logic in the base class or manually copy that logic into every single subclass.
I must assume that the Java-intended design here would be to go with the base class option, but some logic just really does not work in this way.
For example, if I want to conditionally return early from my typechecking method, I can't put that in the base typecheck method since there's now way I can communicate this kind of control flow information back to the derived version of the method.
if (flags.contains(Flags.TYPECHECKED)) return true; ...
Also, while perhaps it is just preference, I find that having all of the typechecking code in one place makes it easier to cross-reference myself on implementation details.
I may think to myself, "how did I go about implicitly casting in this context before?" and then I can just scroll down about half a screen to see where I did that on a different node type, or search within the same buffer.
If I have to switch files all the time, I just tend to feel more lost in my project. It sort of the same feeling as when you walk into a new room and forgot why you came in there, only to remember as soon as you get back to where you were.
Perhaps this is all just a matter of habit and working in an unfamiliar environment, but I don't think it's quite that simple.
or, A story of two Jons (Blow meets Pageau)
An article or video about how the witness points towards the incarnation
I should mention right off the bat that I don't think the game was designed with all of the Christian ideas, which I am about to present, in mind. Of course, I do beleive that these ideas are present in the game or have something of value to contribute to the disucssion around the game.
In the beginning (arche, source, principle)
imposition of structure upon matter meaning is structural
breath of God (energy) hovers over the waters (stochasticity)
In the Orthodox Christian tradition, it is understood that all things are created from the father, through the son, and by the holy spirit. If you're not deeply familiar with the tradition, this may just seem like a somewhat arbitrary statement of dogma. And if that is your inital reaction, I want to challenge you to hear me out and see the real depth of meaning contained in this expression.
It is understood that the Father is source of all things, the ground of being itself, or the great "I am", if you will. The Son then, is the incarnate logos (Logos, being translated alternately as Word or Logic / Reason), eternally begotten of the Father and of the same nature and substance as the Father. While the concept of the Logos in Greek philsophy had long pre-existed Christianity, the Chrisitan theology reinterprets the platonic, impersonal form of the logos as a personal being, and furthermore, asserts that a relationship with this person is the sole bridge connectecting Heaven and Earth.
A relationship is not just something that one has in themselves, intellectually, but something embodied and interpersonal. And one of the fundamental assertions of Christianty, properly understood, is that the rational apprehension of reailty is actually an personal relationship that one has with the very means by which the world is created. This has drastic consequences for how one views that world, its origin and structure, and our place within it.
The structure and themes of The Witness point towards this understanding of reality, through the way it demonstrates both top-down and bottom-up thinking in its puzzles, through the
"The game is about what its like to be in the world" - or something like that, find the real quote
The incarnation is the Christian way of understanding the union and mediation of Heaven and Earth. One can also think about this in terms of the meeting of abstract meaning (or logos, telos) and material reality (pure substance, no intrisic meaning or purpose, particles drifting around aimlessly).
Framed somewhat in terms of scientism vs mysticism at this point in article, don't tip my hand as to the resolution of this tension, just set it up and show both perspectives we will still need to first talk about the notion of attention and how it presumes the whole in the analysis of the parts
Iain McGhilchrist's work is incredibly relevant here. And the structure of the video room also matches up quite precisely to his model of the two hemispheres of the brain. [TODO: I certainly cannot write this section properly until playing the game again and reading the master and his emmisary fully.]
communication requires the involvement of two persons otherwise we only have something like impression / inferrence
I think Blow is still grapplling with this same idea in his talk about the future of game randomization most of the talk is not actually about randomization per se, but spent on explaining how communication happens in games, and how this should be the focus for game designers working on generated content framed somewhat in terms of syntax vs semantics, but I am not sure this distinction is actually the most useful here. (but it makes sense as a goto way of explaining this concept if you are a programmer) Although certainly, this distinction is not irrelevant by any means * connect the above idea to the similar idea in Mattheiu Pageau's "The Language of Creation" where he talks about this in terms of marks on a page vs words vs meaning
As an artist, the most meaningful connection occurs in the form communication between the artist and the viewer. Games have a unique ability to make the viewer a real participant, and to draw him into a real dialogue.
Language as a structure in which meaning and matter cohere Process of integrating marks -> signs -> signified is understanding process of signified -> signs -> marks is something like 'creation' this is the process of speaking, writing, drawing, or creating any kind of art
communication is when these two process are conjoined between two persons because people aren't telepathic and able to directly beam ideas into each other's minds, we have to go through this process of reconstructing meaning from lower, more concrete elements
Talking something over with someone else may bring more clarity or insight about the initial thought because the process of expressing an idea actual gives the idea a sort of 'body' which we can then observe, reintegrate, and judge [link to Jonathan Pageau Genesis talk, specifically the part where he outlines the pattern of creating -> judging. As christ recreates the world, he also is the final judge of creation, and rectifies it.]
when the 'body' or concrete expression fails to express the 'head' one is forced to revise sometimes, the process of expression allows one to see that, by some 'mistake' in expressing the initial idea, they actually arrive at a better understanding of some concept, and revise their initial idea unless one works thorugh the logical extension of some idea, they cannot fully understand it
simply having the initial seed-like form of an idea does not mean actually understanding it as the monadic idea expands/extends itself into some multiplicity, it becomes a more full thing it is not made lesser by its 'emanation', but greater
The greatest things are those which can unfold in this manner generously, giving themselves freely and perpetually downward (kenosis) not by collapsing things together into some undifferentiated oneness (which is a sort of an authoritarian move)
[Could we do a whole aside about the sound of music and the parable of the sower? No, I should just write an article about that separately and simply link to it as a sort of footnote.]
The analogy of creation and communication
There seems to be something to the sort of symmetry between the processes of creation and communication in the process of 'creation', one attempts to find support for some meaning or draw meaning out of some medium. in the process of communication, one attempts to sow the seed of an idea
As humans, we can participate in creation, not ex nihilo, but in a mode of integrating matter towards purpose. We cannot conceive of truly novel ideas to generate new matter, nor can we create wholly new matter with which to construct such truly novel ideas. We can however rearrange the matter we have, attend to the structures of meaning that it represents, and recognize novel ideas out that representation. Likewise, we may be able to iterate on some concept through pure ideation to a degree, but then we will inevitably need to implement the concept and test if it holds up in reality, or if it is too brittle. In this way, human creativity is bounded both from above and below, and man acts as a sort of mediator in the realization of new semantic structures. Human creativity is, in this way, actually less like creation as understood Biblically, that being creation ex nihilo (literally, 'from nothing'), and more like communication. Human creativity is then, a communication between God and man: a dialogue in which man is responsible for continuing the process of creation from within the material world.
[Aside: is math created or discovered?]
One must distinguish mathematical truths from the language of mathematics.
Given some set of axioms, all other things which derive logically from those axioms must already be the case, whether or not we are aware.
I think this reality completely preclude the idea that mathematical truths are themselves somehow created.
However, a much better case can be made that the *language* of mathematics is 'created' (I would prefer the term constructed), but certainly this does not mean that the language of mathematics is in any way arbitrary.
There are very strong, specific constraints on how any such language of mathematics can be constructed, since the semantic structure of the language must correspond to the underlying mathematical truths the language represents.
Furthermore, we can disambiguate the semantics of such a language from the syntax.
In any place that the semantics of some mathematical language diverge from the ground truth of the actual structure of mathematics, the language simply fails to communicate reality.
Syntactically, we have to consider how both syntactic structure and particular lexemes express the semantics of math.
As we've not reached a sort of ontologically lower substrate, we naturally have moire room for variability.
We can express the same semantic structure of some mathematical expression in multiple ways: for example, we can express the addition of two numbers 'a' and 'b' either in prefix `+ a b`, postfix `a b +`, or infix `a + b` notation.
(Certainly one could probably also conceive of other, less intuitive ways of expressing such an operation, but this semantic structure will necessitate the syntactic inclusion of the operator and its operands.)
Much more variability is permissible in the marks we use to represent particular numbers or operators, but again these are not at all arbitrary.
In the most basic numbering systems, the representation of some particular number may literally be that number of lines. (e.g. tally marks)
Tally marks are almost sort of a base 1 numbering system, with some high-level organization into groups of five as a sort of visual aid.
More complex systems of numbering such as Roman numerals introduce new symbols to act as a representation for larger numbers.
Modern numbering systems operate more explicitly on a particular number base N, in which N symbols are used to express the values 0..N-1 at each digit position.
The number base used in particular applications is also not arbitrary, and is based on a variety of factors.
For manual counting, (pun intened) humans gravitated towards base 10. (If humans had seven fingers per hand, we would almost certainly be counting in base 14.)
For meaurement, base 12 or base 16 systems are much more common, due to the greater degree and ease of divisibility in the basic units.
The basic mathematical operators that we are so familiar with are also not arbitrary, and are actually quite beautiful, simple symbols.
The `+` plus sign being a cross signifies the coming together of two things, which is precisely what addition is.
The `-` minus sign is perhaps slightly more obscure to understand if one is not used to thinking symbolically, but I think it is actually quite intuitive as well.
Symbolically, a line is indicative of some demarcation or separation. More specifically, it indicates 'difference'. It is no coincidence that subtraction is also referred to as 'taking the difference between two numbers'.
The `*` or `x` multiplcation symbols contain a similar meaning to the `+` sign, which makes sense given that multiplcation is itself a repetition (or higher-order version) of addition.
(For this reason I tend to prefer the eight-pointed star version of the symbol, as it most clearly expresses this idea of repeated addition.)
The `/` or `%` division symbol is perhaps the most clear symbol. It is again similar to the subtraction symbol as the operation can be understood (albeit perhaps only rudimentarily) as a form of repeated subtraction.
More significantly one will immediately notice that the symbol for division is literally that of dividing one thing from another. [include image of cell division next to the division operator]
(One could try and make the case that our use of base 10 for mathematics is largely arbitrary, but I would strongly contest this!)
Perhaps I should also clarify that when I say these things are not arbitrary, I intend to communicate that they are not unconstrained by external factors.
And those external factors, likewise, are not unconstrained by yet more primitive and unversal truths.
As the player of a game you do the same, getting to be the author of your own actions as you explore the constraints of the world which the designer created. Often, this process feels more like discovery than creation, but in a very cleverly designed game or system, the player may get the opportunity to truly feel as though they have created something totally new. In an even more cleverly designed game, the designer may leave some subtle hint that what the player has created, was in fact intended all along, turning an ecstatic moment of self-expression into an interpersonal connection who saw the same thing the player did, and worked to afford him the possibility.
are the puzzle panels structured to mirror the tree, or is the tree structured on the basis of the puzzle panel? Which is the blueprint for the other? Or, are there constraints which operate in both directions.
[footnote: wheels within wheels]
probably ties more into the whole witness consciousness thing, zen buddhism
"attention creates the world"
attention forms the basis of the processes of creation, understanding, and judgement
science cannot bridge the gap between matter and consciousness, the closest thing to creation ex nihilo that any person can really comprehend is the constant construction of their own inner world If one is to turn their attention away from something in the world, then insofar as his individual epxerience is concrened, that part of the world ceases to exist. (Of course, humans have memory and object permanence, but if you reflect on your own experience for any amount of time you will quickly recognize how incredibly narrow and pointed your conscious experience really is) (there's also some left/right brain points (wide v narrow attention) that would maybe be interesting here, but not sure how relevant they are to the overal point...)
attention is necessarily purpose-driven, requires some notion of telos, which is anathema to our contemporary scientistic worldviews.
but the importance of attention and telos is being rediscovered, and its implications are anything but trivial. Revolutions in AI and biology are occurring right now due to a rediscovery and instrumentation of telos and logos. It's a seismic shift on the level of the invention of software (insert clip of michael levin)
To connect to the issue of randomization, notice that these technologies like AI function by harnessing the enormous levels of natural stochasticity in their respective substrate, yet need to be strongly guided and tuned (iteratively) by constraints imposed from above. AI itself is such an incredible (from a technical standpoint) marriage of evolutionary theory and ancient ideas about logos/telos that if you really understand this duality you should already understand the whole meaning of this article and why I've chosen the Witness as the exemplar but nonetheless I'll expand on the point
Many experienced and talented designers have spoken before about how their games "design themselves".
The process of design starts with a seed of an idea, which contains in itself a wide range of implications or derivations These things are laready true or pre-exist in some sense, but one still needs to discover them
the iteration loop of design is about finding and bringing out / highlighting those things that are the most interesting implications of the original "seed" of the design
A really good game design may consist of many seeds, and then there also emerges a new job of harmonizing the fruits of these seeds one can think of two bonzai trees that are grown together or a garden in which many plants and other elements are composed and arranged together to produce somethign which is greater than the sum of its parts
but to the original point about the design being a process not of creation ex nihilo, but one of attention and refinement in this way the designer acts more as a filter and a judge then as a creator
"everything is a remix" "contraints breed creativity" - maybe connect to mcgilchrist's ideas about the necessity of resistance
one cannot create something completely new, and certainly not without constraint, nor I think, would one want to (as our own nature is derived from the smae principles that have created the entire cosmos, if something entirely new were to be created ex nihilo which operated on entirely foreign principles to our own, it would be utterly inaccesible/incomprehensible to us) (you can experience this on various scales, for example, certain musical genres have very distinct principles that govern (essentially) how melody, harmony, and rhythm are used, as well as the overall song structure and progression. When composing music within a certain genre, you must follow these principles or conventions in order for your audience to 'get' the music. This is not discount the range of expression within a given genre or the blending that happens between 'adjacent' genres, but there is a necessary set of creative constraints here.)
I think a major part of the game's design is about noticing the constraints on very fundamental categories of our perception, as well as drawing connections between these modes of perception. We can recognize a pattern of "high" and "low" in both audio and visual media, and then connect those sense together.
people searching for meaning in places where it simply is not present
"they were channeling their pre-conceptions, they were trapped in a labyrinth of delusion, mining order from chaos"
I wonder at this point if hes just making some point about how it's very human to need to find meaning even though it's not really present in the pure material of the universe. But what the people he descirbes are actually doing in many cases is to try to find secret knowledge by decomposing greater works and viewing them only in isolation. Removing or scrambling context in order to reconstitute what they want to see (very frankensteinian).
Another aspect to this is that often the patterns that people are seeing are, in many cases, actually there. But the problem is that these patterns are too idosyncratic and particular to the work in question, and these patterns do not scale all the way up. In some sense, they are like idols, in that they keep those who attend to these patterns wrapped up in a lesser reality.
So there are two questions here. In one case we have real patterns which people are attending to but which are lesser patterns, which don't correspond to the rest of reality. In the other case, we have people who are decomposing some work and decontextualizing it in order to create their own patterns through a sort of motivated reasoning (or through malice).
I don't think that was really the point he was making there, but anyways, maybe still worth noting the impression.
quote was something like: "it doesnt matter what moves you, what matters is that you are moved" While I can understand this sentiment I do think it carries a bit of a soft universalism that can lead one astray "to the glory of the most high" is critical, and specific. As I mentioned above, it's important that one is not consumed by lower patterns which cut them off from what is most high.
Most of the examples that he gives about people getting carried away with finding meaning where it isn't really there are cases where one is trying to find greater meaning through decomposition. when really, this method only leads to confusion and misunderstanding, it is by the literal meaning of the word, diabolical for example, trying to break things down into smalelr units of meaning, rearrange those to match a preconceived interpretation (sort of prideful) rearranging syntax in an attempt to create new meaning (ex nihilo) But if one wants to understand something more fully, they should strive to understand the parts in terms of the whole.
certainly these people were moved, in that they were motivated very strongly to pursue some ideal, but that ideal was not in alignment with anythign greater instead, that ideal, often very small, was put in the greatest place, given the power to move, and that led to the person's ruin
all things in a great work of art should be ordered towards the highest principle of the work (that is, they should be both symbolic and iconographic) (and, on a meta level, the work should be oriented towards serving the highest principle of all reality)
The way that he talks about things being 'generous' is somewhat like kenosis a giving oneself down, the generous king (this is of course, Christ)
not really related to this article, but the thought occured to me the other day how perfectly symbolic the decapatation of the french revolution is the head of the nation was cut off from the body, it's literally a 1:1 expression of what was going on in the country
look at exhaust anni 6 !!!
Only the actual public content of the website should be present on this repo, and I need to remove everything else I could throw everything else up in a private repo
Implement a css element for some drop-down box sort of thing that can be opened by clicking on particular highlighted bits of text in an article could even insert some of these aside elements automatically based on keywords present on a page the content of the dropdown is itself a template that can be used across multiple pages, so if I want to update my thoughts in one of these little asides, it will be updated across all pages Or, we could even do something like tagging a particular paragraph in one page as an aside that can be referenced from other pages, and the other pages can show that snippet inline, or allow the user to jump to the other article for more context but the idea is really to get something that acts like a sort of hyperlink to add information / context, but does not force the user to navigate to another page
will start with the default metaprogram as a base, and work from there need to really think about how pages will flow through the metaprogam and how we insert page/template rendering procedures
First we generate a raw template which contains the body text of the rendering function and other named code blocks that for now, just get stored into the header at this stage, all we have is a bunch of text
In the second stage, we being actually inserting code that gets compiled and stored back to the header This code can be arbitrary Jai code to an extent, and can influence the final stage of compilation
In the last stage we produce the final template rendering proc using the body text and the precompiled headers By default, all these template rendering procs just get stored into an array, but we will also want to export these template rendering procs into the global namespace so that we can call them from other pages/templates without the need for some wrapper proc
Using code nodes in the header to describe the template's parameters will make it feel much more natural to declare parameters for a template
We will want to still have some struct representing a template call with the parameters attached as Any's, so that we can pass a template with its parameters to another template as a sort of callback
need to copy logic for calling procedure with unknown signature from lead sheets maybe just put that stuff in my dyncall module so that I have access to it from elsewhere
On the third point, perhaps a better proposal would be to change how scope redirections are done entirely. I know there has been some consideration of replacing the syntax of backticking identifiers to indicate a scope modification with something more flexible. My proposal would be to introduce a #scope directive which accepts two code parameters: one for the code to apply the scope redirection to, and one to indicate the code to copy scope from. Here's and example of how that would look:
some_macro :: (body: Code, $code_to_copy_scope_from := #caller_code) #expand {
#scope(, code_to_copy_scope_from);
}
As for the implementation, it would essentially be a simplification of something that is already possible with #insert.
Consider the following case where we have two nested macros, and we want to refer to something from the outermost scope:
main :: () {
foo: int;
macro();
log("foo: %", foo);
}
macro :: () #expand {
other_macro();
}
other_macro :: () #expand {
`foo = 3;
}
This does not work, because the backtick only indicates a scope modificaiton to the direct caller's scope, which in this case is macro, so we get an undefined identifier error on foo.
Using #insert with an explicit scope redirection, we can make this work like so:
main :: () {
foo := 5;
macro();
log("foo: %", foo);
}
macro :: ($code_to_copy_scope_from := #caller_code) #expand {
other_macro(code_to_copy_scope_from);
}
other_macro :: ($code_to_copy_scope_from := #caller_code) #expand {
// This insert is essentially a really verbose way of backticking foo with an explicit target scope.
(#insert,scope(code_to_copy_scope_from) #code foo) = 3;
}
Unfortunately, there is already a Code_Directive_Scope that is used for #scope_file and the like...
Code_Directive_Scope_Redirection :: struct {
#as using base : Code_Node;
kind = .DIRECTIVE_SCOPE_REDIRECTION;
expression: *Code_Node;
scope_redirection: *Code_Node;
resolved_expression: *Code_Node;
}
On the expression level, we could ideally use #scope in a way similar to a cast, but instead of casting some value to a given type, we are casting some code into the proper scope:
other_macro :: ($code_to_copy_scope_from := #caller_code) #expand {
#scope(target_scope, foo) = 5;
}
Where the implementation potentially gets a bit tricky is with declarations. Consider the following example, where we want to declare foo from within the nested maacro rather than just modify it.
The thing about declarations is that the identifier is not a separate node, so we can't trivially introduce some indirection on the AST-level to apply a scope direction to only the identifier of the declaration. In this case, we would have to rescope the entire declaration: