Just wanted to announce my new Patreon page. There’s also a link to it in the social media section at the top right of the page. The $1 tier (for now) will unlock all content, but I plan to post at least as much free content as paid.
Paid content will typically include assets (.blend, .fbx, .sbs, .sbsar files), while free content will typically be mini-tutorials, code snippets, smaller assets like textures, and discussions about tutorials and assets available elsewhere online.
Feel free to check it out, and please follow for the free content even if you aren’t interested in subscribing. ^_^
I’m not sure how many parts this will end up being, but I’ve been spending a good amount of time lately on programmatically generating both 2D and 3D meshes. Currently, I’m working on a library to expand the Unity primitives system to create meshes based on parameters. So far, I’ve built Quads (standard/two triangle, starburst array from center), Circles (starburst), Hexagons (starburst, compact), and Triangles (equilateral, right). I’m now working on basic spheres from sets of circles.
Single CircleSphere from circles
One thing that these shapes do, so long as the shape object is kept, is track vertices across changes. I’d like to do some basic deformation options down the road, but for now this works well because for the sphere, I create just a single circle, copy its vertex[] rotate it and copy over and over until it’s complete.
The above image, “Sphere from circles” is actually just multiple circle objects rotated properly. My current speedbump is sorting the vertices for the sphere itself. The vertex at (0, 0, 0) is removed, and the vertices where x=0 are only parsed from the first circle rotation. All vertices are then ordered descending by y, so from the top down. Now I need to also sort the x/z values in clockwise order so that the vertex[] basically stores the vertices as horizontal slices from top to bottom, then clockwise for each slice (or counter-clockwise). This is necessary so that the triangles can also be generated programmatically without intervention.
It’s been several months since my last post. That isn’t to say I haven’t been slinging code, but as I’m sure you all are feeling as well, this pandemic has really put a damper on mental clarity. Over the past several months I’ve come to a few conclusions: Labyrintheer is not mothballed, but is also on the backburner; this will become my devblog more generally for game dev and other code-related (or even tech-related) posts; and I need to post a lot more.
I’ve been considering creating some tutorials, both here and on YouTube, possibly with a Patreon backing options for additional content. I’ve also considered some small courses for Udemy. I might test the waters of all of the above to see what “feels” right for me.
All of that said, there should be more regular content being pushed out here, and I hope to see you all around. Thanks!
There was a small snafu with the user databases for my WordPress sites, but hopefully it’s all squared away now. Sorry for the inconvenience or annoying emails.
It’s been pretty busy with non-dev stuff the past couple of weeks. Also, I just built my first 3D printer, which has eaten some time. But sometimes it’s good to get away from the grind for a bit. I expect this week will see some work on Labyrintheer as well as a little bit of toss up time on a different project I’ve been mulling over for a bit. I have no plans to stop development on Labyrintheer, but RPGs are a dime a dozen, and to make something that’s actually interesting will take quite a bit of time, still.
So, to bridge that gap, I might do some very preliminary work on another project that I’ve had rattling around in my skull for a few months now – JUST to see how it looks in practice.
Well, I’ve overcome the first major hurdle for cave/dungeon lighting. It’s no longer haphazardly sprawled about – it’s now at wall vertices. Next step – put in on the line segments instead and randomize them a bit more.
A couple of the first unique rooms in the game (interestingly this screenshot shows two of the same room – oops!) with lighting from a single torch.
Tiled and Tiled2Unity are both saviors, but neither come without a few major question marks. Interestingly, right now every time I import a new room into my project, I have to reimport the tileset, even though it doesn’t change at all. Not quite sure what’s up with that. But it’s a minor headache.
I’ve switched to a properly top-down perspective player character as well. It’s a place holder with no animation, but it gives a better feel for scope, motion, and lighting. The movement script is a bit weak, and something funky is going down with the rotation of the sprite – sometimes he just rotates eternally for no good reason after coming to a stop. It’s the joy of figuring out these little things that cause development time to increase.
Remember, great ideas don’t always lead to great code. Hell, great code doesn’t even always lead to great code, and first attempt code is rarely great.
Oddly, the thing I found most difficult about this was using Pyxel Edit to actually put the tilesets together. Not that PE was a problem, *I* was a problem. I ended up overwriting some tiles here and there, then creating duplicate tiles as I was moving between the editor and the tile set itself. But, the lesson is learned.
Cave/Dirt Tileset Base
For anyone interested in the process, I started with a “dirt” image from some other tilesets out there, edited it a bit in Photoshop CS4, brought it down to 64px x 64px (since that’s the “unit” size I’m using in Unity) and used that as the base. The darker dirt color was that base. For the lighter dirt, I lightened the tiles or selections from the tiles by +30. For the cave walls I darkened the selections by -70, then ran Photoshop’s Sponge filter with settings of (0, 0, 8).
Beyond the base full dark dirt tile, I mostly worked in a 3×3 grid with a feathered mask that ran from 32px in and over to 160px back and down, making a sort of rounded, feathered area that blended from a midpoint 32 pixels into the edges. This helps ensure that all tiles will fit together nicely and look decent.
For the diagonal tiles, I overlaid opposing corners, used the polygon lasso tool to cut across the opposite diagonal, merged the layers down and BOOM! There’s a diagonal tile.
The sections at the very top center and bottom center are where the three types of terrain blend together. I’m fairly certain that I’m missing a few combinations, but this should be pretty good to start.
For anyone looking to work in tilesets and the like, Pyxel Edit is a GREAT tool. And I think it costs about US$9, so it won’t break the bank.
You must be logged in to post a comment.