@openchanter

Another devlog as I continue to work on my other project that uses this engine as a dependency. Since I’ve been actually using this engine for making something real, I’ve noticed that it has quite a few flaws that I didn’t catch earlier on in the creation process. For example, when the window resized on the Y axis, the scale of the content within the window would also scale. This actually ended up causing a big issue with my new project as I had to convert screen-space mouse coordinates to positions in the world for placing objects in the editor. Fixing this was pretty simple and I just swapped out the old render resolution for a render scalar that gets multiplied by the window resolution to calculate the render resolution.

Over the time of creating my new project there have also been some other small issues with things such as the button hitboxes and the engine not having the ability to resize objects in real time that I have since fixed.

For the real time object resizing issue though, it was especially annoying because I had to resize the THREE.js Mesh object directly using the .scale.set() method on it which cannot be simply supplied with the size in pixels you want the object to be and is separate from the size of the geometry. To solve this I had to calculate how much I would have to multiply the scale of the geometry by to get the new scale. This ends up being the math equation, newScale / originalScale.

Attached to this devlog are images, showing the window scaling fix in action as well as the scaling fix as it is used in my game. Now the scale of pixels stays exactly the same regardless of the scale of the window, and the 2nd block shown in the image with the Tiles picker is being scaled and rotated when the player hovers it.

Overall, this project is becoming quite a bit larger than I originally intended as I work on it more while actually using it to make a real game. Thanks for reading this devlog!

Another quick devlog as I’ve been adding features while trying to make an actual game with the engine!

I realized that I hadn’t added offsets for colliders, trigger colliders or collision callbacks, so I added all of those and that works now, and I also realized I needed a special renderer that could draw using THREE.js’ InstancedMesh so I created the InstancedRenderer component that allows for that InstancedMesh to be used, this should afford a decent performance boost for any games that have the ground made up of tiles (if used correctly).

The image attached is an image of the game I’ve started working on!

Another short devlog, again about UI!

I got around to adding a proper button component to the engine that supports both a hover and click state! Currently I am using it in one of the demos for a button that slows down time to 1/10 speed when clicked.

When I was trying to get this working, I realized I had a pretty major bug with how the scale of the window worked, which was causing issues with mouse inputs not lining up correctly with the engine’s visual output, but after fixing that it works great!

The implementation for usage is also pretty simple with the Phoenix.Button() component just having two optional fields, one for onHoverCallback and one for onClickCallback. Here is an example of an onClickCallback being supplied to a button component:

new Phoenix.Button(() => {
    app.args.timescale = (app.args.timescale == 1) ? 0.1 : 1
})

Thanks for reading my boring UI yap again!!

Very small devlog this time!

I’ve now added support for screen-space rendering of objects (rendering of objects relative to the screen rather than the world). This will be very important for adding proper UI components such as buttons, switches, sliders and text boxes to the engine later!

With the addition of screen space rendering I also added a new component specifically for it, being the UIRenderer component. It behaves exactly like the standard Renderer component, but it renders to the THREE.js scene that the output of the main scene is rendered to for applying screen-space shaders. This also has the side effect of UI elements being able to ignore the current screen-space shader, so they don’t get distorted or become unreadable in any other way.

Here’s a little code example for how the screen-space rendering works when creating an object:

app.addObject(app.createObject(
    new Phoenix.Transform(new Phoenix.Vector2(64, 96), 0, new Phoenix.Vector2(16, 16)),
    new Phoenix.Sprite("assets/brick.png"),
    new Phoenix.UIRenderer(1)
)

This little bit of code would create an object at coordinates (64, 96) but it would follow the camera rather than staying put in the world!

In my next devlog I plan to actually add components for proper interactivity with UI components!

Thanks for reading my yap!! Byeeee!

Hiya there! Another devlog on this project!!

This time I added an actual particle system to the engine that can be used to spawn a bunch of little particles. It’s still missing a bit of customization such as turning off gravity for particles or the ability to change particle’s initial velocity, but so far it isn’t causing any lag and seems to work well! I had to figure out THREE.js’ InstancedMesh system to get this working without making the game run horribly, but I got it and it works now!

The docs are also updated to reflect this new feature. And the ParticleSystem is used like any other component by just adding it to an object like the following:

app.addObject(
    app.createObject(
        new Phoenix.Transform(new Phoenix.Vector2(0, 0), 0, new Phoenix.Vector2(32, 32)),
        new Phoenix.ParticleSystem("assets/brick.png", 10, new Phoenix.Vector2(24, 24))
    )
)

The entire system for particles is self contained and doesn’t rely on any other components like the Renderer and Sprite because I felt it would be better to separate it due to the fact that the particles using an InstancedMesh, and the user might want to have particles have a different texture than their emitter.

As shown in the images, the ParticleSystem can support a lot of particles and from some testing it is able to handle 10, 1000 and 10000 particles with no lag, but 100000 particles is stretching it a bit. I mean who would put over 10000 particles on screen at a time though, right?

Yay! Another devlog and even more hours poured into this project!

This time I finally got around to reworking how the engine works to actually allow for objects to have children! In the past all objects were stored in a flat array which didn’t allow for any object parenting of any kind, but now the root of the scene is just another GameObject, so it can have children and those children can have children and so on forever.

As you can see in the example photos, the brick object on the left has a smaller checkerboard-pattern object as a child of it that moves relative to it’s parent’s rotation and position.

On the development side of things, adding objects to the scene as a whole remains exactly the same with the way the addition of objects simply being changed to having them be children of the scene root, but now all objects have a new method, GameObject.addChild(object: GameObject). This allows any object have a child added to it, for example:

player.addChild(app.createObject(
    new Phoenix.Transform(new Phoenix.Vector2(0,0), 0, new Phoenix.Vector2(16, 16)),
    new Phoenix.Sprite("assets/null.png"),
    new Phoenix.Renderer(1)
));

This would just add a new smaller object to the player object with the null.png sprite, and this is exactly what is happening in the screenshots attached to this.

I decided to use the feature I added to the engine a while ago that allows for custom screen space shaders to create a lighting shader for the game based on some simple raymarching! I’m going to work on getting it more polished and then implement it as a variable exposed by the main engine as something that can be used in any project.

The usage of the shader isn’t too complicated, it just requires data about the lights to be supplied to the shader via uniforms.

let lightPositions = [
    new THREE.Vector2(-128, 128), 
    new THREE.Vector2(64, 128)
]

let lightScales = [
    new THREE.Vector2(512, 512), 
    new THREE.Vector2(512, 512)
]

let lightColors = [
    new THREE.Vector3(1,0.3,0), 
    new THREE.Vector3(0,1,0.3)
]

This would be supplied to the App’s options to override the shader.

shaderOverride: {
        vertexShader: Phoenix.DefaultVertexShader,
        fragmentShader: LitShader,
        uniforms: {
            uLightPositions: { value: lightPositions },
            uLightScales: { value: lightScales },
            uLightColors: { value: lightColors }
        }
    }

And then positions should be updated every frame to keep them in world space.

app.addFrameIntervalCallback(() => {
    let lps = []
    for (const lightPos of lightPositions) {
        const p = new THREE.Vector3(lightPos.x, lightPos.y, 0);
        p.project(app.camera);

        const x = (p.x + 1) / 2
        const y = (p.y + 1) / 2
        lps.push(new THREE.Vector2(x, y))
    }

    app.screenSpaceShader.uniforms.uLightPositions!.value = lps

    let scls = []
    for (const lightScale of lightScales) {
        const x = lightScale.x! / rScale.x
        const y = lightScale.y! / rScale.y

        scls.push(new THREE.Vector2(x, y))
    }

    app.screenSpaceShader.uniforms.uLightScales!.value = scls
})

Edit: I completely forgot about this but at some point I added support for animated sprites using the AnimatedSprite class which can be supplied an array of strings representing the paths to the image for each frame as well as a animation rate (number of game frames each animation frame is shown for)

I did a bunch of backend stuff, adding features and making the engine overall better. My most recent addition to this is the use of a unified renderer component, where rather than having separate components handling the rendering of text, canvas sprites and normal sprites individually and with duplicate code, the main renderer component automatically finds any sprite type and renders it!

For example, in the scenes below: the text in past versions would have been rendered with a TextRenderer component, whereas now there is a TextSprite component that feeds a texture to a Renderer component on the object.

New Version

const text = new Phoenix.TextSprite("Hello world!", {fontSize: 32, backgroundColor: "#7fefcf", padding: 8});
app.addObject(app.createObject(
    new Phoenix.Transform(new Phoenix.Vector2(0, -83), 0, new Phoenix.Vector2(text.texture!.width, text.texture!.height)),
    text,
    new Phoenix.Renderer(1)
));

Old Version

app.addObject(app.createObject(
    new Phoenix.Transform(new Phoenix.Vector2(0, -83), 0, new Phoenix.Vector2(0,0)),
    new Phoenix.TextRenderer("Hello world!", {fontSize:32, backgroundColor: "#7fefcf", padding: 8}, 1)

Big update! I finally actually got around to making the demo scenes built with this engine publish on GitHub pages (here). I also added a circle collider component and a text renderer which in turn relies on a HTML Canvas Renderer so there’s also now an easier way to create procedural assets for games.

I finally added support for getting inputs within a component without using a web API to register an event listener and then having to deal with destroying that when the object get unloaded! I then updated the test scene to reflect that with a new component added to each object in a tower that adds an impulse when the W key is pressed. The scene can also be switched with the H key.

I added screen-space shader support for now, the shader can’t be overridden but I’ll change that as well as allowing for the shaders attached to individual objects to be overridden.

So far I’ve added all the basics, scenes, objects, physics implementation and rendering. The rendering is currently using a basic HTML canvas method, but I am planning to update it to THREE.js for faster rendering and support for complex shader effects. This will probably be a relatively short project and I probably wont make many devlogs for this. It’s kind of hard to show off an engine with images, and without showing the code, so I don’t know how much visual progress I’ll be able to show, but I’ll definately be able to show a lot more for the game I’m planning on making that will use this engine!

For this update, I worked a lot on cleaning up the code, making sure that there are now significantly less type-check errors present, and overall it’s easier to develop more features in the future. Onto things of actual substance I added though, there are now actual coins inside the lucky blocks scattered throughout the game as well as coins that can be placed directly in levels in the editor! Sometime soon I do plan to add some sort of asset caching system to the main game so that it isn’t trying to fetch assets as you are playing.

I quickly added some hot air balloons, they aren’t in any of the campaign levels but they’re fun to play with in custom levels.

I made some improvements to the UI, such as rounded button corners and a outline when hovering a button. I fixed some bugs with both the player and enemy movement and now the enemies are (a bit) more reliable. There’s also now grass that sways in the wind and interacts with the player in the game! Oh and I added a main menu screen.

Also had to do some pretty major reworks to how the game loads levels, and I moved all of the code for that to a separate file where I can use it from both the normal levels and the main menu.

Another quick devlog because I fixed some of the issues that existed after the previous one. I also made it so that anyone can enter the editor with any level loaded in it from any level and whenever you get to a new level in the campaign it saves your progress. I know this will cause issues with players not being able to replay the game so I will add a button on the title screen (whenever I get around to making that) for resetting save progress. Oh also I think most if not all of the bugs with movement getting stuck in a certain direction are fixed both in the editor and in game.

I’ve decided to make the game and the editor feel more like one cohesive experience rather than two separate applications, so I’m adding a pause menu as well, and I’m changing the editor to be located at the website’s root rather than being a separate webpage. This will also hopefully make the experience playing the itch.io build of the game better. (note: none of these changes have been published on any public instance of the game yet because there are some unresolved issues with the editor however I have pushed my work from today to GitHub)

Apparently there was and issue with the level editor that caused it to not render the icons in the UI, so I fixed that. I also wrote the README for the project including information about the project such as the bundler it uses (vite), controls, and documentation on running the app.