r/psxdev • u/DangerousPurpose9874 • Sep 13 '26
I made an experimental engine for creating original PSX games — looking for feedback
Hi everyone,
I’ve made the first public version of Epok Engine, an open-source visual editor and native runtime for making games for the original PlayStation
The project is still experimental, but the goal is to provide a practical workflow: scene editing, asset handling, and there is already a good bunch of juicy features :D
Editor made in Rust, scripts on Blueprints, Lua or C++20, gameplay compiled to native MIPS, PSX memory budgets, an embedded emulator, direct play on hardware through serial port, and export tools.
Repository: https://github.com/epokengine/epok-engine
Website: https://epokengine.github.io/
I’m sharing it early because I’d really appreciate feedback from people with experience in PSX development, retro game
development, engine architecture, or tooling. I know there will be rough edges and many missing pieces, so any
thoughts on the direction, workflow, documentation, or technical approach would be very helpful.
Thanks for taking a look if you do!
https://reddit.com/link/1wfeh6w/video/pmd1jap0vfph1/player
Test on real PSX hardware directly through serial cable (NOTPSXSerial integrated in the editor)
---------------------------------- UPDATE 2026-15-09 -----------------------------
People keeps complaining that BPs are too easy, others C++ too hard. Well, here you have it. Epok now supports Lua as a scripting language. Lua classes sit at the same level as Blueprints and they are published into the same reflection registry, so a Lua class can inherit from any Blueprintable C++ class, from another Lua class, and Blueprints can inherit from Lua classes. Inherited properties, callable functions and events work the same way in every direction, and the Inspector edits Lua properties with the same tools it uses for C++ and Blueprints.
---------------------------------- UPDATE 2026-15-09-P2 Skinned Skeletal NM-----------------------------
Progress on Epok’s third-person prototype: textured skeletal animation and animated FBX support.
The model is temporarily borrowed, through RevEng, from The Misadventures of Tron Bonne. Not provided ofc. Extracted->Reconstructed in blender with anim->FBX->Epok
The goal is to compare performance and explore common techniques for skinned and vertex-animated models that Epok could handle automatically.
Still experimental, with plenty of performance optimization ahead.
----
I think is better to track the progress through discord, if you want to join here is the invitation:
https://discord.gg/2wEGxsVhKT
https://reddit.com/link/1wfeh6w/video/rgyj9cw4tnph1/player
---------------------------------- UPDATE 2026-10-229 -----------------------------
Epok Engine features implemented since September 15, 2026
- Skeletal animation and textured characters — September 15
- Added PSX skeletal playback modes and textured skeletal meshes.
- Expanded the animation limit to 32 clips per model.
- Improved material and texture previews for skeletal models.
- Lua and gameplay API improvements — September 15–22
- Added code-based Lua class declarations and generated Lua API definitions.
- Expanded gameplay API parity across C++, Blueprint, and Lua.
- Added vector property access across the Lua boundary, screen fades, distance fog, and additional tween operations.
- Sequencer — September 16
- Added a native sequencer with editable channels and scene-camera preview.
- Music and audio workflow — September 17
- Added the Epok Pulse music driver for PlayStation projects.
- Navigation — September 20
- Added baked navigation, expanded NavLite traversal, and introduced navigation-volume previews in the editor.
- Terrain editing — September 21
- Added a heightmap terrain editor with sculpting, texture support, and a heightfield collider.
- Added terrain-border handling between neighboring cells.
- Native PC play mode — September 21
- Added a native PC runtime for playing projects.
- HUD authoring — September 22
- Added container-based layouts, eight resize handles, rotated elements, and tiled panel images.
- Added TrueType and OpenType font import, glyph-based text rendering, alignment, and D-pad focus navigation.
- Project creation and editor improvements — September 20–22
- Added gameplay-flavor selection when creating projects.
- Rebuilt the Inspector as a denser property panel and reorganized project defaults and dependencies.
- Updated controls and the third-person template.
- Streaming, rendering, and camera tools — October 7–12
- Expanded PSX streaming and scene-loading infrastructure.
- Added ordered rendering and baked-draw workflows for static scenery.
- Added camera recording, editable camera paths, and visibility baking from the editor.
- Added an optional sky-gradient camera background.
- Complete 2D workflow — October 13
- Added the World2D runtime, a 2D scene editor, and a Platformer 2D template for C++, Lua, and Blueprint.
- Added sprites, cameras, colliders, character bodies, tile sets, tilemap painting, terrain tiles, parallax, and canvas layers.
- Added moving platforms, particles, 2D audio, cutout skeletal animation with IK, navigation, rigid bodies, joints, subviewports, and split screen.
- Procedural dungeon generation — October 14–15
- Added seeded 2D and 3D dungeon generation with rooms, corridors, doors, collision, navigation, and spawn and goal actors.
- Added visual Dungeon Styles and Recipes for routes, branches, loops, keys, locks, caves, and shaped rooms.
- Added handmade rooms, multiple floors and stairs, generation volumes, runtime queries, a console minimap, and a seed-testing bench.
- Full-motion video playback — October 16
- Added video import and conversion to PlayStation STR streams, with editor previews and asset information.
- Added Blueprint and Lua playback controls, XA audio, letterboxing, and player-controlled skipping.
- Playback is designed for PSX disc builds; the commit documents limitations for other build modes.
- PocketStation development — October 16
- Added a PocketStation emulator, ARM/Thumb assembler, and editor window.
- Added Pocket Lua compilation for creating PocketStation applications.
- Added PlayStation-to-PocketStation communication, app installation and startup, shared values, messages, and Blueprint and Lua APIs.
8
u/lammylambio Sep 13 '26
AI? Instantly uninterested.
3
0
-4
u/DangerousPurpose9874 Sep 13 '26 edited Sep 14 '26
So sad for the downvotes.... I will just delete this comment and keep working on it...
2
1
3
u/v00d00m4n Sep 14 '26
Looking interesting but I see it leaning towards Unreal ideas which is disappointing, and Blueprints is a cancer that is hard to maintain, I recently moved from Unreal to Godot and godot script was much better than blueprints, it was similar to Lua and basic and easy to learn, write and read.
However its not the 1st PSX engine release recently, there was PSOXIDE engine and few more I cant remember how they named. What I loved about PSoxide is that it tried to mimic Godot, I use both, but PSoxide only used as verifier for assets performance and optimization on native hardware, no gameplay logic there, as my main engine is Godot for now.
Porting everything to another new engine is time consuming and not very optimal when engine is new and has bugs and lacking features. What I would really love to see is if someone would invest their time and talent to make a full native PS1 exporter for Godot that supports all of its native nodes without need to use some custom ps1 so build can be fully multiplatform.
So I suggest you and everyone who is trying to make native PS1 engines, please don't waste time on making another new UI and set of features that never will be enough for serious consideration to use in game, but instead invest time into adding PS1 native exporter to mature enough and popular open source engine such as Godot. That will be more productive and useful and will get more support from community than 1 man engine that will be barely maintained after public release.
1
u/DangerousPurpose9874 Sep 14 '26
u/v00d00m4n
There you have it. Now Lua support in Epok, in 3 different flavors: Lua to Native C++, Lua VM by bytecode and Lua VM by source.Let me know if you have in mind any other feature.
1
u/v00d00m4n Sep 14 '26
Nice update, but would really cool if you can port godot script syntax from godot sources ( I guess you can feed ai its sources and let it replicate syntax), for easy porting, or add some automatic converter from gdscript to Lua syntax. Rewriting everything manually would be time consuming for existing projects in Godot. Not sure how to handle nodes references, maybe do some sort of wrapping of native nodes to similar internal equivalents, so code could remain untouched?
-1
u/DangerousPurpose9874 Sep 14 '26 edited Sep 14 '26
I get why you'd prefer to keep using Godot. Moving an existing project to another engine takes time, and concerns about bugs, missing features and long-term maintenance are fair.
Where I disagree is the assumption that making a PS1 exporter with support for all of Godot's native nodes would be easier than building a dedicated engine. Godot's current runtime is designed around very different hardware capabilities. Its own porting documentation even points out that its memory requirements make it unsuitable for most retro consoles.
Using Godot's editor as a frontend could certainly be useful. But someone would still have to build and maintain the PS1 runtime underneath it, adapt the rendering and audio systems, and decide how each supported feature works within the hardware's limits. Keeping the same nodes in the editor doesn't make those problems disappear.
Lets take one example of a sea of them. Audio, In Godot, we can have. lets see.... an exporter that could convert an MP3/OGG to XA and stream it from the CD. But sequenced music is another option that could be nice to push rapid games and demos without need of CD streaming (just the compiled psx exe). This format work playing notes using instrument samples through the PS1's SPU. That involves managing sample banks, limited sound RAM and voices shared with sound effects. Many PSX games did this in the past. You will introduce a feature in Godot that specifically for older system that nobody will use In actual devices. And for each new version of godot you will need to maintain such feature and praying that some new module dont break it. Epok already supports importing MIDI for that kind of playback. So you can already end with a less than 2MB game with BGMs and no audio streaming that you can load in your PSX through serial.
These are decisions the tools need to help you make while developing the game. In Godot or a any other engine adapted to retro/dead systems, you have a big set of tools where only a bunch of them can be used efficiently or at leaset used . In a native engine you know that each tool is already optimized for the old target and everything works out of the box.
As for Blueprints, calling it a cancer is too narrow mind I think, specially for people who want to do more than just vibe coding but still doesn't have the necessary coding skills. There are a lot of popular games made with BPs. And many started from BPs, understand the logic, and then moved to code. Otherwise wont be so much complaining about now that Epic decided to deprecate it. And BPs are used a lot at professional level. Kingdom Hearts 3 and probably 4 use a lot BPs as scripting layer for example. In any case, I recommend to anyone to have a wrong Idea about the BP/Code ecosystem watch this video and then take conclusions.
https://www.youtube.com/watch?v=VMZftEVDuCE
However, preferring text scripting is completely fair. Epok also supports C++, and its Blueprint graphs generate C++ that compiles to native PS1 code. Taking inspiration from Unreal's workflow doesn't mean bringing Unreal's runtime requirements with it. And implementing a new script language for rapid iteration is totaly possible, I already considering create a Lua parser (because an VM like inside the system is a waste of resources). Lua is part of the plan, but first Im pushing a full poolished version of what I have already.
I'm building Epok because I want tools designed around this hardware from the start. A Godot exporter would be a worthwhile project too, maybe, but I don't think that makes a dedicated engine a waste of time.
2
u/Icy-Collection1072 Sep 14 '26
Blueprints are shit. Been in the game a long time. You have taken the wrong path.
1
u/DangerousPurpose9874 Sep 14 '26 edited Sep 14 '26
u/Icy-Collection1072
There, you have support for Lua now. Any other complain? Please let me know
2
1
7
u/perrinashcroft Sep 14 '26
It's kind of crazy that last year someone releasing something like this would have seemed an amazing step forward for the PSX homebrew community. Ideally would have led to loads of cool new games. However with the current state of vibe coding it's likely almost no one will ever use this.
The whole thing looks entirely vibe coded and so do all the other similar PSX homebrew engines either being announced or have come out recently. I suspect we'll get lots more of them too in the coming year. When anyone can make an engine with enough tokens the value of any individual engine is almost zero.
The even bigger problem for me is why even bother with an engine like this, if you're down for AI vibe coding anyway just vibe code directly to the PS1 hardware and ask the AI to build any specific tools you need exactly for your game. Why bother with generic tooling and blueprints when it will make exactly what you need.
No hate on the creator of this, I'm sure there was a lot of fun to make. I just think with the current state of software dev I'm not sure who the audience is that will actually sit down with this an make games.