Been following Fat Old Yeti/Idiot Coder tutorial on how to create a rogue-like in Go:
https://www.fatoldyeti.com/posts/roguelike-tutorial-0/

As ebiten doesn't work on my ubuntu anymore, I made the choice to use http://g3n.rocks as I wanted to play with it for so long.

I'm still at step 2, but adapting g3n to just do 2D work without knowing g3n that much and being rusty in OpenGL made it a little bit more complex.

I just want to make g3n be abstracted and render in 3D some really 2D game mechanics. It's a little bit challenging as some loops are not at the same place (adding tiles to a 3D scene doesn't make you recalculate their position in the render loop, so you need to account for them only once).

And having my children challenge me along the way: "hey, can you make the wall nicer?", "can you add a 3D model instead".

So I dug into how to load a material with Displacement map, normal map, etc.

I'm having fun and I'm pretty proud about the result after a few hours of tinkering.

#golang #3d #g3n #ebiten #blender3d

IT'S ALIVE!

Now I can move the character.

It was way more adaptation as ebiten is more immediate mode and g3n is more retained, but I kind of like it as it is. I don't have a render loop, it is handled by the 3D engine.
I just use the update loop to update the position based on KeyPress events.

Problem is, now it interacts with the camera control as well, so I get to move my character and change the camera settings as well.

#golang #gamedev #3d #g3n

very easy fix, map the z, s, q, d button for player move and keep the arrows for the camera.

I'd like more control over the camera from the code, though. There is some weird thing about it. I'm gonna find what's wrong with it.

I hacked on roublard since, I added some kind of "torch" light to the character, and made the whole environment dark with no ambient light.
It changes the mood!

#golang #g3n #roublard

I also implemented the collision system in ECS following https://www.fatoldyeti.com/posts/roguelike4/

But some places I could go through walls, and sometimes I was blocked by some invisible blocks.
I couldn't see the pattern and the tiles seemed to be at the right places. So I decided to debug it the classical way: `printf` to the rescue!

`.` are the floor and `#` are the walls. They should be all around, but clearly, they aren't. There is a pattern to figure out, but it eluded me until I counted it.

For performance reason, all the tiles were added in a slice, instead of slices of slices.
I added them one after another in a double loop.

Basically, I inverted x and y, and so it was creating a slice of column first then rows. But I was displaying them and computing them by rows first and column next.

Pretty basic error, but the debug print made it all clear very fast.

#golang #g3n #roublard #3d #RogueLike

it highlighted a problem where the display didn't show the logic, which is a code smell to me, and that's something I introduced while adapting to 3D.

On ebiten, the entities will be drawn every frame based on their location.
On g3n, I set their position at creation, and then the engine will render them where they are positioned. But the collision would happen on another part.

I wonder how I can make sure that WYSIWYG without coupling logic too much.

@dolanor reading your text, I guess an mediator/event driven pattern could address this.

Having built an ego shooter decades ago, I know it's a PITA to get things right. But 3D games are an example of Things-need-to-go-fast and additional computational iterations could skew the view building/physics calc etc. In my view that's the reason they end up rather strongly coupled.

An event bus controller could even trigger different goroutines for different calculation types like model change, view render, physics.

Synchronizing all these at the right game tick would be a challenge. Some might be cancelled or rendered if even wrong to benefit following calls of the same type.