I'm writing a multiplayer card game based on an idea I had during COVID. It's been in the back of my mind ever since.
It's being written entirely in Python: Kivy for the desktop and mobile game UI, and aiohttp for the server.
I've written very detailed specification documents for every technical and game-design aspect of the game, and I've implemented the core game engine myself. I'm letting an agent do the rest, incrementally and under supervision, tweaking the specs as we go along. So far, a very pleasant experience.
My goal is to reach beta by the end of the year, and publish the game on Steam by mid-2027.
Great news! Thimbleweed Park is a lovely game. I played it with my children and manage to recreate the atmosphere of those evenings in 1990, spent in front of a Commodore Amiga 500 running Zak McKraken and Maniac Mansion.
Yeah, I loved it, too. Not quite on the level of the first two Monkey Island games, but still a great experience. One of the few games I actually finished in the last bunch of years.
I think the time between the original and this will work out well for me to be excited to play a sequel.
Some features of the Amiga that are peculiar even today:
1. The mouse is a hardware sprite and its movement stays responsive and smooth even under heavy load and even when the OS freezes
2. A screen can be divided into multiple resolutions, e.g. you can have a half a screen in high res and half in low res and with double the amount of simultaneous colors (or even HAM mode)
3. It can genlock natively, i.e. match its screen refresh rate with an inbound video signal, making it popular with broadcasting studios up to the late Nineties
> 1. The mouse is a hardware sprite and its movement stays responsive and smooth even under heavy load and even when the OS freezes
Tbf that's also how it works in modern operating systems. The mouse cursor is a hardware overlay (e.g. a more powerful 'sprite') which is rendered independently from the rest of the screen (without this the mouse cursor would have a very obvious lag, as can be observed in some games that use a 'software mouse cursor').
Also theoretically at least, Windows has a feature where it bumps the thread/process priority of the application that owns the active window to make interaction feel more responsive, but this seems to get lost in the overall complexity, e.g. with some touchpads it's not uncommon that the mouse cursor gets completely stuck under high load. AmigaOS had such a 'bump active application priority' too, but unlike on Windows this feature actually worked.
What made the Amiga mouse so extremely responsive is that the mouse movement code was (more or less) directly reading the hardware registers from inside an interrupt instead of having to go through tons of abstraction layers and an event system like on modern operating systems.
> 2. A screen can be divided into multiple resolutions
AFAIK this has also 'kinda sorta' survived as GPU hardware overlays. It's just hardly used in operating systems except for video playback (and mouse cursors). The special sauce of the Amiga was that the operating system actually made use of low-level hardware features instead of using those features only in games.
> 2. A screen can be divided into multiple resolutions, e.g. you can have a half a screen in high res and half in low res and with double the amount of simultaneous colors (or even HAM mode)
But of course only horizontally. The Copper made it happen.
Implementing mouse cursors as a hardware sprite isn’t that uncommon for 2D accelerated graphics, albeit later than on the Amiga. Something like an ATI Mach32 has one for example. About 15 years ago I had a crappy Dell whose Radeon card would randomly glitch the cursor, so it survived at least until then in newer systems. The extra responsiveness is more of an Amiga thing though.
> The mouse is a hardware sprite and its movement stays responsive and smooth even under heavy load and even when the OS freezes
Modern macbooks do something really interesting when the OS freezes. If the OS OOMs or something like a kernel panic happens, the trackpad stops clicking! There's something in the trackpad hardware that polls the OS and locks the trackpad when the OS stops responding so that it can't be pressed down to click anymore. Almost makes the OS feel like a real physical thing when this happens.
That’s because with most modern MacBook touchpads (bar the Neo) the touchpad never really moves much. It’s all force detection and a haptic feedback thingy. If the system crashes, it stops triggering the feedback.
I think there is realtime 3D used for the player and enemy "sprites" (really 3D objects), including the end of stage bosses. They are small and extremely simple, as this was the maximum the Genesis/Megadrive's 68k CPU could handle. The final boss fight is the exception.
Silpheed was amazing back in the day. It was one of the first titles that really showcased what CD drives could add to games in terms of cinematic experience. The live orchestral music gave it an epic feel and the mecha-design of the SA-77 is beautiful and modern even by today's standards.
I'd be very surprised if player and enemy graphics are realtime 3D. Those look very much like typical sprites where you use different sprites for different angles.
The player ship rotates, but it only is 'rendered' at a handful of angles. This is a very common technique, but here they've used an art style to make it look like realtime 3d.
It's like stun runner on Lynx [1]. The Arcade stun runner was polygon based; but the Lynx doesn't have a chance, so there's just a ton of sprite options for rotation and a lot of work to make it look the part [2].
I'm sure they are 3d models and are rendered using the CPU. You can check by entering the secret Options Mode and selecting the Polygon Test, which will allow you to freely rotate your ship and the enemies, including the end of level bosses (except the final one). Screenshot: https://www.vizzed.com/vizzedboard/retro/user_screenshots/sa...
Fabien seems to be unaware of this, by the way.
This is also why the game play is so bland. The number of 3d objects and their complexity was severely constrained and did not allow for varied or more sophisticated game elements.
> think I could come up with a python example that maps 1:1
My take on it:
class Stuff:
def __init__(self):
self._list = [1, 2, 3, 4]
@property
def each(self):
for el in self._list:
yield el
for item in Stuff().each:
print(item)
It's even less verbose than the Ruby equivalent in the original article, thanks to the indentation-defined blocks.
I love Belgrade and have stayed there maybe a dozen times in the past few years. Usually I stayed in Old Belgrade, in the formerly (or perhaps still?) state-run hotel, which is partly staffed by students from a hospitality/catering college attached to it as they do their training.
A couple of years ago I stayed at an AirBnB apartment in New Belgrade. Beautiful apartment, but the building was brutal and huge, built in a long sort of zig-zag that went on and on. The name of the street nearest to the entrance I was using translated as "Anti-fascist struggle street".
I was just about to mention Belgrade, imo it has the best brutalist buildings outside of the former Soviet Union countries, that's (also) why it is on my to-visit-soon list.
Might be helpful for people interested in this, an acquaintance of mine recently started working on a project for an online archive of socialist modernist concrete-based (so not only brutalism in strict sense) architecture (contains photos, info, publications, art projects inspired by the subject, etc.): https://belgradesocialmodernism.com/
That's why I've said "outside of the former Soviet Union", inside the former Soviet Union there are cities which can compete with Belgrade on the brutalist front, from what I was able to see from IG Sankt Petersburg and Kyiv are quite interesting on that front. To say nothing of the brutalist Soviet bus stations which deserve an architectural category/style all for themselves [1]
It's being written entirely in Python: Kivy for the desktop and mobile game UI, and aiohttp for the server.
I've written very detailed specification documents for every technical and game-design aspect of the game, and I've implemented the core game engine myself. I'm letting an agent do the rest, incrementally and under supervision, tweaking the specs as we go along. So far, a very pleasant experience.
My goal is to reach beta by the end of the year, and publish the game on Steam by mid-2027.
reply