14 ms·

Pyxel: A retro game development environment in Python

549 points by autocorr 8y ago

akuji1993 8y ago
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!
- deleted 8y ago
  [deleted]
- ryan-allen 8y ago
  I thought the same things from the code examples. FYI other readers, to get to the example click on the image in the README!
TuringTest 8y ago
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 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.
- Luc 8y ago
  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. It was convoluted, is what I'm saying
  - beagle3 8y ago
    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.
  - feintruled 8y ago
    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. Example: http://whatnotandgobbleaduke.blogspot.com/2011/07/zx-spectrum-screen-memory-layout.html 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!
- Drakim 8y ago
  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.
  - BonsaiDen 8y ago
    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 [1] https://gitlab.com/BonsaiDen/vectroid.gb https://gitlab.com/BonsaiDen/vectroid.gb
  - beagle3 8y ago
    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.
  - ashleyn 8y ago
    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.
makach 8y ago
this just looks like a fun way to learn python and game development. the api resembles very much the basic commands available in the 80s.
- xorcist 8y ago
  I wish we had that kind of api in the 80s...
w1nt3rmu4e 8y ago
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.
- monadgonad 8y ago
  > 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.
NanoWar 8y ago
It reminds me of the BASIC language shipped with the TI-83 calculator!
lifeisstillgood 8y ago
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?
- fabrixxm 8y ago
  pyinstaller? http://www.pyinstaller.org/ http://www.pyinstaller.org/
- potta_coffee 8y ago
  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.
djaychela 8y ago
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.
- jcelerier 8y ago
  > 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.
  - fredoliveira 8y ago
    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 ;-)
wokwokwok 8y ago
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. Limited in scope and very good at what it does.
- megaman22 8y ago
  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.
  - wokwokwok 8y ago
    It's never been really solid in my experience; it crashes when it fails and its difficult to build due to the heavy use of cython. See, for example how kivy has moved away from using it as a backend https://github.com/kivy/kivy/issues/5590 https://github.com/kivy/kivy/issues/5590
    - bitcraft 8y ago
      Pygame is mostly C. Cython is not used.
adrianN 8y ago
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?
- robertAngst 8y ago
  Interested as well. I'm about to roll out an automation tool. 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'.
- WaxProlix 8y ago
  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.
aquova 8y ago
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 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 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.
- NortySpock 8y ago
  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). https://processing.org https://processing.org https://p5js.org https://p5js.org
  - satsuma 8y ago
    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.
adrianoconnor 8y ago
This looks really nice. It's a shame the name is so similar to an existing app though (Pyxel Edit, https://pyxeledit.com/ 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/ 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...
- potta_coffee 8y ago
  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.
- empyrical 8y ago
  Also similar in name to "Pyxl", like React JSX for Python https://github.com/gvanrossum/pyxl3 https://github.com/gvanrossum/pyxl3
  - benatkin 8y ago
    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.
- mongro1 8y ago
  Wow, great to see Mark Sibly still knocking out good stuff. I loved his games on the Amiga and Blitz was fantastic.
Yuioup 8y ago
Run on Windows, Mac, and Linux :-)
xyproto 8y ago
python-pyxel is now available in AUR, for Arch Linux users.
azhenley 8y ago
I have been learning Go lately and would be interested in an engine like Pyxel but for Go. Does one exist?
- pkaye 8y ago
  I was thinking the same since I have more experience with Go than Python. I guess one could duplicate this in Go using the SDL library.
  - azhenley 8y ago
    Or with Pixel? It looks interesting: https://github.com/faiface/pixel https://github.com/faiface/pixel . Instead of SDL I would at least use SFML: https://www.sfml-dev.org/ https://www.sfml-dev.org/ . Maybe I will try replicating it when I have more free time!
- peppage 8y ago
  Have you seen ebiten? https://github.com/hajimehoshi/ebiten https://github.com/hajimehoshi/ebiten
axiomdata316 8y ago
Duplicate: https://news.ycombinator.com/item?id=17650590 https://news.ycombinator.com/item?id=17650590
- detaro 8y ago
  Please don't point out "duplicates" on valid reposts. "I posted this before, but nobody cared" doesn't add anything.
lordxenu 8y ago
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?
chrismaltby 8y ago
This looks like a great project, reminds me a lot of development for GameBoy using GBDK especially with clipping screen buffers for scrolling. 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/ https://www.gbdkjs.com/docs/example-projects/ There's something about working within the limitations of retro systems that's really fun.
sehugg 8y ago
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. You can see a sample game written in C for the Williams hardware here: http://8bitworkshop.com/v2.1.1/?platform=williams-z80&file=game1.c http://8bitworkshop.com/v2.1.1/?platform=williams-z80&file=g...
megaman22 8y ago
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
tequila_shot 8y ago
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.
- mongro1 8y ago
  https://www.gamedev.net https://www.gamedev.net or itch.io (for indie stuff)

549 points by autocorr 8y ago

akuji1993 8y ago

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!

deleted 8y ago
[deleted]
ryan-allen 8y ago
I thought the same things from the code examples. FYI other readers, to get to the example click on the image in the README!

TuringTest 8y ago

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 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.

Luc 8y ago
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. It was convoluted, is what I'm saying
- beagle3 8y ago
  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.
- feintruled 8y ago
  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. Example: http://whatnotandgobbleaduke.blogspot.com/2011/07/zx-spectrum-screen-memory-layout.html 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!
Drakim 8y ago
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.
- BonsaiDen 8y ago
  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 [1] https://gitlab.com/BonsaiDen/vectroid.gb https://gitlab.com/BonsaiDen/vectroid.gb
- beagle3 8y ago
  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.
- ashleyn 8y ago
  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.

makach 8y ago

this just looks like a fun way to learn python and game development. the api resembles very much the basic commands available in the 80s.

xorcist 8y ago
I wish we had that kind of api in the 80s...

w1nt3rmu4e 8y ago

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.

monadgonad 8y ago
> 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.

NanoWar 8y ago

It reminds me of the BASIC language shipped with the TI-83 calculator!

lifeisstillgood 8y ago

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?

fabrixxm 8y ago
pyinstaller? http://www.pyinstaller.org/ http://www.pyinstaller.org/
potta_coffee 8y ago
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.

djaychela 8y ago

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.

jcelerier 8y ago
> 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.
- fredoliveira 8y ago
  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 ;-)

wokwokwok 8y ago

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. Limited in scope and very good at what it does.

megaman22 8y ago
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.
- wokwokwok 8y ago
  It's never been really solid in my experience; it crashes when it fails and its difficult to build due to the heavy use of cython. See, for example how kivy has moved away from using it as a backend https://github.com/kivy/kivy/issues/5590 https://github.com/kivy/kivy/issues/5590
  - bitcraft 8y ago
    Pygame is mostly C. Cython is not used.

adrianN 8y ago

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?

robertAngst 8y ago
Interested as well. I'm about to roll out an automation tool. 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'.
WaxProlix 8y ago
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.

aquova 8y ago

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 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 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.

NortySpock 8y ago
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). https://processing.org https://processing.org https://p5js.org https://p5js.org
- satsuma 8y ago
  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.

adrianoconnor 8y ago

This looks really nice. It's a shame the name is so similar to an existing app though (Pyxel Edit, https://pyxeledit.com/ 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/ 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...

potta_coffee 8y ago
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.
empyrical 8y ago
Also similar in name to "Pyxl", like React JSX for Python https://github.com/gvanrossum/pyxl3 https://github.com/gvanrossum/pyxl3
- benatkin 8y ago
  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.
mongro1 8y ago
Wow, great to see Mark Sibly still knocking out good stuff. I loved his games on the Amiga and Blitz was fantastic.

Yuioup 8y ago

Run on Windows, Mac, and Linux :-)

xyproto 8y ago

python-pyxel is now available in AUR, for Arch Linux users.

azhenley 8y ago

I have been learning Go lately and would be interested in an engine like Pyxel but for Go. Does one exist?

pkaye 8y ago
I was thinking the same since I have more experience with Go than Python. I guess one could duplicate this in Go using the SDL library.
- azhenley 8y ago
  Or with Pixel? It looks interesting: https://github.com/faiface/pixel https://github.com/faiface/pixel . Instead of SDL I would at least use SFML: https://www.sfml-dev.org/ https://www.sfml-dev.org/ . Maybe I will try replicating it when I have more free time!
peppage 8y ago
Have you seen ebiten? https://github.com/hajimehoshi/ebiten https://github.com/hajimehoshi/ebiten

axiomdata316 8y ago

Duplicate: https://news.ycombinator.com/item?id=17650590 https://news.ycombinator.com/item?id=17650590

detaro 8y ago
Please don't point out "duplicates" on valid reposts. "I posted this before, but nobody cared" doesn't add anything.

lordxenu 8y ago

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?

chrismaltby 8y ago

This looks like a great project, reminds me a lot of development for GameBoy using GBDK especially with clipping screen buffers for scrolling. 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/ https://www.gbdkjs.com/docs/example-projects/ There's something about working within the limitations of retro systems that's really fun.

sehugg 8y ago

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. You can see a sample game written in C for the Williams hardware here: http://8bitworkshop.com/v2.1.1/?platform=williams-z80&file=game1.c http://8bitworkshop.com/v2.1.1/?platform=williams-z80&file=g...

megaman22 8y ago

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

tequila_shot 8y ago

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.

mongro1 8y ago
https://www.gamedev.net https://www.gamedev.net or itch.io (for indie stuff)