Just kidding, this is an awesome project! I wish I would have been that creative and competent in my teenage years... or even now, for that matter. Respect!
This project has been created by many Hack Clubbers, and not only in the development of the engine, editors, firmware and hardware. Hack Club teens handled all logistics/supply. The backings were made by a HCer that taught herself laser cutting. PRs for games are being reviewed and commented upon by 4 teenagers. All front end dev & copy was done by a HCer. The 3d model on the front page was another's first time in Blender.
Our youngest Sprig game dev right now is an 11 year old (https://github.com/hackclub/sprig/pull/443). We have a water sim built by a 13yr old (https://github.com/hackclub/sprig/pull/402). A raycast experiment by a 15yr old (https://github.com/hackclub/sprig/pull/153).
We have so many fun games built already: https://sprig.hackclub.com/gallery.
Hack Clubbers are now running Sprig workshops in their clubs and hackathons - and publishing them for others to use. Others are hosting 'Sprig Jams' to work on games together. Can't wait to see what more comes of this all.
As for Sprig itself the only part that is limited to teens is that we give the console away for free to teenagers who submit games to the gallery. Otherwise anyone can make games and submit them.
You mean you expect it to succeed soon? :D
There is a playable version on the home page at: https://sprig.hackclub.com/
Aside: The game you play on that one was written by my 13yo son. He has become super involved in Hack Club over the last few months, since I showed him that "Sine Rider" game announced on HN (another Hack Club project), and I left it up to him to discover Hack Club from that. As someone who used to run and attend Hacking Society meetings, I was pretty happy to see him dig into Hack Club.
Awesome work!
Phaser still requires a ton of boilerplate code compared to the example games here.
Both Godot and Unity are very similar to each other and aren't great for say.. hacking together a quick js prototype and sharing it with your friends on the web (or with a lil' device).
I've been really impressed with how well people can build out really engaging games with simple graphics but interesting game mechanics. The community already has pushed it beyond what we originally expected when designing the engine.
For all the faults with Flash (security primarily) it gave so many people an easy way into games development.
We’re missing this today.
Just getting the environment setup for a lot of game engines today is beyond today’s teenagers (and to be fair, me - both in terms of required knowledge and attention span), whereas 40 years ago, you just turned your computer on and boom - a flashing cursor. You had to type things to even load games.
Right now I'm working on getting Lingdong Huang's - who has made a bunch of really cool interactive experiences[0] (like a human face eating simulator) - he made a Sprig game for us[1], I'm trying to get it working on the physical device - but there's a problem, since the device is Raspberry Pi 2040 based and only has 256kb of available RAM (yet the games are written in JavaScript - we run them using our own little JerryScript based runtime[2]).
The runtime also runs on personal computers, not just arm-eabi-none, to help us test the games to get better error messages than the physical hardware can give (because no operating system). We call this our Sprig emulator, even though it's just the runtime compiled to a different architecture, hooked up to CoreAudio and a minifb window. Thanks to the emulator, we know Lingdong's game theoretically only uses 180kb of RAM, so we should be fine. And it actually works great in the emulator, but when I try to run it on the device it doesn't get past the startup screen ... which hurts because the entire reason we made the emulator was to get better error messages.
All I can do now is puts("") debug everything and figure out what code is reading or writing out of bounds and making the device freeze. I probably configured the heap to be too small again.
I have always loved finding excuses to figure out how things _actually work_, which is why every time I sit down to make a game, one thing leads to another and I'm making a game engine. Working on Sprig has taken this to a whole 'nother level because it's essentially our own operating system, too. Nobody tells you if you overflow the stack, the stack guard is only 32 bytes and disabled by default. It all started as a module for Kaluma, but we hit so many performance, RAM and flash constraints that we found it was better to write our own JS runtime. Apologies to Kaluma which is also trying to frontpage HN right now! We both use JerryScript heavily, but Kaluma connects you directly to the GPIOs and IRQs. We just connect you to the screen and the buttons through the same API as in the web browser, which is handy for making tile-based games.
[0] - https://lingdong.works/ [1] - Lingdong's game. Keep in mind the controls are all WASD and IJKL because the device only has 8 buttons. https://editor.sprig.hackclub.com/?file=https://raw.githubus... [2] - github.com/hackclub/spade
got it working on the device!
the performance is quite horrible ... enough to make you question why running JS on embedded devices is a fad ... so it's time to start profiling.
It's pretty cool to see projects like this, Sinerider, and the like being developed, even if I am on the sidelines haha
> by teenagers, for teenagers
> I'm 19.
Do you plan to continue contributing after you turn 20? I'm not familiar with the project, so I'm not sure what "by teenagers" means in practical terms (e.g. certain types of contributions no longer allowed?).
Now that you have hopefully read my one takeaway Cedric...
This is from the perspective of someone who has been in the games industry and entrepreneurship for a long time, long enough to become the villain.
You're clearly a very talented programmer.
In 2008, when I was at elite fancy school, an opportunity that is probably open to you, GPGPU programming had just begun.
The last decade of software innovation - machine learning, cryptocurrencies, immersive video games - owes its debts, fundamentally, to people who learned and authored GPU software all day. The ability to program GPUs, and nowadays to build infrastructure for distributed GPU computing, is the primary bottleneck to the greatest innovations in software.
If you love low level stuff, this is where you should go.
If this doesn't interest you, at least learn Unity and/or Unreal. No more custom game engines. There is a time limit. I know a lot of people in R&D across industry and academia, and the #2 bottleneck for innovation (after #1, GPGPUs, i.e., performance) is Unity and Unreal skills, i.e., presentation.
Why write here?
I've seen people in your situation, at 19 years too, capable of great things, attracted to scenes of other talented people like the Hack Club folks.
Every 5-10 years there are certain technologies on which all innovation is built. It isn't going to be Raspberry Pis. Please, don't focus on that anymore.
Like someone else I know in your situation, who was modding video games: put a time limit to... the "kid shit." That's going to get me downvoted, but seriously, the world flies by you, and people like you have a lot more potential.
It is extremely downvotey, but there are objectively more important things for you to be doing. There are other people in your life who know this too (like probably your parents) but they may lack the sophistication to know, really, what you should target your talent cannon on.
What's the point in doing anything if you don't enjoy it, or if it doesn't culminate in something you do enjoy?
My metric when I decide to do something isn't "how cool will Hacker News or Hack Club think this is?"
It's, how much will I enjoy doing this.
You may call it kid shit, and maybe this is the hard-headed kid in me talking, but I hope I never change.
I work in the games industry and couldn't disagree with this post more. The above is generic advice you give to someone just starting out and wants to work on games but has no clue where to begin. This person is working on a custom games console which is incredible experience, useful and impressive on so many levels.
You have to use new hardware all the time. You have to relearn a new shader language all the time. You have to re-learn Unity and Unreal all the time, because they are a shifting target (especially Unity). I have shipped games with 6 different games engines on 4 generations of hardware. I've used 3 professionally in the last two years.
The skills you will learn working on this console are the stripped-down core of game development: relevant and everlasting.
The GPGPU stuff is critically important if you are targeting low-level programming, to which I would add AI processors (NPUs, TPUs, etc.) And bone up on your statistics and linear algebra to like, the "Ph.D in math" level. The AI rocket is about to take off, big time; you want to be on it.
I cringe thinking about long-term exposure to bare PCBs, sure RoHS is a thing, but it's R(eduction), not E(liminiation).. And those guidelines are under the assumption that the electronics are packaged and not touched to bare skin..
PCBs are still made with fibers which can penetrate the skin, and I'd be worried about exposure to soldermask, solder and what other chemicals are involved.
Maybe someone has created a 3d print for one?
Good work, it looks cool.
Things would go wrong on the device but I would have no idea how to diagnose it because I didn't know what all Kaluma was doing for us. EX: to write to flash, you can't have any IRQs going or code running on another core. How do we know what all Kaluma is doing while running our code?
We were going to need a Kaluma-less runtime just to debug our renderer, audio and input handling anyway, haha. I didn't think you were going to let me spend time doing it instead of scrambling to fix bugs with our Kaluma-based impl, so I spent a weekend prototyping our own runtime. It worked, so I didn't have to wait for Kaluma's 2 minute build times anymore.
"Some Assembly Required: An approachable introduction to assembly" - https://github.com/hackclub/some-assembly-required
https://news.ycombinator.com/item?id=31909183 (587 points | 4 months ago | 125 comments)
We decided to make the physical console because it was a cool thing to do and would help motivate people to follow through with projects and make games.
More directly responding to your point Ivan Illich has some interesting commentary on the modern invention of childhood in Deschooling Society.
We used to jump from childhood to adulthood without lingering.
I don’t cast any judgment on the concept of teenagehood. I think it’s out there now.
