Bout time for another update I think.
So I got the 3d movement and spawn/exit location picking working ish just after the last post, so now you can see what it'll look like in game:

Yes movement works.

Then I also made the map look much better too with map zoom and scrolling buttons:

The reason I say the entry/exit location picking works-ish is because I'm not really satisfied with the location selection, basically right now it just chooses the tile, then loops through the tile to select the nearest "open" square, it does this because I didn't bother to have it track which tiles have the spawn/exit values in them, so right now it'll end up putting the player and the exit into the middle of a hallway.

You can see the player as the yellow circle on the above map, and the exit as the blue square.

I've thought about potentially having the map track/only update if you've seen an area, but that seems like potentially scope creep I don't know that I care for, so I'll probably look into that after I get enemies and combat working, since that's like the next things required to make this actually be a game.

I think next time I'll try to have more UI figured out, not sure I'll do inventory, but at least the scrolling text showing what happened, or what is going on would be nice to have so I can potentially have debug printing in there instead of to console.

I may also see if I can set up a jenkins job to build this as well, since I already have a jenkins semi-working on my laptop, it has bad uptime, but if it works to build Linux, no problems there, then I might take a break from dev on this project to work on making a docker image to build windows builds from linux, which would be helpful so I can just press buttons to get both builds of this project. Since I plan on chunking this project out commercially prior to finishing up my game engine project.

And consider the random walk method of improving connectivity and ensuring more of the map is connected to the rest working!

Much better connectivity and much better variety in terms of which direction the halls cross each other.
One caveat to this is that if no tile is found, then the default tile with no connections is used, that might be a problem since that can block off paths that may be wanted. Not sure if I want to make the default wang tile be completely connected or not, but that would prevent any blockages for sure, so then at least if spawn and stairway down are both on the random walk, then they will be connected.

I also have 3d rendering working for floors/walls, but not really any of the other tile types.
Issue is that I haven't done the player spawning yet, so you just spawn in the wall at 0,0, and can't move out of there.

I managed to get a type of procedural generation implemented using wang tiles, I'm using square wang tiles and representing everything in a grid based system, which lets me easily input tile data manually by filling out integer arrays. So I pre-fill a bunch of tiles, and then I have a separate array which holds the connectivity data for each tile, saying what sides are meant to connect to other tiles and where.

Using that data, I can generate reasonably okay looking maps, here's a 5x5 wang map:

Basically I have it consider the edges of the map having blocked connectivity, then have it randomly select tiles from the set of pre-made tiles that will fit in that location. This is great for randomly generating a disjointed/disconnected map, and then I can also add some tile data for enemy, NPC, Item, door placement. In the picture above you can see brown squares where the doors would be, and a little blue square for where a potential stairway could be placed.

I haven't figured out how to actually place the player spawn or stairway down yet, I hope for it to be like nethack, where you basically "spawn" at a stairway that goes up to the previous floor, and then you try to find the stairway going down to get to the next level, so ideally I'll need a way to make sure that the spawn/upstair is connected to the downstair, so that it's possible to actually make your way to the end of a level.

While I could implement some kind of wondrous pathfinding algorithm to do this, I don't think that's the best solution, definitely not the fastest and most bug free. I think instead since I already have it choose tiles based on the connectivity of the tiles that are already placed around it, maybe I could pre-define different connectivity maps for levels, so it could randomly choose a connectivity, and then it would know that any tiles that are defined in the predefined connectivity map as being connected are free real estate for being a possible stairway down or up.

The minor issue with this of course is having to make sure that all the tiles are also internally connected within themselves, which does limit the ability to have potentially interesting tiles, but I'm also thinking of potentially letting players just kind of, bash down the walls of the dungeon anyways, maybe with a pickaxe or a shovel or something. That seems like a solid way to help provide a way out in case the player gets stuck, and/or the map gen is half broken. Only issue is figuring out how to tell the player where to go, as well as how to keep them from escaping the map.

Okay and there's also the issue of having to manually make multiple connectivity maps of multiple sizes, since I plan to be able to hopefully scale the floors to be bigger and bigger the farther down you get. Costs me no extra effort on my side to generate massive floors as long as it's purely random generation with no manual connectivity maps.

Maybe instead of manually creating connectivity maps I just did a random walk for a bit instead? that would ensure some things are connected, would let me place tiles, and would mean less effort than manually creating the connectivity as well as allow for massive levels at no extra manual effort, and allow for more variety in map layouts than just the same 3-5 connectivities I would make manually. Plus it could totally wrap around on itself and have intersections if needed, but I've never done a random walk before and idk how well that would work to create a workable map, or how many steps it would need to have for different sized maps.

So that's all sort of figured out, here's what's next:

• Figuring out classes
• Finalizing player stat generation for classes and generating starter inventories
• item using/management
• UI
• representing the 3d world
• combat
  • I've never designed a turn based rpg and been satisfied with how the numbers are all used for combat, I've thought of looking into how GURPS and DnD do it, and then ripping them off, but I think that's likely to run into licensing issues, and I worry it'll be too similar to other GURPS or DnD based games. If you have any experience designing turn based RPGs and figuring out how to make numbers mean things, hit me up with ideas!
• coming up with some kind of macguffin goal to the whole thing
  • seems like players won't want to endlessly trudge through a dungeon, maybe having some purpose to go down there for, and then having to get back out or come back a different way would help add depth or something, but any likelihood of having a return trip would probably be stretch unless I can find a way to make the return trip fun again.
• finishing up map gen to generate enemies and items, entry and exit points

And some stretch goals:

• Shops
  • I'm thinking similar to nethack possibly where items are laid out on the ground, you can pick them up and examine them, and then a shopkeeper stops you if you try to leave without paying, but items can be snuck out via teleportation or other ways, or the shopkeeper can just be disposed of.
• maybe some more story or something.
• pets maybe?
  • in Nethack you start off with a pet, which is very useful because they will sometimes pick up items and drop them on their own, combine that with what I said above about shops in nethack, and yeah very useful to try to keep your pet alive if you can. Definitely try not to accidentally kill your pet, I've done that before.
• Deities?
  • at this point it's probably ripping off nethack too much and I may as well just crib nethack's code and add 3d rendering on top of it, but hey it's a classic for a reason.

Tune in next time for hopefully some kind of UI and/or seeing the world in 3D!

Yeah I decided not to do the mystery/detective/story based game for the crunchless challenge, because I'm not fast enough at writing to be able to write a story between now and november to implement.

So instead I decided to go with a dungeon crawler roguelike idea, basically inspired by Nethack and Ultima Underworld.
I figure if I can get world gen working then I can just make a crap ton of tiles and basic combat and boom there I go.

Also decided to use Raylib for this project, which I'd never used before, and I accidentally slipped yesterday and basically got a whole main menu, character creation screens all done, and some basic character stat generation working, although I haven't figured out how to have the RPG combat work yet so I might need to rehash that at some point.

Working on doing the map gen now, basically I plan for it to be done using Wang tiles, I would do herringbone wang tiles but having never done wang tiles before I think it's better to start off with basic square tiles and go from there.

Here have some screenshots of what I got together after work yesterday:

Maybe the only thing I need to update/change, is that the main menu uses keyboard input only to select the options, and everything else is mouse only, so I need to figure out how to allow both keyboard + mouse for everything, but tbh maybe going mouse for most things makes more sense.

Right so I haven't done much of anything on anything this past week, other than a few small things on the pixel art mystery game prototype.

I added a character who collides and moves the camera with him, and I added a single object that lets you interact with it, and it'll run a custom script when interacted with.

But I also wanted to mention that I basically joined a game challenge for it: the Crunchless Challenge. Since of course, what's better to do with your half-baked idea than to join a challenge and impose a deadline on yourself?

The idea of the challenge is that it's not a competition with voting, ranking, or anything like that, its more of a personal challenge to plan out all the other things than just chunking out the game, so by the end of it, I should have a whole game made, polished, marketed, and up for sale on a store page, without any crunching.

Posting Devlogs counts as marketing as far as the game challenge is concerned, so maybe I'll be a regular at gruedorfing for the next few months!

Also since its not a competition, there's no hard start date, you can resurrect old projects, use code/assets/pieces you've made before, etc. it's more of like a prompt to kind of get yourself going.

I think the main difficulty here of course is going to be similar to all game jams, limiting your scope. I basically have a whole list of features I want in this game idea, and I'm going to have to cut it down to a reasonable number, and then like, write the story. Deadline is the end of November to have it all completed, polished, marketed, and up for sale.

I think my current plan is to just have a small subset of the features/mechanics I want in for that, and then just release a single part or chapter of the longer story in November, that way I can fulfill the challenge, get a demo/story hook out, and then maybe get some testing time on the mechanics I do have before I add more.

In terms of pricing I'm thinking a pay what you want model for the first chapter, or completely free. the idea being that it hooks you in to want to buy the rest of it.

Of course I'd also need to write a hook or cliff hanger or overall story plot thing, and I need to find a setting, I'm split between just sci-fi or trying to do some sort of period/historical setting, since that also sounds fun. My guess is I'll need to decide that before the challenge technically starts, which is at the beginning of November.

well I guess it's about a week-ish since my last post, and for consistency I should probably post again.

Not much to talk about on the game engine front, been writing boring json saving/loading code as per usual.

But I started a new project! hopefully it won't turn out like the last time I mentioned starting a new project in Godot and then stopped working on it pretty much that same week.

I've been playing a ton of Tales of the Neon Sea lately, got it free on Epic and boy is that a fun game. It's got some very beautiful pixel art, and it's a story based detective/mystery solving game, with all sorts of puzzles and such. it kind of reminds me of a point and click game, but it's also a side-scroller, and has some really slick pixel art and pixel animations.

I don't consider myself good at pixel art, I consider myself passable at it. But combine that with being reminded that pixel art in 3d with modern effects looks super cool, and being also passable at 3d modeling, I'm now in the process of throwing pixel art into 3d scenes in Godot and hoping it sticks.

This is one of those projects where I start diving into art first instead of any planning or story, which means its bound to die within a few eons, especially since I'm currently in the process of hand making normal maps for some of my tiles. Very tedious stuff, and I have no way of knowing if it'll look cool or not.

On the front of making the pixel art go into 3d, I'm not entirely sure on the method I want to use, Godot does support just straight Sprite3D objects, which is basically a 2d sprite rendered in 3d space, and they can be animated like 2d sprites, and have the option to be billboarded. However there's also this pretty slick addon for Blender I found called Sprytile which is free. Sprytile isn't like, always the easiest to use or the fastest most intuitive, but it does let you make 3d models with pixel perfect textures, either applying the textures onto a pre-made model, or making models with the textures, and it supports tilesets. so you can basically make a regular old tileset, and then map that into 3d.

i'm hoping to combine that with hand drawn normal and roughness maps in Godot, to make some PBR-ish pixel art so I can do some cool 3d lighting and GI effects to hide the fact that my pixel art is bad.

So far I haven't done much, but here's a quick peek at what I've got with a mostly default Godot scene, and a couple Pixel art assets:

Both the pixel art assets are Sprite3D for now, and the floor is just a CSGBox for now, with a very reflective surface on it to show off the SSR. I'd put some reflection probes in but I've found they are kind of shitty for a direct mirror finish like this and work better with more uneven surfaces.

I think the plan for if I ever make a character for this is to make a 3d model and render it out as pixel art in Blender, but for now I'll probably just use a box as the character and try to get some type of gameplay down. I'm hoping that with more of a point and click type interaction it should be simpler to do, maybe some side scrolling segments too, but hopefully I can get some kind of gameplay that consists of interacting with items, and maybe popping up panels to interact with for like, minigame type puzzles.

I think once I get a basic prototype with working gameplay, it'll be easier to continue from there and come up with art and story once that's there. That way hopefully instead of having scope creep from making a massive story and then burning myself out on having too many potential coding features, I'll be able to go the other way, do the coding and add the features/puzzles or the ability to have puzzles and do interactions, and then I can do the story writing and actual game design stuff once I have features that sort of work, I think/hope that workflow will let me not get super burnt out, or at least I can call it quits sooner based on being bored of the mechanics themselves, instead of being bored of making art.

Some progress on versioning but I don't think its totally finished yet, still want to take the version number and put it into the filename of the zip file that Jenkins spits out.

But on the saving/loading scenes front I've gotten a bit of progress, I chose a json library to use to save things out to json and started writing code.

Not sure yet if I like how the code is shaping up, but right now it makes most sense to me to have separate code paths for each scene saving/loading format, however I'm not sure I like that I have the separate formats in the SceneLoader specific code itself, or if I should have split it off to a separate utility to handle the specifics and I just broke the pieces up into different parts, so I'm sort of split on that since I suspect I"ll need to do the same shit for serializing other things should I need to do that, so we'll see how that goes.

I chose the Pico Json library for doing the json, it's a single header file json library, so easy to integrate and the API doesn't seem to be too much pain to use.

Basically I just use a picojson::value() to refer to a value, and if I want that value to be a JSON object I just make it be a std::map<std::string, picojson::value> and if I want an array, its a std::vector<picojson::value>. This is nice because then I can just make maps and vectors as normal and it works, only issue is constantly wrapping everything with the picojson::value and I don't tend to do the using C++ thing to use namespaces, so I type every little std:: or picojson:: out, and that seems like it'll get to be a lot of duplicate typing, since I'm basically looking at having each entity be one JSON object, with keys for each component in my ECS, and then each component is also a JSON object, which keys for its values, which are sometimes also JSON objects.

And there'll be arrays thrown in there in some places too

But yeah so that's my progress, started on Scene Saving and chose a json library. now the boredom of typing out code to save/load every single component. and then I get to do that shit twice when I add the binary save/load.

Maybe I should get an intern. Or come up with a better way to serialize this stuff.

Gonna update here again since I fixed it:

So the answer to the problem was in how I was transferring data between my update and render threads, I had used the shaders before without issue so I wasn't sure how it was not working.

See I send data between threads via loading up a RenderState with all the data needed to render meshes, etc. Well I added lights to that rather sloppily and forgot to add a line to clear out any lights added to the data, so the number of lights in the RenderState increased every frame, and apparently when you get hundreds to thousands of lights added in the same spot, it did that weird thing I was seeing before.

Part of what tipped me off is also that after maybe a minute or less the FPS would start dropping to nearly zero, and I figured it had to be something that was increasing or something every frame, and sure enough it was this leak causing the FPS drops as well as the rendering issue.

Problem Solved!

Now I'm thinking I'll put IBL off to a different release, so I split off that to a different story, as well as spotlights, I'm going to leave "3d lighting" at point lights and wrap this up, so only scene saving/loading and version numbering remain, version numbering is part finished and just needs some Jenkins love and it should be finished. So close to the first milestone I wanted!

Alright I actually have some progress to mention now! Decided that instead of trying to keep a weekly cadence, I'd do better by matching my posting with when I have things to post about, and that way I can try to use this to help keep my progress momentum at times instead of as a weekly workitem/todo list task that needs to be completed, it can be instead a "Hey I did xyz and I'm excited about it" kind of thing.

So first: I split the 3D lighting bullet for my 0.0.1 release into multiple parts, I didn't have any 3d point lighting or anything implemented yet, and was looking into IBL.
So I split the IBL out to 0.0.2, which was the pain part, and I"m working on representing 3d lighting data in the scene via ECS, as well as filtering out that data to the render thread when needed. And Lua bindings for adding that stuff to the scene.

That all works, only issue is I think in shaders or something.
Behold what a point light looks like with the same cube I had before:

Notice anything strange going on here?
Let's ignore the FPS: 28.884 part for now
It's in black and white or something for some reason!

Now I tested by having my shader output just "Diffuse" directly, so the diffuse texture is set up properly, so my guess is some issue with metallic, roughness, or normal shaders maybe? Not entirely sure.
I will say this would be a dope shader for a horror game, so I'm not entirely out of business here, but also I'm not convinced that the normal map is the right way round either.
Need to get renderdoc install on my Linux machine from the AUR so I can see the different textures, etc and try to figure out what's going on.

It's been a while, lots has happened, but not a lot on my project.

I'm on the process of gearing up to do the IBL changes, but there are just a lot of pieces so I've been a bit demotivated from my game engine.

However, today I added a second Texture class, TextureF to handle floating point textures, which will allow loading HDR textures.
The idea being that you load a HDR equirectangular environment map, and then I'm working on some code to convert that to a cubemap. Once that is done, I do some processing on it and I'll have a general environment map to do the IBL stuff with.

Just following the tutorial part by part for now, but eventually I'll need to go off tutorial and figure out how to blend that with some screen space, as well as local probes.
That won't be fun.

I'm going to focus for now on putting in the equirectangular to cubemap code, and then maybe making lua bindings, then chunk in the IBL stuff. Once the IBL stuff for the general environment map is in, I'll probably take a break from IBL and implement scene exporting/loading so I can brush past local IBL probes for now and get to my 0.0.1 release without worrying about too much IBL stuff.
Gotta remind myself to do baby steps, and that I have a ton of other scope creep types of items that will possibly be more exciting to do.

Speaking of the 0.0.1 release of my game engine, that's supposed to be the point where I could prototype a breakout clone game using my engine.
It is supposed to have these things working:

• Keyboard, Mouse, and maybe controller input
• 3D rendering
• 3D model loading
• Basic Lua Scripting
• UI buttons working
• text rendering

Basically enough stuff to have a "game" where you have a play button, hit the play button, and then you press keys on the keyboard to move something around on screen.

Right now what is left that I have planned on my Quire board for 0.0.1 are:

• 3D lighting
• Scene saving/loading
• Version numbering

So I'm basically there, and technically, if I really wanted, I could just push off all this stuff to later and make the breakout clone now, but I really want to get the basic IBL stuff finished at least for now so that I can have it behind me.
Also need to implement scene lighting in addition to the IBL so I need to figure out how to represent lights in the scene, and then render them.
I've done that lighting in the past but idk how to represent them in the scene, and I'm hoping to support spot lights, point lights, and potentially area lights.