Game programming is hard. Sure, you can easily throw together something in RPGMaker, RenPy or Unity3D, and it's great -- but you don't actually know how it works inside. There is a certain skill required to go from scratch, write your own main loop, handle events, push the pixels, etc. Incidentally, the same exact skills are required when programming any other interactive system, such as a graphical user interface, an automatic appliance, a mobile art installation or... a robot! Those are going to be much more common in our lives soon. If we want to stay in control, we need to be able to program them ourselves, and for that we need those skills. They empower us and give us back the control over the technology.
One great tool for teaching it is PyGame -- which is a library, and not a game engine, so it forces you to attend to all those pesky details of game engine internals yourself. Which is a bit difficult, of course, but ultimately very useful. But even if you play with PyGame on the Raspberry Pi, it's still a very complicated and difficult to understand system. The learning curve is steep, and debugging is hell.
Enter MicroPython, and one of its flavors, CircuitPython. It's written by the people at Adafruit with the education in mind, but it runs on infinitely simpler devices than your average computer. Devices which you can't break easily, because reflashing the program will reset them to a known good state. Devices which run on batteries for hours, and which you can carry in your pocket. Devices, for which there is a plethora of add-ons and sensors that you could make use of in your game.
However, as of yet, there is no game library and/or add-on that would allow to easily create games in CircuitPython. This project is an attempt to fix this.
I recently assembled a @davedarko's #LAMEBOY kit, and I wrote a simple library in MicroPython to handle all the hardware on the device. Then I thought, hey, this has buttons and display, I bet it could run PewPew games! So I ported the library to CircuitPython and added a small compatibility library for PewPew, and lo and behold, the games work!
And since the ESP8266 has much more memory than the poort little SAMD21, you don't even have to precompile the libraries. It all fits with room to spare.
A few weeks ago I found in my mailbox a strange box from Aisler I was a little bit surprised, as I didn't order anything from them since the last time, when I tried their service for the first time. The box contained another 3 PCBs of version 4.1, and a steel stencil for one side. A few days later another parcel arrived, with another 3 PCBs and a stencil for the other side. This would have been great, except at the moment I was already two versions further into the design, and the boards just added to the pile of the trash PCBs I will never use. Sigh.
So I wrote @Felix Plitzko an e-mail, explaining that I don't really have the time right now to try those boards, that they are wrong version anyways, and that they should not send me anything without asking. I never got any answer to that e-mail, but no further packages arrived, so I guess I am good. I also promised to look at those boards and stencils at some point in the future, just to see how the service improved. So let's look at them.
This is the back of the board, and the corresponding stencil. I have to admit that all the dense thin pads for the ISSI chip are exactly the same, and generally I can't see any problems with the solder mask or copper. The silkscreen is still a little low-res, but it's somehow much more readable. There outline of the ISSI chip is a bit broken on the silkscreen, but that might as well be a Fritzing bug — it has a lot.
You can also see that the drunk German who is cutting out those boards with a hatchet got over his hangover from Octoberfest, but is still not very precise. What's worse, each of the PCB has those leftover tabs different — which I will get back to in a moment.
As for the stencil, it looks correct at first, but if you look closely, there are three strange things. First, there are no pads for the USB socket. I suppose they got confused by all the vias I placed there for mechanical support, and skipped them. Second, there is no hole for the ISSI chip's heatsink. To be frank, I don't know if there is supposed to be one or not — I'm not familiar with stencil practice. Third strange thing is that there are holes in the stencil for the power switch's mounting holes. Am I supposed to put solder paste into them?
Let's look at the other stencil:
This one is much simpler and less mysterious. There is only one problem here, which is the missing pad for the "up" button. Interestingly, no holes for the power switch this time, even though, being holes, they are present on both sides of the PCB. I guess it's enough to fill them with solder paste from one side.
Fine, so there are some mistakes in there. That happens, especially since I had no idea they are going to be making stencils out of my design, and so I didn't pay attention to take care of any details relevant to that. You would still think that they would put more care into checking their "demo" work.
So let's try and actually use a stencil. I never tried one before, so I was curious. I choose the top one, with the buttons, because that part of my design didn't change much and I wouldn't be wasting parts soldering an old version of the project. Also, buttons are easier to recover.
So first I had to somehow align the PCB with the stencil. On the movies I saw that you usually have your stencil taped by one side to something, then tape some stuff around your PCB to fix it in place in an aligned position. I couldn't get that to work, it was just too difficult to move the PCB under the template to align it. It would have been much easier if the template also had the mounting holes or something — but I guess then the solder paste would get into them.
Eventually I untaped the stencil, aligned the PCB by holding both in my hands, and taped some stuff around the PCB to the template to fix the position. Success.
Now try a second PCB, and... it doesn't fit. Because those hacked tabs are uneven, and give different spacing. So I would need to manually align every single PCB I wanted to use with this stencil,...
It's important to periodically revise the project's goals, both to see if they are still relevant, and to adjust the course of the project to better fulfill them. It's time to do this for PewPew. I recently did that for PewPew.
The last change in course of the project was almost two months ago, after the Mini Maker Faire Zürich, when I decided that while PewPew Lite seems functional enough, it costs up to $40 to get all the parts together — the feathers, the battery and the PewPew Lite itself. Then I identified the feather board as the most costly part of the whole, and one that I don't have any control over. So I decided to try and get rid of that part by designing a standalone version of PewPew.
I have to note here, that nobody was complaining about the price, they were, however, complaining about the fact that they have to buy separate things in separate places. Making PewPew standalone would also solve that problem.
I produced four different prototypes for that, with a design for the fifth already on my disk and prepared for ordering. I initially used a smaller PCB, but after struggling with fitting everything on it, I switched back to the Feather form factor, and after @davedarko recently pointed out that I can make it bigger and use the bigger LED matrices, I designed yet another version, shaped more like the GameBoy.
But then, in the mean time, I also worked on #µGame — and I realized that the ST7735R 128x128 RGB display on it is cheaper than the IS31FL3733 chip I use for driving the LED matrix, not to mention the LED matrix itself. And it was trivial to make the PewPew games run on µGame too.
Sure, the LED matrix has a lot of advantages compared to the TFT display. It has excellent brightness and viewing angles, while not using a lot of battery power. It's made of plastic, not glass, and therefore it's very hard to damage, even when carried in the pocket. Its low resolution and limited colors impose restrictions that stimulate creativity and make it actually much easier to finish the game. But the display also has advantages over the LED matrix. It's bigger, has more colors, lets me use cute graphics for the "pixels", doesn't require me to route dozens of tiny traces or solder TQFP48 packages with insane pitches, is very common and easy to source and looks more like a "real" game console. It also lets me display text in a readable form, which is great for things like error messages.
I don't want to merge the µGame and PewPew into one project — PewPew has very well defined goals that are different from the "for fun" nature of µGame. But I think that it doesn't actually make much sense to have an "advanced" version of PewPew, when µGame exists. So I won't be ordering that last prototype. Instead, I made one last version of the PewPew Lite shield, with only one small change — replacing all the resistors on it with resistor arrays, reducing the number of parts from 17 to 11, and making it better suited for eventual fabrication. I will wait for it to sell out on Tindie, and order another batch, and in the mean time I will work on the workshops.
Honestly speaking, PewPew Lite is really good for the goals of this project, and the standalone version doesn't really add much. And after looking into assembly services and the prices for them, I realized that I can't really make it much cheaper than the feathers — not so much that it will matter. Maybe I could get it down to $30 or $25, but I'm not sure it's worth it. And the extra features, like more colors and sound, are not really adding much to the project goals — they are more of a distraction.
So I will stick to the PewPew Lite and work on the content from now on. And new features and developments are going to go into µGame, which is more of an experimental project, without clearly defined goals.
After finding the reason for CircuitPython crashes in #µGame and getting the audio amplifier to work, version 4.1 has pretty much all the parts that I wanted to have. However, its physical layout is somewhat problematic, especially the rather large speaker smack in the middle of the board, which makes it hard to add a battery there.
So I started working on version 4.2. So far I have the following changes:
Added guide holes for the USB socket.
Larger footprint for the flash chip, so that more chips can be used.
Smaller and cheaper reset switch.
Pads instead of holes for the battery connector.
Moved the audio amplifier circuit.
Moved the speaker to the front of the board, and used a footprint for really small SMD speakers.
Moved some components away from each other, so it's not as cramped.
I'm still considering two more changes:
Add a voltage divider to an analog pin, for measuring battery voltage.
Move the charging circuit before the switch, so that charging is possible with the switch off.
I think that 4.2 will be the last prototype, at least if everything works as expected.
There is this challenge, where you have to write a game in Python in one week. I never really had the time for it (I preferred Ludum Dare, where you only have one weekend, so it's easier), but I decided to try and enter this time. Of course CircuitPython is Python too, so I'm going to develop a new game for PewPew. But since others wouldn't be able to play it without making their own PewPew, I will also write an emulator for it.
I assembled one of the boards for the PewPew 4.1 and got it to work. It's really close to what I want ultimately, at least feature-wise.
It has the IS31FL3733 chip for handling the LED matrix, an ATSAMD21E18A-AU microcontroller for running CircuitPython, and extra S25FL216K0PMFI011 flash memory for more disk space, a battery charging circuit, and a piezo speaker. I should have an amplifier for the speaker in there too, but I didn't get it to work yet — I have parts for it on order. Oh, and I'm using a rectifier diode in place of a shottky diode, because I'm waiting for those too.
I have made a custom board definition for CircuitPython, and built custom firmware for it — so that I can make use of all the pins I need and the extra flash memory. Once I finalize the hardware, I will submit the board definition to the CircuitPython upstream.
I'm still not happy with three things: the position of the speaker, the connectors for the battery and the fact that the board is pretty difficult to assemble manually. I would definitely not want to have to assemble 10 of them. So now it's time for optimization of the layout, possibly moving a few parts around. I also considered replacing the piezo speaker with a headphone jack — we will see about that.
Recently I found a board maker similar to OSHPark, but based in Germany, Europe. Could it be that my wish came true? As soon as I had a new version of PewPew's PCBs designed, I decided to try them.
The prices seem similar to what OSHPark offers: at OSHPark I paid $8.95 for three 2.00x0.90 inch PCBs, here it's €8.43. However, OSHPark has free shipping (which constitutes the bulk of the waiting time for me), while Aisler charged me additional €4.96 for shipping. But that's totally fine by my if the boards land in my mailbox faster this way.
There is a bit of disappointment here, though. I made my order on 28th of September, and for nearly two weeks nothing happened. I finally went to check the order's status two days ago, and it said on the website that they will be fabricating it within 1 hour. I assumed that it's just a fancy message, but indeed one hour later the message changed to information that they are shipping it within minutes, and later that day that it shipped. The boards arrived two days later.
So in theory, it could be much faster than OSHPark, which usually makes my boards within a few days, and then they take two weeks to get here. However, in practice waiting for fabrication made it about the same. Perhaps it will get better as they get more orders and the panels will fill up faster?
Now about the boards themselves. Here's a photo:
First of all, as you can see, the boards are green. As with OSHPark there are no color options, which is fine, but green is a bit boring. Their website is all orange, it would be super-awesome to get some orange boards! Oh well, green is fine.
There is ENIG finish, just like with the OSHPark boards.
Both the solder mask and the silkscreen are much lower resolution than what you get with OSHPark. If you look at the chip footprint on the left, you will see that every pin pad is different width — that's the effect of low-res solder mask. You can also see that the head of the sheep logo bled into the outline — that's the effect of low-res silkscreen. For comparison, boards from OSHPark and SeeedStudio:
Finally, the board outline. I'm really shocked about that: it looks like it was cut out with a hatchet by a drunk worker. I guess I shouldn't have ordered during the Octoberfest.
I still need to assemble the board and see if it works, but all the traces look fine visually. We will see how that goes.
I have the video, which is required for the prize finals, finally done, at least the first version of it. I don't really have any video editing tools, so this all has been done by gluing together bits and pieces with ffmpeg.
My pull requests just got merged into CircuitPython. One is the for the Trinket M0 with a hacked on flash chip — it's now called Trinket M0 Haxpress, and the other one is adding a gamepad module with functions for scanning and de-bouncing button presses.
I'm now waiting for the version 4.1 prototype PCB and parts, and once that works, I can make the custom firmware for it and start working on the sound support in the library.