EZGameBuilder Devlog: May 2025

TLDR: Lots of physics engine research, a few improvements to the editor, an asset manager, ezgb will eventually work on a ton of old consoles, and there'll be a very crappy pre-alpha next month.


To start things off, I'll clarify some things I mentioned last month so there's no confusion about what EZGB is. 

1.  EZGB will be able to do basically everything efpse can do, and more. That includes 2d billboard sprites, 3d models, scripts, FSM, custom modifiers, triggers, etc.. Literally everything but shaders.

2.  The tile-based map system is optional. The engine will also have an optional 3d terrain system (fully 3d with caves/overhangs). You can have both systems active in the same world, so if you want to use terrain for the outside landscape and tiles for the buildings, that will work. Or you can have a completely blank map and use 3d models for everything. The choice is yours.

3.  The tile editor will eventually have a top-down overhead mode, so you can still edit maps similarly to efpse if that's how you prefer to work. You'll also be able to switch between side-views for easier wall placement.

4.  The 'genre template system' isn't just a few included template projects with some placeholder prefabs you can duplicate or swap out. Each genre template will contain unique editors and tools catered specifically for that genre of game. So a 'retro fps' genre would have very familiar efpse-like editors. A 'racing' genre template would include tools for building race tracks, car editors, etc..  

5.  When I mentioned 6th-gen consoles, I was very serious.
This is *not* for making games with 'AAA' graphics, and it's not a competitor to godot/unity/unreal. This is an easy to use homebrew game engine, designed specifically for old hardware.
If you're looking to make games for modern consoles, you should use a different engine instead.
I won't be using any official console SDK's, and will only be porting EZGB to consoles which have legal, FOSS homebrew SDK's.  
If you don't care about legacy platforms, I recommend using godot, unity, or unreal instead.
This project is my small rebellion against the poor state of modern gaming and the wasteful mentalities that tech companies foster.

Planned platforms, in no particular order:
- Windows (XP+)
- Linux / steamdeck (+ steam api support)
- macOS (probably no arm builds, I only have an x86 hackintosh)
- iOS (~Apple A5 or newer)
- Android (flagships from ~2013 or newer)
- PS2 (will be one of the last platforms)
- PS3 (will also be one of the last)
- PSP (will be one of the first supported platforms)
- PSVita (will also be one of the first platforms)
- Gamecube (need to investigate libogc legality)
- Wii (same as gamecube)
- WiiU (low priority, so probably later)
- Switch (probably early) 
- 3ds (depends how different citro3d is from gles)
- Xbox  (probably one of the last, as the opengl port isn't very complete and I'll probably need to learn pbkit)
- Possibly Xbox 360 (need to investigate the legality of the shader compiler required for libxenon)
- Probably Dreamcast (I don't have one yet)
- Possibly Windows Phone (very low priority)
- Possibly FreeBSD (if it compiles with no changes from the linux version)
- Possibly SerenityOS (ditto)

This isn't something I'm taking lightly, and I'm fully aware of the amount of work which will be required to support these platforms.  
Some ports will be relatively easy, but most will require a lot of time to optimise to their greatest potential.
The PS2 is an absolute monster and will probably take the most time out of all the console ports, but I'm also very keen to tackle its weird hardware setup, so maybe it will come sooner than some of the others consoles.
For version 1.0 though, I'm only planning on supporting windows, linux, and one of the 'easy' platforms that require a different rendering backend, like the PSP.  
This will help make sure I'm sticking to resource limits and keeping things portable, while also avoiding the burdern of maintaining too many platforms before the engine is in a more complete state.  

I've also planned the first pre-alpha build to be released next month.  
To be clear, you won't be able to build functional games in the pre-alpha build, it's purely a tech demo for people who are curious.  
But it will help give you a better idea of the current state of the editor, and will help to demonstrate changes between each progress update.
You'll be able to create, edit, and save maps, but there likely won't be any gameplay or entity editors yet.  
Depending on how much time I get, there may also be a basic map viewer for windows, linux and the psp.


Anyway, that's enough talking about the future. Lets talk about what's been done since the last post:

- You can now place modified tiles in build mode.
- Custom tiles can be rotated with the 'r' key.  
- There's efpse-style ambient lighting to make walls/corners more obvious.
- There's now a per-project asset manager, which assigns globally-unique ID's to each texture, tile, decoration, etc..
This makes it easier for the editor to handle missing assets, move assets between projects, and makes switching between maps cleaner.
- The map/chunk system has been tweaked to make it easier to support streaming levels to/from disk.
- Some refactoring. The project originally started in C, but I shifted to C++ because it reduces the mental overhead that comes with memory management, and function/operator overloading makes the code neater.
There's still some C-style code that could be cleaned up, but it's not a high priority right now.
- And lastly, a bunch of bug fixes! Not very exciting when you didn't know which bugs existed in the first place.


While I didn't spend a lot of time working directly on the editor, I did spend a fair bit of time time searching for a  lightweight physics engine which will run well on all the planned platforms.
After researching, benchmarking, and comparing various physics engines, I've decided that Bounce will be the physics engine EZGB will use. It's completely free and open source, is currently being used in a game engine that runs on the PSP and Dreamcast, has some great demos, and it can easily simulate 100+ colliders with just a few kilobytes of memory. I haven't done any determinism tests to ensure cross-platform multiplayer will stay in sync, but it's something which can be fixed later down the line if needed.

EZGB will support rigidbody physics with joints and constraints, so you'll be able to pick up and throw 3d objects, have enemies turn into ragdolls, drive vehicles over bumpy terrain, etc..


And..... I think that's everything worth mentioning right now.
Next month's update will be posted here on the EZGB itch page, not on the efpse ce page.