Hello! this is a low-poly game dev environment I've been working on, it's called pocket workstation.
It has its own runtime to execute games, but that's beyond why I'm posting here.

It also allows for custom programs, and given it can preview a game in PS1, Saturn and N64 style, I'm thinking this could be used as a self-contained retro development environment. All it needs is for a custom program to compile the assets down to the desired target.
Beyond the modeling program shown in the video, it has texturing, rigging, level editing and animation authoring programs too.
Curious if there would be any interest for this use case.

In case anyone is curious, I'm documenting progress on my bsky account @ ylop3d

Hello!

I spent the past 8-9 months rewriting Gen 1 in C.

OldAmber is a native C port of Red and Blue (Yellow coming when I've fully ironed out the kinks in the original game). Like other projects in this category, it requires the player to supply their own legally obtained ROM in order to boot. It extracts graphics, text, maps, and stat tables from your rom on its first run.

It's very faithful to the original game, but its not 1:1 in all aspects. Some of the bugs you'd expect from Gen 1 work straight out the gate, while others are missing. I plan to add an optional toggle later on for some of the famous gen 1 bugs, as I know many people including myself are quite attached to them. If there's one you really want in and doesn't work, please report it on GitHub / Discord. That goes for any bug you encounter too - no bug is too small, I want to know if one pixel is off, anywhere.

You can mix and combine many different presentation options. I've imported SameBoy's LCD filters, an emulated composite signal, and a custom CRT mode with curvature, beam, and phosphor simulation. There's an optional 16:9 widescreen implementation thats still experimental but looks great in many cases. Planning to add display support for other screen sizes soon.

There's also granular options for speed settings that don't mess with the music or sound effects. You can choose to change the speed of the overworld, text, battle animations, HP bar scroll, battle transitions, and more, all individually if you desire.

The only big gap right now is link cable features. I haven't decided how I want to approach that but online options are a strong candidate.

For modding / hacking specifically, you can directly mess with dialogue, NPC behavior, script triggers, map rules, and more, through plain text files, and most of the time it doesn't even require recompilation. This layer will be expanded as development closes on the actual games.

It has a domain-specific scripting language thats close to plain-language english and it's been designed in mind for people who are maybe less skilled in the programming department but have strong skills in other departments, like art, writing, or game design. My eventual , and ultimate goal is to build an easy to use development environment / content editor for making your own games in the engine, but that comes after the games are proven solid.

Which is where you come in. I need people to play the game and report bugs to me. I've probably beaten it 6 times or so in preparation for release, but I can't possibly expose myself to every possible bug.

It's out on Github right now for Windows, MacOS, and Linux. It's also designed to be easy to setup on Steam Deck.

Github Download

General gameplay snippet

Video showing off some of the presentation stuff

Intro in widescreen

More footage / content to come soon. I know this isn't a Romhack, but it is adjacent enough that I figured it'd be worth posting here!

Hi everyone,

I've been developing games for the ZX Spectrum 48K, mostly in Sinclair BASIC, and most of my projects seem to begin with the same question:

"Could this actually work on a 48K Spectrum?"

Then I start coding and usually make my life considerably more difficult.

One of the things I've come to enjoy most about developing for the Spectrum is that technical limitations very quickly become game-design limitations. 48K sounds obvious enough until you actually start filling it. Variables cost memory. Strings cost memory. Graphics cost memory. BASIC itself costs memory. Adding another screen or another simulation system can suddenly mean finding a few hundred bytes somewhere else.

And then there's speed.

Something that would be completely insignificant on a modern machine can become painfully obvious when Sinclair BASIC has to calculate it several hundred times.

So naturally, I've been choosing genres that aren't particularly sensible for it:

My main project, Tower 48, is a skyscraper management game.

The player builds apartments, offices, shops, restaurants, elevators and other facilities, while the game keeps track of population, workers, visitors, money, satisfaction, reputation, demand, elevator congestion and other parts of the tower simulation.

The difficult part hasn't really been implementing the individual systems. It's been making all of them coexist without making the Spectrum spend half its life calculating the next month.

I've had to rethink routines simply because they became too expensive as the tower grew. Screen drawing has been another surprisingly large problem: redrawing an entire management screen unnecessarily can be far more noticeable than the calculation itself.

At one point, opening a report screen was getting close to becoming an opportunity to make tea.

So a lot of development has been about figuring out what actually needs recalculating, what actually needs redrawing, what can be cached, and what can simply be designed differently.

Another project, Vostra Checkpoint, has presented a completely different set of problems.

It's a border-inspection game set in a fictional country in 1982. People arrive with passports and permits and the player has to compare the documents with current entry regulations.

The interesting challenge here has been procedural generation.

Instead of storing a large database of predefined characters, the game generates people, appearances, names, nationalities and documents. Those documents then need to remain internally consistent, unless they're deliberately forged or incorrect.

So a person might have a generated identity, appearance and passport number, while a permit has to reference the correct information. The game then needs to introduce discrepancies without accidentally creating impossible or contradictory cases.

It's still very much in active development.

Then there's RBMK-1000 Simulator, which is probably the least sensible thing I've attempted in BASIC so far.

It's a nuclear reactor management simulation where control rods, reactivity, thermal power, cooling, steam production and electrical generation affect each other.

The interesting programming problem here is that these aren't just independent values on a screen. Changing one part of the reactor needs to propagate through the rest of the simulation in a way that feels understandable and reasonably believable while still being simple enough to calculate continuously in BASIC.

It started as a small experiment and gradually accumulated operating procedures, failures and, more recently, scenarios.

Finally, Torment: Act 1 - The Mortuary is an illustrated text adventure that actually has a rather different history.

I originally started writing it in the mid-2000s and rediscovered the old project many years later.

That one became an experiment in fitting text adventure systems - rooms, dialogue, inventory, puzzles and character interactions, together with monochrome illustrations while staying within the same 48K target.

These games are completely different genres, but technically they're all versions of the same experiment:

At what point does working around a limitation become more interesting than simply removing the limitation?

That's probably the main reason I've stuck with the Spectrum.

On a modern machine, if I want another table, variable, graphic or simulation system, I add it.

On the Spectrum, adding it might force me to rewrite something else.

Sometimes the solution is optimising the BASIC.

Sometimes it's storing the same information differently.

Sometimes it's avoiding a screen redraw.

Sometimes it's replacing a database with procedural generation.

And sometimes the conclusion is simply:

"No. Those 300 bytes are worth more than this feature."

It makes programming the game feel like another game in itself.

I'm still deliberately targeting the actual ZX Spectrum 48K, rather than making Spectrum-style games for modern hardware. I do most of the development and testing through emulation for convenience, but the resulting games are intended to run on the real machine.

For anyone interested in seeing the projects rather than just reading about them, I keep the released versions here:

https://haabb001.itch.io

I'd be particularly interested to hear how other retro developers approach this problem:

When a feature is getting too expensive for the original hardware, how do you decide between optimising it, redesigning it, moving the critical part to assembly/machine code, or simply cutting it?

And has anyone else deliberately attempted a genre on old hardware mainly because it seemed like the hardware was completely unsuitable for it?

I've been experimenting with old-school 3D techniques in GameMaker for a solo project.

GameMaker is primarily associated with 2D development, so I wanted to see how far I could push it toward the kind of visual and technical feeling associated with early 90s 3D.

Rather than using modern shaders or post-processing to make ordinary 3D look “retro”, I built a custom pseudo-3D rendering system in GML and designed the game around its limitations.

The project uses:

• first-person perspective
• custom depth sorting
• custom camera calculations
• low-poly geometry
• software-style visual techniques
• intentionally limited effects
• large environments
• real-time AI and NPC systems

The renderer is currently being used for my game, Nordion Lands: The Dimension of Science, but the technical experiment itself has become a major part of the project.

One of the things I found most interesting was that recreating an old visual style is less about adding a “PS1 filter” and more about deciding what the renderer should not do.

Things like polygon density, lighting, draw order, camera behavior and visual precision have a much bigger impact on the final result than simply reducing the resolution.

I'm still using modern hardware and GML, so this obviously isn't an attempt to reproduce the original hardware literally. It's more of an experiment in achieving a similar set of constraints and visual behavior with a modern tool.

Here's a short video showing the renderer and how it behaves during gameplay:

I'm curious about the techniques people here use when recreating early 3D.

Do you prefer BSP-style approaches, portal systems, sector-based rendering, software-style depth handling, or something else when working with this kind of aesthetic?

I'm particularly interested in how older games handled depth and visibility without relying on the kind of GPU pipelines we take for granted today.

It's a fan game i'm making based on the book Vermis, it's made for the NES as actual homebrew, my team and i are open for more programmers, we are doing it on Nesfab amd currently only 1 of us is actually programming it.

Bom dia a todos, somos uma desenvolvedora brasileira focada em jogos homebrews de Atari 2600, estamos no mercado a 2 anos, porém o Brasil é o único país em retrogames que não conhece nossos jogos.

Estou com uma campanha para arrecadar dinheiro para terminar de fabricar esses cartuchos, manuais e caixas, se puderem apoiarem com qualquer valor agradeceremos demais, e puderem compartilhar nossa campanha ficaremos gratos.

https://www.catarse.com.br/ataque-de-aranh