I like the idea but I could only find an image of two keys. It would be great to see a demo of a full layout. With only two keys it's a very early POC and hardly a keyboard.

Does communication work well and feel snappy with a full set of keys? How is the structural integrity of a full one? Can it be easily moved around? That type of questions could easily make this unusable at scale.

I am waiting on some key switches to make more keys (5 in total), but for now I just wanted to show the progress on the mechanical/electrical side. I don’t have enough PCBs for a full set of keys yet, but when the key switches arrive and I assemble the 3 other boards I’ll let you know how it goes :D

Looking forward to seeing it!

What's the production cost of this per key?

Currently production cost is around 8-10 USD but I’m trying to bring that down!

> Can it be easily moved around?

I would assume you could have a custom support the keys rest on, that itself is split eg in the middle, so you can easily split the whole keyboard and have it stored in a compact way (trading length for depth).

Normal keyboards have staggered rows. This design doesn't seem to permit that.

I worked on three of them! While there are some serious issues with Frostbite and everyone loves blaming it for everything, its role in sabotaging huge projects is definitely overblown.

There are some issues with workflow and it is true that the UI definitely was, as many at EA said, "by programmers for programmers". But it's a very capable engine in the right hands.

That said, I'd pick Unreal any day for a AAA project and Unity or Unreal for smaller projects.

cool, i think Frostbite is really pretty honestly. performs well in BF but ive not played other games that use it knowingly.

Why would you pick unreal? It seems a lot of games made in it suffer performance issues. In my mind its a really unwieldy engine. (ofc, because its so feature packed, and perhaps because i am no professional engine dev :-))

For a professional project with at least 30+ developers the complexity of using Unreal is necessary and on par with any competent engine. In fact, I feel it is often much easier to do things well in Unreal.

I like Unreal because it's really quite intuitive and ergonomic for larger productions, fairly well documented, and has some of the coolest tech in the industry. Their rendering pipelines are beautiful and a joy to work with and I could rant all day about my love for Nanite and Lumen. It is light years ahead of Unity and much easier to understand and modify than Frostbite.

I will say that Unity has better support out of the box for custom shaders and compute than Unreal (and Frostbite).

Now, you mentioned performance. Funny thing: performance has been my primary professional concern for the last six years of my career. Unreal itself performs very well if you use it correctly and has really good documentation for best practices as well as amazing tools for measuring performance and indicating what is wrong. The tools in Frostbite were very lackluster. Unity has some fairly good stuff. Unreal feels so far ahead.

I believe the reason there are more visible Unreal games with performance issues is because there are a lot more noteworthy ambitious productions in Unreal. That means games which push what they can deliver, and often don't quite get there. And for smaller productions it's likely just a matter of less experienced teams not following the best practices or cranking settings up to 11 without proper performance budgeting.

I was at another EA studio when BioWare released Andromeda and Anthem. Got to play an early closed beta of Anthem, heard lots of details about Andromeda's development as it was happening. As a huge fan of their games it felt crazy and very sad.

However, The Veilguard to me was amazing. I loved that game and it's my favorite Dragon Age.

Veilguard is a serviceable action romp but it's not a Dragon Age game.

As someone from Gothenburg, Sweden (often referred to as gbg) I shall answer:

A private key is a tiny number you don't need to share publicly because it is easy enough to guess.

I've been working in C++ using VS for about 15 years and for as long as I've remembered my heuristic has been that if I get a breakpoint the offending instruction is on the line above what was reported.

That's just an eternally confusing bug of VS/cdb. On other IDEs such as QtCreator with clang or gdb it shows the break red dot exactly where the issue is.

As a parent a large part of my responsibility is making decisions and regulation about how they are allowed to interact with trends and technology I barely understand.

This sounds cool but a few issues make me suspicious.

The narrative makes it sound like boundless RSI but the actual content is only about training agents to collaborate efficiently by improving communication. That seems like a dimension and approach with limited potential for improvement. I also find it very suspicious that a paper on RSI would stop after just two rounds.

As someone who worked at a AAA studio which delivered a beloved and financially successful game and then was shut down I find this comment almost as cruel as it is funny.

I think this is interesting theory and fun to read about. If I was actually working with cryptography this would seem immensely important. I would also be arguing vehemently online about the std implementation of Mersenne twister and worrying about people analyzing bulk traffic with advanced scripts scraping a hundredth of a bit per sample.

But, I make games.

Bad random in games is also a problem, eg, reversing the poker seed.

Of course, and even good randomness can be reverse engineered like this:

https://gegell.github.io/posts/factorio-rng/

My comment was mainly a joke. Since my work is primarily with performance and graphics, I rarely use any proper RNG and usually only need cheap things which look random enough at first glance.

I looked up your blog and it is clear you have a deep interest for explaining ideas and programming techniques. That's great, there's passion! I even found that you've written about some things close to my own heart:

https://www.makonea.com/en-US/blog/Pokemon-Red-and-the-Evolu...

Looking through it I learned some cool stuff - I had no idea about this.

However, there's one piece of advice which seems applicable to most technical writing I saw on this blog, especially the Pokémon FSM one:

You need to work on pacing and length. The core issue is very broad scope. Think carefully about your target audience and the key insight you want to communicate. Then narrow your scope to communicating only what is necessary for that idea, skipping things your target audience can be assumed to already understand. The writing will automatically get snappier and more engaging.

If you want to explain the FSM script engine in Pokémon you have to assume the reader is somewhat familiar with programming and won't need a primer on registers. Otherwise you're writing a low-level programming primer, not an article about a clever technique in a video game.

thanks!