5 ms·
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 Huan
by cedric-h 4y ago
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.
[0] - https://lingdong.works/ 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.githubusercontent.com/hackclub/sprig/main/games/generic_dungeon_crawler.js https://editor.sprig.hackclub.com/?file=https://raw.githubus...
[2] - github.com/hackclub/spade
- gred 4y agoThis 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?).
- cedric-h 4y agoI 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?
- gred 4y agoYep, thanks!
- hoppityboppity 4y agoFocus 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.