Pyxel: A retro game development environment in Python
github.com
github.com
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.
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).
You can write shaders (not mandatory since it supports 3D without them) but loading them is simple as using ShaderToy.
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.
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.
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.
It was convoluted, is what I'm saying
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.
Example: http://whatnotandgobbleaduke.blogspot.com/2011/07/zx-spectru...
And the icing on the cake being the colour information was stored sequentially at the end on an 8x8 pixel block basis!
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.
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
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.
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.
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.
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 think Unity might be worth playing with for 3D stuff? Or modding the games they're already playing can be a fantastic learning experience.
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.
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.
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 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.
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.
See, for example how kivy has moved away from using it as a backend https://github.com/kivy/kivy/issues/5590
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.
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.
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.
You can see a sample game written in C for the Williams hardware here: http://8bitworkshop.com/v2.1.1/?platform=williams-z80&file=g...
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'.
I've had much worse experiences with py2exe and cx_freeze.
what would be needed - any thoughts?
I ended up writing a rough JS implementation of GBDK and used Emscripten so I could debug those kinds of things while making GameBoy roms.
https://www.gbdkjs.com/docs/example-projects/
There's something about working within the limitations of retro systems that's really fun.
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.
Maybe I will try replicating it when I have more free time!
Run on Windows, Mac, and Linux