11–20 of 65 posts
what would be needed - any thoughts?
I have two step-sons (11 and 17), both of who are into gaming, but the elder one showed a bit of interest in programming when he was 11-12, but the problem (I think) is that the games they are playing are light-years away from anything they can even hope to program - and if they see what's involved in programming a FPS, they are (understandably!) crestfallen and look elsewhere. However, something like this would give them a way in to program something playable (and retro games are cool as far as they're concerned), but do some genuine learning AND see that there may be a path forward for them to produce something worthwhile.
When I was their age, games like Manic Miner seemed possible. I'm not in any way saying I had the skill of Matthew Smith (and still don't, I'm learning myself for a career change), but it didn't seem like impossible future alien technology, whereas today's games are - they take thousands of man years to create, and are made by incredibly skilled people.
Cool for learning to program games. Development environments in the 80's and 90's were so simple that you had to program down to every pixel shown on the screen (well, maybe calling some line and sprite primitives for speed), so you only needed to learn a small mental model for programming, and everything above it was designed by you. Also, the primitive hardware and no expectations of portability meant that you only…
While it's totally true that you had to be very "close to the metal" in everything you do, I feel it's not that dissimilar from coding C and OpenGL today, in terms of the overall flow of your project.
I'd just like to point out as well, that unlike many other similar attempts it is is not based on pygame, and does not suffer from either the flakeyness nor installation irritations that comes with.
Instead it implements a very minimal (dependency wise) custom layer on top of glfw.
Many people will be skeptical of a python game engine, but I would recommend this one over many others.
Limited in scope and very good at what it does.
Having had a quick look through, I think I'm going to spend some time playing around with this... I think that simple game engines are really important to getting young people into programming. I have two step-sons (11 and 17), both of who are into gaming, but the elder one showed a bit of interest in programming when he was 11-12, but the problem (I think) is that the games they are playing are light-years away from…
Well, that would be like going to the cinema for Marvel movies and then refusing to do amateur films because you think that you would not be able to make Marvel movies on your own.
This is actually very nice. I'd just like to point out as well, that unlike many other similar attempts it is is not based on pygame, and does not suffer from either the flakeyness nor installation irritations that comes with. Instead it implements a very minimal (dependency wise) custom layer on top of glfw. Many people will be skeptical of a python game engine, but I would recommend this one over many others. Limit…
I would love to get my kids using something like this - my next question is they would love to share it - i will go with the "walk upstairs" sharing for now but are there plans for some kind of ... i'm not sure, download and run approach. what would be needed - any thoughts?
Cool for learning to program games. Development environments in the 80's and 90's were so simple that you had to program down to every pixel shown on the screen (well, maybe calling some line and sprite primitives for speed), so you only needed to learn a small mental model for programming, and everything above it was designed by you. Also, the primitive hardware and no expectations of portability meant that you only…
Actually, programming homebrew for the NES and SNES, I was surprised by how similar my experience was to learning OpenGL. You can't plot individual pixels on hardware like that, you have to fill CHR memory (like textures) and create arrays of sprite data (like triangles) to upload to the hardware accelerated unit of the console. While it's totally true that you had to be very "close to the metal" in everything you do…
But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for.
However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D
What is the Python packaging story like today? The last time I tried to distribute something that depended on platform specific libraries it was a real pain to get a package that users could just download and run. Would it be difficult to package a game written with this library in some form of installer?
Worried about various versions of Microsoft Office, but as long as I store all the libraries as 64 bit python 3.7 I hope it would 'just run'.