Location: California
Remote: Yes, Remote Only
Willing to relocate: No
Technologies: Web, 3D, Games. JS/TS, C#, Python, Node, Postgres, React/Vue/Angular, ThreeJS/BabylonJS, Unity, HSLS/WebGL/WGSL, AI Integration
Resume: https://docs.google.com/document/d/14VdFEF3q0-HbXYHUkEgjC0DX...
Email: wolff (dot) corey (at) gmail (dot) com
Profile: I'm a full-stack web and game developer with over a decade of experience. I've had roles with every part of web and games. My particular interest is unique web based interactions. I also started with AI by building my own poor man's version of AlphaGo back in like 2020 and have been using AI since.
My current project is a web based raymarching game engine / artist tool: https://jesterswilde.dev/rmfw (requires webgpu, desktop only.)
I feel like part of the difference is how art vs code is viewed. You could make the argument code is art, though most don't have that stance. Visual art and music tend to be made by a few people, there is ego involved, you care who the artist is. Code tends to be made by shops and consumers don't know who the coders are. Programmers are already faceless.
I think it's also about money. Places code and code samples are stored tend to be large companies that are in tech and on the AI hype wagon. Bandcamp is not one of those places.
I'm working on a web-based raymarching renderer. I'm hoping to use it to make silly web interactives. It's still early days but it can be found here: https://jesterswilde.dev/rmfw
In it, the author contrasts 无 (Wú) and 有 (Yǒu). For some extra context of that specific contrast, here are a couple excerpts from the first poem of the Dao De Jing. (spacing is mine)
无 名天地之始
有 名万物之母
---
故 常无欲，以观其妙
... 常有欲，以观其徼。
---
The duality of 'with' and 'without', existence / non-existence is central and embodied heavily by those 2 words.
I am (slowly) trying to learn Chinese by reading the Dao, or possibly the other way around. I ran across this site (which I have 0 affiliation with) but it seems to be a small and unique site made by someone who just wanted it to exist, which very HN: https://dao-de-jing.com/
I'm a senior full-stack web and game developer with over 10 years of professional experience. I love building things from the ground up and products that have lots of user interaction (I can't wait for more webGPU adoption). If you've got a big nebulous idea and you want someone to turn it into a concrete piece of code, I'm your dev.
A lot of the style of images this creates are similar to Cellular Automata. Especially when you have a piece of information move diagonally across the screen.
Chess and Go are very different in that one is for points and the other is for annihilation. However, Go solved the draw (and first player advantage) with 'komi'. Giving white (the second player) some extra points, I think it's usually around 6.5 points right now. The amount that komi should be is still up for debate and changing, though I think everyone agrees the half portion is good.
Though stronger players can no longer give 'presents', where you force a draw on a weaker opponent by ensuring both players end up with the same amount of points.
Is there amendment to chess that could work similarly? Nothing is coming to mind, but Chess is not my domain.
Actually komi in go solves the problem that black won nearly all the even games between strong players, except when white was an exceptionally strong player.
Hence the original 4.5 points komi about 100 years ago. The half point is the part that turns a draw into a win for white, that starts playing after black. But it's not strictly necessary: we could state in the rules that white wins draws.
Black started playing less conservatively and komi was soon adjusted to 5.5 points. It became 6.5 points at the turn of the century. It's 7.5 with Chinese and area rules.
This variant of chess seems to me potentially unfair to the player that gets a bad starting position, one that loses most games or that could even be winning but only with a narrow and difficult path to find. It could work in a tournament if all players have to play all the initial configurations.
In thnk
Just for fun: it is worth noting that there were/are other solutions to the "black wins" problem, usually in the form of playing multiple games and alternating colors, and stuff like kadoban formats where if you win multiple times you start getting pushed to get progressively larger handicaps and see if you can win then.
Chess 960 was done to address memorized openings and,to a certain degree,the issue of draws.
But Chess960's castling mechanism is totally unintuitive. So, Chess 744 was born. The exact mechanic (rook moves to king and king swings behind it) from standard chess is used and all of chess 960's setups that had a rook and the king in a corner were removed. This website goes into detail. There is no better method, IMHO, of creating an intuitive chess variation that addresses this issue. It is very hard and unintuitive in Chess 960 to remember where to move your pieces to castle and whether or not it is even legal given the squares the king has to move through.
I can later (short on time this morning), and I plan to add diagrams to the website and a video discussing it.
Basically, the rook, assuming the spaces are open and he and the rook havent moved, either moves adjacent to the king (if he isnt already adjacent) and the king moves two spaces around him.
Go doesn't really have the draw problem. Scoring is sharper in go, so even with integer komi you don't see enough draws to really be a problem. Only reason you _really_ need non-integer komi is if you're running a tournament or rating system that can't accomodate them at all.
Even on 9x9, like look at GoQuest for example, they must have thousands of game a day at 7 komi and ~nobody complains if there's a jigo, it just means the game was really close.
In chess the problem is just high level play has _so_ very many draws, so it can be worth trying to reduce that.
In go you get a draw once in a while. In chess you get a draw by default and have to really work to avoid it (assuming you're at a level vastly vastly higher than I am).
Hey everyone, my name is Corey Wolff. I've been in games and software for ~13 years. I started as an animator and tech artist and moved to full stack web development. I am constantly building new things and work particularly well in prototyping. Most recently I've founded a startup in ed-tech, built a PBR renderer that I hope to port to WebGPU and Web Assembly and attempted to get a local LLM to play D&D.
Profile: I'm a full-stack web and game developer with over a decade of experience. I've had roles with every part of web and games. My particular interest is unique web based interactions. I also started with AI by building my own poor man's version of AlphaGo back in like 2020 and have been using AI since. My current project is a web based raymarching game engine / artist tool: https://jesterswilde.dev/rmfw (requires webgpu, desktop only.)