This obvious age discrimination against non-teenagers is preposterous! Where are the lawers when you need them?
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.
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.
Sort of, yes! This is great question, and ties into our values and ethos. I'll try to keep it short (and note this is just my perspective as one employee).
We fully expect (and support!) our teenagers 'graduating' from Hack Club. On one hand, this presents a challenge when our most committed and experienced people age out every year. But on the other hand, there's a fresh group that arrive with new perspectives and insights, and really make the space their own.
Our hope is to honor our wonderful alumni too, and the contributions they have made. Many stay on in various ways to continue to support the community.
The cool thing about initiatives like Sprig is that while the current technical contributions will exist 'forever', it too can be enjoyed and iterated on by new young people in ways we don't know yet.
Haha thanks. Hack Club certainly has adults involved (like myself) but we structure projects so teens can be core contributors (the rest of the core engineering staff on Sprig are all less than 20 years old and I'd say 95% of the games in the library are from teenagers).
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.
It appears the project hasn't optimized for production (yet?). For now, I can't help but think it may be possible to cobble together a Sprig using inexpensive Pi Pico HATs and 3D printing. Here's the schematic:
Yeah, I'm sure it could. But even being able to buy a fabbed board (it's all through-hole components) would move things along. And I find the non-optimization pretty endearing, since it enhances the approachability and ability to understand the whole system.
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.
Love to see the combo of hardware and software being offered up to aspiring young game developers! I'm a huge fan of Pico-8 and other "fantasy consoles" so always welcome to see another one.
This is very cool. I love the focus on builders and do think there's a gap in easy to use 2d web-friendly game engines currently.
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).
Thanks! I've been really strongly influenced by great constructionists like Brian Silverman (who worked on Scratch and early Lego Mindstorms). He also helped consult on Sprig actually. We wanted to have a nice composable construct kit of ideas which would make getting started easy but which would still be fun for experts.
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.
I am a big fan of Sprigs. It is kind of crazy that my game is on the front page. Sprig is really easy to make games with, but it is also capable enough to make more complex things.
Hey everyone, I'm Cedric and part of the Sprig team. I'm 19. I've been trying to make games since middle school.
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.
This looks pretty cool, and takes me back to my early programming days.
> 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?).
I started out as a member of Hack Club's online community -- I discovered them through the GitHub Newsletter, and then made a multiplayer game with its own economy playable through their Slack (github.com/hackagotchi/hackagotchi) -- and then graduated high school in the middle of Covid with no plans and ended up working here. The purpose of the Sprig project is to engage and energize our online community. While our mission is to support teenage hackers, there are no hard and fast rules about what it means to be one. While we're not sending out devices to people over 19, we still accept games from them and show them in our gallery. Does that answer your question?
Focus on building things with Unity, Unreal & CUDA.
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.
This is a great attitude that you'd think would be more common at a place called "Hacker News". The temptation to get "finance brained" is incredibly powerful in this industry, especially as you get closer to Silicon Valley, and the more young programmers resist it the better off we're going to be. Thanks.
It's not really about finance brain. It's about where are you, as a smart, talented programmer, going to have an impact? For the past ten years, ALL of the major innovations in the software field have been based on GPGPU. Learning how to program GPUs is thus a core, foundational skill if you want to contribute significantly to the biggest innovations of computing. And of course there's so much else to learn on top of that, particularly in terms of math and algorithmic techniques and stuff.
Messing around with Raspberry Pis is kid shit by comparison. It's fun, but it's not going to advance much of anything. The Raspberry Pi is literally a "get kids into STEM" initiative, and yet it's used mainly by adults who want to cosplay as "makers". And even then, eventually they usually end up in a drawer.
If you want to mess around, Raspberry Pi game consoles are fine but if you want to make a significant contribution, time's a-wastin'. If the rocket takes off and you're not on it, there goes your chance. So yes, set a time limit on the kid shit. Put it away by age 20 or so, and start thinking about what really matters and what's really gonna change things.
Many people who in retrospect are truly innovative almost definitionally spend their time doing things other people don't regard as valuable (at first at least). As an extreme example of someone who prioritized a life of play look at Claude Shannon. He literally had a shop for building toys at home. I'm grateful he wasn't overly attracted to what others regarded as impactful at the time. That being said I still don't think it's important whether one's play becomes valued. I suspect in the long run we're all better off having people in the world who are passionate about what they are doing.
All of that might be true. All generalizations are sometimes untrue.
> spend their time doing things other people don't regard as valuable...
Sprig is an educational project, shepherded by adults affiliated with big name institutions like MIT and Google. They are extremely conventionally successful smart people who think "nurturing programming talent" is valuable. What are we even talking about? These things don't happen in a vacuum.
The idea that a "smart, talented programmer" should reshape their life and their interests around "hav[ing] an impact" and "contributing significantly to the biggest innovations of computing", to have "[their] chance" to get on "the rocket" before it "takes off", this is what I'm referring to. The idea that you're literally wasting your time if not working in certain fields: "machine learning, cryptocurrencies, immersive video games". Why do you assume that "impact" and "innovation" should be the driving interests of a young programmer's life? This is a cultural presumption, if not an ideological position.
Trust me, people don't get into programming video games for the money.
Anyway, this is a funny perspective. Zach Latta, the Hack Club founder, got a Thiel Fellowship. I would not characterize Peter Thiel's philanthropy as 100% mission driven. I also don't think he's a supervillian. But there is a finance angle, not a negative one, to even the most seemingly twee retrocomputing things.
Maybe if you saw Hack Club's deck, you would comprehend.
Any talented non-college enrolled young person could also consider a Thiel Fellowship. There are many opportunities out there.
> If this doesn't interest you, at least learn Unity and/or Unreal. No more custom game engines. There is a time limit.
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.
Second this. It should be drilled into the heads of everyone who wants to get into game development: USE A MAJOR ENGINE. No exceptions. Time is money, and hand-rolling an engine is a waste of yours. Unity and Unreal have many, many more man-hours of work put into them than anything you can build, so by choosing one of them you can avoid pitfalls you WILL run into starting from scratch, on top of the labor you'll save not having to build one in the first place. On top of all this, the entire gaming workforce is oriented around these two engines, so when it comes time to collaborate, you will be able to bring people aboard who can contribute immediately.
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.
Counter-point : the tradeoff you accept when using a commercial engine is that they're extremely general purpose, which can be unsuitable if you're trying to do something weird.
Look at Braid if you want a good example. Using Unity or UE to build that game would almost certainly require more work than writing a simple 2d platformer engine. Furthermore, the story of how it came to be is, in fact, inexorably linked with the act of writing the engine itself.
Sometimes, writing the engine is the right choice.
Braid was released in 2008 -- forever ago in game-industry time. The industry has become more consolidated around Unity and Unreal since then.
Unity has 2D platformer support built right in, and the tricky bits -- like the time mechanic -- could be written as an extension. Heck, there's probably a time rewind mechanic in the Unity Asset Store as we speak. They've so far advanced that you're just never going to keep up writing a bespoke engine because they've benefited from being integral to the industry as a whole. Furthermore, the skills you develop on your own with your little bespoke engine aren't going to translate into the industry, where everybody uses Unity or Unreal.
It's kind of like how you're never going to build a graphic design business using GIMP, Krita, or Inkscape. They're all nice tools for amateurs and dilettantes, but entire industry standards and processes have coalesced around Photoshop and Illustrator, so that's what you use. The open-source alternatives are decades behind the curve here and in some ways, will never ever catch up. Good luck getting PANTONE support, which is critical to graphic design for print, into GIMP or Inkscape, for instance.
but the sprig team just wants to have fun. its exciting for them to NOT use a major engine. It feels new and exciting to work on things that are new, and not go along with the crowd. Time might be money, but we're still teenagers after all.
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.
If you look closely at the picture of it in action, there is a clear acrylic shell covering the PCB on the back. They're actually gripping the acrylic shell. In the picture of the individual components, it appears to be the laser-cut wood pieces. That picture includes a pair of pieces that look like they go on the front (there's a cutout for the D-pad/face buttons), but I don't see them installed on the action shots. I think that the shell may be intended to cover both back and front, and they just didn't install it for the action pictures.
As others pointed out when fully assembled most of the board is covered (but visible). We designed the board to function like a devkit for the pico as well so unused pins are broken out on pads.
Man, I wish something like this would have existed back when I was trying to make choose-your-own-adventure games in QBASIC back in my teens! This is really awesome!
We debated running JS (Kaluma) or micropython on the Pico. We started with Kaluma because the editor is in the browser. After we got some game submissions though we realized we'd have to do our own wrapper around Jerryscript for performance reasons which is what the console ships with.
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.
The idea is to help people learn programming by making it easier for them to think of and execute projects which they share with others. In this case those projects are the making of the console/engine itself and for a much wider group of people the contribution of games to the game library. Thanks for contributing to both!
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.
I think it's a well executed project and the UI design on the editor is nicely done. We focused a lot on the API of our game engine and honed in on having a small construction kit for Sprig which seems to help people become productive. The aim is to communicate a specific mental model for Sprig games through the engine's capabilities (tile-based focused on puzzles and level design, though people have managed to do all sorts of things).
We chose the aesthetic of the bare PCB to help demystify the technology. The console is also designed to be repurposed as a hardware devkit (there are breakout pads and what not).
Slightly OT: I've been wondering recently if the word teenager and it's use has been a bad thing for people between 12 and 20. If we didn't have this word I'm guessing we wouldn't view them as such a distinct lump and be less ready to generalize about them.
This is an interesting point. One of the major things we're trying to demonstrate with Hack Club is we box people in too much based on their age. Especially young people who generally have a well defined set of activities laid out for them before they can start practicing some autonomy (largely from the way schooling works). The hope is that open-source projects like this can show people that there are some accessible routes and supportive communities to help them pursue their passions. Personally I hope the work serves more than just teenagers, but working out the details of serving young people well means as an organization we have to focus on it.
More directly responding to your point Ivan Illich has some interesting commentary on the modern invention of childhood in Deschooling Society.
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!