Posted by bundie 6 days ago
1. Because half her friends and family are on iOS, and that means fighting the App Store. (This is a social problem essentially, in fighting Apple)
2. Because networking is hard. How would you have shared recipes with a computer in the C64 days? Email? BBS? (There are partial technical solutions to this, but they would require people to run something like friend-to-friend overlay networks)
3. Because most stuff happens in web browsers and that means pay-to-play, or vendor lock-in, or using AWS free tier and being a programmer. (Ass, grass, or cash, nobody hosts for free. Friend-to-friend networks may also help with this)
4. Because a recipe manager with sharing is best implemented as just emailing your recipes to your friends and storing them as txt files locally. Anything more complicated is beyond the scope of a Visual Basic-style drag-and-drop WYSIWYG anyway
5. When was drag-and-drop enough? The widgets need code behind them to save and open files, right?
6. You might be kinda onto something, and the longer I write async code I more I think the programming world is ready for another big pruning. Like when structured programming said "No goto, no long jumps, if-else and exceptions is all you need", we might be ready for "A single control thread which never blocks and never awaits, and delegates to worker tasks, is all you need until you are building some C100k shit"
I even made a few (quite simple, from my today's perspective) games in Pascal during high school and university. I expected to become much more productive over years of practice.
That didn't happen, for several reasons.
First, my expectations for a good game have increased. I don't want to make the most complicated game possible; I am perfectly okay with 2D raster graphics and simple algorithms. But I expect a good game to have animations, sound effects, at least ten levels that feel different, and an option to save game progress. My old games barely had half of that (some were animated, some had ten or more levels, only one had both of that).
Second, things became more complicated. It is no longer "320 x 200 pixels, 256 colors". Windows are resizable; different screens have different sizes. Programs need to be aware that multiple threads exist. Sometimes there are many possible choices, and I get paralyzed by choosing between them. Programs are expect to have installers; it is no longer enough to have one EXE file, and optionally a few data files together in a ZIP file. It felt like every time I mastered something, a new problem appeared to be solved.
Third, as a teenager I didn't realize how much my everyday work would differ from the kind of work necessary to make a computer game. Some skills are transferable: I am more comfortable with using threads, parsing data files, writing algorithms, the program architecture in general. But many skills are not: if my dream is to make a desktop application, then e.g. all the web frameworks that I have learned over those years are useless for this purpose; and they have cost me a lot of time and effort. So from the perspective of making computer games, as an adult I maybe learn in five years as many relevant things as I have learned as a teenager in one year, when I had lots of free time that I could dedicate to this goal.
Fourth, life gets in the way. There is much less free time, and much more things that I need or want to do during that free time.
So here I am, after a few decades of IT jobs, and (a) I can't really make a complete computer game over a weekend, and (b) it's irrelevant, because until my kids grow up I probably won't get a free weekend anyway. Or rather, even the rare "free" weekend (when the kids are away) is spent on other things that have higher priority.
In the age of powerful computers, you can use Hypercard on an emulated Mac, you can use any number of hypercard-clones out there. She can just use Google slides. etc.
> Repl.it
Sorry, Grandma has never heard of those fancy-pansy platforms.
Because there's no money in it.
GameBoy Advance game (difficulty = 3/10, time = 2 weeks)
Physics engine (difficulty = 5/10, time = 1 week)
Threaded Virtual Machine (difficulty = 6/10, time = 1 week)
POSIX shell (difficulty = 4/10, time = 3-5 days)
But regardless of the time estimates, I appreciate the idea!
Oftentimes I find that I enjoy one of the projects so much that I take it further than 'toy', but that usually ups the time estimate by an order of magnitude.
Honestly, I think I was in your same position until recently, then I had some time off work thanks to the newborn and decided to start a "simple" coding project. Since it was purely for fun and to challenge myself, I decided to try and avoid bringing in any dependencies and wrote everything from scratch. This made it much larger and more complex than I had initially anticipated, but despite that (or, maybe, because of that?) I longed for those few hours when I could tinker on my project. Coding suddenly became fun again.
Maybe you're just a bit burnt out?
That gave me a good chuckle. Yeah look, you can change your data layout to be in more of an ECS format, make some optimizations and call it a day; but in reality you're still going to be pretty far from the real thing.
I can say this because I've been working on one for some months now, of course I'm going for a production build and also to turn it into a Unity asset that's worthy of being sold, so it's going to require a lot more effort. The goal of mine is to ensure that its extremely simple to use (which Units DOTS totally fails at) while still being as efficient as possible.
Some notable things I've had to do for this project:
- I have a tool releasing on the Unity asset store (currently being vetted) that performs optimization for you, e.g. you give it a variable such as an int, a range of let's say 1..1024; then it'll automatically time your code while searching for the best sample in the range. I needed to create this for the next item, which is
- My C# Thread tool which runs managed threaded code for you. It creates no garbage so and uses the above optimizer on three different variables so as to find the best amount of threads, calls and inner loop sizes to use for your code. Because of that it can run managed code almost as fast as Burst/Jobs (whereas they use their own compiler and optimize code instead of using Mono). It can even beat Burst on small to medium workloads as long as the code inside doesn't contain some efficiency that Burst can natively fix.
- Then of course there are other things an ECS needs like pathfinding, unit collision avoidance etc. For these I have both CPU and GPU solutions since CPU only really works up to about 10k entities at a decent framerate.
So yeah, I don't recommend trying it; it's probably a total waste of time.
Got a few PRs for you when you get to this, friend.
The compiler, chess engine, and text-editor have been targets for years but I haven't quite gotten around to doing them.
I like the idea of the bitwise challenge.
I had been thinking that another challenge that I'd like to see (and have a go at) might be a plotPixel Challenge.
Make a game that does all rendering with
PlotPixel(x : int, y : int, color:??? )
NextFrame(offScreen:boolean = true, clearNow:boolean =true, clearColor:??? =0)
It would be easy enough to test if a game obeyed the rules because a full video capture of the game should be possible by intercepting just those functions.
Perhaps a (generous) source code size constraint to stop people going too crazy. (maybe 64/128/256k source-code, zipped). Not for code golfing as much as to avoid people trying to squeeze Crysis though a straw.
> What I cannot create, I do not understand
I suspect Mr Feynman would have phrased this a bit differently if he had first-hand experience with the modern front-end technology treadmill.