Since it seems that many people here are unaware, so let me introduce Pico-8, the "Fantasy Video Game console" that is referenced in Pyxel's README as an inspiration: https://www.lexaloffle.com/pico-8.php
Pico-8 is (AFAIK) the program that kicked off a trend of simple game engines, and it is by far the most popular. A popular game that came out this year, Celeste, was originally a Pico-8 game that proved popular enough to remake in a more modern game engine. Pico-8 supports a Lua API, with a built-in graphics editor for 8x8 sprites, and a 4-channel audio editor. Games can be exported as a PC/Mac/Linux binary, into HTML+JS for embedding into a webpage, and even as a PNG for easy sharing to other users with the Pico-8 program. There's also a very active BBS where 'cartridges' can be shared and played online: https://www.lexaloffle.com/bbs/?cat=7#mode=carts
I'm a relatively novice programmer, and one of the things that frustrated me was how difficult it was to make a simple game on modern machines. I didn't want to have to set up a whole Unity project or dive into OpenGL just for a little proof of concept. I've been heavily using Pico-8 and really recommend it for simple game programming. There's also a hashtag on Twitter (if you're into that sort of thing), #pico8, where people try to create interesting visual code golf programs that fit into the size of a Tweet, then they post the source code and a gif.
Building on your reply, I have found that Processing (Java) and P5 (JavaScript) have a similar easy-to-use design and the documentation is decent. (It's not opinionated on the color palette though.)
I've been using P5 to write retro video games to learn JavaScript, and it's been a lot of fun using that to learn JS. (Vanilla JS sucks, but the learning process is at least fun).
oh man, processing. i did a weeklong video game programming "camp" back when i was in middle school and processing was the language we used. definitely easy to pick up and use.
Could you please elaborate on why Processing is easier to use over OpenGL wrapper like LWJGL? You still have to write OpenGL shaders to get the desired visual, right?
No, you can do a lot of stuff in processing with the 2D primitives. You can use shaders if you want, but it's not something typically done as an introduction.
well, we were middle schoolers being introduced to programming through video games. we were making basic 2d games like asteroids and tankwar, nothing with shaders.
Yeah it's a really great environment. Very popular for Ludum Dare (next one starts Aug 10) style game jams where time is a factor. Itch hosts quite a few completed games built with Pico-8:
At launch screen, use arrow keys for level up/down, lives up/down (q to enable "rapid fire" cheat) ... start game with either "z" or "x" key.
Pico-8 uses 2 buttons primarily -- keys are mapped to "z" and "x" ... when playing, z will do fastest-sampling fire and x will do regular firing (this is most noticeable after using the q cheat.)
If you use the q cheat -- the score will not count toward the high score.
I stopped developing for pico-8 as I get it that some of the constraints are artificial, but I feel some are just too restrictive (like volume level on sounds). It's a fun little system with everything you need to use it built in. Some people have done some incredible things within the limitations of the system.
In the same realm, check out LÖVE, a Lua framework for making 2d games for most platforms. It's similarly simple to use but does not come with a built-in graphics or audio editor.
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 had to care about one or two combinations of platforms (maybe supporting a small range of graphics and sound cards).
This can help teach younger developers to understand the basic principles, and get a glimpse of how things are done below the surface of those modern do-it-all gaming engines.
Sure, flat bitmap modes existed, but no game I ever worked on used them. Plus they weren't conceptually simple, either.
On PC there was Mode X, which was so convoluted that I'm grateful to have forgotten how it works.
Before that, on C64, you'd generally build the game background out of a redefined character set, but some of the color bits would be read from a different part of memory.
Setting a pixel in bitmap mode wasn't a walk in the park, either, due to the way the memory was laid out (8x8 blocks). Plus you'd have to write to screen memory this time to set the colors in each 8x8 block.
Mode X was convoluted, and if you were serious about double buffering, whole screen pixel perfect scrolling, etc - you had to master it.
But if all you wanted to do was set pixels, VGA mode 13 (IIRC) really was just setting a value to (0xA0000+y * 320+x) ; Turbo Pascal even let you define an "array[0..199][0..319] of byte absolute $a000:0" and treat it as an array; If you manipulated a small enough part of the screen, it was reasonable to do "off screen rending" (poor man's double buffering) and use the CPU to copy onto the screen.
CGA/EGA/Hercules were slightly more complicated because of bit packing and other weird hardware constraints, but only slightly so. As were the flat bitmap modes of most machines at the time, true. But the built in BASICs more than made up for this, as far as beginners were concerned.
On the Apple ][, it was all of "HGR2 : PLOT 100, 100 : LINE 200,200" IIRC; On the spectrum, it was "PLOT 100, 100 : DRAW 100, 100"; on the BBC B (spiritual grandfather of the Raspberry Pi) it was "MODE 7 : LINE (100,100)-(200,200)"
C64 Basic was indeed spartan, but C64 did have a pixel addressable mode that was almost a walk in the park; CPU was limited, so 99.9% of games used the redefined-charset trick, which let them update only one 40x25 charmap instead of a much bigger pixel map (and ... it was actually perfectly matched to the game designs and other memory constraints of the time - your elements had to be repetitive due to lack of memory/cpu to do other things, and the charmap just constrained those repetition to start on an 8-pixel boundary).
I may remember a detail wrong in those examples - but basically, the C64 and VIC20 basics gave you little help; But the ZX Spectrum, Oric Atmos, IBM PC jr, Apple ][, Dragon 32/64, Elan, MSX and all other contemporaries made it extremely easy.
And on a ZX Spectrum display, the horizontal lines were not contiguous in memory - you would get the 1st line, then the 9th, then the 17th.. then after you got one third down the screen it would jump to the 2nd, then the 10th.. a right pain to program! Explains the weird loading screen effect, when the data would be loaded so slowly you could see it drawing in that odd pattern.
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, I feel it's not that dissimilar from coding C and OpenGL today, in terms of the overall flow of your project.
NES and SNES were not your general "development system of the 80s"; I'm quite sure GP was referring to the Apple, Oric, Acorn, BBC, Dragon, MSX, Tandy CoCo, Spectrum, Amiga and even PCg/PCjr/XT of the time.
Commodore's C64, PET and VIC20 were exceptional in how hard they made using graphics at the time from the included BASIC; But in general it was quite easy.
The Atari VCS2600 had an even weirder video setup: It had one line of video memory (a 1D canvas!), and it was up to the program to replace the contents of that line while the screen raster was flying back to the next line. And a few sprites to sweeten the deal.
Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows.
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
Modern hardware still works much the same, writing bytes to hardware that handles graphics generation, albeit today's are vastly more complex and SIMD-oriented. The key difference is these consoles lacked a framebuffer; RAM at the time was very expensive.
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 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.
I was in the generation between you and your kids. We had amazing games like Quake and Half-Life but we also had the awesome Qbasic games community.
There used to be entire sites hosting Qbasic games, many of which were often simple puzzles that had a very unique artistic style and charm to them that was worthy in its own right. They also often came with the source, which let you dig right in, try to modify it for more lives, etc. Qbasic games weren't much to look at compared to the budding photorealism of commercial games, but the constraints imposed upon them by the already-aging Qbasic platform forced developers to come up with some truly cool stuff that maxed out what it was capable of doing. Wetspot 2 and Ghini Run come to mind, as well as countless raycaster tests I built entire worlds within.
There hasn't been anything like it since, with the unique intersection of constrained tooling that creates a distinctive style, a strong community, and an easy to learn programming language. Pico 8, love, and this may come close to recapturing that magic.
> 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
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.
Sure, that's a good analogy, but what's the point? He's still right.
When you are a kid, it is hard to see the forest from the trees. To people here, understanding the basics of game development in a limited environment as a stepping stone to building larger games is probably obvious. But kids don't really have that insight.
I think the solution is to provide that insight (and this should go for parents and game engine developers): that this is foundational game design and thinking. That everyone who's working in the industry today understands these foundations. And maybe that retro is still pretty cool ;-)
I too found it hard to bring achievable game making into the hands of kids, but I've found Indie games have had a great renaissance, especially on portables like the Nintendo Switch.
These have design spaces that are possible for mortals. Celeste, Death Road to Canada, Enter the Gungeon, etc.
Another angle is that there are some great courses online to use something like Unity and, maybe not write a whole game, but design, sculpt, script a boss battle.
This looks really nice. It's a shame the name is so similar to an existing app though (Pyxel Edit, https://pyxeledit.com/)
My favourite 2D framework right now is is LOVE (love2d.org) - I'm using that to build stuff with/for my kids and it's just a joy to use. I'll probably write up some parent/child friendly tutorials at some point. I also like Monkey-2 (http://monkeycoder.co.nz/), but I only really use that when I want to do basic 3D stuff, because Love does the 2D stuff so well...
I'd like to see your thoughts on Love. I've been using it for the past week and so far it's my favorite game-making environment (I've tried a lot of other tools).
I like being able to just sit down and code rather then spend hours trying to understand someone's gui with a bunch of tools I probably don't need for my tiny project. Never tried Lua before this and I'm finding it pretty comfy too.
Those are all unmaintained projects. pyxl4/pyxl4 and Dropbox/pyxl haven't been in a long time and pyxl4 says gvanrossum/pyxl3 is unmaintained and while gvanrossum/pyxl3 was updated a month ago, it was just the README. The code hasn't been updated in over two years.
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.
Is PyGame flaky these days? I haven't much played with it in quite some time; it used to be pretty solid, although as I recall it wasn't much more than a wrapper for SDL 1.2 at the time.
Awesome stuff. Just spent 20 minutes with my 4 year old tweaking settings in the platformer example to see what the results would be. He loved it. Way more fun (for him) than the other day when he asked what the modulo operator was.
It bums me out that the economics of indie games are so awful. The kid in me wants, so badly, to make a gigantic, sprawling version of Zelda or a dungeon crawler. But there's no way I can justify the time investment.
Still, seeing an API this simple is inspiring. Props to kitao.
> But there's no way I can justify the time investment.
It's fun. People build gigantic, sprawling model train sets in their attics over the course of years, not to sell them or to have many people play with them, but just for the fun of building something.
The hardware Pyxel simulates seems closest to the Williams arcade games -- Defender, Robotron, Joust, etc.
These games had a single 256 x 304 pixel frame buffer, 4 bits per pixel (16 color palette). A hardware bit blitter performed fast block copy operations to draw sprites, scrolling, etc.
There was a dedicated 8-bit CPU for sound which could play cool effects, albeit one at a time -- Pyxel's sound generator is closer to the NES, better for music and pure tones.
This is acutally pretty cool. I'll take a look later and check your Jump + Run example, seems to me like there's not as much code required as I thought.
I'm still intrigued by game development, just didn't really have the time to delve deep into it the last few months. Really cool project!
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?
FWIW, I've used both PyInstaller (bundles python and deps) and nuitka (actually compiles code to C++) and been super happy with both, though my use cases are generally simple (lots of networking generally but not much GUI work).
I've had much worse experiences with py2exe and cx_freeze.
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.
TBH I'd just try out Pico-8, which inspired this Python project. Pico-8 games are super easy to share, you can share the png file or embed the game in a webpage. I'm mainly a Python developer but I got started with Pico-8 about a week ago and it's a blast. My 7 year old son loves it too.
Pretty cool, although most game engines/libraries lack a native gui system. Does this provide some way of building retro guis, like for game menus or settings? If not, will it in the future?
This is fantastic. I always loved retro arcade gaming, and I'm sad that there are not a lot of games out there that interest me. So these days I came to a conclusion that I have to build my own games.
Where can learn about general game physics? How are the games designed? How do we make the games tough so as to make sure it doesn't bore players? Basically on "how" I should go about building my game.
This looks real fun, I'll have to play with it when I get a free minute. The graphics and sound apis remind me a lot of QBasic, where I first learned to program
Pico-8 is (AFAIK) the program that kicked off a trend of simple game engines, and it is by far the most popular. A popular game that came out this year, Celeste, was originally a Pico-8 game that proved popular enough to remake in a more modern game engine. Pico-8 supports a Lua API, with a built-in graphics editor for 8x8 sprites, and a 4-channel audio editor. Games can be exported as a PC/Mac/Linux binary, into HTML+JS for embedding into a webpage, and even as a PNG for easy sharing to other users with the Pico-8 program. There's also a very active BBS where 'cartridges' can be shared and played online: https://www.lexaloffle.com/bbs/?cat=7#mode=carts
I'm a relatively novice programmer, and one of the things that frustrated me was how difficult it was to make a simple game on modern machines. I didn't want to have to set up a whole Unity project or dive into OpenGL just for a little proof of concept. I've been heavily using Pico-8 and really recommend it for simple game programming. There's also a hashtag on Twitter (if you're into that sort of thing), #pico8, where people try to create interesting visual code golf programs that fit into the size of a Tweet, then they post the source code and a gif.