There was talk of starting up “Gruedorf” again – a little competition made by McGrue and Kildorf, where all entrants would be required to work on something each week and post something about it. Once a post is made, you have 7 days (168 hours) to make your next post, or you “lose”. The goal is to keep a consistent stream of progress each week, and try to minimize “losing” by doing a little work and posting about it.
As far as I know, there is no requirement that the project remain the same throughout all posts, which I’m thankful for. I accept that at this age that my attention span is all over, and I constantly cycle projects even on the best days. Although, finishing something is better than meandering between 3000 unfinished things that get abandoned for the next thing… Probably other rules I’m forgetting.
Anyway, this sounds like fun. Like many regular routines in my chaotic day-to-day life, and like previous attempts when I had way more free time, I’m not sure I’ll be able to stick to any sort of consistent schedule, but going to give this a try in any case!
With full-time work, and general lack of time organization, I have a few projects going on that I am cycling between depending on my general energy. Here are the ones I can remember off the top of my head, but it is not an exhaustive list:
- Wiz, a high-level assembler. The compiler is a work-in-progress, but it’s already capable enough to write demos and games (and comes with working example programs included). It’s a strongly typed language, with C-like structured programming that compiles directly to machine instructions on different retro CPU systems (6502, 65c02, HuC620, Z80, GB, 65816, SPC700). It has gathered a small community on its Discord channel (linked in the project page). This helped stress-test the language, and uncover neat uses I didn’t expect were possible with the language, as well plenty of hair-pulling bugs. But it’s still nice that this tool has a userbase and came in useful to others, even if it was written as a hobby project for my personal use at first. Hopefully more iterations can be made to improve the syntax, the documentation, the compiler tooling, write more example programs and games, add more platform backends, etc.
Dive into the “examples” folder included with the repo to see some examples of things you can do with it. I’ve included a Hello World for many systems, as well as a partial shmup demo for NES, a virtual pet sim on GB, a multiplayer VS game with ducks on Atari 2600, a few VFX tech demos, some libraries for some hardware register definitions and common utilities (GB and NES are most right now, but others are grown as examples and personal projects are made), and some other miscellaneous things.
- nrpg, a turn-based RPG for the NES. This is written with Wiz, and is a real NES program. I’ve been wanting to design a game that has tile-based overworld puzzles such as Final Fantasy Mystic Quest, Lufia 2, Fairune, and others. It will have a battle system similar to classic FF games, with maybe a sprinkle of the SaGa series.
So far I have a working MMC3 tech demo ROM that allows the player to walk around an top-down map with tile-based map. The map can scroll in all four directions without visible scrolling artifacts. The player is so far able to move across the map and jump (like FFMQ and FFL3/SaGa 3), but there is no support for interactive tile objects, zones or NPC system yet. There is also menu system with a working inventory subsystem. Still early, but the foundation needed to make an RPG is slowly coming together. I had to shelve it for a bit but I want to pick it up again soon.
Here’s some screens and mockups (note some GIFs needed to crunched to 1x size to fit in imgur upload limits)
(tileset / map mockup)
(item system - capture from the NES ROM)
(overworld jumping mechanics - capture from the NES ROM)
(a mockup of a battle scene – not yet implemented in game, in typical Verge community style of not having a battle system yet)
- Wandering Magic, an action RPG, which started as a PICO-8 demo title (released for the 3-color Jam in late 2017).
Here is the original jam entry – you can play in your browser, and it’s about 30 minutes in length. It features simplified Ys-like bump mechanics for the combat, as well as simple leveling system that balances fast-paced grinding with finding/buying new items to enhance your combat abilities. Most areas are gated by your player’s stats (health, attack, defense), and equipment works as key items.
I wanted to rewrite the game, so I ported the game to regular Lua + Love2D, as a cleanup exercise to make the PICO-8 source legible code again. But eventually, I wanted to rewrite the game again in C, as something that can compile out of the box with SDL, doesn’t require a dynamically-typed scripting language, and doesn’t depend on a heavyweight engine or content pipeline. I also wanted to double the game’s internal framerate to 60FPS (rather than PICO-8’s default 30FPS), increase the size of art assets (already redrawn but not integrated), write a coherent quest, and make the action more compelling. The bump combat mechanics were neat, but sometimes it felt like the enemy melee damage could be telegraphed better so the player could evade things more easily.
(dark mages teleport around and shoot fireballs at you, as slimes spawn in from the sides.)
(fighting a skeleton that guards the entrance to the next area.)
- vg - a virtual console system in C (working name, but might stick). This probably requires some elaboration – it simulates the experience of writing games for older consoles, but picks limitations that can be nicely fitted to a modern widescreen 16:9 desktop with gamepad support.
It calls two user provided entry points, one for resetting the game, and one for updating the next frame. All data shared with the engine is global arrays, or through functions that act as ‘system calls’ that convert user-provided data into backend internal texture formats/sound formats/etc. Games are able to tileset graphics and palettes, and then draw them using either tilemap or sprite primitives, which are hardware accelerated. The user of the engine doesn’t need to know the nitty gritty about how the graphics get internally represented (it may be different depending on the platform), and can talk about things in terms of 2D tiles and sprites. Ideally, all games include all data directly as static global data in the source program, and work without solely using the exposed engine functionality. Programs can be written using no stdlib/stdio (except internally to the engine), so to allow extra portability, minimal load times, avoiding the runtime overhead of dynamic memory management by using the static data segment instead, and minimizing runtime issues relating to file I/O.
The screen is resolution is 320x180 (very close to the 320x200 used in the Verge days, but it’s 16:9). Backgrounds can be made from 3 tilemaps of 64x64 each, which can either be comprised of 8x8 or 16x16 tiles. You also get 128 sprites which can be between any of the 3 layers. Tiles and sprites can have 16-step alpha blending applied, and palette remapping for hitflash effects and color swaps. Tilesets are capable of holding up to 512 16x16 tiles at once. The sprite layer and individual tilemaps can select which 256-tile window they are allowed to see of tileset (so one layer could point at a font, while another could be used for the main background graphics or sprites, the arrangement is up to you), Palettes are 256-color 24bpp RGB data. It’s possible to update the tileset graphics on the fly (to load another tileset or modify the current one), and upload new palettes. Input supports gamepads or keyboard input. Persistent saves of up to 16KB are possible (this limit might be expanded)
For audio, it supports wavetable sound synthesis (similar to the PC Engine, SCC soundchip on MSX, Namco N163 expansion chip on the Famicom, GB wave channel, etc) with 6 channels. There is storage reserved for holding short 32-step wave samples and instrument envelopes. There is an MML-like SFX command data that can play different notes, change tracker speeds, apply pitch slides, note slides, vibrato, etc. Playing songs or sound effects works by playing different pieces of the sfx data memory, and is written so that multiple sfx issued on the same frame are played together (for allowing polyphonic music with synchronized channels). The audio thread can run on its own, in parallel with the main game logic, but receives updates from the main thread at roughly 60FPS during normal circumstances.
There’s tools for importing tileset assets from PNG files, as well as converting text files containing an MML-like domain specific language into binary blobs that contain SFX commands.
So far I’ve managed to get a working engine with an example program that I wrote at the same as the engine, need to write actual game with this next. There is a backend currently for SDL that so far compiles on Windows, Raspberry Pi 400, and Emscripten with minimal dependencies (user-installed SDL on non-Windows). It is intended to be easy enough to write other backends in the future, so that porting to non-desktop platforms is a possible option.
Wandering Magic might be a good candidate to port to this engine, since it has enough features at this point.
(a little demo mockup)
…Wow that was a lot more rambly than I intended, lol. This initial post is a quite wordy summary of some projects I have going on and the state they’re in, but intending for future posts be more short and concise, unless something interesting warrants more elaboration. Let’s see if the habit of posting here will stick! Hopefully other folks will be posting on here too, to keep things interesting.